November 2009 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] Error handling failure during load

by Igor Stasenko

2009/11/3 Schwab,Wilhelm K <bschwab(a)anest.ufl.edu>: > Sig, > > How would Sake help? > It supports logging and defining a 'build process' http://wiki.squeak.org/squeak/Sake > Bill > > > > -----Original Message----- > From: pharo-project-bounces(a)lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Igor Stasenko > Sent: Tuesday, November 03, 2009 11:32 AM > To: Pharo-project(a)lists.gforge.inria.fr > Subject: Re: [Pharo-project] Error handling failure during load > > 2009/11/3 Schwab,Wilhelm K <bschwab(a)anest.ufl.edu>: >> Hello all, >> >> I am gradually approaching a working load "script," but I just hit a new wrinkle in RC1: at some point in the process I get offered an emergency evaluator, which appears unable to open. Â There is mention of looking for something in the system dictionary, and something about "system error handling failed." Â Nothing is logged, and the image is helpless at that point. Â Any ideas for how to debug it? >> >> Creating my own build log comes to mind; the idea would be to open/update/close each time it starts work on a new package. Â I can also load the loader into a clean older image and see what happens. >> >> It would be _really_ nice to have a clean-loading version of OS Process/Command Shell. Â Actually, I do not need the shell at all, but I do need the pipeable processes. >> > > Sake is your friend then :) > >> Bill >> >> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > > > -- > Best regards, > Igor Stasenko AKA sig. > > _______________________________________________ > 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 > -- Best regards, Igor Stasenko AKA sig.

Nov. 3, 2009

Re: [Pharo-project] Error handling failure during load

by Schwab,Wilhelm K

Sig, How would Sake help? Bill -----Original Message----- From: pharo-project-bounces(a)lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Igor Stasenko Sent: Tuesday, November 03, 2009 11:32 AM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] Error handling failure during load 2009/11/3 Schwab,Wilhelm K <bschwab(a)anest.ufl.edu>: > Hello all, > > I am gradually approaching a working load "script," but I just hit a new wrinkle in RC1: at some point in the process I get offered an emergency evaluator, which appears unable to open. Â There is mention of looking for something in the system dictionary, and something about "system error handling failed." Â Nothing is logged, and the image is helpless at that point. Â Any ideas for how to debug it? > > Creating my own build log comes to mind; the idea would be to open/update/close each time it starts work on a new package. Â I can also load the loader into a clean older image and see what happens. > > It would be _really_ nice to have a clean-loading version of OS Process/Command Shell. Â Actually, I do not need the shell at all, but I do need the pipeable processes. > Sake is your friend then :) > Bill > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Best regards, Igor Stasenko AKA sig. _______________________________________________ Pharo-project mailing list Pharo-project(a)lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Nov. 3, 2009

Re: [Pharo-project] vm on ubuntu

by Schwab,Wilhelm K

Are there any changes to the vm itself (or plugins)? -----Original Message----- From: pharo-project-bounces(a)lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Damien Cassou Sent: Tuesday, November 03, 2009 11:27 AM To: Mariano Martinez Peck Cc: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] vm on ubuntu On Tue, Nov 3, 2009 at 3:13 AM, Mariano Martinez Peck <marianopeck(a)gmail.com> wrote: > Damien: I updated the README.txt with the Doru's experience. I just add: > > "You may have an error saying that it did not find any "ia32-libs" package. > In that case, you can try: > > sudo apt-get update" > > I attach the new version of the README.txt. Would you mind putting it > in the next LinuxVM zip of the website download? done. Thank you -- Damien Cassou http://damiencassou.seasidehosting.st "Lambdas are relegated to relative obscurity until Java makes them popular by not having them." James Iry _______________________________________________ Pharo-project mailing list Pharo-project(a)lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Nov. 3, 2009

Re: [Pharo-project] Error handling failure during load

by Igor Stasenko

2009/11/3 Schwab,Wilhelm K <bschwab(a)anest.ufl.edu>: > Hello all, > > I am gradually approaching a working load "script," but I just hit a new wrinkle in RC1: at some point in the process I get offered an emergency evaluator, which appears unable to open. Â There is mention of looking for something in the system dictionary, and something about "system error handling failed." Â Nothing is logged, and the image is helpless at that point. Â Any ideas for how to debug it? > > Creating my own build log comes to mind; the idea would be to open/update/close each time it starts work on a new package. Â I can also load the loader into a clean older image and see what happens. > > It would be _really_ nice to have a clean-loading version of OS Process/Command Shell. Â Actually, I do not need the shell at all, but I do need the pipeable processes. > Sake is your friend then :) > Bill > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Best regards, Igor Stasenko AKA sig.

Nov. 3, 2009

Re: [Pharo-project] vm on ubuntu

by Damien Cassou

On Tue, Nov 3, 2009 at 3:13 AM, Mariano Martinez Peck <marianopeck(a)gmail.com> wrote: > Damien: I updated the README.txt with the Doru's experience. I just add: > > "You may have an error saying that it did not find any "ia32-libs" package. > In that case, you can try: > > sudo apt-get update" > > I attach the new version of the README.txt. Would you mind putting it in the > next LinuxVM zip of the website download? done. Thank you -- Damien Cassou http://damiencassou.seasidehosting.st "Lambdas are relegated to relative obscurity until Java makes them popular by not having them." James Iry

Nov. 3, 2009

Re: [Pharo-project] Compiler compile:

by Gary Chambers

+1 too. Fewer side-effects and/or more side-effect free refactoring is better. Regards, Gary ----- Original Message ----- From: "Igor Stasenko" <siguctua(a)gmail.com> To: <Pharo-project(a)lists.gforge.inria.fr> Sent: Tuesday, November 03, 2009 3:56 PM Subject: Re: [Pharo-project] Compiler compile: > +1 Niko. > There should be an easy interface for compiling the source code > without installing the result into system. > And of course, compiler should answer an instance of compiled method > > 2009/11/3 Niko Schwarz <niko.schwarz(a)googlemail.com>: >> Hi list, >> >> consider this code: >> >> c := Compiler compile: 'meth "bla" ^ 2'. >> > Try using > > c:= Compiler new > compiledMethodFor: ... > > > The class-side #compile:... method , is method which serves for > directly compiling & installing the method into receiver. > In the above case - into Compiler class, but you can also do that for > any other class: > > MyClass compile: .... > >> Here, c will be set to the symbol #meth. And Compiler will be added a >> new method "meth". >> >> This is of course counter-intuitive, but it's kind of wired into the >> system. Behavior>compile: does certainly more than compile. It >> compiles the code and adds it to itself, then returns the methodName >> as a symbol. Without mirrors, it's hard to do it right, though. >> >> Also, there's an easy method to add a method to a class, but no easy >> method to get a CompiledMethod object. I don't want to strongly >> advocate for my change, I just want to offer it. Here's what I did in >> my system: >> >> I changed Compiler>compile: to do the following: >> class side: >> >> compile: aString onClass: aClass >> ^ self new compiledMethodFor: aString onClass: aClass >> >> instance side: >> >> compiledMethodFor: textOrStream onClass: aClass >> >> | methodNode method | >> class := aClass. >> self from: textOrStream class: class context: nil notifying: nil. >> methodNode := self translate: sourceStream noPattern: false ifFail: >> [^self error: 'Compilation failed']. >> method := methodNode generate: #(0 0 0 0). >> self interactive ifTrue: >> [method := method copyWithTempsFromMethodNode: methodNode]. >> ^method >> >> This has its own problem, like: compile: suddenly has different >> semantics on Compiler than anywhere else. Best might be renaming >> Behavior>compile: to something more intuitive. Like >> #compileFromAndAdd:. >> >> Cheers, >> >> Niko >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > > > -- > Best regards, > Igor Stasenko AKA sig. > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Nov. 3, 2009

[Pharo-project] Error handling failure during load

by Schwab,Wilhelm K

Hello all, I am gradually approaching a working load "script," but I just hit a new wrinkle in RC1: at some point in the process I get offered an emergency evaluator, which appears unable to open. There is mention of looking for something in the system dictionary, and something about "system error handling failed." Nothing is logged, and the image is helpless at that point. Any ideas for how to debug it? Creating my own build log comes to mind; the idea would be to open/update/close each time it starts work on a new package. I can also load the loader into a clean older image and see what happens. It would be _really_ nice to have a clean-loading version of OS Process/Command Shell. Actually, I do not need the shell at all, but I do need the pipeable processes. Bill

Nov. 3, 2009

Re: [Pharo-project] lastKeystroke: ???

by Igor Stasenko

Just checked.. there is senders of #lastKeyStroke: in my Pharo image, but no senders of #lastKeyStroke , to retreive it.. Which means that both these accessors can be just wiped out 2009/11/3 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: > Thanks > this is probably that! > > Stef > > On Nov 2, 2009, at 11:16 PM, HernÃ¡n Morales Durand wrote: > >> Hi Stef, maybe they were removed cleaning eToys, because the methods >> #lastKeystroke and #lastKeystroke: were under *etoys-e-toy support >> method category. I've attached both under 'event handling' category >> now. >> Cheers, >> >> HernÃ¡n >> >> 2009/11/1 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> >> Hi guys >> >> apparently typing a character on the world -> DNU >> Â lastKeystroke: from PasteUpMorph is not there. >> Apparently the senders was integrated by me on 26 of October but I >> could not find its trace. >> So does anybody know from where this bug is coming? >> >> Stef >> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> <PasteUpMorph-#event >> handling.st>_______________________________________________ >> 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 > -- Best regards, Igor Stasenko AKA sig.

Nov. 3, 2009

Re: [Pharo-project] lastKeystroke: ???

by StÃ©phane Ducasse

Thanks this is probably that! Stef On Nov 2, 2009, at 11:16 PM, HernÃ¡n Morales Durand wrote: > Hi Stef, maybe they were removed cleaning eToys, because the methods > #lastKeystroke and #lastKeystroke: were under *etoys-e-toy support > method category. I've attached both under 'event handling' category > now. > Cheers, > > HernÃ¡n > > 2009/11/1 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> > Hi guys > > apparently typing a character on the world -> DNU > lastKeystroke: from PasteUpMorph is not there. > Apparently the senders was integrated by me on 26 of October but I > could not find its trace. > So does anybody know from where this bug is coming? > > Stef > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > <PasteUpMorph-#event > handling.st>_______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Nov. 3, 2009

Re: [Pharo-project] Compiler compile:

by Igor Stasenko

+1 Niko. There should be an easy interface for compiling the source code without installing the result into system. And of course, compiler should answer an instance of compiled method 2009/11/3 Niko Schwarz <niko.schwarz(a)googlemail.com>: > Hi list, > > consider this code: > > c := Compiler compile: 'meth "bla" Â ^ 2'. > Try using c:= Compiler new compiledMethodFor: ... The class-side #compile:... method , is method which serves for directly compiling & installing the method into receiver. In the above case - into Compiler class, but you can also do that for any other class: MyClass compile: .... > Here, c will be set to the symbol #meth. And Compiler will be added a > new method "meth". > > This is of course counter-intuitive, but it's kind of wired into the > system. Behavior>compile: does certainly more than compile. It > compiles the code and adds it to itself, then returns the methodName > as a symbol. Without mirrors, it's hard to do it right, though. > > Also, there's an easy method to add a method to a class, but no easy > method to get a CompiledMethod object. I don't want to strongly > advocate for my change, I just want to offer it. Here's what I did in > my system: > > I changed Compiler>compile: to do the following: > class side: > > compile: aString onClass: aClass > Â Â Â Â ^ self new compiledMethodFor: aString onClass: aClass > > instance side: > > compiledMethodFor: textOrStream onClass: aClass > > Â Â Â Â | methodNode method | > Â Â Â Â class := aClass. > Â Â Â Â self from: textOrStream class: class context: nil notifying: nil. > Â Â Â Â methodNode := self translate: sourceStream noPattern: false ifFail: > [^self error: 'Compilation failed']. > Â Â Â Â method := methodNode generate: #(0 0 0 0). > Â Â Â Â self interactive ifTrue: > Â Â Â Â Â Â Â Â [method := method copyWithTempsFromMethodNode: methodNode]. > Â Â Â Â ^method > > This has its own problem, like: compile: suddenly has different > semantics on Compiler than anywhere else. Best might be renaming > Behavior>compile: to something more intuitive. Like > #compileFromAndAdd:. > > Cheers, > > Niko > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Best regards, Igor Stasenko AKA sig.

Nov. 3, 2009