- Pharo-dev - lists.pharo.org

Re: [Pharo-project] [squeak-dev] Re: Some questions about new traits (Crismas edition) ; )

by StÃ©phane Ducasse

>> I imagine that this gives an historical view to the question and I thanks >> you because we will probably clean it. > > Stef, > > Thanks for providing this historical background. It's an interesting story > and helps understanding for those of us who did not have an office near by :) I'm a bit sad that google attracted nathanael because he had plenty of other cool ideas. But we cannot redo the history. So head to the future :) Stef

Dec. 31, 2009

Re: [Pharo-project] 1.1 -- Inconsistent enumeration behavior of WeakKeyDictionary and subclasses

by Igor Stasenko

2009/12/31 Martin McClure <martin(a)hand2mouse.com>: > Igor Stasenko wrote: >> 2009/12/31 Martin McClure <martin(a)hand2mouse.com>: >>> If you run this in 1.1: >>> >>> | dict | >>> dict := WeakKeyDictionary new. >>> dict at: 'foo' copy put: 'bar'. >>> Smalltalk garbageCollect. >>> dict associationsDo: [:assoc | self halt]. >>> dict do: [:val | self halt] >>> >>> >>> It stops in the second halt, but not the first. >>> >>> This is because #associationsDo: does not include associations whose >>> keys have been GCed, but #do: *does* include values whose corresponding >>> keys have been GCed. >>> >>> This behavior seems inconsistent, and not particularly useful, and also >>> seems to contradict the comments by the author in the Squeak bug from >>> 2007, from which I'd think that #do: would not include the value which >>> it currently does. >>> >> It is useful in terms, that sometimes you don't want to see the >> objects which GCed, >> but sometimes do. See how WeakRegistry using this. >> The lack of ephemerons support in VM, forcing us to deal with such >> things manually. > > I see the value in being able to choose both. WeakRegistry uses > #allAssociationsDo:, not #associationsDo:. Seems like it would be more > consistent to also have an #allDo: that includes values of collected > keys, and a #do: that does not. > Well, let first take in account that Dictionary is not well consistent with Collection protocol. For instance, if #add: expects association, then one could say, that Dictionary is a Collection of associations. But if you try pass association to #includes: , or observe what objects iterated in #do: you'll find out that its not. And so, if you treat a dictionary as a collection of values, indexed by associated keys, then from this POV, a #do: behavior in weak dict is consistent with Collection protocol. But #associationsDo: will not report same number of entries, since some of them having invalid (nil) keys. >> >>> So I *think* this is an oversight, and is easy to fix by defining >>> WeakKeyDictionary>>do: in terms of self associationsDo:. >>> >>> But then there's the question of #size. The collection above answers 1 >>> to #size, which also seems wrong. >>> >> #size for weak key dict is non-deterministic. Because even if you want to know >> the exact number of elements, you will need to iterate over the >> collection, but then, >> iteration can trigger GC, and you have a big chances to answer wrong value. > > That seems reasonable, though there's no effort to even come close in size. > I don't think that #size having any value for weak key dicts at all, since there is no strict guarantees at any point of time, that collection will have same number of elements as few cycles before. So, measuring size of weak dict is pointless, and existing simply to conform with Collection protocol. > -Martin > > _______________________________________________ > 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.

Dec. 31, 2009

Re: [Pharo-project] Pharo-beginner mailing list ?

by Janko MivÅ¡ek

Hi guys! Maybe it could be good idea to rename this list to pharo-dev? pharo-user, pharo-dev, a perfect balance in name and content :) Best regards Janko On 30. 12. 2009 18:46, StÃ©phane Ducasse wrote: > ok let us wait to get more feedback on the idea... > > Stef -- Janko MivÅ¡ek AIDA/Web Smalltalk Web Application Server http://www.aidaweb.si

Dec. 31, 2009

Re: [Pharo-project] 1.1 -- Inconsistent enumeration behavior of WeakKeyDictionary and subclasses

by Martin McClure

Igor Stasenko wrote: > 2009/12/31 Martin McClure <martin(a)hand2mouse.com>: >> If you run this in 1.1: >> >> | dict | >> dict := WeakKeyDictionary new. >> dict at: 'foo' copy put: 'bar'. >> Smalltalk garbageCollect. >> dict associationsDo: [:assoc | self halt]. >> dict do: [:val | self halt] >> >> >> It stops in the second halt, but not the first. >> >> This is because #associationsDo: does not include associations whose >> keys have been GCed, but #do: *does* include values whose corresponding >> keys have been GCed. >> >> This behavior seems inconsistent, and not particularly useful, and also >> seems to contradict the comments by the author in the Squeak bug from >> 2007, from which I'd think that #do: would not include the value which >> it currently does. >> > It is useful in terms, that sometimes you don't want to see the > objects which GCed, > but sometimes do. See how WeakRegistry using this. > The lack of ephemerons support in VM, forcing us to deal with such > things manually. I see the value in being able to choose both. WeakRegistry uses #allAssociationsDo:, not #associationsDo:. Seems like it would be more consistent to also have an #allDo: that includes values of collected keys, and a #do: that does not. > >> So I *think* this is an oversight, and is easy to fix by defining >> WeakKeyDictionary>>do: in terms of self associationsDo:. >> >> But then there's the question of #size. The collection above answers 1 >> to #size, which also seems wrong. >> > #size for weak key dict is non-deterministic. Because even if you want to know > the exact number of elements, you will need to iterate over the > collection, but then, > iteration can trigger GC, and you have a big chances to answer wrong value. That seems reasonable, though there's no effort to even come close in size. -Martin

Dec. 31, 2009

Re: [Pharo-project] 1.1 -- Inconsistent enumeration behavior of WeakKeyDictionary and subclasses

by Igor Stasenko

2009/12/31 Martin McClure <martin(a)hand2mouse.com>: > If you run this in 1.1: > > | dict | > dict := WeakKeyDictionary new. > dict at: 'foo' copy put: 'bar'. > Smalltalk garbageCollect. > dict associationsDo: [:assoc | self halt]. > dict do: [:val | self halt] > > > It stops in the second halt, but not the first. > > This is because #associationsDo: does not include associations whose > keys have been GCed, but #do: *does* include values whose corresponding > keys have been GCed. > > This behavior seems inconsistent, and not particularly useful, and also > seems to contradict the comments by the author in the Squeak bug from > 2007, from which I'd think that #do: would not include the value which > it currently does. > It is useful in terms, that sometimes you don't want to see the objects which GCed, but sometimes do. See how WeakRegistry using this. The lack of ephemerons support in VM, forcing us to deal with such things manually. > So I *think* this is an oversight, and is easy to fix by defining > WeakKeyDictionary>>do: in terms of self associationsDo:. > > But then there's the question of #size. The collection above answers 1 > to #size, which also seems wrong. > #size for weak key dict is non-deterministic. Because even if you want to know the exact number of elements, you will need to iterate over the collection, but then, iteration can trigger GC, and you have a big chances to answer wrong value. > > Comments? > > Regards, > > -Martin > > _______________________________________________ > 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.

Dec. 31, 2009

Re: [Pharo-project] Developer guide ... ?

by Schwab,Wilhelm K

Levente, Please mention curl early and often. However, there are more uses for SSL than just https, and I've already run aground on limitations of the plugin: access to http(s) headers. Bill -----Original Message----- From: pharo-project-bounces(a)lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Levente Uzonyi Sent: Wednesday, December 30, 2009 11:12 PM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] Developer guide ... ? On Wed, 30 Dec 2009, Schwab,Wilhelm K wrote: > You're twisting what I said; I did not put CORBA at the top, I simply acknowledged that it has some value. SSL is useful to the point that I find NO excuse for its not having been wrapped long ago by Sqeuak. The cryptography team _insisted_ on building their own stack vs. using OpenSSL. They managed it; then they burned out. If I have the facts wrong and am missing code, please tell me. > SSL is useful, though most of the time it's used for HTTPS, and we have the cURL plugin to handle that. And you're right, the Cryptography team doesn't exists anymore, the code was abandoned, but the Croquet guys picked it up and fixed a few bugs in it, though it still has some. The code is available here: http://croquet-src-01.oit.duke.edu:8886/Contributions.html (Note that without the DESPlugin the implementation is really slooooooooooow) Levente > Bill > > > > -----Original Message----- > From: pharo-project-bounces(a)lists.gforge.inria.fr > [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of > Levente Uzonyi > Sent: Wednesday, December 30, 2009 8:16 PM > To: Pharo-project(a)lists.gforge.inria.fr > Subject: Re: [Pharo-project] Developer guide ... ? > > On Wed, 30 Dec 2009, Schwab,Wilhelm K wrote: > >> Levente, >> >> I'll give you a pass on RPC, on SOAP for sure, and _almost_ on CORBA :) However, a culture of dismissing important things as crap lead us to a point approaching 15 years into Squeak's existence where it does not have ready access to SSL. I know about stunnel, but that is more cheat than fix. Pharo needs to embrace the worthy or we will still be on the fringe 15 years from now, and that would be tragic. > > There's an SSL implementation in the Cryptography package, though I don't know if it works or not. > If CORBA is so important then why doesn't exist a free smalltalk implementation after 18 years? > > > Levente > >> >> Bill >> >> >> >> >> -----Original Message----- >> From: pharo-project-bounces(a)lists.gforge.inria.fr >> [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of >> Levente Uzonyi >> Sent: Wednesday, December 30, 2009 7:14 PM >> To: Pharo-project(a)lists.gforge.inria.fr >> Subject: Re: [Pharo-project] Developer guide ... ? >> >> On Wed, 30 Dec 2009, Schwab,Wilhelm K wrote: >> >>> Levente, >>> >>> I have to call you out on something: SSL is **definitely** not crap, and we should have a clean interface to it, probably via OpenSSL. I will eventually create same if not beaten to it. >> >> That's true, I was thinking about the rpc stuff. >> >>> >>> CORBA is also not crap. To be blunt, none of the listed technologies are crap if one has an externally defined problem (aka something that pay$ the bill$) that requires communicating with something that uses them. I will grant you that most of them have a pretty high crap coefficient, and I would not go out of my way to use them unless "forced" to do so. >>> >> >> Crap may not be the best word (but fits really well IMO), so overcomplicated bloatware. >> >> >> Levente >> >>> Bill >>> >>> >>> >>> >>> -----Original Message----- >>> From: pharo-project-bounces(a)lists.gforge.inria.fr >>> [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of >>> Levente Uzonyi >>> Sent: Wednesday, December 30, 2009 5:45 PM >>> To: Pharo-project(a)lists.gforge.inria.fr >>> Subject: Re: [Pharo-project] Developer guide ... ? >>> >>> On Wed, 30 Dec 2009, Guido Stepken wrote: >>> >>> [snip] >>> >>> As others pointed out, these are implemented with blocks. What would you do if, say you wanted to know how to do threading in java? Reading a book or googling is helpful: >>> - http://www.google.com/search?q=squeak+threads >>> (I guess a chapter on processes would be useful in PBE/SBE.) >>> >>>> 5. Standards: XML-RPC, SOAP, RMI, CORBA, .... encryption (SSL) ... >>>> Without having a precise idea, where to find working examples to >>>> exchance data with other systems, i would hesitate to begin to do projects with Pharo/Squeak... >>> >>> Some of this crap is available at squeaksource/squeakmap. >>> >>> Levente >>> >>> >>> _______________________________________________ >>> 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 >> > > _______________________________________________ > 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

Dec. 31, 2009

[Pharo-project] 1.1 -- Inconsistent enumeration behavior of WeakKeyDictionary and subclasses

by Martin McClure

If you run this in 1.1: | dict | dict := WeakKeyDictionary new. dict at: 'foo' copy put: 'bar'. Smalltalk garbageCollect. dict associationsDo: [:assoc | self halt]. dict do: [:val | self halt] It stops in the second halt, but not the first. This is because #associationsDo: does not include associations whose keys have been GCed, but #do: *does* include values whose corresponding keys have been GCed. This behavior seems inconsistent, and not particularly useful, and also seems to contradict the comments by the author in the Squeak bug from 2007, from which I'd think that #do: would not include the value which it currently does. So I *think* this is an oversight, and is easy to fix by defining WeakKeyDictionary>>do: in terms of self associationsDo:. But then there's the question of #size. The collection above answers 1 to #size, which also seems wrong. Comments? Regards, -Martin

Dec. 31, 2009

Re: [Pharo-project] Developer guide ... ?

by Levente Uzonyi

On Wed, 30 Dec 2009, Schwab,Wilhelm K wrote: > You're twisting what I said; I did not put CORBA at the top, I simply acknowledged that it has some value. SSL is useful to the point that I find NO excuse for its not having been wrapped long ago by Sqeuak. The cryptography team _insisted_ on building their own stack vs. using OpenSSL. They managed it; then they burned out. If I have the facts wrong and am missing code, please tell me. > SSL is useful, though most of the time it's used for HTTPS, and we have the cURL plugin to handle that. And you're right, the Cryptography team doesn't exists anymore, the code was abandoned, but the Croquet guys picked it up and fixed a few bugs in it, though it still has some. The code is available here: http://croquet-src-01.oit.duke.edu:8886/Contributions.html (Note that without the DESPlugin the implementation is really slooooooooooow) Levente > Bill > > > > -----Original Message----- > From: pharo-project-bounces(a)lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Levente Uzonyi > Sent: Wednesday, December 30, 2009 8:16 PM > To: Pharo-project(a)lists.gforge.inria.fr > Subject: Re: [Pharo-project] Developer guide ... ? > > On Wed, 30 Dec 2009, Schwab,Wilhelm K wrote: > >> Levente, >> >> I'll give you a pass on RPC, on SOAP for sure, and _almost_ on CORBA :) However, a culture of dismissing important things as crap lead us to a point approaching 15 years into Squeak's existence where it does not have ready access to SSL. I know about stunnel, but that is more cheat than fix. Pharo needs to embrace the worthy or we will still be on the fringe 15 years from now, and that would be tragic. > > There's an SSL implementation in the Cryptography package, though I don't know if it works or not. > If CORBA is so important then why doesn't exist a free smalltalk implementation after 18 years? > > > Levente > >> >> Bill >> >> >> >> >> -----Original Message----- >> From: pharo-project-bounces(a)lists.gforge.inria.fr >> [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of >> Levente Uzonyi >> Sent: Wednesday, December 30, 2009 7:14 PM >> To: Pharo-project(a)lists.gforge.inria.fr >> Subject: Re: [Pharo-project] Developer guide ... ? >> >> On Wed, 30 Dec 2009, Schwab,Wilhelm K wrote: >> >>> Levente, >>> >>> I have to call you out on something: SSL is **definitely** not crap, and we should have a clean interface to it, probably via OpenSSL. I will eventually create same if not beaten to it. >> >> That's true, I was thinking about the rpc stuff. >> >>> >>> CORBA is also not crap. To be blunt, none of the listed technologies are crap if one has an externally defined problem (aka something that pay$ the bill$) that requires communicating with something that uses them. I will grant you that most of them have a pretty high crap coefficient, and I would not go out of my way to use them unless "forced" to do so. >>> >> >> Crap may not be the best word (but fits really well IMO), so overcomplicated bloatware. >> >> >> Levente >> >>> Bill >>> >>> >>> >>> >>> -----Original Message----- >>> From: pharo-project-bounces(a)lists.gforge.inria.fr >>> [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of >>> Levente Uzonyi >>> Sent: Wednesday, December 30, 2009 5:45 PM >>> To: Pharo-project(a)lists.gforge.inria.fr >>> Subject: Re: [Pharo-project] Developer guide ... ? >>> >>> On Wed, 30 Dec 2009, Guido Stepken wrote: >>> >>> [snip] >>> >>> As others pointed out, these are implemented with blocks. What would you do if, say you wanted to know how to do threading in java? Reading a book or googling is helpful: >>> - http://www.google.com/search?q=squeak+threads >>> (I guess a chapter on processes would be useful in PBE/SBE.) >>> >>>> 5. Standards: XML-RPC, SOAP, RMI, CORBA, .... encryption (SSL) ... >>>> Without having a precise idea, where to find working examples to >>>> exchance data with other systems, i would hesitate to begin to do projects with Pharo/Squeak... >>> >>> Some of this crap is available at squeaksource/squeakmap. >>> >>> Levente >>> >>> >>> _______________________________________________ >>> 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 >> > > _______________________________________________ > 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 >

Dec. 31, 2009

Re: [Pharo-project] Developer guide ... ?

by Igor Stasenko

2009/12/31 Schwab,Wilhelm K <bschwab(a)anest.ufl.edu>: > Cesar, > > Sometimes rewriting is exactly the right thing to do. Â For example, Object Arts wrapped the Microsoft XML library. Â First, there is the question of untrusted input and MS binaries (yikes!!!), but also, any time bad input went into it, it would fire off an error with no indication of where it got into trouble. Â For some reason, MS did not think to take an IStream pointer that would have allowed one to check the position. > > For an http client, OA again wrapped MS binaries, complete with the typical punishing timeouts under MS control, and being hobbled if IE had been set (or set itself) to work offline. > I really , see no reason why one would want to wrap such things around. They are so basic, so easy to implement by yourself and not being dependent on crap which comes from MS. > Dolphin is a wonderful product, but users would have been better served with home-grown code in those cases. > > Bottom line: I think we should rewrite when it makes sense to do so, and wrap just about anything that makes sense for interoperability. Â Clearly there is a lot to wrap, and priorities must be set, as it will often fall on an individual to do the dirty work. Â SSL is a no-brainer. > Why keep bugging about missing bindings to foo/bar? If you would really need them, you would already implement them by yourself. Event if you are not skilled enough to deal with FFI/primitives stuff, there are a lot of people who do , and can help you with that. Just ask. > Bill > -- Best regards, Igor Stasenko AKA sig.

Dec. 31, 2009

[Pharo-project] Can't debug in 1.1

by Martin McClure

This one's pretty nasty. Symptom: The debugger in recent and current 1.1 images is completely broken. To reproduce (save your image first!): "self halt" doit. It goes into an infinite loop, and if there's a way to get out of that without killing the VM I'd like to know about it. Alt-. works, but just tries to open another debugger, which goes into another infinite loop, etc. Cause: DebuggerMethodMap>MapCache is a WeakIdentityKeyDictionary, but it is corrupt. It has an array of 22 nils, expired is 0, so it contains nothing, but tally=16. This causes MapCache to lie about its size. This drives DebuggerMethodMap class>>cacheDebugMap:forMethod: into an infinite loop, the whileTrue: condition is always true, it keeps trying to remove non-existent elements to get the size to be less than 16 but the size is always 16. I don't see any obvious code paths to get into this state. I suspect it may have been left in this state when weak collections were updated with the new code not too long ago. Cure: In an inspector, set tally=0. Debuggers then work again. Not sure how to package this as a slice, so I'll leave the update to someone else, and get back to hashing, which was hard when every walkback froze my system :-) Regards, -Martin

Dec. 31, 2009