- Original Message -
| From: Sven Van Caekenberghe s...@stfx.eu
| To: Pharo-project@lists.gforge.inria.fr
| Cc: dale henrichs dale.henri...@gemtalksystems.com
| Sent: Friday, May 3, 2013 12:39:30 PM
| Subject: Re: [Pharo-project] [ANN] GemStone/S product and team move
If you haven't already heard, the GemStone/S team is becoming an independent
company after 3 years as part of VMware. The entire engineering team is moving
to GemTalk Systems[1].
GemTalk Systems is completely focused on Smalltalk, GemStone/S and allied
initiatives.
I've published a blog
, Dale Henrichs wrote:
| If you haven't already heard, the GemStone/S team is becoming an
| independent company after 3 years as part of VMware. The entire
| engineering team is moving to GemTalk Systems[1].
|
| GemTalk Systems is completely focused on Smalltalk, GemStone/S and allied
Some status:
The Preview is functional (all tests passing:) on GemStone (included in base
for GLASS 1.0-beta.9), Squeak 4.3 through 4.5 (is Squeak4.5 the trunk?) and
Pharo 1.1 through 1.4. Christophe Demarey is helping me port the Metacello
Preview/Metacello Scripting API to Pharo2.0.
For
, at 9:55 PM, stephane ducasse wrote:
|
|
| On Apr 18, 2013, at 6:29 PM, Dale Henrichs dhenr...@vmware.com wrote:
|
| Stef,
|
| I think it is clear that #stable is not the right name, but I also think
| it is better to have one badly named, commonly used symbolic version
| rather than
I've cross-posted to pharo and metacello mailing list ... I'd prefer that the
ongoing (possibly gory discussion:) take place on the metacello list, but since
symbolic versions have been discussed on the pharo list it might make sense to
keep the discussion in the pharo list ...
First a bit of
: Thursday, April 18, 2013 12:57:47 PM
| Subject: Re: [Pharo-project] Metacello configuration conventions
|
|
| On 2013-04-18, at 18:47, Dale Henrichs dhenr...@vmware.com wrote:
|
|
|
| - Original Message -
| | From: Camillo Bruni camillobr...@gmail.com
| | To: Pharo-project
Diego,
You raise some good points here ... In the Metacello Scripting API, I have
added some capabilities that just might fill the bill.
For example you can write the following expression:
Metacello image
configuration: 'MyProject';
version: '1.0.1';
onUpgrade: [:ex | ex deny];
Sean,
When Cami refers to automatic dependencies he's referring to the fact that
with ruby-gems one can specify a range of versions that will satisfy the
dependencies for your project instead of a single version as is done with
Metacello today.
automatic dependencies actually only work (and
Sean,
The Metacello Preview will support semantic versioning system as well as the
current metacello versioning system ... and one will be able to choose on a
project by project basis.
I have all of the version comparison operators implemented for semantic
versioning, but at the time I did
- Original Message -
| From: Camillo Bruni camillobr...@gmail.com
| To: Pharo-project@lists.gforge.inria.fr
| Sent: Tuesday, April 16, 2013 3:19:57 PM
| Subject: Re: [Pharo-project] Metacello configuration conventions
|
| I liked ruby-gems approach more than the one in Metacello. You
Martin,
github pretty much requires a master branch, but it doesn't have to be named
master ... For FileTree where I use the branch per platform approach, the
master branch is where I stash the cherry-picked common code ... then all of
the platform branches can merge at their leisure ... If
Mariano,
I would think that you'd treat the FTP repository like the HTTP repository,
i.e., if you add the repository in the MetacelloBrowser and set the
username/password there, then Metacello should honor that (like it does for the
HTTP repository) ... so instead of adding some sort of
Julian,
FWIW, I have not had the time to port Seaside3.1 to GemStone, yet my plate
has been too full for too long:( ... I intend to take a crack at the port as
soon as I get some free time
Dale
- Original Message -
| From: Julian Fitzell jfitz...@gmail.com
| To: Seaside -
| To: Pharo-project@lists.gforge.inria.fr Development
Pharo-project@lists.gforge.inria.fr
| Cc: Dale Henrichs dhenr...@vmware.com
| Sent: Sunday, March 3, 2013 1:51:18 AM
| Subject: About development on symbolic versions
|
| Hi dale
|
| for pharo 3.0 alpha I want the following setup.
|
| I want
embedded comments
- Original Message -
| From: Christophe Demarey christophe.dema...@inria.fr
| To: Pharo-project@lists.gforge.inria.fr
| Sent: Thursday, February 21, 2013 1:11:49 AM
| Subject: Re: [Pharo-project] Metacello issues on Pharo 2.0
|
| Hi Dale
|
| Sure no problem was tired
I think that the suspendAllWhile: call is important because a) some Metacello
tests are sensitive to packages getting marked dirty or other events getting
triggered ...
- Original Message -
| From: Christophe Demarey christophe.dema...@inria.fr
| To:
Christophe,
I'm not exactly sure what your problem is ...
I have to admit that I haven't kept up with Pharo2.0 since last summer when I
couldn't use Pharo2.0 for development because of OsProcess issues. I know that
recently those issues have been cleared up, but I haven't had the time to
Stef,
I definitely intend to keep supporting Metacello on ALL platforms ...
I have not made any public changes to Metacello since the summer (roughly) so
in one sense I've been ignoring all platforms equally for a while now ...
I am looking forward to porting the Metacello Scripting API work
Stef,
The className: message will be optional with the release of the Metacello
scripting API ... so it _is_ planned.
Dale
- Original Message -
| From: Stéphane Ducasse stephane.duca...@inria.fr
| To: Dale Henrichs dhenr...@vmware.com
| Cc: Pharo-project@lists.gforge.inria.fr
stef,
1.0-beta.32 is the Metacello Scripting API and that is definitely not working
in Pharo 2.0 ... 1.0-beta.31.1.5 from September is the current stable version
of Metacello for all platforms with the exception of Pharo2.0 (which has
already been discussed) ... AFAIK Metacello was
Stef,
AFAIK, this is the first report of any bugs with Metacello since September...
just saying
Dale
- Original Message -
| From: stephane ducasse stephane.duca...@free.fr
| To: Pharo-project@lists.gforge.inria.fr
| Sent: Wednesday, February 20, 2013 11:53:28 AM
| Subject: Re:
Comments embedded below...
- Original Message -
| From: stephane ducasse stephane.duca...@free.fr
| To: Dale Henrichs dhenr...@vmware.com
| Cc: Pharo-project@lists.gforge.inria.fr Development
Pharo-project@lists.gforge.inria.fr
| Sent: Sunday, February 10, 2013 8:01:45 AM
| Subject
+1
- Original Message -
| From: Mariano Martinez Peck marianop...@gmail.com
| To: Pharo-project@lists.gforge.inria.fr
| Cc: Dale Henrichs dhenr...@vmware.com
| Sent: Sunday, February 10, 2013 7:40:53 AM
| Subject: Re: [Pharo-project] About dependency granularity in metacello
|
| On Sun
Metacello does use the package cache, but there _are_ certain specifications
that can force a load from the repository:
1) If a configuration is blessed as #development, the configuration will be
downloaded from the repository when referenced (to ensure that you are picking
up the latest
Stef,
That looks correct.
Dale
- Original Message -
| From: Stéphane Ducasse stephane.duca...@inria.fr
| To: Pharo-project@lists.gforge.inria.fr
| Sent: Thursday, January 24, 2013 6:57:57 AM
| Subject: Re: [Pharo-project] looking for the description of the MC file
package format
Stef,
Over the years I have seen all kinds of weird junk in mcz file names, including
a number with embedded $(.
Presumably that code was put in in self defense against a poorly formed file
name in one of the repositories that Lukas was using:)
Dale
- Original Message -
| From:
Göran,
Regarding sluggish ss3 searches ... you are absolutely right that not a lot of
work has gone into optimizing ss3 for GemStone ... you will note that ss3 is
still ALPHA ... ss3 was put into production as alpha over a year ago because
smalltalkhub wasn't ready for prime time ... the
Cami,
In the old days, the following event was registered:
aSystemChangeNotifier
notify: self ofSystemChangesOfItem: #method change: #Recategorized using:
#methodMoved:
in MCPackageManager classreregisterForNotificationsWith:
So either that event is not being generated by the code or
Sven,
When viewing changes from the Monticello Browser, there are certain
circumstances when the Browser doesn't recognize that the package in a FileTree
repository is an ancestor (I haven't fully characterized this, but I have seen
it happen - I think it usually happens when the package in
- Original Message -
| From: Tudor Girba tu...@tudorgirba.com
| To: pharo-project Pharo-project@lists.gforge.inria.fr
| Sent: Thursday, November 22, 2012 3:15:36 AM
| Subject: Re: [Pharo-project] Metacello Why symbolicversion and not simply
tagged version:?
|
| Hi Dale,
|
|
| I think
Stef,
I'm not sure which context you are talking about ... the symbolic version
#stable can be used as an argument anywhere that the linear version '1.1' can
be used, so I think that it is true that symbolic versions can be used in a
#version: message ...
So I guess I need a little more
Stef,
If you need to leverage the multi-package load, you can do that in Metacello by
using the #atomic loadType in the project method of your configuration:
project
^ project
ifNil: [
Bootstrap Metacello if it is not already loaded
self class
named 'stable'?
|
| Cheers,
| Doru
|
|
| On 21 Nov 2012, at 19:27, Dale Henrichs dhenr...@vmware.com wrote:
|
| Stef,
|
| I'm not sure which context you are talking about ... the symbolic
| version #stable can be used as an argument anywhere that the
| linear version '1.1' can be used, so
| that to provide a flattened configuration version based on what is
| in the image.
|
| Cheers,
| Doru
|
|
|
| On 21 Nov 2012, at 19:33, Dale Henrichs dhenr...@vmware.com wrote:
|
| Stef,
|
| If you need to leverage the multi-package load, you can do that in
| Metacello by using the #atomic
, Dale Henrichs wrote:
|
| Doru,
|
| The loadDirectives structure is the structure that does the actual
| package load for metacello, so extracting the information from the
| loadDirectives is the correct technique for producing a list of
| packages in load order. From a cursory read of Stefs
, at 8:16 PM, Dale Henrichs wrote:
|
| Doru,
|
| I guess because I don't agree that the following statement would be
| true:
|
| there will never be a regular version named 'stable'
|
| I know that in git I can have a branch named 'stable' and a tag
| named 'stable' and that causes
Frank,
With the Metacello Scripting API, I have introduced just the capability you are
looking for. You can specify that a particular project be associated with a
particular repository location for your image and whenever that project is
referenced your local override will be used ...
I
| Sent: Sunday, November 4, 2012 2:27:41 AM
| Subject: Re: [Pharo-project] How to load MetacelloToolbox
|
|
| On Nov 3, 2012, at 8:34 PM, Dale Henrichs dhenr...@vmware.com
| wrote:
|
| Out of curiosity, what are some of the undeclared references?
|
| There shouldn't be any undeclared references
it?
|
| AFAIK I didn't find any reference in the ConfigurationOfMetacello
| but then again I am not particularly at searching :P
|
| On 2012-11-04, at 11:27, Marcus Denker marcus.den...@inria.fr
| wrote:
| On Nov 3, 2012, at 8:34 PM, Dale Henrichs dhenr...@vmware.com
| wrote:
|
| Out
Out of curiosity, what are some of the undeclared references?
There shouldn't be any undeclared references, unless you ignored the required
packages or ??? offhand I can't imagine what they might be...
Dale
- Original Message -
| From: Esteban Lorenzano esteba...@gmail.com
| To:
I think that:
#(#squeakCommon #pharo #'pharo2.x' #'pharo2.0.x')
is the standard pattern. #'pharo2.x' implies that the code is common across the
whole pharo2 family. #'pharo2.0.x' covers the pharo2.0 family.
If you want to explicitly exclude pharo2.1, pharo2.2, etc. and beyond then the
Sven,
I'm not asking about the parser for the literal array but the parser to parse
the literal array itself, but I think you've answered my question (indirectly:)
The original reason for going with JSON 9 months ago was that since GemStone
does not have a accessible parser for Smalltalk
, October 21, 2012 1:25:03 PM
| Subject: Re: [Pharo-project] Parsing Smalltalk Array/Object Literals
|
| On 10/21/2012 08:23 PM, Dale Henrichs wrote:
| Sven,
|
| I'm not asking about the parser for the literal array but the
| parser to parse the literal array itself, but I think you've
| answered
, there are 2 steps:
|
| 1. String - Array Literal
| 2. Object Literal - Object
|
| All in all, its very little code.
|
| Sven
|
| On 21 Oct 2012, at 20:23, Dale Henrichs dhenr...@vmware.com wrote:
|
| Sven,
|
| I'm not asking about the parser for the literal array but the
| parser to parse
...@gmail.com wrote:
| On 20 October 2012 03:48, Dale Henrichs dhenr...@vmware.com
| wrote:
|
|
| - Original Message -
| | From: Igor Stasenko siguc...@gmail.com
| | To: Pharo-project@lists.gforge.inria.fr
| | Sent: Friday, October 19, 2012 4:46:47 PM
| | Subject: Re: [Pharo-project] Yet
- Original Message -
| From: Igor Stasenko siguc...@gmail.com
| To: Pharo-project@lists.gforge.inria.fr
| Sent: Friday, October 19, 2012 8:13:12 PM
| Subject: Re: [Pharo-project] Yet another Notation format: Object literals
|
| On 20 October 2012 03:48, Dale Henrichs dhenr...@vmware.com
Stef,
Yes... the specifications from each section are merged in order to produce the
final set of specifications:
for: #common do: [
spec: 'package' with: [
spec repository: 'http://example.com/repo' ]].
for: #pharo do: [
spec: 'package' with: [
spec file:
Sven,
For some reason I can't see any of the packages in your project on
SmalltalkHub, but I was just curious if your work depends upon a pre-existing
Smalltalk parser or not?
I assume that the JSON issue will come up in a month or two again, so it is
worth knowing the answer ahead of time:)
Igor,
I'm afraid that your notation is not very friendly to humans ... a computer can
keep track of the key value pairs in the literal dictionary, but a human will
fail very quickly...
The appeal of JSON (and STON) is that the output is readable by mere mortals:
(JavaScript Object Notation)
.
|
| Sven
|
| BTW: Is the # in front of Symbols needed ?
|
| On 19 Oct 2012, at 16:55, Dale Henrichs dhenr...@vmware.com wrote:
|
| Igor,
|
| I'm afraid that your notation is not very friendly to humans ... a
| computer can keep track of the key value pairs in the literal
| dictionary, but a human
)... YAML appears to be the format of choice when humans and computers
need to share the data file and would be not only work across dialects...
Dale
[1] http://www.yaml.org/
- Original Message -
| From: Dale Henrichs dhenr...@vmware.com
| To: Pharo-project@lists.gforge.inria.fr
| Sent: Friday
| Subject: Re: [Pharo-project] Yet another Notation format: Object literals
|
| On 19 October 2012 16:55, Dale Henrichs dhenr...@vmware.com wrote:
| Igor,
|
| I'm afraid that your notation is not very friendly to humans ... a
| computer can keep track of the key value pairs in the literal
: [Pharo-project] Yet another Notation format: Object literals
|
| On 19 October 2012 18:33, Dale Henrichs dhenr...@vmware.com wrote:
| Igor,
|
| you can do anything you like ... you mean like choosing to use
| STON and not invent my own notation format?
|
| STON is a perfectly good notation
@lists.gforge.inria.fr
| | Sent: Friday, October 19, 2012 9:10:26 AM
| | Subject: Re: [Pharo-project] Yet another Notation format: Object
| | literals
| |
| | On 19 October 2012 16:55, Dale Henrichs dhenr...@vmware.com
| | wrote:
| | Igor,
| |
| | I'm afraid that your notation is not very friendly to humans
October 2012 18:47, Dale Henrichs dhenr...@vmware.com wrote:
| Igor,
|
| But my aims is slightly different. and so are mine ...
|
| I think that we can agree on this point and move on...
|
| :)
|
| i cannot agree on one point: JSON is harder to read to me, comparing
| to smalltalk literal
- Original Message -
| From: Stéphane Ducasse stephane.duca...@inria.fr
| To: Pharo Development Pharo-project@lists.gforge.inria.fr
| Sent: Friday, October 19, 2012 1:51:38 PM
| Subject: [Pharo-project] Group metacello question
|
| Hi dale
|
| Q1:
| can I have
| group: 'Pharo'
|
Message -
| From: Eliot Miranda eliot.mira...@gmail.com
| To: Pharo-project@lists.gforge.inria.fr
| Sent: Friday, October 19, 2012 2:07:28 PM
| Subject: Re: [Pharo-project] Yet another Notation format: Object literals
|
| HI Dale, Hi Igor,
|
|
| On Fri, Oct 19, 2012 at 9:33 AM, Dale Henrichs
| Subject: Re: [Pharo-project] Yet another Notation format: Object literals
|
|
|
|
| On Fri, Oct 19, 2012 at 2:42 PM, Dale Henrichs dhenr...@vmware.com
| wrote:
|
|
| Eliot,
|
| STON (and JSON IIRC) allows either $ or $' as string literal
| delimiters, so I am not holding onto the $ as a key
Message -
| From: Igor Stasenko siguc...@gmail.com
| To: Pharo-project@lists.gforge.inria.fr
| Sent: Friday, October 19, 2012 2:11:37 PM
| Subject: Re: [Pharo-project] Yet another Notation format: Object literals
|
| On 19 October 2012 22:15, Dale Henrichs dhenr...@vmware.com wrote:
| Igor
- Original Message -
| From: Igor Stasenko siguc...@gmail.com
| To: Pharo-project@lists.gforge.inria.fr
| Sent: Friday, October 19, 2012 4:09:18 PM
| Subject: Re: [Pharo-project] Yet another Notation format: Object literals
|
| On 20 October 2012 00:26, Dale Henrichs dhenr...@vmware.com
- Original Message -
| From: Igor Stasenko siguc...@gmail.com
| To: Pharo-project@lists.gforge.inria.fr
| Sent: Friday, October 19, 2012 4:46:47 PM
| Subject: Re: [Pharo-project] Yet another Notation format: Object literals
|
| On 20 October 2012 00:54, Dale Henrichs dhenr...@vmware.com
Stephan,
You should be able to use FileTree[1] to export data from Pharo and then use
STIG[2] to import the data into VW ... I would use git to manage the repository
and create a VW branch to manage your VW-specific changes ... you will likely
need to hand massage the code base to get it to
:)
- Original Message -
| From: Henrik Sperre Johansen henrik.s.johan...@veloxit.no
| To: Pharo-project@lists.gforge.inria.fr
| Sent: Tuesday, October 2, 2012 1:10:11 AM
| Subject: Re: [Pharo-project] [Another sad day] a nice example of the mess
with json in FileTree
|
| On 01.10.2012
imagine a lot more of them/
| If you had ideas just send them.
|
| Stef
|
|
| On Oct 1, 2012, at 11:54 PM, Dale Henrichs wrote:
|
| Not sure whether or not these are doable with Slime, but they are
| good ideas
|
| Dale
|
| - Original Message -
| | From: Alexandre Bergel
- Original Message -
| From: Stéphane Ducasse stephane.duca...@inria.fr
| To: Pharo-project@lists.gforge.inria.fr
| Sent: Sunday, September 30, 2012 11:25:28 PM
| Subject: Re: [Pharo-project] Metacello bleedingEdge question
|
| OK
| so we should not talk about it anymore and ban it from
Stef,
I forgot to share with you that at this last ESUG we (Jan Vrany, Martin Kobetic
and myself) agreed that the next version of Filetree will use .ston files
instead of .json files. I am planning on writing a blog post on
this...eventually.
The Smalltalk/X implementation (Jan Vrany) is
- Original Message -
| From: Stéphane Ducasse stephane.duca...@inria.fr
| To: Pharo-project@lists.gforge.inria.fr
| Sent: Monday, October 1, 2012 12:26:25 PM
| Subject: Re: [Pharo-project] Metacello bleedingEdge question
|
| | It would be good to have specific rules for configurations.
The methodProperties.json file is a stopgap until we have proper integration
with git...it will eventually go away...
Dale
- Original Message -
| From: Frank Shearar frank.shea...@gmail.com
| To: Pharo-project@lists.gforge.inria.fr
| Sent: Monday, October 1, 2012 12:55:50 PM
| Subject:
- Original Message -
| From: Tudor Girba tu...@tudorgirba.com
| To: Pharo-project@lists.gforge.inria.fr
| Sent: Monday, October 1, 2012 1:22:41 PM
| Subject: Re: [Pharo-project] [Another sad day] a nice example of the mess
with json in FileTree
|
| Hi,
|
| I like the project, but I
Not sure whether or not these are doable with Slime, but they are good ideas
Dale
- Original Message -
| From: Alexandre Bergel alexandre.ber...@me.com
| To: Pharo-project@lists.gforge.inria.fr
| Sent: Monday, October 1, 2012 1:30:44 PM
| Subject: Re: [Pharo-project] Metacello
| To: Pharo-project@lists.gforge.inria.fr
| Sent: Saturday, September 29, 2012 1:02:17 PM
| Subject: Re: [Pharo-project] Metacello bleedingEdge question
|
|
| On 29 Sep 2012, at 21:38, Stéphane Ducasse
| stephane.duca...@inria.fr wrote:
|
| On Sep 29, 2012, at 5:39 PM, Dale Henrichs wrote:
|
| Stef
, September 28, 2012 11:37:30 AM
| Subject: Re: [Pharo-project] Metacello bleedingEdge question
|
| dale
|
| at the end do we really need latestVersion because I'm still confused
| by it.
|
| On Sep 28, 2012, at 3:42 PM, Dale Henrichs wrote:
|
| #latestVersion is defined as the latest version
- Original Message -
| From: Mariano Martinez Peck marianop...@gmail.com
| To: Pharo-project@lists.gforge.inria.fr
| Sent: Friday, September 28, 2012 12:59:46 AM
| Subject: Re: [Pharo-project] Metacello bleedingEdge question
|
|
|
|
| On Thu, Sep 27, 2012 at 6:46 PM, Dale Henrichs
Yes, `Metacello-Platform.pharo-dale.15` indicates that the package is on the
`pharo` branch of the `Metacello-Platform` package.
See GoferVersionReferenceparseName: for parsing rules.
Dale
- Original Message -
| From: Stéphane Ducasse stephane.duca...@inria.fr
| To:
Sven,
The versions in ConfigurationOfZTimestamp aren't quite defined correctly ...
bleedingEdge defaults to loading the latest baseline version. A baseline
version is declared by setting the blessing to #baseline:
spec blessing: #baseline.
Your versions in ConfigurationOfZTimestamp are
:36 AM
| Subject: Re: [Pharo-project] OSProcess ... ported to 2.0?
|
|
| On 2012-09-25, at 18:59, Dale Henrichs dhenr...@vmware.com wrote:
|
| Cami,
|
| Your code seems to have conflicts with the implementation of
| FileSystem in Pharo-2.0 ... besides overriding a number of methods
| (most
Thanks Cami...
Dale
- Original Message -
| From: Camillo Bruni camillobr...@gmail.com
| To: Pharo-project@lists.gforge.inria.fr
| Sent: Monday, September 24, 2012 11:23:35 PM
| Subject: Re: [Pharo-project] OSProcess ... ported to 2.0?
|
|
| On 2012-09-25, at 01:11, Dale Henrichs dhenr
outdated ...
Dale
- Original Message -
| From: Camillo Bruni camillobr...@gmail.com
| To: Pharo-project@lists.gforge.inria.fr
| Sent: Monday, September 24, 2012 11:23:35 PM
| Subject: Re: [Pharo-project] OSProcess ... ported to 2.0?
|
|
| On 2012-09-25, at 01:11, Dale Henrichs dhenr
As I take yet another stab at getting the Metacello Preview running on
Pharo2.0, I find that OSProcess is sprinkled with references to FileDirectory
... at least in the packages referenced by the configuration, so I'm wondering
if a port exists for Phar0-2.0 ... At the moment OSProcess is a
The site is up and running and we have had no alerts from our data center so
there must be something else going on if you are having trouble accessing the
site ...
Dale
- Original Message -
| From: Usman Bhatti usman.bha...@gmail.com
| To: Pharo-project@lists.gforge.inria.fr
| Sent:
FWIW, Gofer Project Loader was loaded by default in GemStone and the GemStone
load expressions on the glassdb site used it:)
Dale
- Original Message -
| From: Tobias Pape das.li...@gmx.de
| To: Pharo-project@lists.gforge.inria.fr
| Sent: Wednesday, September 19, 2012 12:48:13 AM
|
The new Metacello Scripting API[1] does exactly that and more:
Metacello new
configuration: 'NativeBoost';
squeaksource: 'NativeBoost';
load.
does what you want ... there are additional shortcuts that you can use once you
have a project loading in your image ... I am looking for some
Cami,
What kind of work needs to be done for the Cypress-compatible format? I've done
a couple of different implementations already:) So I can definitely do one more
... If you give me the name of the class that is the entry point for read/write
then I can take it from there ...
Metacello
: Re: [Pharo-project] git support
|
|
| On 2012-09-07, at 15:13, Dale Henrichs dhenr...@vmware.com wrote:
| Cami,
|
| What kind of work needs to be done for the Cypress-compatible
| format? I've done a couple of different implementations already:)
| So I can definitely do one more ... If you
and 2.0 as long as you manually backport the newest
| filesystem packages (I've got both images on my machine and it works
| fine).
|
|
| On 07.09.2012, at 15:32, Camillo Bruni camillobr...@gmail.com
| wrote:
|
| On 2012-09-07, at 15:29, Dale Henrichs dhenr...@vmware.com wrote:
| Does FsGit run
I am poised for getting the Metacello Preview running in Pharo2.0, but there
are a couple of stability issues that are outstanding at the moment, but I
believe Esteban and co. will hit that hard this week...
Dale
- Original Message -
| From: Igor Stasenko siguc...@gmail.com
| To:
Thanks Alexander ... I've submitted an issue[1] to have the wlecome page
updated...
Dale
[1] http://code.google.com/p/squeaksource3/issues/detail?id=98
- Original Message -
| From: Alexandre Bergel alexandre.ber...@me.com
| To: Pharo-project@lists.gforge.inria.fr open-source Smalltalk
: Re: [Pharo-project] Pharo 2.0 + Travis = ?
|
| yeah, we are working on that... but there are still some RPackage
| issues non completely handled :(
|
| I suppose for week-end we'll be back in a stable stage :)
|
| Esteban
|
| On Sep 5, 2012, at 7:20 PM, Dale Henrichs dhenr...@vmware.com
| wrote
:
| On 22 August 2012 21:08, Dale Henrichs dhenr...@vmware.com wrote:
|
|
| - Original Message -
| | From: Frank Shearar frank.shea...@gmail.com
| | To: Pharo-project@lists.gforge.inria.fr
| | Sent: Wednesday, August 22, 2012 11:56:12 AM
| | Subject: Re: [Pharo-project] latam mirror down
- Original Message -
| From: Frank Shearar frank.shea...@gmail.com
| To: Pharo-project@lists.gforge.inria.fr
| Sent: Wednesday, September 5, 2012 1:41:00 PM
| Subject: Re: [Pharo-project] latam mirror down?
|
| On 5 September 2012 19:18, Dale Henrichs dhenr...@vmware.com wrote:
| Frank
Frank,
I'll try to get the Pharo-2.0 build for builderCI working soon ...
Dale
- Original Message -
| From: Frank Shearar frank.shea...@gmail.com
| To: Pharo Development pharo-project@lists.gforge.inria.fr
| Cc: Dale Henrichs dhenr...@vmware.com
| Sent: Thursday, August 30, 2012 1:52:37
I'm running a headless pharo2.0 from a script and the vm disappears without a
trace (no pharodebug.log info etc.) ... when I run the script in a gui, I see
that a warning dialog box is popping up, so perhaps this is the source of the
issue? ... or perhaps it's something else?
Dale
Message -
| From: Frank Shearar frank.shea...@gmail.com
| To: Pharo-project@lists.gforge.inria.fr
| Sent: Wednesday, August 22, 2012 12:54:15 AM
| Subject: Re: [Pharo-project] latam mirror down?
|
| On 21 August 2012 22:20, Dale Henrichs dhenr...@vmware.com wrote:
| http://www.dsal.cl
-
| From: Frank Shearar frank.shea...@gmail.com
| To: Pharo-project@lists.gforge.inria.fr
| Sent: Wednesday, August 22, 2012 8:02:31 AM
| Subject: Re: [Pharo-project] latam mirror down?
|
| On 22 August 2012 15:16, Dale Henrichs dhenr...@vmware.com wrote:
| Yes, it's the travis builds ... It's more than
- Original Message -
| From: Frank Shearar frank.shea...@gmail.com
|
| Sorry, I wasn't clear - I meant precisely that it wasn't a Metacello
| ConfigurationOf's responsibility to find something, but just to name
| parts. _My particular_ setup might say try local cache, then SS,
| then
|
- Original Message -
| From: Frank Shearar frank.shea...@gmail.com
| To: Pharo-project@lists.gforge.inria.fr
| Sent: Wednesday, August 22, 2012 11:56:12 AM
| Subject: Re: [Pharo-project] latam mirror down?
|
| On 22 August 2012 19:33, Dale Henrichs dhenr...@vmware.com wrote:
| Frank
Cami,
(ConfigurationOfMetacello project version: #stable)
load: #('batch' 'Metacello-ToolBox')
Should do the trick the 'batch' group is loaded when you bootstrap
Metacello (which brings in the absolute minimum for loading packages)...
Dale
- Original Message -
| From:
| To: Pharo-project@lists.gforge.inria.fr
| Sent: Friday, August 10, 2012 1:56:37 AM
| Subject: Re: [Pharo-project] FileDirectory FSFileSystem
|
|
| On 2012-08-10, at 01:10, Dale Henrichs dhenr...@vmware.com wrote:
|
| Cami,
|
| If you can let me know where to find your new FS code, I can take
@lists.gforge.inria.fr
| Sent: Friday, August 10, 2012 1:56:37 AM
| Subject: Re: [Pharo-project] FileDirectory FSFileSystem
|
|
| On 2012-08-10, at 01:10, Dale Henrichs dhenr...@vmware.com wrote:
|
| Cami,
|
| If you can let me know where to find your new FS code, I can take
| it for a spin
1 - 100 of 704 matches
Mail list logo
