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

[Pharo-project] [update 1.2] #12112

by stephane ducasse

- Issue 1899: MethodDictionary improvement. Part two. - Issue 2560: Convenient methods from Grease for Strings. We should get more of them. We need cool libraries. - Issue 2857: improve String to Number conversion. readFrom: now raises an error instead of silently returning 0. Thanks Guillermo Polito. Stef

Aug. 25, 2010

Re: [Pharo-project] 'foo' asTime

by Nicolas Cellier

2010/8/25 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: > Hi nicolas > > If I understand you correctly we are in sync. > Yes readFrom: should read or fails raising an Error > and we should use Integer readFrom: 'foo' ifFail: [the default value that the client knows that he wants] > > Now we integrated your number parsers so this is strange that the behavior is not like you mention > did you make them backwards compatible? > > So I would give a try to get readFrom: clean. > Johan please give a try > > Stef > Yes, all the infrastructure is there, just change the top message to be awkward-uncompatible ;) like Guillermo is suggesting. See also my other suggestion: implement #readFrom:ifFail: in every class instead of #readFrom: and let readFrom default implementation to just be ^self readFrom: aStream ifFail: [self error: 'invalid format'] One question I'm not sure about is whether we should distinguish 2 API's: - one for reading a single object and bark on extra-characters - IMO, this would be the correct Behaviour of #readFromString: - one for reading an object in a longer sequence of objects (just keep the stream positionned after last character read) - this would be readFrom: aStream Nicolas > > >> 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>: >>> >>> 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 >>> 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 >

Aug. 25, 2010

[Pharo-project] Really funny bug... :(

by stephane ducasse

Hi guys I was integrated the methodDictionary enh of levente. And after I integrated the addition of some methods into String. Then it seems that I got all the packages extending String dirty. I checked the changes and nothing special. The changed methods are not logged in the changeSorter. So may be the dictionary got rehashed, changed and all the methods went to get "changed". Strange. Stef

Aug. 25, 2010

Re: [Pharo-project] String to Number conversion

by Schwab,Wilhelm K

Stef, I thought about this a little more: perhaps the conversion got started for eToys? I could see somebody adding that to make them work; the Dolphin guy in me then screams Value-Adapter!!! :) A quick look at my image does not reveal an aspect value adapter and a converter; I thought I had built them. I probably did and lost track of them due to my (for far too long) woefully incomplete understanding of package info and MC. The basic idea is that a suitable object can be "clipped" between a thing that understands #value and #value: and a consumer. With some artful use, a text editor can then be used, for example, to edit a floating point aspect of something else. Having real closures vs. Smalltalk-80 blocks will only make it easier to get it right. I will look for an existing implementation of mine or put it in the queue; we can't not have these things. Bill ________________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of StÃ©phane Ducasse [stephane.ducasse(a)inria.fr] Sent: Wednesday, August 25, 2010 12:44 PM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] String to Number conversion +1 Stef On Aug 25, 2010, at 12:53 PM, Schwab,Wilhelm K wrote: > 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 > > _______________________________________________ > 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

[Pharo-project] [update 1.2] #12111

by StÃ©phane Ducasse

12111 ----- - Issue 1899: MethodDictionary improvement part one. Thanks Levente Uzonyi and Guillermo Polito. - Philipp fixes for WebClient. Thanks Philippe Marshall and Sven Van Caekenberghe. Stef

Aug. 25, 2010

Re: [Pharo-project] Delivery Status Notification (Failure)

by StÃ©phane Ducasse

"Pharo-project(a)lists.gforge.inria.fr Development" <Pharo-project(a)lists.gforge.inria.fr> is the dev list may be I used the wrong one. Stef On Aug 25, 2010, at 7:15 PM, John M McIntosh wrote: > Well isn't Pharo development -> Pharo Development <Pharo-project(a)lists.gforge.inria.fr> > versus pharo-dev(a)lists.gforge.inria.fr ? > > > On 2010-08-25, at 10:12 AM, StÃ©phane Ducasse wrote: > >> strange did you try directly? >> >> Stef >> >> On Aug 25, 2010, at 7:05 PM, John M McIntosh wrote: >> >>> Somehow the original email from Marcin Tustin <mm3(a)zepler.net> to pharo-dev(a)lists.gforge.inria.fr which I >>> responded to could be wrong? >>> >>> Begin forwarded message: >>> >>>> From: "Mail Delivery System" <MAILER-DAEMON(a)mail4-relais-sop.national.inria.fr> >>>> Date: August 25, 2010 9:59:14 AM PDT >>>> To: johnmci(a)smalltalkconsulting.com >>>> Subject: Delivery Status Notification (Failure) >>>> >>>> The following message to <pharo-dev(a)lists.gforge.inria.fr> was undeliverable. >>>> The reason for the problem: >>>> 5.1.0 - Unknown address error 550-'Unrouteable address' >>>> Reporting-MTA: dns; mail4-relais-sop.national.inria.fr >>>> >>>> Final-Recipient: rfc822;pharo-dev(a)lists.gforge.inria.fr >>>> Action: failed >>>> Status: 5.0.0 (permanent failure) >>>> Remote-MTA: dns; [131.254.249.20] >>>> Diagnostic-Code: smtp; 5.1.0 - Unknown address error 550-'Unrouteable address' (delivery attempts: 0) >>> <Mail Attachment.eml> >>> >>> -- >>> =========================================================================== >>> John M. McIntosh <johnmci(a)smalltalkconsulting.com> Twitter: squeaker68882 >>> Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com >>> =========================================================================== >>> >>> >>> >>> >> > > -- > =========================================================================== > John M. McIntosh <johnmci(a)smalltalkconsulting.com> Twitter: squeaker68882 > Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com > =========================================================================== > > > >

Aug. 25, 2010

[Pharo-project] Fwd: Alien install issue?

by John M McIntosh

Begin forwarded message: > From: Marcin Tustin <mm3(a)zepler.net> > Date: August 25, 2010 2:31:16 AM PDT > To: John McIntosh <johnmci(a)smalltalkconsulting.com> > Cc: A friendly place where any question about pharo is welcome <pharo-users(a)lists.gforge.inria.fr>, pharo-dev(a)lists.gforge.inria.fr > Subject: Re: [Pharo-users] Invoking external processes/IPC > > I'm not sure that I would class the fact that Alien wants the Special Objects Array to be bigger than it actually is to be a mere installation issue. > > On Wed, Aug 25, 2010 at 10:13 AM, John McIntosh <johnmci(a)smalltalkconsulting.com> wrote: > Ask on the Pharo list for help or instruction on loading alien into pharo, I didn't write any of the loader code so I can't deal with the fact it may or may not be broken. > > Sent from my iPad > > On 2010-08-25, at 1:30 AM, Marcin Tustin <mm3(a)zepler.net> wrote: > >> John, >> >> Do you have any intention of commenting on this, even to confirm that you are content for Alien to be incompatible with current versions of Pharo? >> >> Marcin >> >> On Mon, Aug 23, 2010 at 11:15 PM, Marcin Tustin <mm3(a)zepler.net> wrote: >> John, >> >> That is the installation recipe I was following, as should have been apparent from my description of the process followed given in my previous email. My problem occurred on the first step after loading the ConfigurationOfAlien package. >> >> For completeness, I tried loading ConfigurationOfAlien using Gofer, and the exact same thing occurred. I also note that Gofer>>addPackage is deprecated. >> >> Marcin >> >> >> >> >> On Mon, Aug 23, 2010 at 10:40 PM, John M McIntosh <johnmci(a)smalltalkconsulting.com> wrote: >> LIkely the installation process is wrong, look at the http://squeaksource.com/@EGv-75Ct7JEKFz5m/rnvjMef8 >> and follow the instructions for installing there. >> >> On 2010-08-23, at 2:08 PM, Marcin Tustin wrote: >> >>> Following Mariano's advice, I just tried installing Alien (using Pharo-1.1-11406-rc3 with the Seaside RC3 image; this is a sane version, not affected by previous package loading problems). >>> >>> I loaded ConfigurationOfAlien (ConfigurationOfAlien-KenTreis.26) using Monticello, then executed ConfigurationOfAlien loadCore (as per the instructions). That resulted in an error: 'SystemDictionary>>recreateSpecialObjectsArray appears incompatible' raised from ensureInSpecialObjectsArray. The cause appears to be that Alien wants to be in the special objects array at 53, but the array is created to be size 50. >>> >>> Proceeding through the error results in the predictable subscript out of bounds error. >>> >>> running loadCore once more (second time) does the same thing. Doing it a third time results in a message not understood 'initScannerForTokenization' from Parser>>ParseSelector:. >>> >>> Any ideas? >>> >>> >>> On Mon, Aug 23, 2010 at 8:41 PM, Marcin Tustin <mm3(a)zepler.net> wrote: >>> Mariano, >>> >>> Thanks for this. I belive CommandShell depends on OSProcess. I am using windows, so I guess neither is a runner anyway. I'll try FFI/AlienFFI. >>> >>> Marcin >>> >>> >>> On Mon, Aug 23, 2010 at 8:19 PM, Mariano Martinez Peck <marianopeck(a)gmail.com> wrote: >>> >>> >>> On Mon, Aug 23, 2010 at 7:45 PM, Marcin Tustin <mm3(a)zepler.net> wrote: >>> Hi all, >>> >>> I'm an occasional squeak/pharo dabbler, and I'm wondering what the recommended way of interacting with external processes is these days? >>> >>> Should I go through the process of getting all the VMMaker and OSProcess stuff, and build the OSProcess plugin, or is there some other way in Pharo to interact with the OS environment? >>> >>> >>> Hi. Which OS are you? because I think OSProcess is not working on Windows. And I also think there are binaries for it, so you don't need to generate .c from VMMaker neither compile c code to binary. >>> But I may be wrong. >>> >>> CommandShell ? >>> >>> Maybe using normal FFI or AlienFFI? They will let you invoke shared libraries of the OS from Pharo. >>> >>> Alternatively, are people doing something (easy) with IPC mechanisms like named sockets or TCP streams? >>> >>> The "project" I'm working on is putting figlet on a website, just for fun. >>> >>> Marcin >>> >>> -- >>> Marcin Tustin >>> Mobile: 07773787105 >>> Office: 020 3400 3259 >>> >>> _______________________________________________ >>> Pharo-users mailing list >>> Pharo-users(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users >>> >>> >>> >>> _______________________________________________ >>> Pharo-users mailing list >>> Pharo-users(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users >>> >>> >>> >>> >>> -- >>> Marcin Tustin >>> Mobile: 07773787105 >>> Office: 020 3400 3259 >>> >>> >>> >>> -- >>> Marcin Tustin >>> Mobile: 07773787105 >>> Office: 020 3400 3259 >> >> -- >> =========================================================================== >> John M. McIntosh <johnmci(a)smalltalkconsulting.com> Twitter: squeaker68882 >> Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com >> =========================================================================== >> >> >> >> >> >> >> >> -- >> Marcin Tustin >> Mobile: 07773787105 >> Office: 020 3400 3259 >> >> >> >> -- >> Marcin Tustin >> Mobile: 07773787105 >> Office: 020 3400 3259 > > > > -- > Marcin Tustin > Mobile: 07773787105 > Office: 020 3400 3259 -- =========================================================================== John M. McIntosh <johnmci(a)smalltalkconsulting.com> Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com ===========================================================================

Aug. 25, 2010

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

by Schwab,Wilhelm K

Options are always good. I would not at all recommend removing the current null display and sound drivers. However, it would be nice to see the image and vm cooperate to emulate Dolphin's session managers and associated deployment design. IMHO Object Arts went a little overboard with stripping; we would not have to work that hard at it to have something very useful. Bill ________________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of StÃ©phane Ducasse [stephane.ducasse(a)inria.fr] Sent: Wednesday, August 25, 2010 1:06 PM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] [SPAM] Re: why are Bitmaps instanciated even in headless mode? On Aug 25, 2010, at 12:49 PM, Sven Van Caekenberghe wrote: > 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). we should arrive one day to that :) > > 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 > > > _______________________________________________ > 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] [SPAM] Re: why are Bitmaps instanciated even in headless mode?

by StÃ©phane Ducasse

On Aug 25, 2010, at 12:49 PM, Sven Van Caekenberghe wrote: > 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). we should arrive one day to that :) > > 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 > > > _______________________________________________ > 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

+1 Stef On Aug 25, 2010, at 12:53 PM, Schwab,Wilhelm K wrote: > 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 > > _______________________________________________ > 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