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

Re: [Pharo-project] ConfigurationOfOSProcess updated

by David T. Lewis

On Sat, Jul 03, 2010 at 10:29:49AM +0200, Adrian Lienhard wrote: > > On Jul 2, 2010, at 22:32 , David T. Lewis wrote: > > >> I wonder whether the Mac VM includes the latest version of the OSProcess plugin? > >> > > > > FWIW, you can check the versions of the plugins, on my Linux box > > I have: > > > > OSProcess accessor osppModuleVersionString ==> '4.3.3' > > OSProcess accessor aioVersionString ==> '2.2.2' > > OSProcess accessor xdcpVersionString ==> '2.1.4' > > On my Mac VM (4.2.4beta1U) I get: > > OSProcess accessor osppModuleVersionString ==> '4.0.1' > OSProcess accessor aioVersionString ==> nil > OSProcess accessor xdcpVersionString ==> nil That's the problem. OSPP 4.0.1 is from November 2005. IIUC, John noticed this and updated the sources in his more recent VMs. If you are building your VMs from scratch, the plugin sources are on SqueakSource in projects OSProcessPlugin, AioPlugin, and XDCP. FYI, the specific fix for OSPP to support OS X was this: Name: VMConstruction-Plugins-OSProcessPlugin-dtl.3 Author: dtl Time: 5 March 2006, 12:15:57 pm UUID: b09d2caa-cb4b-46f8-a1c9-6f4dda49de4f Ancestors: VMConstruction-Plugins-OSProcessPlugin-dtl.2 Version 4.0.2 Add pthread access primitive. Add pthread signal masking to ensure that forwarded signals are delivered to the interpreter thread. This is required for OS X. Strategy: Signal handler checks to see if it is executing in the context of the interpreter pthread. If yes, signal the Squeak semaphore, otherwise mask this pthread to prevent future delivery if this signum and resend the signal to the interpreter pthread. Note, John's new VM code base (iOS) is very different, so I don't know if there will be issues for OSProcess on the new iOS VM. Dave

July 3, 2010

Re: [Pharo-project] ConfigurationOfOSProcess updated

by Adrian Lienhard

Hi David, On Jul 2, 2010, at 22:32 , David T. Lewis wrote: [...] > The Aio failures are due to AioPlugin not being present. I don't > think this has ever been included in the Mac VMs (it would probably > work, but I don't think anyone has tried it). It's not serious and > will not affect usability of OSProcess. Ok, good to know. >> I wonder whether the Mac VM includes the latest version of the OSProcess plugin? >> > > FWIW, you can check the versions of the plugins, on my Linux box > I have: > > OSProcess accessor osppModuleVersionString ==> '4.3.3' > OSProcess accessor aioVersionString ==> '2.2.2' > OSProcess accessor xdcpVersionString ==> '2.1.4' On my Mac VM (4.2.4beta1U) I get: OSProcess accessor osppModuleVersionString ==> '4.0.1' OSProcess accessor aioVersionString ==> nil OSProcess accessor xdcpVersionString ==> nil Cheers, Adrian

July 3, 2010

Re: [Pharo-project] Collection>>ifNotEmpty: changed semantics

by StÃ©phane Ducasse

thanks for the discussion! http://code.google.com/p/pharo/issues/detail?id=2636 Stef On Jul 3, 2010, at 9:04 AM, Nicolas Cellier wrote: > 100% agreement on this > > 2010/7/3 Eliot Miranda <eliot.miranda(a)gmail.com>: >> Hi Nicolas, >> in any case the comment needs to specify that behavior, e.g. >> Collection>>ifNotEmpty: aBlock >> "Evaluate the given block with the receiver as argument, answering its >> value >> unless the receiver is empty, in which case answer the receiver." >> ^self isEmpty >> ifTrue: [self] >> ifFalse: [aBlock valueWithPossibleArgument: self] >> >> and in this case IMO the explicit return self is better than the implicit >> one. >> On Fri, Jul 2, 2010 at 2:34 PM, Nicolas Cellier >> <nicolas.cellier.aka.nice(a)gmail.com> wrote: >>> >>> 2010/7/2 Simon Denier <Simon.Denier(a)inria.fr>: >>>> I just noticed that the semantic of Collection>>ifNotEmpty: has changed >>>> in subtle ways between Pharo 1.0 and 1.1 >>>> >>>> In 1.0 >>>> Collection>>ifNotEmpty: aBlock >>>> "Evaluate the given block unless the receiver is empty. >>>> >>>> If the block has an argument, eval with the receiver as its >>>> argument, >>>> but it might be better to use ifNotEmptyDo: to make the code easier >>>> to >>>> understand" >>>> >>>> ^self isEmpty ifFalse: [aBlock valueWithPossibleArgument: self]. >>>> >>>> -----> it returns nil if collection is empty >>>> >>>> >>>> in 1.1 >>>> Collection>>ifNotEmpty: aBlock >>>> "Evaluate the given block unless the receiver is empty. >>>> >>>> If the block has an argument, eval with the receiver as its >>>> argument, >>>> but it might be better to use ifNotEmptyDo: to make the code easier >>>> to >>>> understand" >>>> >>>> self isEmpty ifFalse: [^ aBlock valueWithPossibleArgument: self]. >>>> >>>> ----> the return is inside the block, now it returns the collection if >>>> collection is empty >>>> >>>> >>>> Apparently all similar code (#ifEmpty:....) has been adapted in the same >>>> way. >>>> >>>> Of course I would not have stumbled upon this change if it didn't break >>>> some of my code which rely on the previous assumption. >>>> >>>> Now I would like to understand before making some change in my code. Is >>>> it considered bad practice to return nil in such cases? What is the >>>> rationale to return yourself instead of nil? >>>> >>> >>> The new version is better because: >>> - it is homogeneous with ifNil: behaviour >>> - it enables writing: self classifyMethodAs: (myProtocol ifEmpty: >>> ['As yet unclassified']) >>> >>> Nicolas >>> >>>> -- >>>> Simon >>>> >>>> >>>> >>>> _______________________________________________ >>>> 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

July 3, 2010

Re: [Pharo-project] Collection>>ifNotEmpty: changed semantics

by Nicolas Cellier

100% agreement on this 2010/7/3 Eliot Miranda <eliot.miranda(a)gmail.com>: > HiÂ Nicolas, > Â Â Â in any case the comment needs to specify that behavior, e.g. > Collection>>ifNotEmpty: aBlock > Â Â Â Â "Evaluate the given block with the receiver as argument, answering its > value > Â Â Â Â unless the receiver is empty, in which case answer the receiver." > Â Â Â ^self isEmpty > Â Â Â Â Â Â ifTrue: [self] > Â Â Â Â Â Â ifFalse: [aBlock valueWithPossibleArgument: self] > > and in this case IMO the explicit return self is better than the implicit > one. > On Fri, Jul 2, 2010 at 2:34 PM, Nicolas Cellier > <nicolas.cellier.aka.nice(a)gmail.com> wrote: >> >> 2010/7/2 Simon Denier <Simon.Denier(a)inria.fr>: >> > I just noticed that the semantic of Collection>>ifNotEmpty: has changed >> > in subtle ways between Pharo 1.0 and 1.1 >> > >> > In 1.0 >> > Collection>>ifNotEmpty: aBlock >> > Â Â Â Â "Evaluate the given block unless the receiver is empty. >> > >> > Â Â If the block has an argument, eval with the receiver as its >> > argument, >> > Â Â but it might be better to use ifNotEmptyDo: to make the code easier >> > to >> > Â Â understand" >> > >> > Â Â Â Â ^self isEmpty ifFalse: [aBlock valueWithPossibleArgument: self]. >> > >> > -----> it returns nil if collection is empty >> > >> > >> > in 1.1 >> > Collection>>ifNotEmpty: aBlock >> > Â Â Â Â "Evaluate the given block unless the receiver is empty. >> > >> > Â Â If the block has an argument, eval with the receiver as its >> > argument, >> > Â Â but it might be better to use ifNotEmptyDo: to make the code easier >> > to >> > Â Â understand" >> > >> > Â Â Â Â self isEmpty ifFalse: [^ aBlock valueWithPossibleArgument: self]. >> > >> > ----> the return is inside the block, now it returns the collection if >> > collection is empty >> > >> > >> > Apparently all similar code (#ifEmpty:....) has been adapted in the same >> > way. >> > >> > Of course I would not have stumbled upon this change if it didn't break >> > some of my code which rely on the previous assumption. >> > >> > Now I would like to understand before making some change in my code. Is >> > it considered bad practice to return nil in such cases? What is the >> > rationale to return yourself instead of nil? >> > >> >> The new version is better because: >> - it is homogeneous with ifNil: behaviour >> - it enables writing: Â self classifyMethodAs: (myProtocol ifEmpty: >> ['As yet unclassified']) >> >> Nicolas >> >> > -- >> > Simon >> > >> > >> > >> > _______________________________________________ >> > 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 >

July 3, 2010

Re: [Pharo-project] HTML Parser

by GermÃ¡n Arduino

Will check, thanks. 2010/7/1 Mariano Martinez Peck <marianopeck(a)gmail.com> > There were some threads few weeks ago about this: > > > http://forum.world.st/template/NodeServlet.jtp?tpl=search-page&node=1294836… > > On Thu, Jul 1, 2010 at 1:41 AM, GermÃ¡n Arduino <garduino(a)gmail.com> wrote: > >> Trying PetitParser of Lukas. Seems to work ok to my current (small) html >> needs. >> >> Cheers. >> >> 2010/6/30 GermÃ¡n Arduino <garduino(a)gmail.com>: >> > Hi: >> > >> > I used to use HTML Parser on squeak, a package of Avi and Julian if I >> > not bad remember. That package needed Yaxo also. >> > >> > What are using on Pharo to parsing HTML on these days? >> > >> > Thanks. >> > >> > -- >> > ================================================= >> > GermÃ¡n S. Arduino <gsa @ arsol.net> Twitter: garduino >> > Arduino Software & Web Hosting http://www.arduinosoftware.com >> > PasswordsPro http://www.passwordspro.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 >

July 2, 2010

Re: [Pharo-project] Collection>>ifNotEmpty: changed semantics

by Eliot Miranda

Hi Nicolas, in any case the comment needs to specify that behavior, e.g. Collection>>ifNotEmpty: aBlock "Evaluate the given block with the receiver as argument, answering its value unless the receiver is empty, in which case answer the receiver." ^self isEmpty ifTrue: [self] ifFalse: [aBlock valueWithPossibleArgument: self] and in this case IMO the explicit return self is better than the implicit one. On Fri, Jul 2, 2010 at 2:34 PM, Nicolas Cellier < nicolas.cellier.aka.nice(a)gmail.com> wrote: > 2010/7/2 Simon Denier <Simon.Denier(a)inria.fr>: > > I just noticed that the semantic of Collection>>ifNotEmpty: has changed > in subtle ways between Pharo 1.0 and 1.1 > > > > In 1.0 > > Collection>>ifNotEmpty: aBlock > > "Evaluate the given block unless the receiver is empty. > > > > If the block has an argument, eval with the receiver as its argument, > > but it might be better to use ifNotEmptyDo: to make the code easier > to > > understand" > > > > ^self isEmpty ifFalse: [aBlock valueWithPossibleArgument: self]. > > > > -----> it returns nil if collection is empty > > > > > > in 1.1 > > Collection>>ifNotEmpty: aBlock > > "Evaluate the given block unless the receiver is empty. > > > > If the block has an argument, eval with the receiver as its argument, > > but it might be better to use ifNotEmptyDo: to make the code easier > to > > understand" > > > > self isEmpty ifFalse: [^ aBlock valueWithPossibleArgument: self]. > > > > ----> the return is inside the block, now it returns the collection if > collection is empty > > > > > > Apparently all similar code (#ifEmpty:....) has been adapted in the same > way. > > > > Of course I would not have stumbled upon this change if it didn't break > some of my code which rely on the previous assumption. > > > > Now I would like to understand before making some change in my code. Is > it considered bad practice to return nil in such cases? What is the > rationale to return yourself instead of nil? > > > > The new version is better because: > - it is homogeneous with ifNil: behaviour > - it enables writing: self classifyMethodAs: (myProtocol ifEmpty: > ['As yet unclassified']) > > Nicolas > > > -- > > Simon > > > > > > > > _______________________________________________ > > 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 >

July 2, 2010

Re: [Pharo-project] Problem with number parsing in Shout...help needed!

by Nicolas Cellier

2010/7/2 Mariano Martinez Peck <marianopeck(a)gmail.com>: > If you load Shout-lr.84 and ShoutTests-tween.9 from > http://www.squeaksource.com/shout > > and run theÂ testNumbersÂ it will in: > > Â Â Â s := 'x 16r-d'. > Â Â Â types := self tokenTypesIn: s. > Â Â Â tokens := self tokensIn: s. > Â Â Â self assert: types = #(patternUnary number unary). > Â Â Â self assert: tokens = #('x' '16r-' 'd'). > First, try: (Compiler evaluate: '16r-d') -> -13. Then you can conclude 16r-d is a valid number token now. The test is not up-to-date, so change the test. I guess this might be related to enablement of lower case letters in number literals... Nicolas > because types isÂ #(#patternUnary #number) > and in addition, tokens isÂ #('x' '16r-d') > > I have no idea about this. Does someone know how to fix it? > > Thanks > > mariano > > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

July 2, 2010

Re: [Pharo-project] Collection>>ifNotEmpty: changed semantics

by Nicolas Cellier

2010/7/2 Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com>: > 2010/7/2 Simon Denier <Simon.Denier(a)inria.fr>: >> I just noticed that the semantic of Collection>>ifNotEmpty: has changed in subtle ways between Pharo 1.0 and 1.1 >> >> In 1.0 >> Collection>>ifNotEmpty: aBlock >> Â Â Â Â "Evaluate the given block unless the receiver is empty. >> >> Â Â If the block has an argument, eval with the receiver as its argument, >> Â Â but it might be better to use ifNotEmptyDo: to make the code easier to >> Â Â understand" >> >> Â Â Â Â ^self isEmpty ifFalse: [aBlock valueWithPossibleArgument: self]. >> >> -----> it returns nil if collection is empty >> >> >> in 1.1 >> Collection>>ifNotEmpty: aBlock >> Â Â Â Â "Evaluate the given block unless the receiver is empty. >> >> Â Â If the block has an argument, eval with the receiver as its argument, >> Â Â but it might be better to use ifNotEmptyDo: to make the code easier to >> Â Â understand" >> >> Â Â Â Â self isEmpty ifFalse: [^ aBlock valueWithPossibleArgument: self]. >> >> ----> the return is inside the block, now it returns the collection if collection is empty >> >> >> Apparently all similar code (#ifEmpty:....) has been adapted in the same way. >> >> Of course I would not have stumbled upon this change if it didn't break some of my code which rely on the previous assumption. >> >> Now I would like to understand before making some change in my code. Is it considered bad practice to return nil in such cases? What is the rationale to return yourself instead of nil? >> > > The new version is better because: > - it is homogeneous with ifNil: behaviour > - it enables writing: Â self classifyMethodAs: (myProtocol ifEmpty: > ['As yet unclassified']) > > Nicolas > Oops, embarassing, I didn't answer the good question :( Maybe it's homogeneous with ifNotNil: ? Nicolas >> -- >> Simon >> >> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >

July 2, 2010

Re: [Pharo-project] Collection>>ifNotEmpty: changed semantics

by Nicolas Cellier

2010/7/2 Simon Denier <Simon.Denier(a)inria.fr>: > I just noticed that the semantic of Collection>>ifNotEmpty: has changed in subtle ways between Pharo 1.0 and 1.1 > > In 1.0 > Collection>>ifNotEmpty: aBlock > Â Â Â Â "Evaluate the given block unless the receiver is empty. > > Â Â If the block has an argument, eval with the receiver as its argument, > Â Â but it might be better to use ifNotEmptyDo: to make the code easier to > Â Â understand" > > Â Â Â Â ^self isEmpty ifFalse: [aBlock valueWithPossibleArgument: self]. > > -----> it returns nil if collection is empty > > > in 1.1 > Collection>>ifNotEmpty: aBlock > Â Â Â Â "Evaluate the given block unless the receiver is empty. > > Â Â If the block has an argument, eval with the receiver as its argument, > Â Â but it might be better to use ifNotEmptyDo: to make the code easier to > Â Â understand" > > Â Â Â Â self isEmpty ifFalse: [^ aBlock valueWithPossibleArgument: self]. > > ----> the return is inside the block, now it returns the collection if collection is empty > > > Apparently all similar code (#ifEmpty:....) has been adapted in the same way. > > Of course I would not have stumbled upon this change if it didn't break some of my code which rely on the previous assumption. > > Now I would like to understand before making some change in my code. Is it considered bad practice to return nil in such cases? What is the rationale to return yourself instead of nil? > The new version is better because: - it is homogeneous with ifNil: behaviour - it enables writing: self classifyMethodAs: (myProtocol ifEmpty: ['As yet unclassified']) Nicolas > -- > Simon > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

July 2, 2010

Re: [Pharo-project] ConfigurationOfOSProcess updated

by David T. Lewis

On Fri, Jul 02, 2010 at 12:28:54PM +0200, Adrian Lienhard wrote: > Hi David, > > Thanks a lot! > > Please find my report for OS X below. Thanks Adrian, much appreciated. I guess that I should get a Mac one of these days ;) > Image: Pharo-1.1-11406-rc3dev10.07.1 > VM: Squeak 4.2.4beta1U > > Loading OSProcess: > > Gofer new > squeaksource: 'MetacelloRepository'; > package: 'ConfigurationOfOSProcess'; > load. > ((Smalltalk at: #ConfigurationOfOSProcess) project latestVersion) load > > ThisOSProcess initialize (this seems necessary, is it the right #initialize?) In ConfigurationOfOSProcess class>>load I call the #startUp: method in ThisOSProcess. Without this the unit tests will fail until after you restart the image. This is probably a poor way to do it, but it works. > The following tests crash the VM: > - UnixProcessUnixFileLockingTest > - UnixProcessWin32FileLockingTest > - UnixProcessTestCase Ouch. I think this used to run without crashing on OS X. > The failures and errors of the other tests: > > Failures: > AioEventHandlerTestCase>>#testEnableHandleAndDisable > AioEventHandlerTestCase>>#testPrimAioModuleVersionString > AioEventHandlerTestCase>>#testFileWritableEvent > AioEventHandlerTestCase>>#testFileReadableEvent > UnixProcessAccessorTestCase>>#testChDir > UnixProcessAccessorTestCase>>#testIsWritableForUserInGroup > AioEventHandlerTestCase>>#testSuspendAioForSocketReadableEvent > UnixProcessAccessorTestCase>>#testIsReadableForUserInGroup > AioEventHandlerTestCase>>#testHandleForSocket > AioEventHandlerTestCase>>#testHandleForFile > AioEventHandlerTestCase>>#testSocketReadableEvent > UnixProcessAccessorTestCase>>#testIsExecutableForUserInGroup > > Errors: > AioEventHandlerTestCase>>#testPrimAioModuleName The Aio failures are due to AioPlugin not being present. I don't think this has ever been included in the Mac VMs (it would probably work, but I don't think anyone has tried it). It's not serious and will not affect usability of OSProcess. > I wonder whether the Mac VM includes the latest version of the OSProcess plugin? > FWIW, you can check the versions of the plugins, on my Linux box I have: OSProcess accessor osppModuleVersionString ==> '4.3.3' OSProcess accessor aioVersionString ==> '2.2.2' OSProcess accessor xdcpVersionString ==> '2.1.4' Thanks for the feedback! Dave

July 2, 2010