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

Re: [Pharo-project] Why is readStream on SequenceableCollection and not on Collection?

by Bart Gauquie

On Wed, Aug 25, 2010 at 10:38 AM, Henrik Johansen < henrik.s.johansen(a)veloxit.no> wrote: > > > Den 24.08.2010 17:58, skrev Nicolas Cellier: > > 2010/8/24 Schwab,Wilhelm K <bschwab(a)anest.ufl.edu>: > > > >> This cropped up in Dolphin some years back. IIRC, OA's answer was that > streams historically worked on only Array and maybe something else. Having > said that, they relaxed a constraint because it was harmless and a good > idea. > >> > >> I'm not sure about streaming over a set; lack of order means that it > might be tricky to maintain a reasonable position?? > >> > >> > > Exactly, the Stream would hardly be positionable, unless you use a > > sort of OrderedSet... > > A ReadWriteStream would be problematic for the same reasons. > > > > What would be the interest of such a Stream ? > > (I mean something more than what just you can do with #do:or #add:) > > > > Nicolas > +1. > I don't quite see what use could would find in a stream of a > non-sequenced source that is not better served by using a different > abstraction, or the source itself.. > > Cheers, > Henry > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > Ok, but why can you then do a collect:[] / select:[] / do: [] over a set? It also iterates over all the elements. So why is it then strange to have a readstream over a set? I'm not saying it should be a positionable stream. But I also agree that is more logical to only do a ReadStream over a SequenceableCollection if you take into account positions ... Maybe change the code so that it only accepts a SequenceableCollection? Haven't tried Nile yet. Kind Regards, Bart

Aug. 25, 2010

Re: [Pharo-project] String to Number conversion

by Schwab,Wilhelm K

While I'm on rant, what happened to the good old day when men were men and 2+'2' was not 4? I *still* have bugs in my R data frame code because of that nonsense - just tell me I blew it, please?? Ceorsing integers to floats to make things like 2+Float pi is a good thing, converting strings to numbers is coddling that ultimately backfires. Bill ________________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Schwab,Wilhelm K [bschwab(a)anest.ufl.edu] Sent: Wednesday, August 25, 2010 5:01 AM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] String to Number conversion Squeak has a long tradition of silent failures of all types (in the image and the vm), and IMNSHO, it is a **really** bad idea with terrible consequences and needs to be fixed. Default actions that return nil merely push problems down stream to a point where there is no context to figure out what went wrong. I think much of this goes back to the late 70's and early 80's, before structured exception handling, and has never been modernized. Dolphin, which started life in the mid 90's, is built from the ground up to do these things correctly. Once one learns that the exceptions are indeed helping to make things work reliably, it is hard to imagine making something robust without them. Exceptions can be expensive, both to set up handlers, and even more so when exceptions are thrown. You have identified the answer, which is to provide #readFrom:ifFail: (or #readFrom:onError: - whatever you want to call it) that evaluates a block when things go wrong, which allows one to bypass the overhead, much like #at:ifAbsent:; if error and remedy are near by, it is easy to do and skips the overhead. For the lazy<g>, or simply for frameworks that can/should use exceptions to handle exceptional conditions (big separation between the problem and anything that knows how to cope with it), #readFrom: (without the block) does the robust/correct thing, and raises an exception. As you no doubt know, it can (often should) be written in terms of #readFrom:ifFail: with the block raising the exception. Things will break for a while, but I hesitate to think how much stuff is just plain broken and we never notice it because things answer nil and/or ignore error conditions. The industry tried to formalize such head-in-the-sand-hope-it-goes-away design under the fancy name "defensive programming." It remains a useful approach when used sparingly to keep critical systems running, but it generally failed under its own lack of merit. It was popularized as a way to cope with the dreaded UAEs of 16 bit Windows, which was in turn due to the lack of exception handling and ensured execution in the GUI, which lead to incomplete cleanup, memory leaks, and all kinds of crashes. YES. PLEASE DO THIS. **GREAT** IDEA. You might take a look at http://www.squeaksource.com/PharoInbox/DolphinCompatibility-Streams-BillSch… for what I consider to be very much related changes to stream I/O. Since it quickly became obvious to me that #next and #next: were not going to change any time soon, I simply stopped using them myself; instead I write code using #nextOne, #nextMany:, and #nextAvailable:. You will also find methods such as #nextDWORD to help with binary file formats, device interfacing, etc . It is a work in progress, but the idea is to have read streams bark when they run out of data, unless (#nextAvailable:) specifically authorized to truncate. I also have some text converters modeled after Dolphin's framework. I don't think I have released those yet, but plan to do so eventually. Because of the problem you have identified, I have added some tests (and throw exceptions when they fail) for whether the stream is or is not at the end or read an expected number of types, etc. Thanks for working on this! Bill ________________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Guillermo Polito [guillermopolito(a)gmail.com] Sent: Tuesday, August 24, 2010 4:33 PM To: Pharo-project(a)lists.gforge.inria.fr Subject: [Pharo-project] String to Number conversion http://code.google.com/p/pharo/issues/detail?id=2857 Which will be the impact in the system and other tools to throw an error when the conversion cannot take place? I think an error must be thrown, but should it be in Pharo 1.2 or in next version? On Tue, Aug 24, 2010 at 11:45 AM, Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com<mailto:nicolas.cellier.aka.nice@gmail.com>> wrote: In squeak, (Integer readFromString: 'foo') ->Error Use: - Integer readFrom: 'foo' ifFail: [0], tp get backward compatibility, - (Integer readFrom: 'foo' ifFail: []), to get nil Though it is possible, I dislike anwsering nil, because it would mean a bunch of #readFrom: send should be protected by #ifNil: Blocks... 1) That's nonsense, readFrom:ifFail: already does the work. 2) you cripple the code with Error conditions and end up with unreadable C-looking like code (3 lines of Error condition crap for 1 line of underlying algorithm at every function call) 3) Exception handling can avoid long chains of ifFail: / ifNil: tests But that conversation already took place many times... I'd like the readFrom:ifFail: form to be generalized to other objects, with default behaviour raising an Error. What do you think ? Nicolas 2010/8/24 Johan Brichau <johan(a)inceptive.be<mailto:johan@inceptive.be>>: > > On 24 Aug 2010, at 15:19, StÃ©phane Ducasse wrote: > >> I thought that readFromString: was raising an error and that guessNumber* was returning zero > > I thought that too. I even have application code that shows that this used to return nil in some version of Pharo... > But: > > 'foo' asInteger = nil > Integer readFromString: 'foo' = 0 > 'foo' asNumber -> Error > > aargh :-( > > disclaimer: currently testing this in pharo1.1 > > Johan > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr<mailto:Pharo-project@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<mailto:Pharo-project@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

Aug. 25, 2010

Re: [Pharo-project] [SPAM] Re: why are Bitmaps instanciated even in headless mode?

by Sven Van Caekenberghe

It depends on how you look at it: a properly configured deployed seaside image will have zero windows and will never popup anything, so it makes no difference. I never use the RFB model, mostly out of principle, a server app should not have a classic gui. The seaside development tools allow you to upgrade MC packages, browse code, execute doits, save the image, kill processes, ... That being said, the headless support in VW 7 is very nice (mainly capturing display activity into errors, errors/transcript go to stdout/stderr/logfile, options to make std image headless and vice versa). Sven On 25 Aug 2010, at 12:18, Schwab,Wilhelm K wrote: > That makes complete sense, and it is a crushingly disappointing realization :( I'll get over it, but it is all the more reason to eventually strive for the Dolphin session-based model. Then deployed console apps would not have a GUI at all, for real. I will admit that there is something to be said for having something running headless and then magically popping into a GUI, locally or remotely, but something that is really headless, not merely making a bunch of calls that are artificially no-ops, has value too and we can't build that right now. > > BTW, hopefully no one is thinking of making it impossible to create bitmaps when headless, right? That would be bad for web servers and other things that create graphics for use elsewhere. Sorry to even mention it, but... > > Bill > > > ________________________________________ > From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Sven Van Caekenberghe [sven(a)beta9.be] > Sent: Tuesday, August 24, 2010 8:59 AM > To: Pharo-project(a)lists.gforge.inria.fr > Subject: Re: [Pharo-project] why are Bitmaps instanciated even in headless mode? > > > Running -headless (actually -vm-display-null -vm-sound-null) just instructs the VM to connect to a dummy (null) display and sound device, so that display operations have no effect, as far as I understand. > > Sven > > > _______________________________________________ > 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

Aug. 25, 2010

Re: [Pharo-project] #hasClassNamed

by StÃ©phane Ducasse

On Aug 25, 2010, at 10:37 AM, Torsten Bergmann wrote: > Stef wrote: >> well named: means that you expect a name no? > > When I type and write Object I write down the name of the class > Object, dont I? > > Thats why I'm not sure. I think it is more a philosophical > problem... sounds like :) > > Bye > T. > > -- > Neu: GMX De-Mail - Einfach wie E-Mail, sicher wie ein Brief! > Jetzt De-Mail-Adresse reservieren: http://portal.gmx.net/de/go/demail > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Aug. 25, 2010

Re: [Pharo-project] Philippe's WebClient patches

by StÃ©phane Ducasse

Ok sven could publish the merge in the inbox? Since you know your changes, else I will have to understand both :) > I just had a quick look (comparing pmm's latest package with 1.2 latest) and the merge should be feasable: there are some style differences (asString vs printString) some of my fixes are later/better, some of him are better... > > It is really amazing that somebody else also put in this effort (a good thing for Pharo though) > > On 25 Aug 2010, at 09:43, StÃ©phane Ducasse wrote: > >> Hi guys >> >> Philippe sent me these patches that apparently did not get into the webclient trunk. I will integrate them later with >> our fork since it does not seem possible otherwise. >> >> Stef >> >> >>> Anyway here are my patches. >>> >>> >>> Cheers >>> Philippe >> <WebClient-Core-pmm.54.mcz><WebClient-Core-pmm.59.mcz><WebClient-Core-pmm.60.mcz><WebClient-Core-pmm.61.mcz><WebClient-Core-pmm.67.mcz><WebClient-Core-pmm.68.mcz> >>> >>> >> >> _______________________________________________ >> 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

Aug. 25, 2010

Re: [Pharo-project] Fwd: About SPDF

by StÃ©phane Ducasse

>> Similar to iText for Java, this allows you change the >> license and block your government later ;), see the story >> of Bruno Lowagie [1] > > Don't you just like Belgium and the Belgians ? > > We're definitively in one of the most absurd and surreal places imaginable. come on france is not that bad on this level too.... :) > > Sven > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Aug. 25, 2010

Re: [Pharo-project] String to Number conversion

by StÃ©phane Ducasse

Ok I will have to read it finally :) Stef On Aug 25, 2010, at 11:01 AM, Schwab,Wilhelm K wrote: > Squeak has a long tradition of silent failures of all types (in the image and the vm), and IMNSHO, it is a **really** bad idea with terrible consequences and needs to be fixed. Default actions that return nil merely push problems down stream to a point where there is no context to figure out what went wrong. I think much of this goes back to the late 70's and early 80's, before structured exception handling, and has never been modernized. Dolphin, which started life in the mid 90's, is built from the ground up to do these things correctly. Once one learns that the exceptions are indeed helping to make things work reliably, it is hard to imagine making something robust without them. > > Exceptions can be expensive, both to set up handlers, and even more so when exceptions are thrown. You have identified the answer, which is to provide #readFrom:ifFail: (or #readFrom:onError: - whatever you want to call it) that evaluates a block when things go wrong, which allows one to bypass the overhead, much like #at:ifAbsent:; if error and remedy are near by, it is easy to do and skips the overhead. For the lazy<g>, or simply for frameworks that can/should use exceptions to handle exceptional conditions (big separation between the problem and anything that knows how to cope with it), #readFrom: (without the block) does the robust/correct thing, and raises an exception. As you no doubt know, it can (often should) be written in terms of #readFrom:ifFail: with the block raising the exception. > > Things will break for a while, but I hesitate to think how much stuff is just plain broken and we never notice it because things answer nil and/or ignore error conditions. The industry tried to formalize such head-in-the-sand-hope-it-goes-away design under the fancy name "defensive programming." It remains a useful approach when used sparingly to keep critical systems running, but it generally failed under its own lack of merit. It was popularized as a way to cope with the dreaded UAEs of 16 bit Windows, which was in turn due to the lack of exception handling and ensured execution in the GUI, which lead to incomplete cleanup, memory leaks, and all kinds of crashes. > > YES. PLEASE DO THIS. **GREAT** IDEA. You might take a look at > > http://www.squeaksource.com/PharoInbox/DolphinCompatibility-Streams-BillSch… > > for what I consider to be very much related changes to stream I/O. Since it quickly became obvious to me that #next and #next: were not going to change any time soon, I simply stopped using them myself; instead I write code using #nextOne, #nextMany:, and #nextAvailable:. You will also find methods such as #nextDWORD to help with binary file formats, device interfacing, etc . > > It is a work in progress, but the idea is to have read streams bark when they run out of data, unless (#nextAvailable:) specifically authorized to truncate. I also have some text converters modeled after Dolphin's framework. I don't think I have released those yet, but plan to do so eventually. Because of the problem you have identified, I have added some tests (and throw exceptions when they fail) for whether the stream is or is not at the end or read an expected number of types, etc. > > Thanks for working on this! > > Bill > > > > ________________________________________ > From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Guillermo Polito [guillermopolito(a)gmail.com] > Sent: Tuesday, August 24, 2010 4:33 PM > To: Pharo-project(a)lists.gforge.inria.fr > Subject: [Pharo-project] String to Number conversion > > http://code.google.com/p/pharo/issues/detail?id=2857 > > Which will be the impact in the system and other tools to throw an error when the conversion cannot take place? > I think an error must be thrown, but should it be in Pharo 1.2 or in next version? > > On Tue, Aug 24, 2010 at 11:45 AM, Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com<mailto:nicolas.cellier.aka.nice@gmail.com>> wrote: > In squeak, (Integer readFromString: 'foo') ->Error > > Use: > - Integer readFrom: 'foo' ifFail: [0], tp get backward compatibility, > - (Integer readFrom: 'foo' ifFail: []), to get nil > > Though it is possible, I dislike anwsering nil, because it would mean > a bunch of #readFrom: send should be protected by #ifNil: Blocks... > 1) That's nonsense, readFrom:ifFail: already does the work. > 2) you cripple the code with Error conditions and end up with > unreadable C-looking like code > (3 lines of Error condition crap for 1 line of underlying algorithm > at every function call) > 3) Exception handling can avoid long chains of ifFail: / ifNil: tests > > But that conversation already took place many times... > > I'd like the readFrom:ifFail: form to be generalized to other objects, > with default behaviour raising an Error. What do you think ? > > Nicolas > > 2010/8/24 Johan Brichau <johan(a)inceptive.be<mailto:johan@inceptive.be>>: >> >> On 24 Aug 2010, at 15:19, StÃ©phane Ducasse wrote: >> >>> I thought that readFromString: was raising an error and that guessNumber* was returning zero >> >> I thought that too. I even have application code that shows that this used to return nil in some version of Pharo... >> But: >> >> 'foo' asInteger = nil >> Integer readFromString: 'foo' = 0 >> 'foo' asNumber -> Error >> >> aargh :-( >> >> disclaimer: currently testing this in pharo1.1 >> >> Johan >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr<mailto:Pharo-project@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<mailto:Pharo-project@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

Aug. 25, 2010

Re: [Pharo-project] Inter-image communication

by Noury Bouraqadi

On 14 aoÃ»t 2010, at 18:53, Mariano Martinez Peck wrote: > > > On Sat, Aug 14, 2010 at 4:11 PM, Sean P. DeNigris <sean(a)clipperadams.com> wrote: > > > Noury Bouraqadi-2 wrote: > > > > Yes. But, we need an appropriate set of tools. We (Douai's team) developed > > a few tools a while ago as part of the UbiquiTalk project. We had a > > remote-workspace working quite fine. > > > > Is this code available? > > I guess > http://www.squeaksource.com/UbiquiTalk Yes. More info on: http://vst.ensm-douai.fr/UbiquiTalk Noury > Thanks, > Sean > -- > View this message in context: http://forum.world.st/Inter-image-communication-tp2320723p2325234.html > 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 > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project Noury

Aug. 25, 2010

Re: [Pharo-project] why are Bitmaps instanciated even in headless mode?

by Schwab,Wilhelm K

That makes complete sense, and it is a crushingly disappointing realization :( I'll get over it, but it is all the more reason to eventually strive for the Dolphin session-based model. Then deployed console apps would not have a GUI at all, for real. I will admit that there is something to be said for having something running headless and then magically popping into a GUI, locally or remotely, but something that is really headless, not merely making a bunch of calls that are artificially no-ops, has value too and we can't build that right now. BTW, hopefully no one is thinking of making it impossible to create bitmaps when headless, right? That would be bad for web servers and other things that create graphics for use elsewhere. Sorry to even mention it, but... Bill ________________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Sven Van Caekenberghe [sven(a)beta9.be] Sent: Tuesday, August 24, 2010 8:59 AM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] why are Bitmaps instanciated even in headless mode? Running -headless (actually -vm-display-null -vm-sound-null) just instructs the VM to connect to a dummy (null) display and sound device, so that display operations have no effect, as far as I understand. Sven _______________________________________________ Pharo-project mailing list Pharo-project(a)lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Aug. 25, 2010

Re: [Pharo-project] Philippe's WebClient patches

by Sven Van Caekenberghe

I just had a quick look (comparing pmm's latest package with 1.2 latest) and the merge should be feasable: there are some style differences (asString vs printString) some of my fixes are later/better, some of him are better... It is really amazing that somebody else also put in this effort (a good thing for Pharo though) On 25 Aug 2010, at 09:43, StÃ©phane Ducasse wrote: > Hi guys > > Philippe sent me these patches that apparently did not get into the webclient trunk. I will integrate them later with > our fork since it does not seem possible otherwise. > > Stef > > >> Anyway here are my patches. >> >> >> Cheers >> Philippe > <WebClient-Core-pmm.54.mcz><WebClient-Core-pmm.59.mcz><WebClient-Core-pmm.60.mcz><WebClient-Core-pmm.61.mcz><WebClient-Core-pmm.67.mcz><WebClient-Core-pmm.68.mcz> >> >> > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Aug. 25, 2010