Re: [Pharo-project] In Latest OB I cannot add a class variable
This works for me.
'superclassName' is the superclass name, but contains the definition
which should be in the variable 'definition'.
Looks like you need to recompile your image, the instance variable
indexes seem to be messed up.
Another bug I noticed in the ClassBuilder is that existing instances
cannot be migrated if the old or the new class are subclasses of nil
or ProtoObject, because #instVarAt: is then missing.
Lukas
2010/10/2 Mariano Martinez Peck :
>
>
> On Sat, Oct 2, 2010 at 8:02 PM, Lukas Renggli wrote:
>>
>> It works for me, are you sure to use the latest code?
>
> yep.
>
> I tried to evaluate:
>
> ProtoObject subclass: #RBSemanticTest
> instanceVariableNames: 'instVar'
> classVariableNames: 'ClassVar'
> poolDictionaries: ''
> category: 'AST-Tests-Semantic'
>
>
> and got an error in
>
> AddClassChange >> definitionClass
> ^ Smalltalk globals at: (self superclassName ifNil: [ ^ ProtoObject ])
>
> since self superclassName answers:
>
> a Text for 'ProtoObject subclass: #RBSemanticTest
> instanceVariableNames: ''instVar''
> classVariableNames: ''ClassVar''
> poolDictionaries:
> category: ''AST-Tests-Semantic'''
>
>
> weird
>
> thanks
>
> mariano
>
>>
>> 2010/10/2 Mariano Martinez Peck :
>> >
>> >
>> > On Sat, Oct 2, 2010 at 1:54 PM, Lukas Renggli wrote:
>> >>
>> >> Ok, I fixed that. The refactoring engine now supports all the 24 (!!!)
>> >> distinct patterns of defining a subclass/trait in Pharo (see below).
>> >>
>> >> Name: Refactoring-Changes-lr.15
>> >> Author: lr
>> >> Time: 2 October 2010, 1:50:13 pm
>> >> UUID: 82093dfb-e7f2-4ff7-afe7-ac7196632196
>> >> Ancestors: Refactoring-Changes-lr.14
>> >>
>> >> - also support subclasses of nil
>> >>
>> >
>> > Hi Lukas. I tried with nil and it works. However, putting ProtoObject,
>> > it
>> > didn't, since
>> >
>> > definitionClass
>> > ^ Smalltalk globals at: (self superclassName ifNil: [ ^ ProtoObject
>> > ])
>> >
>> > self superclassName answers
>> >
>> > a Text for 'ProtoObject variableSubclass: #MessageCatchingProxy
>> > instanceVariableNames:
>> > classVariableNames:
>> > poolDictionaries:
>> > category: ''Proxies'''
>> >
>> > Cheers
>> >
>> > Mariano
>> >
>> >
>> >>
>> >> The undo operation of the respective actions should work as well. The
>> >> exception here is an asymmetry (bug?) in the Pharo class definition
>> >> strings that causes classes without traits to be printed without the
>> >> #uses: claus. Evaluating this definition string does not remove the
>> >> trait composition if the class happens to have one though.
>> >>
>> >> Lukas
>> >>
>> >> #('`className class instanceVariableNames: `#instanceVariableNames'
>> >> '`className class uses: `...@traitcomposition instanceVariableNames:
>> >> `#instanceVariableNames' '`...@superclass subclass: `#className
>> >> instanceVariableNames: `#instanceVariableNames classVariableNames:
>> >> `#classVariableNames poolDictionaries: `#poolDictionaries category:
>> >> `#category' 'ProtoObject subclass: `#className instanceVariableNames:
>> >> `#instanceVariableNames classVariableNames: `#classVariableNames
>> >> poolDictionaries: `#poolDictionaries category: `#category. `className
>> >> superclass: `...@superclass' '`...@superclass subclass: `#className uses:
>> >> `...@traitcomposition instanceVariableNames: `#instanceVariableNames
>> >> classVariableNames: `#classVariableNames poolDictionaries:
>> >> `#poolDictionaries category: `#category' 'ProtoObject subclass:
>> >> `#className uses: `...@traitcomposition instanceVariableNames:
>> >> `#instanceVariableNames classVariableNames: `#classVariableNames
>> >> poolDictionaries: `#poolDictionaries category: `#category. `className
>> >> superclass: `...@superclass' '`...@superclass variableByteSubclass:
>> >> `#className instanceVariableNames: `#instanceVariableNames
>> >> classVariableNames: `#classVariableNames poolDictionaries:
>> >> `#poolDictionaries category: `#category' 'ProtoObject
>> >> variableByteSubclass: `#className instanceVariableNames:
>> >> `#instanceVariableNames classVariableNames: `#classVariableNames
>> >> poolDictionaries: `#poolDictionaries category: `#category. `className
>> >> superclass: `...@superclass' '`...@superclass variableByteSubclass:
>> >> `#className uses: `...@traitcomposition instanceVariableNames:
>> >> `#instanceVariableNames classVariableNames: `#classVariableNames
>> >> poolDictionaries: `#poolDictionaries category: `#category'
>> >> 'ProtoObject variableByteSubclass: `#className uses:
>> >> `...@traitcomposition instanceVariableNames: `#instanceVariableNames
>> >> classVariableNames: `#classVariableNames poolDictionaries:
>> >> `#poolDictionaries category: `#category. `className superclass:
>> >> `...@superclass' '`...@superclass variableSubclass: `#className
>> >> instanceVariableNames: `#instanceVariableNames classVariableNames:
>> >> `#classVariableNames poolDictionaries: `#poolDictionaries category:
>> >> `#cate
Re: [Pharo-project] XMLRPC project on Squeaksource is MIT
Thanks Germán, Markus and Christian. On 1 oct. 2010, at 15:43, Germán Arduino wrote: > Hi Guys: > > Attached the agreement of the authors of current XMLRPC code on > Squeaksource to make it MIT. > > Thanks Markus and Christian. > > > > > -- From Markus -- > From: Markus Fritsche > Date: 2010/10/1 > Subject: Re: About the XMLRPC project on Squeaksource > To: Germán Arduino > > > Hello Germán, > as far as I am concerned, I am happy to release my code under MIT license. > > I hope it will be well adapted to recent developments happening around > Smalltalk & Pharo! > > Kind regards, > Markus (aka maf) > > 2010/9/22 Germán Arduino >> >> Hi Markus, Christian, César: >> >> I asked previously about the xmlrpc code on Squeaksource of each one >> of you and all agreed on release it as public domain. >> >> I need now (sorry by the bothering) your agreement that all your code >> on this repo XMLRPC is MIT licensed. Then I will send your responses >> to the pharo list to the system keeps track on that. >> >> Thanks Again! >> >> Germán. > > > > -- From Christian -- > 2010/9/22 Christian Langreiter : >> Hello Germán, >> >>> I need now (sorry by the bothering) your agreement that all your code >>> on this repo XMLRPC is MIT licensed. Then I will send your responses >>> to the pharo list to the system keeps track on that. >> >> no objections from my side. >> >> Best regards, >> -- Chris > > ___ > Pharo-project mailing list > Pharo-project@lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
[Pharo-project] Less plugins, more Smalltalk code! (was: Re: Pharo 1.1.1 OneClickCogVm)
On 30 sept. 2010, at 20:22, Germán Arduino wrote: > 2010/9/30 Sven Van Caekenberghe : >> >> Less plugins, more Smalltalk code! >> I want to look at everything and never see C. >> Plugins/primitives should only be there when they are absolutely necessary >> (to access a platform feature or for crucial performance). >> >> Sven >> > > +1 > Yes. This is the approach we advocate in the Ocean project. We would like to see it generalized beyond the network library. Noury ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] In Latest OB I cannot add a class variable
On Sun, Oct 3, 2010 at 9:31 AM, Lukas Renggli wrote:
> This works for me.
>
> 'superclassName' is the superclass name, but contains the definition
> which should be in the variable 'definition'.
>
> Looks like you need to recompile your image, the instance variable
> indexes seem to be messed up.
>
Thanks Lukas, indeed, evaluating a Compiler recompileAll was the trick to
make it work.
>
> Another bug I noticed in the ClassBuilder is that existing instances
> cannot be migrated if the old or the new class are subclasses of nil
> or ProtoObject, because #instVarAt: is then missing.
>
Yes, I saw this also. I had some proxies that extended from ProtoObject,
then I wanted them to extend from Object...
thanks!
mariano
>
> Lukas
>
> 2010/10/2 Mariano Martinez Peck :
> >
> >
> > On Sat, Oct 2, 2010 at 8:02 PM, Lukas Renggli wrote:
> >>
> >> It works for me, are you sure to use the latest code?
> >
> > yep.
> >
> > I tried to evaluate:
> >
> > ProtoObject subclass: #RBSemanticTest
> > instanceVariableNames: 'instVar'
> > classVariableNames: 'ClassVar'
> > poolDictionaries: ''
> > category: 'AST-Tests-Semantic'
> >
> >
> > and got an error in
> >
> > AddClassChange >> definitionClass
> > ^ Smalltalk globals at: (self superclassName ifNil: [ ^ ProtoObject
> ])
> >
> > since self superclassName answers:
> >
> > a Text for 'ProtoObject subclass: #RBSemanticTest
> > instanceVariableNames: ''instVar''
> > classVariableNames: ''ClassVar''
> > poolDictionaries:
> > category: ''AST-Tests-Semantic'''
> >
> >
> > weird
> >
> > thanks
> >
> > mariano
> >
> >>
> >> 2010/10/2 Mariano Martinez Peck :
> >> >
> >> >
> >> > On Sat, Oct 2, 2010 at 1:54 PM, Lukas Renggli
> wrote:
> >> >>
> >> >> Ok, I fixed that. The refactoring engine now supports all the 24
> (!!!)
> >> >> distinct patterns of defining a subclass/trait in Pharo (see below).
> >> >>
> >> >> Name: Refactoring-Changes-lr.15
> >> >> Author: lr
> >> >> Time: 2 October 2010, 1:50:13 pm
> >> >> UUID: 82093dfb-e7f2-4ff7-afe7-ac7196632196
> >> >> Ancestors: Refactoring-Changes-lr.14
> >> >>
> >> >> - also support subclasses of nil
> >> >>
> >> >
> >> > Hi Lukas. I tried with nil and it works. However, putting ProtoObject,
> >> > it
> >> > didn't, since
> >> >
> >> > definitionClass
> >> > ^ Smalltalk globals at: (self superclassName ifNil: [ ^
> ProtoObject
> >> > ])
> >> >
> >> > self superclassName answers
> >> >
> >> > a Text for 'ProtoObject variableSubclass: #MessageCatchingProxy
> >> > instanceVariableNames:
> >> > classVariableNames:
> >> > poolDictionaries:
> >> > category: ''Proxies'''
> >> >
> >> > Cheers
> >> >
> >> > Mariano
> >> >
> >> >
> >> >>
> >> >> The undo operation of the respective actions should work as well. The
> >> >> exception here is an asymmetry (bug?) in the Pharo class definition
> >> >> strings that causes classes without traits to be printed without the
> >> >> #uses: claus. Evaluating this definition string does not remove the
> >> >> trait composition if the class happens to have one though.
> >> >>
> >> >> Lukas
> >> >>
> >> >> #('`className class instanceVariableNames: `#instanceVariableNames'
> >> >> '`className class uses: `...@traitcomposition instanceVariableNames:
> >> >> `#instanceVariableNames' '`...@superclass subclass: `#className
> >> >> instanceVariableNames: `#instanceVariableNames classVariableNames:
> >> >> `#classVariableNames poolDictionaries: `#poolDictionaries category:
> >> >> `#category' 'ProtoObject subclass: `#className instanceVariableNames:
> >> >> `#instanceVariableNames classVariableNames: `#classVariableNames
> >> >> poolDictionaries: `#poolDictionaries category: `#category. `className
> >> >> superclass: `...@superclass' '`...@superclass subclass: `#className
> >> >> uses:
> >> >> `...@traitcomposition instanceVariableNames: `#instanceVariableNames
> >> >> classVariableNames: `#classVariableNames poolDictionaries:
> >> >> `#poolDictionaries category: `#category' 'ProtoObject subclass:
> >> >> `#className uses: `...@traitcomposition instanceVariableNames:
> >> >> `#instanceVariableNames classVariableNames: `#classVariableNames
> >> >> poolDictionaries: `#poolDictionaries category: `#category. `className
> >> >> superclass: `...@superclass' '`...@superclass variableByteSubclass:
> >> >> `#className instanceVariableNames: `#instanceVariableNames
> >> >> classVariableNames: `#classVariableNames poolDictionaries:
> >> >> `#poolDictionaries category: `#category' 'ProtoObject
> >> >> variableByteSubclass: `#className instanceVariableNames:
> >> >> `#instanceVariableNames classVariableNames: `#classVariableNames
> >> >> poolDictionaries: `#poolDictionaries category: `#category. `className
> >> >> superclass: `...@superclass' '`...@superclass variableByteSubclass:
> >> >> `#className uses: `...@traitcomposition instanceVariableNames:
> >> >> `#instanceVariableNames classVariableNames: `#classVariableNames
> >> >> poolD
Re: [Pharo-project] Less plugins, more Smalltalk code! (was: Re: Pharo 1.1.1 OneClickCogVm)
you should read the recurrent thread in the vm list, some of you may be concerned :) Stef >>> Less plugins, more Smalltalk code! >>> I want to look at everything and never see C. >>> Plugins/primitives should only be there when they are absolutely necessary >>> (to access a platform feature or for crucial performance). >>> >>> Sven >>> >> >> +1 >> > Yes. This is the approach we advocate in the Ocean project. > We would like to see it generalized beyond the network library. > > Noury > > > ___ > Pharo-project mailing list > Pharo-project@lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Another fixes to finalization (was Re: [update 1.2] #12161 - #12172)
On 03.10.2010 05:47, Igor Stasenko wrote: On 3 October 2010 03:13, Henrik Sperre Johansen wrote: On 02.10.2010 19:01, Igor Stasenko wrote: On 2 October 2010 19:47, Stéphane Ducasse wrote: Hi igor do you understand why the previous definition was cachedDefinitions Definitions ifNil: [Definitions := WeakIdentityKeyDictionary new. WeakArray addWeakDependent: Definitions]. ^ Definitions i don't. :) It just a way to free memory as fast as possible. But its really not worth spending so much CPU in order to save few bytes of memory. Without registering the dict for finalization, the values won't ever be removed with the current implementation. They are removed. After each package load/unload operation. I don't see a reason to do this more often. If they are removed explicitly, then yes. But then again, if that's the case, why use a weak dictionary in the first place? Which can be somewhat hampering to performance once you have lots of nil-keyed elements all stashed from index 1 and onwards after a rehash. In Pharo, weak dict knows how to reuse expired associations: And when do they expire? Only when they are either finalized, or removed explicitly. So if you do neither, they will stay indefinately without being removed/reused. Cheers, Henry ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Another fixes to finalization (was Re: [update 1.2] #12161 - #12172)
On 3 October 2010 12:36, Henrik Sperre Johansen wrote: > On 03.10.2010 05:47, Igor Stasenko wrote: >> >> On 3 October 2010 03:13, Henrik Sperre Johansen >> wrote: >>> >>> On 02.10.2010 19:01, Igor Stasenko wrote: On 2 October 2010 19:47, Stéphane Ducasse wrote: > > Hi igor > > do you understand why the previous definition was > > cachedDefinitions > Definitions ifNil: [Definitions := WeakIdentityKeyDictionary > new. > WeakArray addWeakDependent: Definitions]. > ^ Definitions > i don't. :) It just a way to free memory as fast as possible. But its really not worth spending so much CPU in order to save few bytes of memory. >>> >>> Without registering the dict for finalization, the values won't ever be >>> removed with the current implementation. >> >> They are removed. After each package load/unload operation. >> I don't see a reason to do this more often. > > If they are removed explicitly, then yes. But then again, if that's the > case, why use a weak dictionary in the first place? i don't know much about MC to tell for sure. >>> >>> Which can be somewhat hampering to performance once you have lots of >>> nil-keyed elements all stashed from index 1 and onwards after a rehash. >>> >> In Pharo, weak dict knows how to reuse expired associations: >> > And when do they expire? Only when they are either finalized, or removed > explicitly. > So if you do neither, they will stay indefinately without being > removed/reused. no. they expiring when key become nil. > > Cheers, > Henry > > ___ > Pharo-project mailing list > Pharo-project@lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- Best regards, Igor Stasenko AKA sig. ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Another fixes to finalization (was Re: [update 1.2] #12161 - #12172)
On 03.10.2010 11:59, Igor Stasenko wrote: On 3 October 2010 12:36, Henrik Sperre Johansen wrote: On 03.10.2010 05:47, Igor Stasenko wrote: On 3 October 2010 03:13, Henrik Sperre Johansen wrote: On 02.10.2010 19:01, Igor Stasenko wrote: On 2 October 2010 19:47, Stéphane Ducasse wrote: Hi igor do you understand why the previous definition was cachedDefinitions Definitions ifNil: [Definitions := WeakIdentityKeyDictionary new. WeakArray addWeakDependent: Definitions]. ^ Definitions i don't. :) It just a way to free memory as fast as possible. But its really not worth spending so much CPU in order to save few bytes of memory. Without registering the dict for finalization, the values won't ever be removed with the current implementation. They are removed. After each package load/unload operation. I don't see a reason to do this more often. If they are removed explicitly, then yes. But then again, if that's the case, why use a weak dictionary in the first place? i don't know much about MC to tell for sure. Which can be somewhat hampering to performance once you have lots of nil-keyed elements all stashed from index 1 and onwards after a rehash. In Pharo, weak dict knows how to reuse expired associations: And when do they expire? Only when they are either finalized, or removed explicitly. So if you do neither, they will stay indefinately without being removed/reused. no. they expiring when key become nil. You'd think so, yes. However, see implementor of WeakKeyAssociation>>#expired, and senders of #expire. Cheers, Henry ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
[Pharo-project] [update 1.2] #12168
12168 - - Issue 3043:Refactor SystemOrganizer to decouple it from Smalltalk. Thanks Nicolas Paez and Damien Pollet. - Issue 3027: Base64MimeConverterTest>>#testOnByteArray raise an error. Thanks Cyrille Delaunay Stef ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Less plugins, more Smalltalk code! (was: Re: Pharo 1.1.1 OneClickCogVm)
For Ocean to succeed, you either have to work really hard to make non-blocking calls (I'm thinking of SSL sockets), or you need the ability to call functions on OS threads. The calls need to block their calling Process and let the other Processes run as though nothing is happening. From: pharo-project-boun...@lists.gforge.inria.fr [pharo-project-boun...@lists.gforge.inria.fr] On Behalf Of Noury Bouraqadi [bouraq...@gmail.com] Sent: Sunday, October 03, 2010 4:57 AM To: Pharo-project@lists.gforge.inria.fr Subject: [Pharo-project] Less plugins, more Smalltalk code! (was: Re: Pharo 1.1.1 OneClickCogVm) On 30 sept. 2010, at 20:22, Germán Arduino wrote: > 2010/9/30 Sven Van Caekenberghe : >> >> Less plugins, more Smalltalk code! >> I want to look at everything and never see C. >> Plugins/primitives should only be there when they are absolutely necessary >> (to access a platform feature or for crucial performance). >> >> Sven >> > > +1 > Yes. This is the approach we advocate in the Ocean project. We would like to see it generalized beyond the network library. Noury ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] XMLRPC Project - Progress Report
Started working on the tests, the current Encoder/Decoder (at client
level) works ok.
For example, I opened an account on http://snipplr.com (to save useful
and interesting Smalltalk snippets) and can connect without problems.
Next, some examples:
| url proxy r |
url := Url absoluteFromText: 'http://snipplr.com/xml-rpc.php'.
proxy := XMLRPCProxy new url: url.
r := proxy invokeMethod: 'languages.list' withArgs: #('Your snipplr key').
r := proxy invokeMethod: 'user.checkkey' withArgs: #('Your snipplr key').
r := proxy invokeMethod: 'snippet.list' withArgs: #('Your snipplr key' 'pharo').
"To get a snippet you don't need key, but the Snippet ID"
r := proxy invokeMethod: 'snippet.get' withArgs: #('41365').
The complete Snipplr xmlrpc API is on:
http://snipplr.com/blog/2006/07/06/snipplr-api/
Next step is check the complete API specification
(http://www.xmlrpc.com/spec.) to implement all the features at client
level.
As usual, any comment, suggestion or criticism is more than welcome.
Cheers.
2010/9/23 Germán Arduino :
> ok, ConfigurationOfXMLRPC is on MetacelloRepository, documentation on
> #workspace method.
>
> Suggestions or corrections from the Metacello experts are more than welcome.
>
> Next Step: The real work start now :)
>
> Cheers.
> Germán.
>
>
> 2010/9/23 Mariano Martinez Peck :
>>
>>
>> On Thu, Sep 23, 2010 at 12:49 AM, Miguel Cobá wrote:
>>>
>>> El mié, 22-09-2010 a las 19:16 -0300, Germán Arduino escribió:
>>> > Hi Everybody:
>>> >
>>> > I reorganized the XMLRPC packages, integrating the changes of Skrish
>>> > (currently on PharoGoodies) renaming the packages in four categories:
>>> >
>>> > XMLRPC-Client-Core
>>> > XMLRPC-Client-Tests
>>> > XMLRPC-Server-Core
>>> > XMLRPC-Server-Tests
>>> >
>>> > Next step: Build the following metacello configurations:
>>> >
>>> > ConfigurationOfXMLRPCClient
>>> > ConfigurationOfXMLRPCServer
>>> > ConfigurationOfXMLRPCAll
>>>
>>> You don't need three configurations, just create one and create 3 groups
>>> 'All','Server', 'Client'.
>>>
>>
>> You were faster than :) I was going to answer exactly the same...one
>> ConfigurationOfXMLRPC and different groups:
>> - 'All'
>> - 'Server'
>> - 'Server with Tests'
>> - 'Client'
>> - 'Client with Tests'
>> -etc
>>
>> Check ConfigurationOfMagma since it does almost the same I think.
>>
>> cheers
>>
>> mariano
>>
>>> Cheers
>>> >
>>> >
>>> > I want to ask to any person wanting to contribute with XMLRPC project
>>> > take contact with me to coordinate efforts.
>>> >
>>> >
>>> > Cheers.
>>> >
>>> >
>>>
>>> --
>>> Miguel Cobá
>>> http://miguel.leugim.com.mx
>>>
>>>
>>> ___
>>> Pharo-project mailing list
>>> Pharo-project@lists.gforge.inria.fr
>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>
>> ___
>> Pharo-project mailing list
>> Pharo-project@lists.gforge.inria.fr
>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>
>
___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] XMLRPC Project - Progress Report
Germán, On 03 Oct 2010, at 17:41, Germán Arduino wrote: > As usual, any comment, suggestion or criticism is more than welcome. Well, you could consider using the Zinc HTTP Components framework. XMLRPCProxy>>#sendXmlRpc: is using the ugly HTTPSocket interface. Using any of the clients in Zn will give you a semantically much richer interface to headers and content (entities), both for requests and for responses. And you get many features on top. I haven't looked at the server side, but there too you can get HTTP functionality for free. It will add a dependency though, but I would guess you have one for the server side already, no ? Anyway, we're looking for users... Sven ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] OB Dev in Metacello
2010/9/29 Diogenes Moreira > hi folks: > > anybody could tell how load the OB Dev Tools with Metacello. > Gofer new squeaksource: 'MetacelloRepository'; package: 'ConfigurationOfOmniBrowser'; load. ((Smalltalk at: #ConfigurationOfOmniBrowser ) project version: '1.2') load: 'Dev' or... ((Smalltalk at: #ConfigurationOfOmniBrowser ) project version: '1.2') load for the core... Cheers Mariano > > > Thank in Advance.. > > > ___ > Pharo-project mailing list > Pharo-project@lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Metacello Configuration Browser?
2010/9/28 Simon Denier > > On 28 sept. 2010, at 21:30, Mariano Martinez Peck wrote: > > What I would love is a UI for GoferProjectLoader from Esteban. I mean, we > have the apt-get but we need now synaptic :) > > Andif we plan to do what I say in the email about Pharo and Metacello, > having something like that is very, VERY useful. From my point of view, even > more than a Metacello browser. > > > > That's too different usages, which are complementary: GoferProjectLoader is > for end-users, > yes! > while I'm thinking more of a browser for developers, when they have to > create a new release and check there configuration is consistent. Right now > it's quite a pain, ask Jannik who did the 4.1 Moose :) > > ah got it ;) so...the question is...why not improving Metacello-OB instead? > > > Cheers > > Mariano > > 2010/9/28 Simon Denier > >> >> On 28 sept. 2010, at 15:14, Guillermo Polito wrote: >> >> Okok, I saw there already exists a Configuration browser :P. But it can >> be reaally improved. >> >> >> >> Which one are you talking about? The one in 1.2? Or on Squeaksource? >> >> There have been multiple efforts (GTMetaceller, MooseDevBrowser...) >> already to try and see what we would like to do in a browser. But there are >> also some performance issues with Metacello right now, which makes it >> impractical to browser config. which Dale and Alex have started to tackle >> them. >> >> Anyway, the latest effort (started during ESUG) is there: it is basically >> a rewrite of what have been done in the tools above (with still some missing >> parts). >> >> MCHttpRepository >> location: 'http://www.squeaksource.com/MetacelloBrowser' >> user: '' >> password: '' >> >> >> Note, it requires Glamour and is more of a testbed than a fully-supported >> tool for now. >> >> >> >> >> On Tue, Sep 28, 2010 at 10:00 AM, Guillermo Polito < >> guillermopol...@gmail.com> wrote: >> >>> I'm always reading people saying that metacello configurations are some >>> kind of... overdesign. So, maybe we need a tool (or to modify monticello >>> browser) wich allow us to: >>> >>> - know wich packages are core and dev. Sometimes using a dev image, I >>> write things depending on Dev packages and I don't realize it. >>> - create automatically or propose configurations depending on the actual >>> state of the packages. >>> - browse configurations nicely :). It's a new concept, we need a nice >>> tool to support it. >>> >>> Maybe if the configs are easily created, we can have more of them, and we >>> will be no longer so lazy. >>> >>> Cheers, >>> Guille >>> >> >> ___ >> Pharo-project mailing list >> Pharo-project@lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> >> -- >> Simon >> >> >> >> >> ___ >> Pharo-project mailing list >> Pharo-project@lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > ___ > Pharo-project mailing list > Pharo-project@lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > -- > Simon > > > > > ___ > Pharo-project mailing list > Pharo-project@lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] XMLRPC Project - Progress Report
Tell us when pharo core can be a user. Because we want to clean the mess. Stef On Oct 3, 2010, at 6:52 PM, Sven Van Caekenberghe wrote: > Germán, > > On 03 Oct 2010, at 17:41, Germán Arduino wrote: > >> As usual, any comment, suggestion or criticism is more than welcome. > > Well, you could consider using the Zinc HTTP Components framework. > > XMLRPCProxy>>#sendXmlRpc: is using the ugly HTTPSocket interface. > > Using any of the clients in Zn will give you a semantically much richer > interface to headers and content (entities), both for requests and for > responses. And you get many features on top. > > I haven't looked at the server side, but there too you can get HTTP > functionality for free. > > It will add a dependency though, but I would guess you have one for the > server side already, no ? > > Anyway, we're looking for users... > > Sven > > > ___ > Pharo-project mailing list > Pharo-project@lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Metacello Configuration Browser?
2010/10/3 Mariano Martinez Peck > > > 2010/9/28 Simon Denier > >> >> On 28 sept. 2010, at 21:30, Mariano Martinez Peck wrote: >> >> What I would love is a UI for GoferProjectLoader from Esteban. I mean, we >> have the apt-get but we need now synaptic :) >> >> Andif we plan to do what I say in the email about Pharo and Metacello, >> having something like that is very, VERY useful. From my point of view, even >> more than a Metacello browser. >> >> >> >> That's too different usages, which are complementary: GoferProjectLoader >> is for end-users, >> > > yes! > > >> while I'm thinking more of a browser for developers, when they have to >> create a new release and check there configuration is consistent. Right now >> it's quite a pain, ask Jannik who did the 4.1 Moose :) >> >> Yes, you Simon got it right :). I want a button ( :P ) to create a configuration for a package. I want it to look for dependant packages, allow me to write pre load and post load scripts. And let me upload it to the right monticello metacello reporsitory. So we can automate this ugly configuration stuff. > > ah got it ;) > > so...the question is...why not improving Metacello-OB instead? > How can I get it? I would like to have a tool running in the core image, but maybe that's not the right approach. In my 1.2 Core I have a MetacelloConfigurationBrowser, where I can browse the configurations in MetaRepoForPharo12 in squeaksource. Why not improving that? If not, why do we have this browser??? Are the alternatives Simon mentioned all the ones we have? We should unify the solutions to gather all the power that is disperse right now in 2 or 3 different solutions. > > > >> >> >> Cheers >> >> Mariano >> >> 2010/9/28 Simon Denier >> >>> >>> On 28 sept. 2010, at 15:14, Guillermo Polito wrote: >>> >>> Okok, I saw there already exists a Configuration browser :P. But it can >>> be reaally improved. >>> >>> >>> >>> Which one are you talking about? The one in 1.2? Or on Squeaksource? >>> >>> There have been multiple efforts (GTMetaceller, MooseDevBrowser...) >>> already to try and see what we would like to do in a browser. But there are >>> also some performance issues with Metacello right now, which makes it >>> impractical to browser config. which Dale and Alex have started to tackle >>> them. >>> >>> Anyway, the latest effort (started during ESUG) is there: it is basically >>> a rewrite of what have been done in the tools above (with still some missing >>> parts). >>> >>> MCHttpRepository >>> location: 'http://www.squeaksource.com/MetacelloBrowser' >>> user: '' >>> password: '' >>> >>> >>> Note, it requires Glamour and is more of a testbed than a fully-supported >>> tool for now. >>> >>> >>> >>> >>> On Tue, Sep 28, 2010 at 10:00 AM, Guillermo Polito < >>> guillermopol...@gmail.com> wrote: >>> I'm always reading people saying that metacello configurations are some kind of... overdesign. So, maybe we need a tool (or to modify monticello browser) wich allow us to: - know wich packages are core and dev. Sometimes using a dev image, I write things depending on Dev packages and I don't realize it. - create automatically or propose configurations depending on the actual state of the packages. - browse configurations nicely :). It's a new concept, we need a nice tool to support it. Maybe if the configs are easily created, we can have more of them, and we will be no longer so lazy. Cheers, Guille >>> >>> ___ >>> Pharo-project mailing list >>> Pharo-project@lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >>> >>> -- >>> Simon >>> >>> >>> >>> >>> ___ >>> Pharo-project mailing list >>> Pharo-project@lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >> >> ___ >> Pharo-project mailing list >> Pharo-project@lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> >> -- >> Simon >> >> >> >> >> ___ >> Pharo-project mailing list >> Pharo-project@lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > > ___ > Pharo-project mailing list > Pharo-project@lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Metacello Configuration Browser?
2010/10/3 Guillermo Polito
>
>
> 2010/10/3 Mariano Martinez Peck
>
>
>>
>> 2010/9/28 Simon Denier
>>
>>>
>>> On 28 sept. 2010, at 21:30, Mariano Martinez Peck wrote:
>>>
>>> What I would love is a UI for GoferProjectLoader from Esteban. I mean, we
>>> have the apt-get but we need now synaptic :)
>>>
>>> Andif we plan to do what I say in the email about Pharo and
>>> Metacello, having something like that is very, VERY useful. From my point of
>>> view, even more than a Metacello browser.
>>>
>>>
>>>
>>> That's too different usages, which are complementary: GoferProjectLoader
>>> is for end-users,
>>>
>>
>> yes!
>>
>>
>>> while I'm thinking more of a browser for developers, when they have to
>>> create a new release and check there configuration is consistent. Right now
>>> it's quite a pain, ask Jannik who did the 4.1 Moose :)
>>>
>>>
> Yes, you Simon got it right :). I want a button ( :P ) to create a
> configuration for a package. I want it to look for dependant packages,
> allow me to write pre load and post load scripts. And let me upload it to
> the right monticello metacello reporsitory. So we can automate this ugly
> configuration stuff.
>
>
>>
>> ah got it ;)
>>
>> so...the question is...why not improving Metacello-OB instead?
>>
>
> How can I get it? I would like to have a tool running in the core image,
> but maybe that's not the right approach.
>
>
When you load a Metacello conf in a image where Metacello is not present,
the automatic Metacello bootstrap will load only the core, as it should.
However, you can explictly load the UI. Check the ConfigurationOfMetacello
and you will see a group 'UI'.
To install:
ConfigurationOfMetacello project latestVersion load: #('UI'
'Metacello-Core')
In Pharo 1.1.1 I already install those packages of Metacello. You will see
the package OB-Metacello.
But I have never use it.
Here is some info
http://code.google.com/p/metacello/wiki/MetacelloTools
In my 1.2 Core I have a MetacelloConfigurationBrowser, where I can browse
> the configurations in MetaRepoForPharo12 in squeaksource.
>
>
>
Why not improving that? If not, why do we have this browser??? Are the
> alternatives Simon mentioned all the ones we have? We should unify the
> solutions to gather all the power that is disperse right now in 2 or 3
> different solutions.
>
yes, please. I would like that people join eforce in this topic.
cheers
mariano
>
>
>>
>>
>>
>>>
>>>
>>> Cheers
>>>
>>> Mariano
>>>
>>> 2010/9/28 Simon Denier
>>>
On 28 sept. 2010, at 15:14, Guillermo Polito wrote:
Okok, I saw there already exists a Configuration browser :P. But it can
be reaally improved.
Which one are you talking about? The one in 1.2? Or on Squeaksource?
There have been multiple efforts (GTMetaceller, MooseDevBrowser...)
already to try and see what we would like to do in a browser. But there are
also some performance issues with Metacello right now, which makes it
impractical to browser config. which Dale and Alex have started to tackle
them.
Anyway, the latest effort (started during ESUG) is there: it is
basically a rewrite of what have been done in the tools above (with still
some missing parts).
MCHttpRepository
location: 'http://www.squeaksource.com/MetacelloBrowser'
user: ''
password: ''
Note, it requires Glamour and is more of a testbed than a
fully-supported tool for now.
On Tue, Sep 28, 2010 at 10:00 AM, Guillermo Polito <
guillermopol...@gmail.com> wrote:
> I'm always reading people saying that metacello configurations are some
> kind of... overdesign. So, maybe we need a tool (or to modify monticello
> browser) wich allow us to:
>
> - know wich packages are core and dev. Sometimes using a dev image, I
> write things depending on Dev packages and I don't realize it.
> - create automatically or propose configurations depending on the
> actual state of the packages.
> - browse configurations nicely :). It's a new concept, we need a nice
> tool to support it.
>
> Maybe if the configs are easily created, we can have more of them, and
> we will be no longer so lazy.
>
> Cheers,
> Guille
>
___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
--
Simon
___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>>
>>> ___
>>> Pharo-project mailing list
>>> Pharo-project@lists.gforge.inria.fr
>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>
[Pharo-project] Pharocasts: Getting started with Pier CMS
Pier is a content management system that is light, flexible and free. This screencast shows - how to setup Pier for a minimal web site - configure persistency. http://www.pharocasts.com/2010/10/getting-started-with-pier-cms.html Recorded by Damien Cassou, voice by Christoph Budzinsky, edited by Laurent Laffont. This video is a real team work :) Cheers, Laurent Laffont Pharo Smalltalk Screencasts: http://www.pharocasts.com/ Blog: http://magaloma.blogspot.com/ ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] [Seaside] Pharocasts: Getting started with Pier CMS
cool! Stef On Oct 3, 2010, at 10:19 PM, laurent laffont wrote: > Pier is a content management system that is light, flexible and free. > > This screencast shows > - how to setup Pier for a minimal web site > - configure persistency. > > http://www.pharocasts.com/2010/10/getting-started-with-pier-cms.html > > Recorded by Damien Cassou, voice by Christoph Budzinsky, edited by Laurent > Laffont. This video is a real team work :) > > Cheers, > > Laurent Laffont > > Pharo Smalltalk Screencasts: http://www.pharocasts.com/ > Blog: http://magaloma.blogspot.com/ > ___ > seaside mailing list > seas...@lists.squeakfoundation.org > http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Another fixes to finalization (was Re: [update 1.2] #12161 - #12172)
And this is why I had that #isTimeToClean (90-second timer) hack in the MaDictionary's... On Sat, Oct 2, 2010 at 12:01 PM, Igor Stasenko wrote: > On 2 October 2010 19:47, Stéphane Ducasse wrote: >> Hi igor >> >> do you understand why the previous definition was >> >> cachedDefinitions >> Definitions ifNil: [Definitions := WeakIdentityKeyDictionary new. >> WeakArray addWeakDependent: Definitions]. >> ^ Definitions >> > i don't. :) > > It just a way to free memory as fast as possible. > But its really not worth spending so much CPU in order to save few > bytes of memory. > >> Stef >> >> On Oct 1, 2010, at 7:34 PM, Igor Stasenko wrote: >> >>> Here the simple fix for it. >>> >>> >>> >>> >>> >>> -- >>> Best regards, >>> Igor Stasenko AKA sig. >>> ___ >>> Pharo-project mailing list >>> Pharo-project@lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> >> ___ >> Pharo-project mailing list >> Pharo-project@lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > > > -- > Best regards, > Igor Stasenko AKA sig. > > ___ > Pharo-project mailing list > Pharo-project@lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
[Pharo-project] MC: somebody has to say this
I am starting to make a 1.1.1 image; the first step is to save packages so they can hopefully load in the new image. The first step of that is to save my package called Migrate and then to ask it to save everything else. Bugs in Migrate or not, I saw a progress bar mentioning the Pharo in box. That's not acceptable on various fronts. It was cumbersome to add, needed to be added in various packages, and now I find perhaps does things behind my back. Whether or not it did is not the point; it emphasizes another way in which our current system is inadequate. We need real packages, a single-operation way to save all of them to a clearly specified location, and a simple way to separately upload something that has been so saved to the in-box. Migrate is my attempt to help with that; clearly it's not enough. Bill ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] XMLRPC Project - Progress Report
Hi Sven: To be honest I haven't looked at Zn* yet. I know (and use) WebClient and imagine that Zn have similar features? Anyway I have not problem in use the things the Board consider better, but need to make the things step at step. At the server side I really don't looked deeper neither yet, because the main goal of the project is having a xmlrpc client capable of interact with any xmlrpc exposed api, implementing the full specification. Cheers and thanks by the comment. 2010/10/3 Sven Van Caekenberghe : > Germán, > > On 03 Oct 2010, at 17:41, Germán Arduino wrote: > >> As usual, any comment, suggestion or criticism is more than welcome. > > Well, you could consider using the Zinc HTTP Components framework. > > XMLRPCProxy>>#sendXmlRpc: is using the ugly HTTPSocket interface. > > Using any of the clients in Zn will give you a semantically much richer > interface to headers and content (entities), both for requests and for > responses. And you get many features on top. > > I haven't looked at the server side, but there too you can get HTTP > functionality for free. > > It will add a dependency though, but I would guess you have one for the > server side already, no ? > > Anyway, we're looking for users... > > Sven > > > ___ > Pharo-project mailing list > Pharo-project@lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
[Pharo-project] Pool dictionaries = 'private'?
This was probably done by SIF as I brought the code over from Dolphin, but just in case, have any of you ever seen 'private' added for Pool dictionaries? I didn't see it until saving my packages failed; I am pretty sure the code is the first I have ported that used a pool, and that this is the first time I had tried to save it from Pharo. After replacing private with the intended pool name, it appears to be ok. I'll know more when I try to load it. Bill ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Pool dictionaries = 'private'?
I'm having a tough time with a pool dictionary that works in 1.1; there are underscores in the variable names, and 1.1.1 appears to be chopping them up somehow. I recalled having to activate _/:= to get SIXXX loaded, so I quickly tried to file in the offending pool dictionary with the setting disabled, and it worked. The SIXX sar is old, so I am assuming it still contains underscore assignments, and hacked the preference at the right time to (hopefully) allow things to load. OSProcess Command Shell still warns about MVC; it's a drag, because it happens several minutes into my build process :( I'm getting a lot of resistance about something anObsoletePresenter, presumably a reference to a class called Presenter that I added to pacify some Dolphin code, and has slowly taken on a life of its own. There are clearly potenial problems with packages that create hassles on load, and there should be a way to detect them before saving if at all possible. Telling me about it on load is not nearly as much help as would be telling me, prior to saving, that something is wrong, at a time when I can fix it. Bill From: pharo-project-boun...@lists.gforge.inria.fr [pharo-project-boun...@lists.gforge.inria.fr] On Behalf Of Schwab,Wilhelm K [bsch...@anest.ufl.edu] Sent: Sunday, October 03, 2010 7:30 PM To: Pharo-project@lists.gforge.inria.fr Subject: [Pharo-project] Pool dictionaries = 'private'? This was probably done by SIF as I brought the code over from Dolphin, but just in case, have any of you ever seen 'private' added for Pool dictionaries? I didn't see it until saving my packages failed; I am pretty sure the code is the first I have ported that used a pool, and that this is the first time I had tried to save it from Pharo. After replacing private with the intended pool name, it appears to be ok. I'll know more when I try to load it. Bill ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
[Pharo-project] Pointer types
Sig, You mentioned something that might be useful, depending on where it lives. Our ability to use underscores now leaves me thinking I really should rework some things that suffered mightily: there are some external things that are named assuming underscores, and in mixed case, they turn into an unreadable mess. Along with this, I have a large number of FFI calls that take double pointers, and I have for some time been demoralized into (or stupid enough to) expressing them as void pointers to allow me to pass byte arrays into them. Is there a way that I can get FFI to recognize DOUBLEArray (which uses a ByteArray to hold its data) as something that should be acceptable for a double* call? If not FFI, how does NB handle it? Bill ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] MC: somebody has to say this
Gofer? On Monday, October 4, 2010, Schwab,Wilhelm K wrote: > I am starting to make a 1.1.1 image; the first step is to save packages so > they can hopefully load in the new image. The first step of that is to save > my package called Migrate and then to ask it to save everything else. Bugs > in Migrate or not, I saw a progress bar mentioning the Pharo in box. That's > not acceptable on various fronts. It was cumbersome to add, needed to be > added in various packages, and now I find perhaps does things behind my back. > Whether or not it did is not the point; it emphasizes another way in which > our current system is inadequate. > > We need real packages, a single-operation way to save all of them to a > clearly specified location, and a simple way to separately upload something > that has been so saved to the in-box. Migrate is my attempt to help with > that; clearly it's not enough. > > Bill > > > ___ > Pharo-project mailing list > Pharo-project@lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Lukas Renggli www.lukas-renggli.ch ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
