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

[Pharo-project] MessageNames tool tidyup

by Gary Chambers

Created another issue: http://code.google.com/p/pharo/issues/detail?id=2639 Regards, Gary

July 5, 2010

Re: [Pharo-project] bug with documentation link

by Mariano Martinez Peck

On Mon, Jul 5, 2010 at 12:07 PM, Geert Claes <geert.wl.claes(a)gmail.com>wrote: > > > StÃ©phane Ducasse wrote: > > > > by the way somebody told me that lighthouse in portuguese is farol and > not > > faro (which means smelling). > > > > I don't speak Portuguese nor Spanish but the good old Google Translate > confirms that lighthouse is indeed Farol and not Faro .... however > lighthouse does still translate as Faro in Spanish :) > Yes, in Spanish, it is Faro. Marcus told me he chose Pharo just to be easily indexed by search engines like Google. It doesn't mean lighthouse in any language. Just a deformation for google ;) cheers mariano > -- > View this message in context: > http://forum.world.st/bug-with-documentation-link-tp2278198p2278220.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 >

July 5, 2010

Re: [Pharo-project] bug with documentation link

by Geert Claes

StÃ©phane Ducasse wrote: > > by the way somebody told me that lighthouse in portuguese is farol and not > faro (which means smelling). > I don't speak Portuguese nor Spanish but the good old Google Translate confirms that lighthouse is indeed Farol and not Faro .... however lighthouse does still translate as Faro in Spanish :) -- View this message in context: http://forum.world.st/bug-with-documentation-link-tp2278198p2278220.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

July 5, 2010

Re: [Pharo-project] bug with documentation link

by Adrian Lienhard

I exchanged the tutorial/books page with the FAQ page so that the former gets displayed by default. We don't have a Screencasts page; what content would such a page contain? Would we list available screen cast or just link to http://pharocasts.blogspot.com/? Adrian On Jul 5, 2010, at 11:47 , StÃ©phane Ducasse wrote: > Hi all > > when I go to the pharo web site and click on documentation I go to faq (and I do not care of FAQ) > I want to see screencast > adrian could it be possible to get > > Documentation > tutorialBooks > screencast > faq > > > by the way somebody told me that lighthouse in portuguese is farol and not faro (which means smelling). > > Stef > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

July 5, 2010

[Pharo-project] bug with documentation link

by StÃ©phane Ducasse

Hi all when I go to the pharo web site and click on documentation I go to faq (and I do not care of FAQ) I want to see screencast adrian could it be possible to get Documentation tutorialBooks screencast faq by the way somebody told me that lighthouse in portuguese is farol and not faro (which means smelling). Stef

July 5, 2010

Re: [Pharo-project] OSProcess in Pharo (on Windows)

by Fabrizio Perin

Hi, I don't know if there were some evolution on OSProcess but sometime ago i had problem using it under Windows too. Basically under Windows some primitives used during the initialization fails. The result is that OSProcess cannot comunicate with the actual OS. So no magic incantation available as far as i know. Cheers, Fabrizio 2010/7/5 Rob Rothwell <r.j.rothwell(a)gmail.com> > Forgive me if this question has already been answered, but I can't seem to > find it... > > Is OSProcess running in Pharo, and what is the magic incantation to call an > external program, batch file, etc... in Windows? > > I seem to recall something like: > > OSProcess thisOSProcess command: 'dosomething.exe' > > But that doesn't seem to currently be working for me... > > Thank you, > > Rob > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

July 5, 2010

[Pharo-project] I updated the how to contribute web page

by stephane ducasse

please comment :) http://code.google.com/p/pharo/wiki/HowToContribute Stef

July 5, 2010

[Pharo-project] OSProcess in Pharo (on Windows)

by Rob Rothwell

Forgive me if this question has already been answered, but I can't seem to find it... Is OSProcess running in Pharo, and what is the magic incantation to call an external program, batch file, etc... in Windows? I seem to recall something like: OSProcess thisOSProcess command: 'dosomething.exe' But that doesn't seem to currently be working for me... Thank you, Rob

July 5, 2010

[Pharo-project] [update 1.2] #12034

by StÃ©phane Ducasse

12034 ----- - Issue 2638: DNU does not open a debugger. Thanks pavel :) We are allowed to break the system to improve it ok after we have to help to repair it :) Stef

July 4, 2010

Re: [Pharo-project] What does it take to implement tail-call optimization?

by Eliot Miranda

[oops; forgot the link I meant to post, so here's a 2nd attempt On Sun, Jul 4, 2010 at 1:26 AM, Stefan Marr <pharo(a)stefan-marr.de> wrote: > Hello Pharo: > > What would it take to implement tail-call optimization? > > My goal is to have an Erlang-like framework, which allows to port existing > Erlang code as straight forward as possible. > But this requires to have tail-call optimization, since Erlang provides no > loops. > But the system will run for a long time before it runs out of stack. Don't get hung up on this. Continue with the rest of the problem. > However, I am not going for implementing the whole language and all its > semantics, but only the basics I am interested in. > > So, a possible solution would also be a pragma/hint to the compiler to > apply the optimization. > When you come to deal with tail calls you may find that the obvious case, namely spotting recursive sends to self, is adequate, in which case the compiler implementation is relatively trivial; one maps a tail-recursive send to self to a set of assignments to the arguments (*) followed by any necessary pops to level the stack, followed by a jump to the start. (* Assignment to arguments legal in the bytecode; the compiler prevents explicit assignment to arguments but args and temps are the same at the bytecode level). > Has anyone done something like this before, or has some hints where to > start digging? > Various people, myself included, have done context-based hacks for fun, but they're merely parlour tricks; they have abysmal performance (certainly for loops, which is where we came in), no safety and don't integrate with the debugger. You'll want to look at Scheme and Java implementations. There's an excellent discussion in Gilad Bracha's blog<http://gbracha.blogspot.com/2009/12/chased-by-ones-own-tail.html>which has some good starting points. If Newspeak gets ported to Cog (or rather vice verse, if Cog is extended to run Newspeak) and Gilad doesn't dismount from the TCO hobby horse then I expect TCO will be implemented in Cog in a more complete manner. But as Gilad says, "one can cheat for a very long time though.". best Eliot > Thanks > Stefan > > > -- > Stefan Marr > Software Languages Lab > Vrije Universiteit Brussel > Pleinlaan 2 / B-1050 Brussels / Belgium > http://soft.vub.ac.be/~smarr > Phone: +32 2 629 2974 > Fax: +32 2 629 3525 > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

July 4, 2010

Re: [Pharo-project] What does it take to implement tail-call optimization?

by Eliot Miranda

On Sun, Jul 4, 2010 at 1:26 AM, Stefan Marr <pharo(a)stefan-marr.de> wrote: > Hello Pharo: > > What would it take to implement tail-call optimization? > > My goal is to have an Erlang-like framework, which allows to port existing > Erlang code as straight forward as possible. > But this requires to have tail-call optimization, since Erlang provides no > loops. > But the system will run for a long time before it runs out of stack. Don't get hung up on this. Continue with the rest of the problem. However, I am not going for implementing the whole language and all its > semantics, but only the basics I am interested in. > > So, a possible solution would also be a pragma/hint to the compiler to > apply the optimization. > When you come to deal with tail calls you may find that the obvious case, namely spotting recursive sends to self, is adequate, in which case the compiler implementation is relatively trivial; one maps a tail-recursive send to self to a set of assignments to the arguments (*) followed by any necessary pops to level the stack, followed by a jump to the start. (* Assignment to arguments legal in the bytecode; the compiler prevents explicit assignment to arguments but args and temps are the same at the bytecode level). Has anyone done something like this before, or has some hints where to start > digging? > Various people, myself included, have done context-based hacks for fun, but they're merely parlour tricks; they have abysmal performance (certainly for loops, which is where we came in), no safety and don't integrate with the debugger. You'll want to look at Scheme and Java implementations. There's an excellent discussion in Gilad Bracha blog which has some good starting points. If Newspeak gets ported to Cog (or rather vice verse, if Cog is extended to run Newspeak) and Gilad doesn't dismount from the TCO hobby horse then I expect TCO will be implemented in Cog in a more complete manner. But as Gilad says, "one can cheat for a very long time though.". best Eliot > Thanks > Stefan > > > -- > Stefan Marr > Software Languages Lab > Vrije Universiteit Brussel > Pleinlaan 2 / B-1050 Brussels / Belgium > http://soft.vub.ac.be/~smarr > Phone: +32 2 629 2974 > Fax: +32 2 629 3525 > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

July 4, 2010

Re: [Pharo-project] [SPAM] Re: ESUG will sponsor the XMLRPC project!

by GermÃ¡n Arduino

Hi Sven: Which JSON are you using? The package I know from Squeaksource (http://www.squeaksource.com/JSON.html) doesn't includes the class JSJsonParser. Cheers. GermÃ¡n. 2010/6/28 Sven Van Caekenberghe <sven(a)beta9.be> > And REST+JSON is easy to do with what is available in > Pharo/Seaside/WebClient: > > client := WebClient new. > client authCredentialsBlock: [:client :realm :fail | > client username: '680'; password: ((MD5 new hashMessage: 'secret') > hex) ]. > response := client httpGet: 'http://api.t3-platform.net:9000/users/680'. > JSJsonParser parse: response content. > > Sven > > PS: Only HTTPS is missing ;-) > > On 28 Jun 2010, at 13:35, StÃ©phane Ducasse wrote: > > > Thanks. > > May be german should have a look at this solution instead of XML-RCP. > > > > Stef > > > >>> My impression is that people either moved from XML-RCP to SOAP or > >>> abandoned the idea and went to REST. I don't know anybody who considers > >>> it for new projects. > >>> > >> > >> As Philippe stated, many projects are moving to REST. > >> REST/JSON webservices are getting all the hype these days... > >> > >> > >> _______________________________________________ > >> 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 > -- ================================================= GermÃ¡n S. Arduino <gsa @ arsol.net> Twitter: garduino Arduino Software & Web Hosting http://www.arduinosoftware.com PasswordsPro http://www.passwordspro.com =================================================

July 4, 2010

Re: [Pharo-project] UnhandledError instead of DNU?

by Pavel Krivanek

fixed... shame on me :-) -- Pavel On Sun, Jul 4, 2010 at 4:30 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > http://code.google.com/p/pharo/issues/detail?id=2638 > of course > > > Stef > > On Jul 4, 2010, at 4:24 PM, StÃ©phane Ducasse wrote: > >> Hi pavel >> >> to explain it to others >> >> was in 12023 >> >> UnhandledError>>defaultAction >> Â Â Â "The current computation is terminated. The cause of the error should be logged or reported to the user. If the program is operating in an interactive debugging environment the computation should be suspended and the debugger activated." >> Â Â Â ^ToolSet debugError: exception. >> >> >> and now in 12033 >> we got >> >> UnhandledError>>defaultAction >> >> Â Â Â UIManager default unhandledErrorDefaultAction: self >> >> >> DummyManager>>unhandledErrorDefaultAction: anException >> >> Â Â Â Transcript show: '*** EXCEPTION ***'; cr. >> Â Â Â Transcript show: anException; cr. >> Â Â Â Transcript show: (thisContext stack first: (20 min: thisContext stack size)); cr. >> Â Â Â anException isResumable ifTrue: [ anException resume ] >> >> >> MorphicUIManager>>unhandledErrorDefaultAction: anException >> >> Â Â Â "The current computation is terminated. The cause of the error should be logged or reported to the user. If the program is operating in an interactive debugging environment the computation should be suspended and the debugger activated." >> Â Â Â ^ToolSet debugError: anException. >> >> Now this raises an interesting question: we should start to think a bit more about the architecture of the system. >> >> For example: >> Â Â Â UIManager role vs ToolSet role >> >> Â Â Â for the UI do we want to have it based on globals or on exception. >> I discussed that often with lukas and we came to the conclusion that exceptions are better because we >> could trap differently per thread different aspects (If I recall correctly). >> >> Stef >> >> >> >> >> >> _______________________________________________ >> 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 4, 2010

Re: [Pharo-project] OSProcess and VM crash

by David T. Lewis

On Sun, Jul 04, 2010 at 04:21:03PM +0200, Adrien BARREAU wrote: > > Hi all, > > I wanna understand how OSProcess is working, so I loaded it and tried to run the tests. > And ... my VM crashed. > > It seems to crash during the first tests. > > I'll search to give you more details, but does I sound familiar to somebody? Hi Adrien, The problem is discussed here: http://lists.gforge.inria.fr/pipermail/pharo-project/2010-July/028964.html Some versions of the Mac VM apparently have an out of date plugin that leads to this problem. Dave

July 4, 2010

Re: [Pharo-project] UnhandledError instead of DNU?

by StÃ©phane Ducasse

http://code.google.com/p/pharo/issues/detail?id=2638 of course Stef On Jul 4, 2010, at 4:24 PM, StÃ©phane Ducasse wrote: > Hi pavel > > to explain it to others > > was in 12023 > > UnhandledError>>defaultAction > "The current computation is terminated. The cause of the error should be logged or reported to the user. If the program is operating in an interactive debugging environment the computation should be suspended and the debugger activated." > ^ToolSet debugError: exception. > > > and now in 12033 > we got > > UnhandledError>>defaultAction > > UIManager default unhandledErrorDefaultAction: self > > > DummyManager>>unhandledErrorDefaultAction: anException > > Transcript show: '*** EXCEPTION ***'; cr. > Transcript show: anException; cr. > Transcript show: (thisContext stack first: (20 min: thisContext stack size)); cr. > anException isResumable ifTrue: [ anException resume ] > > > MorphicUIManager>>unhandledErrorDefaultAction: anException > > "The current computation is terminated. The cause of the error should be logged or reported to the user. If the program is operating in an interactive debugging environment the computation should be suspended and the debugger activated." > ^ToolSet debugError: anException. > > Now this raises an interesting question: we should start to think a bit more about the architecture of the system. > > For example: > UIManager role vs ToolSet role > > for the UI do we want to have it based on globals or on exception. > I discussed that often with lukas and we came to the conclusion that exceptions are better because we > could trap differently per thread different aspects (If I recall correctly). > > Stef > > > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

July 4, 2010

Re: [Pharo-project] OSProcess and VM crash

by StÃ©phane Ducasse

how did you loaded it? which version ? did you use ConfigurationOf...? to get precise answers provide more context Stef On Jul 4, 2010, at 4:21 PM, Adrien BARREAU wrote: > Hi all, > > I wanna understand how OSProcess is working, so I loaded it and tried to run the tests. > And ... my VM crashed. > > It seems to crash during the first tests. > > I'll search to give you more details, but does I sound familiar to somebody? > > Adrien. > > Surfez en toute confiance avec IE8, le navigateur le plus utilisÃ© au monde ! _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

July 4, 2010

Re: [Pharo-project] UnhandledError instead of DNU?

by StÃ©phane Ducasse

Hi pavel to explain it to others was in 12023 UnhandledError>>defaultAction "The current computation is terminated. The cause of the error should be logged or reported to the user. If the program is operating in an interactive debugging environment the computation should be suspended and the debugger activated." ^ToolSet debugError: exception. and now in 12033 we got UnhandledError>>defaultAction UIManager default unhandledErrorDefaultAction: self DummyManager>>unhandledErrorDefaultAction: anException Transcript show: '*** EXCEPTION ***'; cr. Transcript show: anException; cr. Transcript show: (thisContext stack first: (20 min: thisContext stack size)); cr. anException isResumable ifTrue: [ anException resume ] MorphicUIManager>>unhandledErrorDefaultAction: anException "The current computation is terminated. The cause of the error should be logged or reported to the user. If the program is operating in an interactive debugging environment the computation should be suspended and the debugger activated." ^ToolSet debugError: anException. Now this raises an interesting question: we should start to think a bit more about the architecture of the system. For example: UIManager role vs ToolSet role for the UI do we want to have it based on globals or on exception. I discussed that often with lukas and we came to the conclusion that exceptions are better because we could trap differently per thread different aspects (If I recall correctly). Stef

July 4, 2010

[Pharo-project] OSProcess and VM crash

by Adrien BARREAU

Hi all, I wanna understand how OSProcess is working, so I loaded it and tried to run the tests. And ... my VM crashed. It seems to crash during the first tests. I'll search to give you more details, but does I sound familiar to somebody? Adrien. _________________________________________________________________ DÃ©couvrez Microsoft Security Essentials, l'antivirus gratuit par Microsoft http://clk.atdmt.com/FRM/go/212688364/direct/01/

July 4, 2010

Re: [Pharo-project] System vs System-support package

by StÃ©phane Ducasse

there is probably a problem since we worked with pavel on reorganization at the package level. Stef On Jul 4, 2010, at 3:53 PM, Michael Roberts wrote: > I am about to post a deprecation of SystemVersion>>version: to 1.2 but > once i have made my changes i see something odd in MC browser: > > dirty packages > * System (System-StephaneDucasse.6) > * System-Support (System-Support-StephaneDucasse.317) > > Stef, have you started to publish System as a whole? did you mean to? > My changes therefore hit two packages. System is still packaged in 1.2 > at its sub-level of ~20 packages. > > thanks, > Mike > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

July 4, 2010

[Pharo-project] System vs System-support package

by Michael Roberts

I am about to post a deprecation of SystemVersion>>version: to 1.2 but once i have made my changes i see something odd in MC browser: dirty packages * System (System-StephaneDucasse.6) * System-Support (System-Support-StephaneDucasse.317) Stef, have you started to publish System as a whole? did you mean to? My changes therefore hit two packages. System is still packaged in 1.2 at its sub-level of ~20 packages. thanks, Mike

July 4, 2010

Re: [Pharo-project] UnhandledError instead of DNU?

by Pavel Krivanek

Hi, The same problem is for 1 error: 'foo'. the problem starts in UnhandledError >> defaultAction. The original implementation calls directly ^ToolSet debugError: exception. The new one calls UIManager that calls ToolSet. I expect that the problem will be somewhere in the hardcoded count of contexts in the debugger. Firstly I expected that the problem is in the missing return (that should be placed back). Cheers, -- Pavel On Sun, Jul 4, 2010 at 1:19 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > It was working in 12023 but no time to check (I'm sick) > > Stef > > On Jul 4, 2010, at 12:19 PM, Gary Chambers wrote: > >> Noticed that a few weeks ago if that's any help. >> >> Regards, Gary >> >> >> ----- Original Message ----- From: "StÃ©phane Ducasse" <stephane.ducasse(a)inria.fr> >> To: "Pharo Development" <Pharo-project(a)lists.gforge.inria.fr> >> Sent: Sunday, July 04, 2010 10:50 AM >> Subject: [Pharo-project] UnhandledError instead of DNU? >> >> >>> In 12033 >>> >>> when I try to generate a DNU >>> >>> example >>> >>> 1 foo >>> >>> I get an handledError and not a debugger >>> >>> I'm trying to identify what changes this behavior. >>> >>> Stef >>> >>> >>> _______________________________________________ >>> 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 4, 2010

Re: [Pharo-project] UnhandledError instead of DNU?

by StÃ©phane Ducasse

It was working in 12023 but no time to check (I'm sick) Stef On Jul 4, 2010, at 12:19 PM, Gary Chambers wrote: > Noticed that a few weeks ago if that's any help. > > Regards, Gary > > > ----- Original Message ----- From: "StÃ©phane Ducasse" <stephane.ducasse(a)inria.fr> > To: "Pharo Development" <Pharo-project(a)lists.gforge.inria.fr> > Sent: Sunday, July 04, 2010 10:50 AM > Subject: [Pharo-project] UnhandledError instead of DNU? > > >> In 12033 >> >> when I try to generate a DNU >> >> example >> >> 1 foo >> >> I get an handledError and not a debugger >> >> I'm trying to identify what changes this behavior. >> >> Stef >> >> >> _______________________________________________ >> 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 4, 2010

Re: [Pharo-project] ConfigurationOfOSProcess updated

by Adrian Lienhard

Ok, that explains it... I've checked the latest beta version of the Mac VM (4.2.5beta1U) and it doesn't ship with a newer version of the plugin. Cheers, Adrian On Jul 3, 2010, at 14:26 , David T. Lewis wrote: > 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 > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

July 4, 2010

Re: [Pharo-project] UnhandledError instead of DNU?

by Gary Chambers

Noticed that a few weeks ago if that's any help. Regards, Gary ----- Original Message ----- From: "StÃ©phane Ducasse" <stephane.ducasse(a)inria.fr> To: "Pharo Development" <Pharo-project(a)lists.gforge.inria.fr> Sent: Sunday, July 04, 2010 10:50 AM Subject: [Pharo-project] UnhandledError instead of DNU? > In 12033 > > when I try to generate a DNU > > example > > 1 foo > > I get an handledError and not a debugger > > I'm trying to identify what changes this behavior. > > Stef > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

July 4, 2010

[Pharo-project] UnhandledError instead of DNU?

by StÃ©phane Ducasse

In 12033 when I try to generate a DNU example 1 foo I get an handledError and not a debugger I'm trying to identify what changes this behavior. Stef

July 4, 2010

Re: [Pharo-project] What does it take to implement tail-call optimization?

by StÃ©phane Ducasse

On Jul 4, 2010, at 11:15 AM, Lukas Renggli wrote: >> What would it take to implement tail-call optimization? > > Implementing tail recursion is easily doable and could be > transparently done at the compiler level. The basic idea (at the > language level) is described here: > > http://stackoverflow.com/questions/2500483?tab=oldest#tab-top > > However, tail call optimization is not a good match for Smalltalk > code. You arbitrarily loose stack frames that you might want for > debugging (and other kinds of reflection). Also the code in the above > article kills the performance of modern VMs, because it manipulates > the runtime stack (if you do the jump using bytecodes that wouldn't be > a problem though). Furthermore you need to take a lot of care to keep > your code correct, because these kind of optimization can easily break > with polymorphism and reflective code. Excellent this is now what was the conclusion of the discussion :) > >> I would really like to know what would be gain and the cost >> (implementation wise to do that). > > I did some analysis in a Squeak 3.9 image a long time ago and I came > to the following conclusion: "In my Squeak image there are 160464 send > locations of which 8884 are possible tail call locations (5.5%). I > guess this does not really make it worth the trouble." > > Lukas > > -- > Lukas Renggli > www.lukas-renggli.ch > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

July 4, 2010

Re: [Pharo-project] What does it take to implement tail-call optimization?

by Lukas Renggli

> What would it take to implement tail-call optimization? Implementing tail recursion is easily doable and could be transparently done at the compiler level. The basic idea (at the language level) is described here: http://stackoverflow.com/questions/2500483?tab=oldest#tab-top However, tail call optimization is not a good match for Smalltalk code. You arbitrarily loose stack frames that you might want for debugging (and other kinds of reflection). Also the code in the above article kills the performance of modern VMs, because it manipulates the runtime stack (if you do the jump using bytecodes that wouldn't be a problem though). Furthermore you need to take a lot of care to keep your code correct, because these kind of optimization can easily break with polymorphism and reflective code. > I would really like to know what would be gain and the cost > (implementation wise to do that). I did some analysis in a Squeak 3.9 image a long time ago and I came to the following conclusion: "In my Squeak image there are 160464 send locations of which 8884 are possible tail call locations (5.5%). I guess this does not really make it worth the trouble." Lukas -- Lukas Renggli www.lukas-renggli.ch

July 4, 2010

Re: [Pharo-project] What does it take to implement tail-call optimization?

by StÃ©phane Ducasse

Hi Stefan I always wanted to understand what a tail recursive execution for smalltalk (I know for the other) would bring to a smalltalk system. We got a lot of discussion during a dagsthul seminar with schemers and others. I would really like to know what would be gain and the cost (implementation wise to do that). Stef On Jul 4, 2010, at 10:26 AM, Stefan Marr wrote: > Hello Pharo: > > What would it take to implement tail-call optimization? > > My goal is to have an Erlang-like framework, which allows to port existing Erlang code as straight forward as possible. > But this requires to have tail-call optimization, since Erlang provides no loops. > > However, I am not going for implementing the whole language and all its semantics, but only the basics I am interested in. > > So, a possible solution would also be a pragma/hint to the compiler to apply the optimization. > > Has anyone done something like this before, or has some hints where to start digging? > > Thanks > Stefan > > > -- > Stefan Marr > Software Languages Lab > Vrije Universiteit Brussel > Pleinlaan 2 / B-1050 Brussels / Belgium > http://soft.vub.ac.be/~smarr > Phone: +32 2 629 2974 > Fax: +32 2 629 3525 > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

July 4, 2010

[Pharo-project] What does it take to implement tail-call optimization?

by Stefan Marr

Hello Pharo: What would it take to implement tail-call optimization? My goal is to have an Erlang-like framework, which allows to port existing Erlang code as straight forward as possible. But this requires to have tail-call optimization, since Erlang provides no loops. However, I am not going for implementing the whole language and all its semantics, but only the basics I am interested in. So, a possible solution would also be a pragma/hint to the compiler to apply the optimization. Has anyone done something like this before, or has some hints where to start digging? Thanks Stefan -- Stefan Marr Software Languages Lab Vrije Universiteit Brussel Pleinlaan 2 / B-1050 Brussels / Belgium http://soft.vub.ac.be/~smarr Phone: +32 2 629 2974 Fax: +32 2 629 3525

July 4, 2010

[Pharo-project] [update 1.2] #12033

by StÃ©phane Ducasse

12033 ----- - Issue 2636: Collection>>ifNotEmpty: and ifEmpty: better comment and more explitcit definition - Issue 2483: test to check that temp are nil out

July 3, 2010

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

Re: [Pharo-project] BogusSnapshotResource >> restoreMethod: ref using deprecated and: and:

by Mariano Martinez Peck

thanks lukas :) Mariano On Fri, Jul 2, 2010 at 5:58 PM, Lukas Renggli <renggli(a)gmail.com> wrote: > Fixed in: > > Name: BogusInfo-lr.22 > Author: lr > Time: 2 July 2010, 5:58:02 pm > UUID: cad9f459-36e1-4859-82a6-1ba6bcaad1c3 > Ancestors: BogusInfo-lr.21 > Dependencies: Bogus-cwp.18, BogusExt-cwp.4 > > - refactored #and:and: callers > > 2010/7/2 Mariano Martinez Peck <marianopeck(a)gmail.com>: > > Hi Lukas. BogusSnapshotResource >> restoreMethod: ref is using the > and: > > and: that was just deprecated in Pharo 1.1. > > > > Just replacing it by this I think should work: > > > > restoreMethod: ref > > | definition | > > definition := snapshot definitions detect: > > [ :ea | > > ea isMethodDefinition and: [ (ea className = ref classSymbol > ) > > and: [ ea selector = ref methodSymbol ] ]] > > ifNone: [ ^ self removeMethod: ref ]. > > definition load > > > > > > cheers > > > > mariano > > > > _______________________________________________ > > Pharo-project mailing list > > Pharo-project(a)lists.gforge.inria.fr > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > > > > -- > Lukas Renggli > www.lukas-renggli.ch > > _______________________________________________ > 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] [BetaTesting] [ANN] Pharo-1.1-11406-rc3dev10.07.1

by Mariano Martinez Peck

2010/7/2 Johan Fabry <jfabry(a)dcc.uchile.cl> > > This RC has problems with 02, I get the below 3 deprecated warnings when > opening a new browser. Who do I notify? > > To the O2 "mainteiners". Alexandre Bergel and David RÃ¶thlisberger as I am aware. I cc'ed them. Cheers Mariano > The method Collection asSortedArray has been deprecated. > Use asArray sort > The method Collection asSortedArray has been deprecated. > Use asArray sort > The method Boolean and:and:and:and: has been deprecated. > Use and: instead > > On 01 Jul 2010, at 18:29, Mariano Martinez Peck wrote: > > Hi folks. I am glad to announce the Pharo 1.1 RC3. It has not too much > changes in compare to RC2. The main change is the menu structure. I also > updated to newest version of external packages. > > Here is the image: > > > https://gforge.inria.fr/frs/download.php/27241/Pharo-1.1-11406-rc3dev10.07.… > > We would really appreaciate feedback and help to fix the failing tests. > > Cheers > > Mariano > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > -- > Johan Fabry > jfabry(a)dcc.uchile.cl - http://dcc.uchile.cl/~jfabry<http://dcc.uchile.cl/%7Ejfabry> > PLEIAD Lab - Computer Science Department (DCC) - University of Chile > > > > > _______________________________________________ > 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

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

by Simon Denier

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? -- Simon

July 2, 2010

[Pharo-project] LDAPlayer deprecated method

by Schwab,Wilhelm K

Andreas, I ran into a warning about LDAPResult>>checkForExceptions sending the now deprecated #or:or:. It was easy to silence (comment out the warning), but that won't fix the problem. Maybe (untested): checkForExceptions ( #( 0 5 6 ) includes:resultCode ) ifFalse: [ | ex | ex := LDAPException newWithCode: resultCode. ex signal: (errorMessage ifEmpty:[ex messageText]) ] Bill

July 2, 2010

Re: [Pharo-project] [BetaTesting] [ANN] Pharo-1.1-11406-rc3dev10.07.1

by Johan Fabry

This RC has problems with 02, I get the below 3 deprecated warnings when opening a new browser. Who do I notify? The method Collection asSortedArray has been deprecated. Use asArray sort The method Collection asSortedArray has been deprecated. Use asArray sort The method Boolean and:and:and:and: has been deprecated. Use and: instead On 01 Jul 2010, at 18:29, Mariano Martinez Peck wrote: > Hi folks. I am glad to announce the Pharo 1.1 RC3. It has not too much changes in compare to RC2. The main change is the menu structure. I also updated to newest version of external packages. > > Here is the image: > > https://gforge.inria.fr/frs/download.php/27241/Pharo-1.1-11406-rc3dev10.07.… > > We would really appreaciate feedback and help to fix the failing tests. > > Cheers > > Mariano > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- Johan Fabry jfabry(a)dcc.uchile.cl - http://dcc.uchile.cl/~jfabry PLEIAD Lab - Computer Science Department (DCC) - University of Chile

July 2, 2010

[Pharo-project] [update 1.2] #12032

by StÃ©phane Ducasse

12032 ----- - Issue 2613: remove PopUpMenu SelectionMenu CustomMenu

July 2, 2010

Re: [Pharo-project] adding a keyboard shotcut in SystemBrowser

by StÃ©phane Ducasse

but we will have still to have the notion of coherent set. Stef On Jul 2, 2010, at 7:19 PM, Gary Chambers wrote: > Petals a pragma approach for registering key shortcuts in context? > > Sent from my iPad > > On 2 Jul 2010, at 06:12 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > >> Dave >> >> I did that more than 5 years ago and it was a nightmare. >> I would really like to have a clean room implementation so that we can plug on instance editor potentially different keybinding. >> >> So yes if somebody want to play with that it would be great. >> >> >> Note that by using an instance variable pointing to a classVar, and only have the method referencing the instance variable >> we can get a shared table with possible per instance specialization to optimise space. >> >> >> Stef >> >> On Jul 2, 2010, at 6:59 PM, Dave Woodward wrote: >> >>> On 07/02/2010 03:16 AM, laurent laffont wrote: >>>> Hi, >>>> >>>> I would like to add a keyboard shortcut in SystemBrowser to trigger Autotest as it's tedious to add/remove a space + accept a method to trigger it. >>>> >>>> I cannot find how I should do this. Ideally this would be an Autotest class extension. >>> >>> I just recently hacked up ParagraphEditor locally to add Emacs-like cursor navigation for the code editor. >> >> I would love that :) >> >>> It has two class side initialization methods which setup callback to some instance side methods. This was in Pharo 1.0, I don't know about 1.1 or 1.2. I also don't know how you'd make the shortcuts cleanly extensible (seems like it might be a good small project?). >>>> >>>> Cheers, >>>> >>>> Laurent Laffont >>>> >>>> http://pharocasts.blogspot.com/ >>>> http://magaloma.blogspot.com/ >>>> >>>> _______________________________________________ >>>> Pharo-project mailing list >>>> >>>> Pharo-project(a)lists.gforge.inria.fr >>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >>> >>> -- >>> Dave Woodward >>> ................................................... >>> >>> www.promedmedical.net >>> >>> 317.332.6438 >>> >>> davewoodward(a)promedmedical.net >>> >>> >>> _______________________________________________ >>> 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 2, 2010

Re: [Pharo-project] adding a keyboard shotcut in SystemBrowser

by Gary Chambers

Petals a pragma approach for registering key shortcuts in context? Sent from my iPad On 2 Jul 2010, at 06:12 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > Dave > > I did that more than 5 years ago and it was a nightmare. > I would really like to have a clean room implementation so that we can plug on instance editor potentially different keybinding. > > So yes if somebody want to play with that it would be great. > > > Note that by using an instance variable pointing to a classVar, and only have the method referencing the instance variable > we can get a shared table with possible per instance specialization to optimise space. > > > Stef > > On Jul 2, 2010, at 6:59 PM, Dave Woodward wrote: > >> On 07/02/2010 03:16 AM, laurent laffont wrote: >>> Hi, >>> >>> I would like to add a keyboard shortcut in SystemBrowser to trigger Autotest as it's tedious to add/remove a space + accept a method to trigger it. >>> >>> I cannot find how I should do this. Ideally this would be an Autotest class extension. >> >> I just recently hacked up ParagraphEditor locally to add Emacs-like cursor navigation for the code editor. > > I would love that :) > >> It has two class side initialization methods which setup callback to some instance side methods. This was in Pharo 1.0, I don't know about 1.1 or 1.2. I also don't know how you'd make the shortcuts cleanly extensible (seems like it might be a good small project?). >>> >>> Cheers, >>> >>> Laurent Laffont >>> >>> http://pharocasts.blogspot.com/ >>> http://magaloma.blogspot.com/ >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> >>> Pharo-project(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> >> -- >> Dave Woodward >> ................................................... >> >> www.promedmedical.net >> >> 317.332.6438 >> >> davewoodward(a)promedmedical.net >> >> >> _______________________________________________ >> 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] adding a keyboard shotcut in SystemBrowser

by StÃ©phane Ducasse

Dave I did that more than 5 years ago and it was a nightmare. I would really like to have a clean room implementation so that we can plug on instance editor potentially different keybinding. So yes if somebody want to play with that it would be great. Note that by using an instance variable pointing to a classVar, and only have the method referencing the instance variable we can get a shared table with possible per instance specialization to optimise space. Stef On Jul 2, 2010, at 6:59 PM, Dave Woodward wrote: > On 07/02/2010 03:16 AM, laurent laffont wrote: >> Hi, >> >> I would like to add a keyboard shortcut in SystemBrowser to trigger Autotest as it's tedious to add/remove a space + accept a method to trigger it. >> >> I cannot find how I should do this. Ideally this would be an Autotest class extension. > > I just recently hacked up ParagraphEditor locally to add Emacs-like cursor navigation for the code editor. I would love that :) > It has two class side initialization methods which setup callback to some instance side methods. This was in Pharo 1.0, I don't know about 1.1 or 1.2. I also don't know how you'd make the shortcuts cleanly extensible (seems like it might be a good small project?). >> >> Cheers, >> >> Laurent Laffont >> >> http://pharocasts.blogspot.com/ >> http://magaloma.blogspot.com/ >> >> _______________________________________________ >> Pharo-project mailing list >> >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > -- > Dave Woodward > ................................................... > > www.promedmedical.net > > 317.332.6438 > > davewoodward(a)promedmedical.net > > > _______________________________________________ > 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] what is the equivalence to PopUpMenu>>setMenuFontTo: aFont in MenuMorph

by stephane ducasse

Since menus are normally created dynamically I'd simply replace with nothing! (see MenuItemMorph>>initialize) Regards, Gary :) On Jul 2, 2010, at 6:59 PM, StÃ©phane Ducasse wrote: > I'm removing PopUpMenu and friends from the image and I need to replace setMenuFontTo: but I do not know with what? > > Stef

July 2, 2010