October 2010 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] XMLRPC Project - Progress Report

by 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

Oct. 3, 2010

Re: [Pharo-project] XMLRPC Project - Progress Report

by GermÃ¡n Arduino

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 <garduino(a)gmail.com>: > 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 <marianopeck(a)gmail.com>: >> >> >> On Thu, Sep 23, 2010 at 12:49 AM, Miguel CobÃ¡ <miguel.coba(a)gmail.com> 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(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >

Oct. 3, 2010

Re: [Pharo-project] Less plugins, more Smalltalk code! (was: Re: Pharo 1.1.1 OneClickCogVm)

by Schwab,Wilhelm K

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-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Noury Bouraqadi [bouraqadi(a)gmail.com] Sent: Sunday, October 03, 2010 4:57 AM To: Pharo-project(a)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 <sven(a)beta9.be>: >> >> 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(a)lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Oct. 3, 2010

[Pharo-project] [update 1.2] #12168

by stephane ducasse

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

Oct. 3, 2010

Re: [Pharo-project] Another fixes to finalization (was Re: [update 1.2] #12161 - #12172)

by Henrik Sperre Johansen

On 03.10.2010 11:59, Igor Stasenko wrote: > On 3 October 2010 12:36, Henrik Sperre Johansen > <henrik.s.johansen(a)veloxit.no> wrote: >> On 03.10.2010 05:47, Igor Stasenko wrote: >>> On 3 October 2010 03:13, Henrik Sperre Johansen >>> <henrik.s.johansen(a)veloxit.no> wrote: >>>> On 02.10.2010 19:01, Igor Stasenko wrote: >>>>> On 2 October 2010 19:47, StÃ©phane Ducasse<stephane.ducasse(a)inria.fr> >>>>> 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

Oct. 3, 2010

Re: [Pharo-project] Another fixes to finalization (was Re: [update 1.2] #12161 - #12172)

by Igor Stasenko

On 3 October 2010 12:36, Henrik Sperre Johansen <henrik.s.johansen(a)veloxit.no> wrote: > Â On 03.10.2010 05:47, Igor Stasenko wrote: >> >> On 3 October 2010 03:13, Henrik Sperre Johansen >> <henrik.s.johansen(a)veloxit.no> Â wrote: >>> >>> Â On 02.10.2010 19:01, Igor Stasenko wrote: >>>> >>>> On 2 October 2010 19:47, StÃ©phane Ducasse<stephane.ducasse(a)inria.fr> >>>> Â 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(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- Best regards, Igor Stasenko AKA sig.

Oct. 3, 2010

Re: [Pharo-project] Another fixes to finalization (was Re: [update 1.2] #12161 - #12172)

by Henrik Sperre Johansen

On 03.10.2010 05:47, Igor Stasenko wrote: > On 3 October 2010 03:13, Henrik Sperre Johansen > <henrik.s.johansen(a)veloxit.no> wrote: >> On 02.10.2010 19:01, Igor Stasenko wrote: >>> On 2 October 2010 19:47, StÃ©phane Ducasse<stephane.ducasse(a)inria.fr> >>> 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

Oct. 3, 2010

Re: [Pharo-project] Less plugins, more Smalltalk code! (was: Re: Pharo 1.1.1 OneClickCogVm)

by StÃ©phane Ducasse

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(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Oct. 3, 2010

Re: [Pharo-project] In Latest OB I cannot add a class variable

by Mariano Martinez Peck

On Sun, Oct 3, 2010 at 9:31 AM, Lukas Renggli <renggli(a)gmail.com> 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 <marianopeck(a)gmail.com>: > > > > > > On Sat, Oct 2, 2010 at 8:02 PM, Lukas Renggli <renggli(a)gmail.com> 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 <marianopeck(a)gmail.com>: > >> > > >> > > >> > On Sat, Oct 2, 2010 at 1:54 PM, Lukas Renggli <renggli(a)gmail.com> > 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: > >> >> `#category' 'ProtoObject variableSubclass: `#className > >> >> instanceVariableNames: `#instanceVariableNames classVariableNames: > >> >> `#classVariableNames poolDictionaries: `#poolDictionaries category: > >> >> `#category. `className superclass: `@superclass' '`@superclass > >> >> variableSubclass: `#className uses: `@traitComposition > >> >> instanceVariableNames: `#instanceVariableNames classVariableNames: > >> >> `#classVariableNames poolDictionaries: `#poolDictionaries category: > >> >> `#category' 'ProtoObject variableSubclass: `#className uses: > >> >> `@traitComposition instanceVariableNames: `#instanceVariableNames > >> >> classVariableNames: `#classVariableNames poolDictionaries: > >> >> `#poolDictionaries category: `#category. `className superclass: > >> >> `@superclass' '`@superclass variableWordSubclass: `#className > >> >> instanceVariableNames: `#instanceVariableNames classVariableNames: > >> >> `#classVariableNames poolDictionaries: `#poolDictionaries category: > >> >> `#category' 'ProtoObject variableWordSubclass: `#className > >> >> instanceVariableNames: `#instanceVariableNames classVariableNames: > >> >> `#classVariableNames poolDictionaries: `#poolDictionaries category: > >> >> `#category. `className superclass: `@superclass' '`@superclass > >> >> variableWordSubclass: `#className uses: `@traitComposition > >> >> instanceVariableNames: `#instanceVariableNames classVariableNames: > >> >> `#classVariableNames poolDictionaries: `#poolDictionaries category: > >> >> `#category' 'ProtoObject variableWordSubclass: `#className uses: > >> >> `@traitComposition instanceVariableNames: `#instanceVariableNames > >> >> classVariableNames: `#classVariableNames poolDictionaries: > >> >> `#poolDictionaries category: `#category. `className superclass: > >> >> `@superclass' '`@superclass weakSubclass: `#className > >> >> instanceVariableNames: `#instanceVariableNames classVariableNames: > >> >> `#classVariableNames poolDictionaries: `#poolDictionaries category: > >> >> `#category' 'ProtoObject weakSubclass: `#className > >> >> instanceVariableNames: `#instanceVariableNames classVariableNames: > >> >> `#classVariableNames poolDictionaries: `#poolDictionaries category: > >> >> `#category. `className superclass: `@superclass' '`@superclass > >> >> weakSubclass: `#className uses: `@traitComposition > >> >> instanceVariableNames: `#instanceVariableNames classVariableNames: > >> >> `#classVariableNames poolDictionaries: `#poolDictionaries category: > >> >> `#category' 'ProtoObject weakSubclass: `#className uses: > >> >> `@traitComposition instanceVariableNames: `#instanceVariableNames > >> >> classVariableNames: `#classVariableNames poolDictionaries: > >> >> `#poolDictionaries category: `#category. `className superclass: > >> >> `@superclass' '`traitName classTrait uses: `@traitComposition' 'Trait > >> >> named: `#traitName uses: `@traitComposition category: `#category') > >> >> > >> >> On 2 October 2010 13:01, Lukas Renggli <renggli(a)gmail.com> wrote: > >> >> >> Lukas, now I have another problem. I am not sure if it is OB > latest > >> >> >> code > >> >> >> related, but I think so. > >> >> > > >> >> > No, that was always the case. > >> >> > > >> >> >> If you take any class, suppose RBSemanticTest and go to its > >> >> >> definition. > >> >> >> Change it so that it extends from ProtoObject instead of TestCase. > >> >> >> When > >> >> >> you > >> >> >> accept the code (save it), the browser goes directly to Browse > >> >> >> ProtoObject, > >> >> >> actually to : > >> >> >> > >> >> >> ProtoObject subclass: #ProtoObject > >> >> >> instanceVariableNames: '' > >> >> >> classVariableNames: '' > >> >> >> poolDictionaries: '' > >> >> >> category: 'Kernel-Objects'. > >> >> >> ProtoObject superclass: nil > >> >> > > >> >> > Creating a subclass like this was never supported by the > refactoring > >> >> > engine. > >> >> > > >> >> > You have to write it like: > >> >> > > >> >> > nil subclass: #ProtoObject > >> >> > instanceVariableNames: '' > >> >> > classVariableNames: '' > >> >> > poolDictionaries: '' > >> >> > category: 'Kernel-Objects' > >> >> > > >> >> > Lukas > >> >> > > >> >> > -- > >> >> > Lukas Renggli > >> >> > www.lukas-renggli.ch > >> >> > > >> >> > >> >> > >> >> > >> >> -- > >> >> Lukas Renggli > >> >> www.lukas-renggli.ch > >> >> > >> >> _______________________________________________ > >> >> Pharo-project mailing list > >> >> Pharo-project(a)lists.gforge.inria.fr > >> >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > >> > > >> > > >> > _______________________________________________ > >> > Pharo-project mailing list > >> > Pharo-project(a)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(a)lists.gforge.inria.fr > >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > > > > _______________________________________________ > > Pharo-project mailing list > > Pharo-project(a)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(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Oct. 3, 2010

[Pharo-project] Less plugins, more Smalltalk code! (was: Re: Pharo 1.1.1 OneClickCogVm)

by Noury Bouraqadi

On 30 sept. 2010, at 20:22, GermÃ¡n Arduino wrote: > 2010/9/30 Sven Van Caekenberghe <sven(a)beta9.be>: >> >> 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

Oct. 3, 2010