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

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

by Igor Stasenko

2010/10/4 Levente Uzonyi <leves(a)elte.hu>: > On Mon, 4 Oct 2010, Igor Stasenko wrote: > >> On 4 October 2010 22:51, Henrik Sperre Johansen > > <henrik.s.johansen(a)veloxit.no> wrote: >> >> Â On 04.10.2010 21:47, Igor Stasenko wrote: >>> >>> On 4 October 2010 22:09, StÃ©phane Ducasse<stephane.ducasse(a)inria.fr> >>> Â wrote: >>>> >>>> so let us know in the bug entry what is the conclusion :) >>>> >>> I think someone should verify my benchmarks i.e. >>> >>> [ self loadsomething ] timeToRun >>> >>> before and after patch. >>> >>> And conclusion is better be written by Henrik, because he's having >>> concerns about speed, >>> while i don't. :) >> >> I already have: >> >> http://code.google.com/p/pharo/issues/detail?id=1628#c13 >> > emm.. wait. > WeakKeyDict should not delete associations with nil-ed keys > automatically, because otherwise > you won't be able to use it in weak finalization scheme. > > There is two distinct use cases of weak-key dicts: > a) for weak finalization > b) for attaching some extra info(value) per object(key), which can be > automatically discarded once object become garbage > > so, while in case (b) you can mercilessly kill/reuse associations with > nil keys, once they discovered > in case (a) you should preserve them until there is explicit request > from outside to finalize values. > > The need in (a), apparently prohibits from using (b) in most efficient > manner. > So, i think, the solution would be to introduce a specialized weak-key > dicts, which can work much better for (b). > > > Squeak's implementation works well in both cases. > > Trust me, scanning a whole dict to detect nil keys is not what can be called 'well' :) My point is, that these two scenarios should use different classes/implementors each optimized for own case. 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. > Levente > >> 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. 4, 2010

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

by Henrik Sperre Johansen

Sorry for the duplications in last mail, there comes a point where I just think "screw it", stop editing, and just press send :) Cheers, Henry

Oct. 4, 2010

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

by Henrik Sperre Johansen

On 04.10.2010 22:26, Levente Uzonyi wrote: > On Mon, 4 Oct 2010, Igor Stasenko wrote: > >> On 4 October 2010 22:51, Henrik Sperre Johansen > <henrik.s.johansen(a)veloxit.no> wrote: >> On 04.10.2010 21:47, Igor Stasenko wrote: >>> >>> On 4 October 2010 22:09, StÃ©phane Ducasse<stephane.ducasse(a)inria.fr> >>> wrote: >>>> >>>> so let us know in the bug entry what is the conclusion :) >>>> >>> I think someone should verify my benchmarks i.e. >>> >>> [ self loadsomething ] timeToRun >>> >>> before and after patch. >>> >>> And conclusion is better be written by Henrik, because he's having >>> concerns about speed, >>> while i don't. :) >> >> I already have: >> >> http://code.google.com/p/pharo/issues/detail?id=1628#c13 >> > emm.. wait. > WeakKeyDict should not delete associations with nil-ed keys > automatically, because otherwise > you won't be able to use it in weak finalization scheme. It could in 1.0, without anyone noticing. #rehash truncated duplicate nil keys, thus if it was triggered (f.ex. by a manual removal, or adding enough to cause growth) in a thread with priority higher than finalization process (ie ran after GC but before finalization thread), the nil keys could be truncated before finalization being run. An unlikely scenario, I admit, which I guess is why noone encountered it. #grow suffered the same problem. (well, actually, it didn't add any of the nil keyed associations) > > There is two distinct use cases of weak-key dicts: > a) for weak finalization > b) for attaching some extra info(value) per object(key), which can be > automatically discarded once object become garbage > > so, while in case (b) you can mercilessly kill/reuse associations with > nil keys, once they discovered > in case (a) you should preserve them until there is explicit request > from outside to finalize values. Yes, that's the point I've been trying to make these past couple of months :) > > The need in (a), apparently prohibits from using (b) in most efficient > manner. > So, i think, the solution would be to introduce a specialized weak-key > dicts, which can work much better for (b). The difference between a and b, and the fact Pharo 1.1's implementation severly screws with the performance if b) (and honestly, isn't that good for a) either) is the point I've been trying to make for months now... In Pharo 1.1 we've moved to the other extreme compared to 1.0, nil keys are never removed. b) always works, but a) HAS to be registered to work satisfactory at all. It was changed to do an extra step of keeping finalized assocs in a special state where they can be simply replaced without rehashing after finalization instead of doing rehash, but that's not really the major result of the change. > > > Squeak's implementation works well in both cases. > > > Levente The way I read it (correct me if I'm wrong), the solution in Squeak was adding a finalizer inst var to WeakKeyDictionary, that way you can distinguish the two cases and handle them appropriately. (in addition there were speed improvements for rehashing, growing, etc.) I looked for another solution which would keep WeakKeyDictionary oblivious to whether or not it was being finalized or not and could not find one, thus I think it is worth porting. Keeping the (pardon my fren.. err, norwegian) POS that is currectly in 1.1, or reverting to the 1.0 version for 1.2, is not a good alternative. Cheers, Henry

Oct. 4, 2010

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

by Igor Stasenko

I think that this project would be good test-bed for testing a non-blocking FFI callouts. On 4 October 2010 23:23, Levente Uzonyi <leves(a)elte.hu> 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. > >> >> 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 > -- Best regards, Igor Stasenko AKA sig.

Oct. 4, 2010

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

by Levente Uzonyi

On Mon, 4 Oct 2010, Igor Stasenko wrote: > On 4 October 2010 22:51, Henrik Sperre Johansen <henrik.s.johansen(a)veloxit.no> wrote: > Â On 04.10.2010 21:47, Igor Stasenko wrote: >> >> On 4 October 2010 22:09, StÃ©phane Ducasse<stephane.ducasse(a)inria.fr> >> Â wrote: >>> >>> so let us know in the bug entry what is the conclusion :) >>> >> I think someone should verify my benchmarks i.e. >> >> [ self loadsomething ] timeToRun >> >> before and after patch. >> >> And conclusion is better be written by Henrik, because he's having >> concerns about speed, >> while i don't. :) > > I already have: > > http://code.google.com/p/pharo/issues/detail?id=1628#c13 > emm.. wait. WeakKeyDict should not delete associations with nil-ed keys automatically, because otherwise you won't be able to use it in weak finalization scheme. There is two distinct use cases of weak-key dicts: a) for weak finalization b) for attaching some extra info(value) per object(key), which can be automatically discarded once object become garbage so, while in case (b) you can mercilessly kill/reuse associations with nil keys, once they discovered in case (a) you should preserve them until there is explicit request from outside to finalize values. The need in (a), apparently prohibits from using (b) in most efficient manner. So, i think, the solution would be to introduce a specialized weak-key dicts, which can work much better for (b). Squeak's implementation works well in both cases. Levente > 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

Oct. 4, 2010

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

by Levente Uzonyi

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. > > 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 >

Oct. 4, 2010

Re: [Pharo-project] Newbie question: Connection to SQLite DB

by nullPointer

Mariano Martinez Peck wrote: > > >> Anything, I need OpenDBX for use Sqlite3 project? ( >> http://squeaksource.com/@7SFD7f008dKbC-Yt/rKzITl0- >> http://squeaksource.com/@7SFD7f008dKbC-Yt/rKzITl0- ) I donÂ´t need use >> glorp for the work; is for a very dummy DB. >> >> > I don't get this links....what did you want to link? > Is a project on SqueakSource for connect to Sqlite DBs. Excuse me for the bad link. http://www.squeaksource.com/SQLite.html That libs work without SqueakDBX, but obviously needs FFI. Works on Windows without problems, but in MACOSX donÂ´t found any table on DB... :( Many thanks for the help. -- View this message in context: http://forum.world.st/Newbie-question-Connection-to-SQLite-DB-tp2954195p295… Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Oct. 4, 2010

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

by Igor Stasenko

On 4 October 2010 22:51, Henrik Sperre Johansen <henrik.s.johansen(a)veloxit.no> wrote: > Â On 04.10.2010 21:47, Igor Stasenko wrote: >> >> On 4 October 2010 22:09, StÃ©phane Ducasse<stephane.ducasse(a)inria.fr> >> Â wrote: >>> >>> so let us know in the bug entry what is the conclusion :) >>> >> I think someone should verify my benchmarks i.e. >> >> [ self loadsomething ] timeToRun >> >> before and after patch. >> >> And conclusion is better be written by Henrik, because he's having >> concerns about speed, >> while i don't. :) > > I already have: > > http://code.google.com/p/pharo/issues/detail?id=1628#c13 > emm.. wait. WeakKeyDict should not delete associations with nil-ed keys automatically, because otherwise you won't be able to use it in weak finalization scheme. There is two distinct use cases of weak-key dicts: a) for weak finalization b) for attaching some extra info(value) per object(key), which can be automatically discarded once object become garbage so, while in case (b) you can mercilessly kill/reuse associations with nil keys, once they discovered in case (a) you should preserve them until there is explicit request from outside to finalize values. The need in (a), apparently prohibits from using (b) in most efficient manner. So, i think, the solution would be to introduce a specialized weak-key dicts, which can work much better for (b). > 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. 4, 2010

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

by Henrik Sperre Johansen

On 04.10.2010 21:47, Igor Stasenko wrote: > On 4 October 2010 22:09, StÃ©phane Ducasse<stephane.ducasse(a)inria.fr> wrote: >> so let us know in the bug entry what is the conclusion :) >> > I think someone should verify my benchmarks i.e. > > [ self loadsomething ] timeToRun > > before and after patch. > > And conclusion is better be written by Henrik, because he's having > concerns about speed, > while i don't. :) I already have: http://code.google.com/p/pharo/issues/detail?id=1628#c13 Cheers, Henry

Oct. 4, 2010

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

by StÃ©phane Ducasse

:) >> Tell us when pharo core can be a user. >> Because we want to clean the mess. > > I know you are anxious to do so, and it will happen one day, for sure. Not anxious :) Happily eager :) > > There is still some technical work to do, but the most important thing is that we need as much users as possible to shake out the bugs. The code has to prove itself for others (with different encodings/languages/networks). > > Sven > > PS: As I said before, I am using it myself everyday, working in a Pharo 1.1 image were all HTTPSocket stuff is routed to Zn, so far so good. I also replaced all my other HTTP client uses by using Zn directly, and that works well too. We're getting closer. Excellent. I want to have nice code so that I can learn something.

Oct. 4, 2010

Re: [Pharo-project] Refactoring>checkPreconditions behaves funny about the errorBlock

by StÃ©phane Ducasse

please clean. Use version management to control impact on other clients. Else we cannot move and this is agony. slow and painful. Stef >> Ok, let's summarize: If an error occurs, the handler block is not >> evaluated, but attached to a new exception, that exception is raised. >> Then, the caller catches that exception, retrieves the handler block, >> does some more ballyhoo, and then runs the handler block. > > Yes, the block mostly contains some code to that allows the user to > fix the problem (like to show all references of a class to be removed, > etc.). > >> And you get invited to this construction by these methods in >> RBAbstractCondition: >> >> errorBlock >> ^self errorBlockFor: false >> >> errorBlockFor: aBoolean >> ^nil > > These methods (and subclass implementations) are used to retrieve the > right block that caused the composite condition to fail. > >> We can clean it up on the next sprint, if you want :) > > The implementation in RBCondition is fine, the problem is more the way > how exceptions are used to pass the values. This mainly stems from the > fact that exceptions evolved over the past 15 years and are no longer > the same as the signals that were used when the refactoring code was > originally written. > > Now of course it is difficult to change this code because there are > various users out there that depend on it, e.g. OB, > RefactoringBrowser, SmaCC, ... > > Lukas > > -- > 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. 4, 2010

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

by Igor Stasenko

On 4 October 2010 22:09, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > so let us know in the bug entry what is the conclusion :) > I think someone should verify my benchmarks i.e. [ self loadsomething ] timeToRun before and after patch. And conclusion is better be written by Henrik, because he's having concerns about speed, while i don't. :) > >> 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 > > > _______________________________________________ > 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. 4, 2010

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

by StÃ©phane Ducasse

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

Oct. 4, 2010

Re: [Pharo-project] CodeMorph >> text should return an instance of Text but return a String

by StÃ©phane Ducasse

Excellent! On Oct 4, 2010, at 11:10 AM, Fernando olivero wrote: > ISSUE 2902: CodeMorph removal . > > Done, added the change set and set the issue to fixed. > > > Fernando > > On Oct 1, 2010, at 12:58 PM, Fernando olivero wrote: > >> Yes, i've been busy so i couldn't finish this issue. >> >> Because CodeMorph comes from Gaucho, and until now there was no need for it in the Pharo-Core. so i will remove it, and possibly when the need arises will propose its re-inclusion. >> >> Fernando >> pd: the idea behind CodeMorph is to have a specialized NewTextMorph for dealing with Methods sources, Class definitions. But now i have second thoughts, because i have the impression that having diferent Editors ( subclasses of TextEditor or SmalltalkEditor) should do the trick. >> >> On Oct 1, 2010, at 12:02 PM, Cyrille Delaunay wrote: >> >>> I just saw that there is propositions to remove CodeMorph: >>> >>> http://code.google.com/p/pharo/issues/detail?id=2902&q=CodeMorph&colspec=ID… >>> >>> So maybe the best fix will be to remove all the tests related ? :) >>> >>> 2010/10/1 Cyrille Delaunay <cy.delaunay(a)gmail.com> >>> In pharo 1.2, NewTextMorphTests>>#testFullMethodName raise an error. This error happen when calling: >>> >>> CodeMorph >> defaultStyledText >>> | text attribute | >>> text := self text. >>> text addAttribute: ( self newTextColorAttribute: Color black ). >>> ^ text. >>> >>> text is a string, and therefore it does not understand 'addAttribute'. The value return by 'text' depends on the value of the instance variable 'adapter'. adapter can have different values according the way we initialize the CodeMorph. One of them is: >>> >>> beFullMethodName >>> aspect := #selector. >>> adapter := [:selector| target methodClass name , '.' , self selectorWithArguments ]. >>> >>> The block return a String and I guess the right code should be >>> >>> beFullMethodName >>> aspect := #selector. >>> adapter := [:selector| (target methodClass name , '.' , self selectorWithArguments) asText ] >>> >>> ??. >>> >>> >>> I opened an Issue: http://code.google.com/p/pharo/issues/detail?id=3031 >>> >>> <ATT00001..txt> >> >> <ATT00001..txt> > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Oct. 4, 2010

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

by Schwab,Wilhelm K

+1 -----Original Message----- From: pharo-project-bounces(a)lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Sven Van Caekenberghe Sent: Monday, October 04, 2010 9:51 AM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] Ocean (was Re: Less plugins, more Smalltalk code! (was: Re: Pharo 1.1.1 OneClickCogVm)) 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/> ;-) 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. 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

Oct. 4, 2010

Re: [Pharo-project] Senders

by Sven Van Caekenberghe

It has just been fixed in #12169 this is development at the speed of light... On 04 Oct 2010, at 20:14, Benjamin Van Ryseghem wrote: > Hi guys > > Am I the only one who can't browse senders anymore ? > > > I'm working on 1.2-12168 > > > Benjamin > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Oct. 4, 2010

[Pharo-project] Senders

by Benjamin Van Ryseghem

Hi guys Am I the only one who can't browse senders anymore ? I'm working on 1.2-12168 Benjamin

Oct. 4, 2010

[Pharo-project] [update 1.2] #12169

by StÃ©phane Ducasse

12169 ----- - fixing showMenus. Thanks Gary Chambers

Oct. 4, 2010

Re: [Pharo-project] Problem with popup lists (Senders of, implementors of etc.)

by StÃ©phane Ducasse

Thanks this is my mistake.... I will integrate it now. On Oct 4, 2010, at 12:57 PM, Gary Chambers wrote: > Hi. > > Since the update to 12168 I am getting an MNU... > Tracked down to > > showMenuOf: selectorCollection withFirstItem: firstItem ifChosenDo: choiceBlock withCaption: aCaption > "Show a sorted menu of the given selectors, preceded by firstItem, and all abbreviated to 40 characters. Use aCaption as the menu title, if it is not nil. Evaluate choiceBlock if a message is chosen." > > | index menuLabels sortedList | > sortedList := selectorCollection asSortedCollection. > menuLabels := Array streamContents: > [:strm | strm nextPutAll: (firstItem contractTo: 40). > sortedList do: [:sel | strm nextPutAll: (sel contractTo: 40)]]. > index := UIManager default chooseFrom: (menuLabels substrings) lines: #(1). > index = 1 ifTrue: [choiceBlock value: firstItem]. > index > 1 ifTrue: [choiceBlock value: (sortedList at: index - 1)] > > The following revision seems to work ok... > > > showMenuOf: selectorCollection withFirstItem: firstItem ifChosenDo: choiceBlock withCaption: aCaption > "Show a sorted menu of the given selectors, preceded by firstItem, and all abbreviated to 40 characters. Use aCaption as the menu title, if it is not nil. Evaluate choiceBlock if a message is chosen." > > | index menuLabels sortedList | > sortedList := selectorCollection asSortedCollection. > menuLabels := Array streamContents: > [:strm | strm nextPut: (firstItem contractTo: 40). > sortedList do: [:sel | strm nextPut: (sel contractTo: 40)]]. > index := UIManager default chooseFrom: menuLabels lines: #(1). > index = 1 ifTrue: [choiceBlock value: firstItem]. > index > 1 ifTrue: [choiceBlock value: (sortedList at: index - 1)] > > Regards, Gary > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Oct. 4, 2010

Re: [Pharo-project] Newbie question: Connection to SQLite DB

by Mariano Martinez Peck

On Mon, Oct 4, 2010 at 5:11 PM, nullPointer <epicfan(a)gmail.com> wrote: > > The final work must be in MacOSX... IÂ´m searching for the existence of > binary > but I donÂ´t found. Perhaps is needed compile :( > Yes. I don't know how to create binaries for MacOS. So yes, I guess you should compile: http://www.squeakdbx.org/Compiling%20for%20different%20backends/Common%20st… http://www.squeakdbx.org/Sqlite3%20for%20mac http://www.linuxnetworks.de/doc/index.php/OpenDBX/Setup/MacOS_X For linux I can have rpm, for Windows dll, but I have no idea for Mac. And I am a new mac user in addition. Please feel free to ask further questions about it. > > Anything, I need OpenDBX for use Sqlite3 project? ( > http://squeaksource.com/@7SFD7f008dKbC-Yt/rKzITl0- > http://squeaksource.com/@7SFD7f008dKbC-Yt/rKzITl0- ) I donÂ´t need use > glorp for the work; is for a very dummy DB. > > I don't get this links....what did you want to link? Cheers mariano Thanks for the help. > -- > View this message in context: > http://forum.world.st/Newbie-question-Connection-to-SQLite-DB-tp2954195p295… > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Oct. 4, 2010

Re: [Pharo-project] Newbie question: Connection to SQLite DB

by nullPointer

The final work must be in MacOSX... IÂ´m searching for the existence of binary but I donÂ´t found. Perhaps is needed compile :( Anything, I need OpenDBX for use Sqlite3 project? ( http://squeaksource.com/@7SFD7f008dKbC-Yt/rKzITl0- http://squeaksource.com/@7SFD7f008dKbC-Yt/rKzITl0- ) I donÂ´t need use glorp for the work; is for a very dummy DB. Thanks for the help. -- View this message in context: http://forum.world.st/Newbie-question-Connection-to-SQLite-DB-tp2954195p295… Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Oct. 4, 2010

Re: [Pharo-project] Newbie question: Connection to SQLite DB

by Mariano Martinez Peck

On Mon, Oct 4, 2010 at 4:36 PM, nullPointer <epicfan(a)gmail.com> wrote: > > > Mariano Martinez Peck wrote: > > > > > > You need the opendbx and sqlite libraries. > > Everything is explained here: > > http://www.squeakdbx.org/Compiling%20and%20installing%20OpenDBX > > > > or here http://www.squeakdbx.org/Compiling%20for%20different%20backends > > > > > > glups! that must be the problem :| I did install the binary sqlite on OS ( > in the bin folder, correct? ) > yes > but not the OpenDBX. Anything Sqlite3 project donÂ´t work of that way. I > will > try with SqueakDBX and installing OpenDBX before. > > in which OS are you? if Windows, just download the dlls and put it there. > As you can see IÂ´m very newbie on that things :( > > Thanks. > > > -- > View this message in context: > http://forum.world.st/Newbie-question-Connection-to-SQLite-DB-tp2954195p295… > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Oct. 4, 2010

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

by Sven Van Caekenberghe

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/> ;-) 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. 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

Oct. 4, 2010

Re: [Pharo-project] Soap Webservices for pharo

by Janko MivÅ¡ek

Hi guys, Nice to see that SOA Web Services in Squeak/Pharo is rolling on again. We really need that, if we want Pharo to be useful in commercial, specially in so called "enterprisely" world. Those who listen Andreas ThÃ¶nne's talk on ESUG, know what I mean. What we really need on SOA Web Services front: - WSDL support, - XML <-> Object mapping. - Tools Goal should be a "one-click" use of Web Services. From both client and server setup. As all Smalltalks support it, except Squeak/Pharo yet not. Look at excellent VW or VA Smalltlak WebServices suport for inspiration. Best regards Janko On 04. 10. 2010 16:21, Guillermo Polito wrote: > http://www.mars.dti.ne.jp/~umejava/smalltalk/soapOpera/soapCore.html > > So, we have some tasks now: > > - put it in squeaksource > - test it in pharo > - build a metacello config > - document it? > > Any help is really appreciated, since I don't have too much time. > > Cheers, > Guille > > ---------- Forwarded message ---------- > From: *Masashi Umezawa* <umejava(a)mars.dti.ne.jp > <mailto:umejava@mars.dti.ne.jp>> > Date: Mon, Oct 4, 2010 at 8:46 AM > Subject: Re: About SoapOpera and SoapCore > To: Guillermo Polito <guillermopolito(a)gmail.com > <mailto:guillermopolito@gmail.com>> > > > Hi Guillermo, > > I am happy to hear that SoapOpera and SoapCore would be useful for your > projects. Please feel free to reuse my Soap stuff. > Recently I do not have enough time to upgrade those packages. So I > really appreciate your offer. > > I hope SoapOpera and SoapCore will start growing again! > > Best regards, > > Guillermo Polito <guillermopolito(a)gmail.com > <mailto:guillermopolito@gmail.com>> wrote: >> Hi! >> >> My name's Guillermo and I'm from Argentina. I'm participating in the > pharo >> project (www.pharo-project.org <http://www.pharo-project.org>), and I > would love to integrate your soap >> package into our available packages :). >> I was wandering if you let us put it into squeaksource > (www.squeaksource.com <http://www.squeaksource.com>) >> and mantain it for our use, because pharo is growing very quickly and it >> needs this kind of really cool stuff :). Of course we will keep the MIT >> license. >> >> Thank you for your time and sorry for bothering :P! >> Guille > > --- > [:masashi | ^umezawa] -- Janko MivÅ¡ek AIDA/Web Smalltalk Web Application Server http://www.aidaweb.si

Oct. 4, 2010

[Pharo-project] Wrong fix: Issue 2947: SmalltalkEditor doesn't handle ESC key.

by Fernando olivero

I argue that this fix is wrong, giving the morph logic to the Editor instead of the View ( the morph). this conceptual problem, leads to having to ask for the Global ActiveEvent in the Editor>>offerMenuFromEsc:. If you take a look at the already present method, which should be the one to be used. Editor>>escapePressed "The message is sent when the user hits esc" self announceEscape Which allows the Morph to take care of the view related behavior. So i propose reverting to this behavior: Editor>>escapePressed self morph escapePressed . ^ false Then adding TextMorph>>escapePressed self yellowButtonActivity: false. TextMorphForEditView>>escapePressed self editView yellowButtonActivity: false . Given that TextMorphForEditView is the only implementor of #editView, and following the logic in TextEditor>>raiseContextMenu: TextEditor>>offerMenuFromEsc: aKeyboardEvent The attached change set implements the fixes.

Oct. 4, 2010