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

Re: [Pharo-project] Question about deepCopy,

by Stan Shepherd

arnaud Jean Baptiste wrote: > > > I don't suggest to rename #deepCopy, i suggest to replace the behavior > of #deepCopy by #veryDeepCopy behavior. > >From my observation, the two do not have identical behaviour. In my own case, I need the behaviour of deepCopy to avoid copying a very large object unnecessarily; for now I have a specific method for the object copyWithoutCircularity. There are 44 senders of deepCopy, which would need testing. Another solution is to rewrite deepCopy like veryDeepCopy, to have a copier object. This needs another method on Object, deepCopyWith: I'm happy to implement a solution, given a consensus on the best way to do this. I have created a general test case for this situation, attached to issue 521 http://pharo.googlecode.com/issues/attachment?aid=7298911011553982520&name=… ...Stan -- View this message in context: http://n2.nabble.com/Question-about-deepCopy-tp3859147p3923585.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Oct. 31, 2009

Re: [Pharo-project] About FixedIdentitySet

by Martin McClure

Nicolas Cellier wrote: > I just noticed this: > > (FixedIdentitySet withAll: #(a b c)) = #(a a a). > > I presume that does not matter... > > > FixedIdentitySet also make usage of identityHash > - with a basicSize power of two > - using bitAnd: rather than modulo (because of the size being power of > two, that should be equivalent) > I guess it works because used with small size only... > Beware not using scaledIdentityHash then ! Yes, I noticed that; FixedIdentitySet was the only class other than MethodDictionary that needed to use the unscaled primIdentityHash. I wondered what FixedIdentitySet was used for, it seems like a very odd beast, but I didn't dig into it. Regards, -Martin

Oct. 31, 2009

Re: [Pharo-project] Socket>>socketStream

by Igor Stasenko

2009/10/31 Schwab,Wilhelm K <bschwab(a)anest.ufl.edu>: > Sig, > > Furthering a bad design practice does not illustrate an attempts to promote safe use of resources. Â If you knew that adding the behavior was a bad idea, why did you suggest it? > because, as to me, what you are proposing is equivalent to it. In smalltalk you can enforce the correct usage of provided functionality only by means of provided behavior. > Server behavior: consider listening on ports and accepting connections. Â True, that is BSD socket behavior, but you are trying to have it both ways. Â You cannot complain about superset behavior that I might introduce and then later say that the current design is ok because it uses the same shotgun wedding approach as BSD (aka a superset interface). > we have what we have. :) If you'd were writing own library for network communication which directly speaks with hardware (like in SqueakNOS), then you are free to do it differently. But Socket implementation depends on underlaying socket library, adopted by wide range of OSes working with wide range of hardware. It is good that we having something in common and don't need to invent or implement it from scratch. And despite how good or bad it is, it allows us to write portable software, including smalltalk, unless you refactor Socket class :) > Taking your approach, nothing in Squeak would ever get fixed. Â In fact, "well, YOU can always do such and such in YOUR image" was the usual argument used to block change in Squeak. Â Something to think about. > if there will be fix or extension in original socket library, only then we should consider synchronizing Socket class with it. > And yes, replacing the entire network system has crossed my mind. Â IPv4 and 6 are currently mixed into a big ball of mud (no offense to those working hard to add it, but it's not at all factored, and should be). Â I will hopefully soon be in a position to get network connections running across platforms, and I suspect that the errors reported some months ago will turn out to be due to the new sockets. Â Finally, we should have access to SSL sockets via OpenSSL. Â That might just drop in along side of the current socket system, but there might be room for a better solution, perhaps as an extension of Nile. > as long as you are using same library (sockets), i see not much reasons why we would need to drastically refactor the stuff. Because, with whatever code will wrap it, you end up using same system calls which expecting same argument types & returning same results. So, instead of 'better wrapper', we should expose these calls to language, as close as possible to original and this is the main role of Socket class. Then anyone is free to use them as he likes to. This is what i meant by talking about 'own subclass' and this is why i think that Socket class is bad place for refactory. My point is, that if you writing own library/classes, which having virtually no dependencies from other frameworks, then you are free to do it in any way you like to. But if your goal is to expose the functionality of existing library (such as sockets), then instead, you should be very pedantic and do it as much as close to original, despite how good or bad it is. Then you are opening doors to people who already used this library before, but in another environment/language. -- Best regards, Igor Stasenko AKA sig.

Oct. 31, 2009

[Pharo-project] About FixedIdentitySet

by Nicolas Cellier

I just noticed this: (FixedIdentitySet withAll: #(a b c)) = #(a a a). I presume that does not matter... FixedIdentitySet also make usage of identityHash - with a basicSize power of two - using bitAnd: rather than modulo (because of the size being power of two, that should be equivalent) I guess it works because used with small size only... Beware not using scaledIdentityHash then ! Shouldn't the read-only version really use an Array, up to a given size greater than 0 or 1 ?

Oct. 31, 2009

Re: [Pharo-project] Socket>>socketStream

by Schwab,Wilhelm K

Sig, Furthering a bad design practice does not illustrate an attempts to promote safe use of resources. If you knew that adding the behavior was a bad idea, why did you suggest it? Server behavior: consider listening on ports and accepting connections. True, that is BSD socket behavior, but you are trying to have it both ways. You cannot complain about superset behavior that I might introduce and then later say that the current design is ok because it uses the same shotgun wedding approach as BSD (aka a superset interface). Taking your approach, nothing in Squeak would ever get fixed. In fact, "well, YOU can always do such and such in YOUR image" was the usual argument used to block change in Squeak. Something to think about. And yes, replacing the entire network system has crossed my mind. IPv4 and 6 are currently mixed into a big ball of mud (no offense to those working hard to add it, but it's not at all factored, and should be). I will hopefully soon be in a position to get network connections running across platforms, and I suspect that the errors reported some months ago will turn out to be due to the new sockets. Finally, we should have access to SSL sockets via OpenSSL. That might just drop in along side of the current socket system, but there might be room for a better solution, perhaps as an extension of Nile. Bill -----Original Message----- From: pharo-project-bounces(a)lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Igor Stasenko Sent: Friday, October 30, 2009 6:01 PM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] Socket>>socketStream 2009/10/30 Schwab,Wilhelm K <bschwab(a)anest.ufl.edu>: > Sig, > > Exposing the streams is an interesting idea, and I think I could adapt it should I ever want to back-port what I am doing to Dolphin (something I want to keep open to allow an incremental escape from Windows). Â That might be the answer. > > Subclassing socket to add stream protocol is a very bad idea IMHO - there is too much overuse of inheritance in Squeak, and that would only add to it. > Right, it is BAD idea. I just illustrated the idea of keeping 1:1 correspondence between socket and stream at the extremum :) > Re UDP sockets, I could ask similar questions about the current mix of client and server behavior in Socket. > what exactly you mean by server behavior? For what i see in Socket, its a wrapping aroung BSD-socket functionality, so you can send #accept using wrong socket as well as in C you can call accept() function and get similar results. Making a Socket interface behave similar to original sockets library, despite how bad or good the original design, having own reasons, which not even worth mentioning. So, i prefer to leave Socket to resemble the original BSD sockets functionality & behavior as close as possible, and if one wants a custom behavior, he can always create a subclass, or wrap it with own object, such as stream or whatever.. > Thanks! > > Bill > > > -----Original Message----- > From: pharo-project-bounces(a)lists.gforge.inria.fr > [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Igor > Stasenko > Sent: Friday, October 30, 2009 3:54 PM > To: Pharo-project(a)lists.gforge.inria.fr > Subject: Re: [Pharo-project] Socket>>socketStream > > 2009/10/30 Schwab,Wilhelm K <bschwab(a)anest.ufl.edu>: >> Hello all, >> >> What would be involved in adding a socket stream instance variable/accessor to Socket? Â Is that something you would support? Â So far, I created a shared dictionary (cleared on true startup) of sockets to streams, so once created, the stream is associated with the corresponding socket, and accessible from same using #socketStream. Â From there, I have #readStream and #writeStream accessors, which return the one stream - Dolphin separates them, and there is no reason to break the news to my code just yet. >> > > Err... what kind of stream you would answer for UDP socket, a socket which inherently doesn't mean to support streaming capabilities? > The only reason why i would need to enforce 1:1 association of stream-based socket with corresponding stream is to make sure that nobody constructs multiple streams for using the same socket and in this way abuses it. But i wouldn't care about that. There are numerous ways how to shoot in own foot, and given case is very unlikely happen, unless you doing a really stupid things, like exposing the sockets to different layers of your application instead of exposing the streams which they should use. > > But from this perspective, wouldn't it be better to simply create a subclass of Socket, which supports a stream protocol, so you enforcing the 1:1 rule from very start and there is no way how to create one socket to many streams association. > >> Bill >> >> >> >> _______________________________________________ >> 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. _______________________________________________ Pharo-project mailing list Pharo-project(a)lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Oct. 30, 2009

Re: [Pharo-project] Socket>>socketStream

by Igor Stasenko

2009/10/30 Schwab,Wilhelm K <bschwab(a)anest.ufl.edu>: > Sig, > > Exposing the streams is an interesting idea, and I think I could adapt it should I ever want to back-port what I am doing to Dolphin (something I want to keep open to allow an incremental escape from Windows). Â That might be the answer. > > Subclassing socket to add stream protocol is a very bad idea IMHO - there is too much overuse of inheritance in Squeak, and that would only add to it. > Right, it is BAD idea. I just illustrated the idea of keeping 1:1 correspondence between socket and stream at the extremum :) > Re UDP sockets, I could ask similar questions about the current mix of client and server behavior in Socket. > what exactly you mean by server behavior? For what i see in Socket, its a wrapping aroung BSD-socket functionality, so you can send #accept using wrong socket as well as in C you can call accept() function and get similar results. Making a Socket interface behave similar to original sockets library, despite how bad or good the original design, having own reasons, which not even worth mentioning. So, i prefer to leave Socket to resemble the original BSD sockets functionality & behavior as close as possible, and if one wants a custom behavior, he can always create a subclass, or wrap it with own object, such as stream or whatever.. > Thanks! > > Bill > > > -----Original Message----- > From: pharo-project-bounces(a)lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Igor Stasenko > Sent: Friday, October 30, 2009 3:54 PM > To: Pharo-project(a)lists.gforge.inria.fr > Subject: Re: [Pharo-project] Socket>>socketStream > > 2009/10/30 Schwab,Wilhelm K <bschwab(a)anest.ufl.edu>: >> Hello all, >> >> What would be involved in adding a socket stream instance variable/accessor to Socket? Â Is that something you would support? Â So far, I created a shared dictionary (cleared on true startup) of sockets to streams, so once created, the stream is associated with the corresponding socket, and accessible from same using #socketStream. Â From there, I have #readStream and #writeStream accessors, which return the one stream - Dolphin separates them, and there is no reason to break the news to my code just yet. >> > > Err... what kind of stream you would answer for UDP socket, a socket which inherently doesn't mean to support streaming capabilities? > The only reason why i would need to enforce 1:1 association of stream-based socket with corresponding stream is to make sure that nobody constructs multiple streams for using the same socket and in this way abuses it. But i wouldn't care about that. There are numerous ways how to shoot in own foot, and given case is very unlikely happen, unless you doing a really stupid things, like exposing the sockets to different layers of your application instead of exposing the streams which they should use. > > But from this perspective, wouldn't it be better to simply create a subclass of Socket, which supports a stream protocol, so you enforcing the 1:1 rule from very start and there is no way how to create one socket to many streams association. > >> Bill >> >> >> >> _______________________________________________ >> 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. 30, 2009

Re: [Pharo-project] Socket>>socketStream

by Schwab,Wilhelm K

Sig, Exposing the streams is an interesting idea, and I think I could adapt it should I ever want to back-port what I am doing to Dolphin (something I want to keep open to allow an incremental escape from Windows). That might be the answer. Subclassing socket to add stream protocol is a very bad idea IMHO - there is too much overuse of inheritance in Squeak, and that would only add to it. Re UDP sockets, I could ask similar questions about the current mix of client and server behavior in Socket. Thanks! Bill -----Original Message----- From: pharo-project-bounces(a)lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Igor Stasenko Sent: Friday, October 30, 2009 3:54 PM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] Socket>>socketStream 2009/10/30 Schwab,Wilhelm K <bschwab(a)anest.ufl.edu>: > Hello all, > > What would be involved in adding a socket stream instance variable/accessor to Socket? Â Is that something you would support? Â So far, I created a shared dictionary (cleared on true startup) of sockets to streams, so once created, the stream is associated with the corresponding socket, and accessible from same using #socketStream. Â From there, I have #readStream and #writeStream accessors, which return the one stream - Dolphin separates them, and there is no reason to break the news to my code just yet. > Err... what kind of stream you would answer for UDP socket, a socket which inherently doesn't mean to support streaming capabilities? The only reason why i would need to enforce 1:1 association of stream-based socket with corresponding stream is to make sure that nobody constructs multiple streams for using the same socket and in this way abuses it. But i wouldn't care about that. There are numerous ways how to shoot in own foot, and given case is very unlikely happen, unless you doing a really stupid things, like exposing the sockets to different layers of your application instead of exposing the streams which they should use. But from this perspective, wouldn't it be better to simply create a subclass of Socket, which supports a stream protocol, so you enforcing the 1:1 rule from very start and there is no way how to create one socket to many streams association. > Bill > > > > _______________________________________________ > 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. 30, 2009

Re: [Pharo-project] Socket>>socketStream

by Igor Stasenko

2009/10/30 Schwab,Wilhelm K <bschwab(a)anest.ufl.edu>: > Hello all, > > What would be involved in adding a socket stream instance variable/accessor to Socket? Â Is that something you would support? Â So far, I created a shared dictionary (cleared on true startup) of sockets to streams, so once created, the stream is associated with the corresponding socket, and accessible from same using #socketStream. Â From there, I have #readStream and #writeStream accessors, which return the one stream - Dolphin separates them, and there is no reason to break the news to my code just yet. > Err... what kind of stream you would answer for UDP socket, a socket which inherently doesn't mean to support streaming capabilities? The only reason why i would need to enforce 1:1 association of stream-based socket with corresponding stream is to make sure that nobody constructs multiple streams for using the same socket and in this way abuses it. But i wouldn't care about that. There are numerous ways how to shoot in own foot, and given case is very unlikely happen, unless you doing a really stupid things, like exposing the sockets to different layers of your application instead of exposing the streams which they should use. But from this perspective, wouldn't it be better to simply create a subclass of Socket, which supports a stream protocol, so you enforcing the 1:1 rule from very start and there is no way how to create one socket to many streams association. > Bill > > > > _______________________________________________ > 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. 30, 2009

[Pharo-project] Socket>>socketStream

by Schwab,Wilhelm K

Hello all, What would be involved in adding a socket stream instance variable/accessor to Socket? Is that something you would support? So far, I created a shared dictionary (cleared on true startup) of sockets to streams, so once created, the stream is associated with the corresponding socket, and accessible from same using #socketStream. From there, I have #readStream and #writeStream accessors, which return the one stream - Dolphin separates them, and there is no reason to break the news to my code just yet. Bill

Oct. 30, 2009

Re: [Pharo-project] [newbee] About different class browsers

by Mariano Martinez Peck

On Fri, Oct 30, 2009 at 4:26 PM, alesch <alex(a)schenkman.info> wrote: > > Hello list: > > What is the name of the class browser that comes standard with Squeak, in > Cassou's dev-images? > How can I get it in Pharo, also with Cassou's dev-images? > > Hello! This is very easy: just open any browser. On the top right of the windows you will see a little button. Click the button and you will see several options. One of them is "Choose default new browser". There you can select the O2PackageBrowserAdaptor Or...as you may know, smalltalk is like Linux. Anything you can do from a windows, you can do it from command line. The same with smalltalk. Everything you do from a windows, you can do it by code. At the end, both send the same message :) So, you can evaluate: SystemBrowser default: (Smalltalk classNamed: #O2PackageBrowserAdaptor). Best regards, Mariano I tried with the halo but I get the halo for SystemWindow... > > Thanks in advance! > > -- > View this message in context: > http://n2.nabble.com/newbee-About-different-class-browsers-tp3920959p392095… > 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. 30, 2009