- Pharo-dev - lists.pharo.org

[Pharo-project] Xml Parser
by Guillermo Polito Oct. 5, 2010

Oct. 5, 2010

I looked after it in squeaksource and I didn't find it... Can some one enlight me? Cheers!

3 4

Re: [Pharo-project] Ocean (was Re: Less plugins, more Smalltalk code! (was: Re: Pharo 1.1.1 OneClickCogVm))
by StÃ©phane Ducasse Oct. 5, 2010

Oct. 5, 2010

On Oct 4, 2010, at 10:23 PM, Levente Uzonyi wrote: > On Mon, 4 Oct 2010, Sven Van Caekenberghe wrote: > >> Noury, >> >> One of the other aspects that I find important is elementary efficiency. >> >> A lot of stream related code in Smalltalk is not efficient, the actual data is copied around like crazy, turning it from a stream to a collection and then back into a stream multiple times. For Zinc HTTP Components I made a lot of effort to make it possible to read data from a socket stream in true streaming fashion (instead of just returning a byte array). Now, the idea was then that for example JPEGReadWriter>>#nextImage would work transparaently on that raw stream. Sadly, the code in JPEGReadWriter and friends just reads everything into an array before it starts to work ! >> >> Doing a #nextPutAll: <some byte array> should really try never to copy the array. Similary, a #next: <count> into: <some byte array> should similary write directly into the given array. What I see in the current SocketStream is <censored/> ;-) > > This is why we implemented our own SocketStream in PostgresV3. what is the license? Stef > >> >> But OK, maybe this is easier said than done. The step from Smalltalk to system call should also not copy if that is possible, but then FFI and GC come into play. > > I wonder if there's a language, that provides socket access via FFI. > > > Levente > >> >> Anyway, good luck, I am willing to try using Ocean as soon as it becomes available. >> >> Sven >> >> On 04 Oct 2010, at 10:59, Noury Bouraqadi wrote: >> >>> >>> On 3 oct. 2010, at 16:28, Schwab,Wilhelm K wrote: >>> >>>> 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. >>>> >>> You're right. >>> Another option is having a multi-threaded VM. Eliot seem to work on it. >>> So far we're working on cleaning up the design of basic functionalities before going on. >>> Then, we'll try to find a workaround for non-blocking calls. >>> All ideas are welcome :-) >>> >>> BTW, some people (you included) proposed to help for the Ocean project. >>> Luc and I want to thank you and we are happy that others are willing to help. >>> We thought about the best way to integrate others help. >>> Our conclusion is that we should first do alone (luc and me) the reference design, before integrating other developers. >>> So, we all can work on solid foudations. >>> >>> Noury >>> >>> >>> >>> _______________________________________________ >>> 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 >> > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

2 1

Re: [Pharo-project] [update 1.2] #12170
by StÃ©phane Ducasse Oct. 5, 2010

Oct. 5, 2010

aMethod is a selector. so we should change the code and like that the tests get green :). Stef > Henrik > > when I drop a cs I get a DNU. > No time to check now. > > Stef > On Oct 5, 2010, at 11:51 AM, StÃ©phane Ducasse wrote: > >>> >>> >>> From: stephane ducasse <stephane.ducasse(a)gmail.com> >>> Date: October 5, 2010 11:43:17 AM GMT+02:00 >>> To: An open mailing list to discuss any topics related to an open-source Smalltalk <Pharo-project(a)lists.gforge.inria.fr> >>> Subject: [update 1.2] #12170 >>> >>> >>> >>> 12170 >>> ----- >>> >>> - Issue 3060: Update Monticello to detect method recategorization correctly. Thanks Pavel Krivanek and Henrik Johanssen >>> >>> >> >> _______________________________________________ >> 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

3 5

Re: [Pharo-project] [update 1.2] #12170
by StÃ©phane Ducasse Oct. 5, 2010

Oct. 5, 2010

Henrik when I drop a cs I get a DNU. No time to check now. Stef On Oct 5, 2010, at 11:51 AM, StÃ©phane Ducasse wrote: >> >> >> From: stephane ducasse <stephane.ducasse(a)gmail.com> >> Date: October 5, 2010 11:43:17 AM GMT+02:00 >> To: An open mailing list to discuss any topics related to an open-source Smalltalk <Pharo-project(a)lists.gforge.inria.fr> >> Subject: [update 1.2] #12170 >> >> >> >> 12170 >> ----- >> >> - Issue 3060: Update Monticello to detect method recategorization correctly. Thanks Pavel Krivanek and Henrik Johanssen >> >> > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

1 0

[Pharo-project] [update 1.2] #12170
by StÃ©phane Ducasse Oct. 5, 2010

Oct. 5, 2010

> > > From: stephane ducasse <stephane.ducasse(a)gmail.com> > Date: October 5, 2010 11:43:17 AM GMT+02:00 > To: An open mailing list to discuss any topics related to an open-source Smalltalk <Pharo-project(a)lists.gforge.inria.fr> > Subject: [update 1.2] #12170 > > > > 12170 > ----- > > - Issue 3060: Update Monticello to detect method recategorization correctly. Thanks Pavel Krivanek and Henrik Johanssen > >

1 0

Re: [Pharo-project] Issue 3060: Update Monticello to detect method recategorization correctly
by StÃ©phane Ducasse Oct. 5, 2010

Oct. 5, 2010

Thanks guys. I will just after my presentation on seaside to IRIL http://www.irill.org/events/irill-days-2010/irill-days-2010-detailed-program Stef On Oct 5, 2010, at 10:18 AM, Pavel Krivanek wrote: > Hi, > > please integrate the fix. > > Cheers, > -- Pavel > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

1 0

[Pharo-project] Issue 3060: Update Monticello to detect method recategorization correctly
by Pavel Krivanek Oct. 5, 2010

Oct. 5, 2010

Hi, please integrate the fix. Cheers, -- Pavel

2 1

[Pharo-project] Issue 3061: ZipArchiveTest should be removed Compression package
by NicolÃ¡s Paez Oct. 5, 2010

Oct. 5, 2010

Code and Test should be in different packages, to execute your applications you don't need tests. Test should have their own package. http://code.google.com/p/pharo/issues/detail?id=3061 Regards, Saludos! Nico. blog: nicopaez.wordpress.com

1 0

Re: [Pharo-project] Another fixes to finalization (was Re: [update 1.2] #12161 - #12172)
by StÃ©phane Ducasse Oct. 5, 2010

Oct. 5, 2010

>>> > > Moreover, case (b) comes from the inability to dynamically add extra > slot(s) to object, > which you can easily do in Self or JavaScript, but can't do in smalltalk. > > > > It can be done better, with extra VM features, but without those, it's pretty close to best possible solution IMHO. > There are already two different classes for a) and b): WeakRegistry and WeakKeyDictionary (and subclasses). Igor Levente is right. Having dynamic slots to object is nearly a paradigm shift. So let us focus on what we can do now. Now is there a technical problem to apply the solution implemented by levente in Squeak? Because if not this is what we should do. Stef

1 0

Re: [Pharo-project] Another fixes to finalization (was Re: [update 1.2] #12161 - #12172)
by StÃ©phane Ducasse Oct. 4, 2010

Oct. 4, 2010

so let us know in the bug entry what is the conclusion :) > 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. >> > > Oh, you are right. They are not reused unless marked as expired > (associatin's value == association). > But concerning speed, then my benchmark should show an opposite results. :) > > cache holding a pairs of: > compiledmethod -> MCMethodDefinitions. > > Compiled methods usually gone when you either recompiling class or > removing it from system. > This is why i put #finalizeValues after package loading/unloading. > But if you think it worth adding it into some other places, then tell me where. > Still, putting it into FinalizationDependents is bad idea. > >> 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. > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

4 10