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

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