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

Re: [Pharo-project] Experimental Cocoa OS-X based Squeak Cog JIT VM 5.8b3.

by Philippe Marschall

On 08/26/2010 12:12 AM, John M McIntosh wrote: > I've stuck a version (5.8b3) of the cocoa based os-x squeak cog JIT based VM in my experimental folder. > > http://homepage.mac.com/johnmci/.Public/experimental/Squeak%205.8b3.app.zip > > This VM is built from the Cog sources (with some minor changes for the iPhone) & revised & fixed Socket Plugin. > It currently does NOT contain any external plugins. I did check in the changes to squeakvm.org that are required to > build this VM excluding the required Cog changes... > > People are invited to take it for a whirl, report any performance gains, issues and especially crashes. I did a short test with Seaside. It did not crash and all tests are green. Rendering is about two to three times faster which seems to be in line with the performance gains other people report for other applications. Cheers Philippe

Aug. 26, 2010

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

by Sven Van Caekenberghe

On 26 Aug 2010, at 07:39, Philippe Marschall wrote: > Currently I'm down to one multipart test failure. Did you start from the latest 1.2 merged version ?

Aug. 26, 2010

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

by Philippe Marschall

On 25.08.2010 14:04, StÃ©phane Ducasse wrote: > > On Aug 25, 2010, at 1:56 PM, Sven Van Caekenberghe wrote: > >> I was afraid you were going to ask that ;-) > > but I'm easy going no :) > >> OK, I'll see what I can do later today. >> I'll have to read up a bit about MC merging. Like here http://www.lukas-renggli.ch/blog/monticello-merging ? >> Later on Philippe should maybe also have a look at what I did... > > Philippe? Done. Some context for other people: The patches make Seaside on WebClient and Websockets work in Pharo 1.1 without any overrides or loading any other code. Currently I'm down to one multipart test failure. Cheers Philippe

Aug. 26, 2010

[Pharo-project] DNU after updating 1.2 core image

by Guillermo Polito

When you right click over the category panel and the method category panel in the system browser. ByteString DNU lines Guille

Aug. 26, 2010

Re: [Pharo-project] 'foo' asTime

by Guillermo Polito

And now, because of fixing Integer>>readFrom:, 'foo' asTime throws an exception and we all are a bit happier :D. On Wed, Aug 25, 2010 at 7:55 PM, Schwab,Wilhelm K <bschwab(a)anest.ufl.edu>wrote: > I would like to be *able* to use a read method to pull from a stream with > other data in it. Whether it needs to be at the end when that is over is > open for debate, perhaps left to the caller?? It is an important question. > Off the top of my head, it seems that Dolphin somewhat dodges it for dates > and times by taking strings. I can check on whether they raise errors if > there is "stuff left over." > > Again, I am fully supportive of raising errors by default. They help to > fix a lot more trouble than they cause. > > > ________________________________________ > From: pharo-project-bounces(a)lists.gforge.inria.fr [ > pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Nicolas Cellier > [nicolas.cellier.aka.nice(a)gmail.com] > Sent: Wednesday, August 25, 2010 4:50 PM > To: Pharo-project(a)lists.gforge.inria.fr > Subject: Re: [Pharo-project] 'foo' asTime > > 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 > > > > _______________________________________________ > 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. 26, 2010

Re: [Pharo-project] 'foo' asTime

by Schwab,Wilhelm K

I would like to be *able* to use a read method to pull from a stream with other data in it. Whether it needs to be at the end when that is over is open for debate, perhaps left to the caller?? It is an important question. Off the top of my head, it seems that Dolphin somewhat dodges it for dates and times by taking strings. I can check on whether they raise errors if there is "stuff left over." Again, I am fully supportive of raising errors by default. They help to fix a lot more trouble than they cause. ________________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Nicolas Cellier [nicolas.cellier.aka.nice(a)gmail.com] Sent: Wednesday, August 25, 2010 4:50 PM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] 'foo' asTime 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 > _______________________________________________ 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] Experimental Cocoa OS-X based Squeak Cog JIT VM 5.8b3.

by John M McIntosh

I've stuck a version (5.8b3) of the cocoa based os-x squeak cog JIT based VM in my experimental folder. http://homepage.mac.com/johnmci/.Public/experimental/Squeak%205.8b3.app.zip This VM is built from the Cog sources (with some minor changes for the iPhone) & revised & fixed Socket Plugin. It currently does NOT contain any external plugins. I did check in the changes to squeakvm.org that are required to build this VM excluding the required Cog changes... People are invited to take it for a whirl, report any performance gains, issues and especially crashes. PS (a) yes shortly we'll get the iPhone changes folded back into the source tree so you can build the VM. (b) yes when resizing a window you get neat graphic effects (fixing that issue is non-trival). (c) As time permits we'll look into rebuild this rather long list of plugins. ClipboardExtendedPlugin.bundle CroquetPlugin.bundle CurlPlugin.bundle FloatMathPlugin.bundle FT2Plugin.bundle IA32ABI.bundle KedamaPlugin.bundle KedamaPlugin2.bundle LocalePlugin.bundle mpeg3Plugin.bundle ObjectiveCPlugin.bundle OggPlugin.bundle PrintJobPlugin.bundle QuicktimePlugin.bundle RomePlugin.bundle SerialExtendedUnixPlugin.bundle ServicesPlugin.bundle SpellingPlugin.bundle SqueakFFIPrims.bundle TestOSAPlugin.bundle UnixOSProcessPlugin.bundle -- =========================================================================== John M. McIntosh <johnmci(a)smalltalkconsulting.com> Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com ===========================================================================

Aug. 25, 2010

Re: [Pharo-project] 'foo' asTime

by Schwab,Wilhelm K

Stef, I was so happy to see somebody ringing the "don't return nil; raise an exception" alram that I completely missed the time (and date?) connection. Any #readFrom:* method will be inadequate due to formats. Dolphin tackles thiat with type converters, and I have a minimal set that I fully intend to grow. See http://squeaksource.com/PharoInbox/DolphinCompatibility-ValueAdapters-BillS… and repeat after me: Caveat Emptor. Beyond that, if the code runs w/o my streams enhancements installed, please let me know - I would consider that a horrible bug. 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 5:00 PM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] 'foo' asTime http://code.google.com/p/pharo/issues/detail?id=2859 Stef _______________________________________________ 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] 'foo' asTime

by StÃ©phane Ducasse

http://code.google.com/p/pharo/issues/detail?id=2859 Stef

Aug. 25, 2010

Re: [Pharo-project] 'foo' asTime

by StÃ©phane Ducasse

On Aug 25, 2010, at 10:50 PM, Nicolas Cellier wrote: > 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. I integrated the changes of guillermo. But readFrom:ifFail: is a nice API. > 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 Yes. I was thinking about something in the same vein so that we could walk on the stream Now I think that we should get a concrete case to learn from. First raising an error instead of zero is a good behavior and it may break some code. Stef >> >> >>> 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 >> > > _______________________________________________ > 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