- Pharo-dev - lists.pharo.org

Re: [Pharo-project] Using Pharo from the command-line

by Igor Stasenko

The problem with command-line arguments as a file names, like: cat myfile.foo is that the location of myfile.foo is determined by using a search path , usually provided in environment PATH var of a shell. I worked in a different unix shells, and some of them, do not adding/using the ./ into the search path by default, which means that cat myfile.foo will end up with 'file not found' message, while cat ./myfile.foo will work fine. i think that squeak should follow the shell semantics and do not try to automatically expand the pure file name, like foo.bar into something like: ./foo.bar, or ~/foo.bar 2009/9/2 John M McIntosh <johnmci(a)smalltalkconsulting.com>: > I think Â here you are trying to get to test.sq > > I only adjust the incoming image name in the VM looking for ~ for > example, and resolving usage of ./ and ../ > > The additional command line items are then passed to the image > unchanged, so it sees only 'test.sq' Â as the path name. > You would have to check the smalltalk code at the point where it gets > the command line parm and decide if it's 'test.sq' should that really > be './test.sq' > You might also try putting './test.sq' on the command line and see if > that works. > > > On 2-Sep-09, at 9:23 AM, StÃ©phane Ducasse wrote: > >>>> >>> The full path requirement should be considered a bug from my >>> perspective. >> >> mine too and I thought that john fixed that. >> So did you try without? > > -- > = > = > = > ======================================================================== > John M. McIntosh <johnmci(a)smalltalkconsulting.com> Â Twitter: > squeaker68882 > Corporate Smalltalk Consulting Ltd. Â http://www.smalltalkconsulting.com > = > = > = > ======================================================================== > > > > > > _______________________________________________ > 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.

Sept. 7, 2009

Re: [Pharo-project] problem with running Pharo under Solaris 10 9/05

by Ivaylo Ganchev

Squeak works fine under solaris 10, I managed to compile one with some struggle. Now a teacher at our department wants to have pharo, because she feels better with it. I was suggested by her to ask a for assistance at the mailing list. Regards, Ivaylo StÃ©phane Ducasse wrote: > first you should try squeak to run on solaris because there was a > release on the new squeak vm. > Then solaris this is 10 years I do not touch one :) > > Stef > > On Sep 7, 2009, at 3:58 PM, ivaylo.ganchev(a)univ-paris8.fr wrote: > > >> Hello. >> >> I can't manage to run the virtual machine under solaris 10. I have >> permanently the following output: >> >> -bash: ./squeak: Invalid argument >> >> Here is the output when I try to run the image with the vm of squeak: >> >> iconv_open: Invalid argument >> This interpreter (vers. 6502) cannot read image file (vers. >> 1746468864). >> Press CR to quit... >> >> Could someone provide me with a solution or with instructions to >> compile a >> vm for Solaris 10? The makefile is somewhat obscure with plenty of >> includes at /home/bryce/squeak/exupery without knowing whatś in >> there. >> >> Help would be much appreciated. >> >> Thanks in advance, >> Ivaylo >> >> >> _______________________________________________ >> 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 > >

Sept. 7, 2009

Re: [Pharo-project] The better debugger support by extending an Object protocol

by Peter Hugosson-Miller

On 7 sep 2009, at 17.02, Igor Stasenko <siguctua(a)gmail.com> wrote: > Hello guys, > i'd like to discuss with you an idea of having a specific methods in > Object class for a better and more clever behavior when debugging. > > For those of you who are using different kinds of proxies, the main > problem with them that you should override the #printOn: > or #printString methods in order to behave them similar to what > original(proxied) object should be, > but from other side, especially for debugging purposes, this incurs a > major inconvenience, because you often need to differentiate between > the real object and object proxy while debugging. Because if proxy > behaves similar to proxied object while printing, you can't really > make a difference when looking at it. > > So, i thought that a nice solution would be to extend an Object > protocol especially for debugging purposes by adding > #debugPrintOn: > method > and change the debugger to use this message, instead of #printOn: for > displaying objects in inspector panels. > > Here is the default implementation of > > Object>>debugPrintOn: aStream > ^ self printOn: aStream > > And, as you may guess, now the proxy could choose to behave > differently depending on context. > > P.S. Maybe i'm missing a point, and there are already the existing > good practices how to get around this.. if so, then please tell me. > > -- > 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 Just one thing: maybe the default implementation could wrap that call to #printOn: in an exception handler, in case one is in the process of debugging a #printOn: method. The exception could just swallow all errors and return a String like 'Receiver cannot be printed' or similar. -- Cheers, Peter

Sept. 7, 2009

Re: [Pharo-project] Closure review

by Damien Cassou

Hi Michael, On Wed, Sep 2, 2009 at 10:50 PM, Michael Roberts<mike(a)mjr104.co.uk> wrote: > can someone point me to any of the following > 2) a definitive squeak (or other) image with closures integrated. Did > Elliot publish a closure image? Pharo has closures for a long time now: http://pharo-project.org/pharo-download -- Damien Cassou http://damiencassou.seasidehosting.st "Lambdas are relegated to relative obscurity until Java makes them popular by not having them." James Iry

Sept. 7, 2009

Re: [Pharo-project] The better debugger support by extending an Object protocol

by Igor Stasenko

2009/9/7 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: > good idea! > We will add that in pharo if you open a bug item ticket. > Stef > I could add it easily. But first we should make a good expertise, if this change is worth doing. Because for Object it means a trivial addition of a method, but for Debugger/Inspector and other tools this could mean a major refactoring and tracing all calls to printing methods in order to make sure that all of them using new message(s). This could be a big amount of work :) > On Sep 7, 2009, at 5:02 PM, Igor Stasenko wrote: > >> Hello guys, >> i'd like to discuss with you an idea of having a specific methods in >> Object class for a better and more clever behavior when debugging. >> >> For those of you who are using different kinds of proxies, the main >> problem with them that you should override the #printOn: >> or #printString methods in order to behave them similar to what >> original(proxied) object should be, >> but from other side, especially for debugging purposes, this incurs a >> major inconvenience, because you often need to differentiate between >> the real object and object proxy while debugging. Because if proxy >> behaves similar to proxied object while printing, you can't really >> make a difference when looking at it. >> >> So, i thought that a nice solution would be to extend an Object >> protocol especially for debugging purposes by adding >> #debugPrintOn: >> method >> and change the debugger to use this message, instead of #printOn: for >> displaying objects in inspector panels. >> >> Here is the default implementation of >> >> Object>>debugPrintOn: aStream >> Â ^ self printOn: aStream >> >> And, as you may guess, now the proxy could choose to behave >> differently depending on context. >> >> P.S. Maybe i'm missing a point, and there are already the existing >> good practices how to get around this.. if so, then please tell me. >> >> -- >> 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.

Sept. 7, 2009

Re: [Pharo-project] Using Pharo from the command-line

by Damien Cassou

Hi Stefan, On Tue, Sep 1, 2009 at 8:38 PM, Stefan Marr<pharo(a)stefan-marr.de> wrote: > However as a thank you and for my own records, a small tutorial for > your google code wiki: I've put your text to http://code.google.com/p/pharo/wiki/CommandLine. Thank you very much -- Damien Cassou http://damiencassou.seasidehosting.st "Lambdas are relegated to relative obscurity until Java makes them popular by not having them." James Iry

Sept. 7, 2009

Re: [Pharo-project] The better debugger support by extending an Object protocol

by StÃ©phane Ducasse

good idea! We will add that in pharo if you open a bug item ticket. Stef On Sep 7, 2009, at 5:02 PM, Igor Stasenko wrote: > Hello guys, > i'd like to discuss with you an idea of having a specific methods in > Object class for a better and more clever behavior when debugging. > > For those of you who are using different kinds of proxies, the main > problem with them that you should override the #printOn: > or #printString methods in order to behave them similar to what > original(proxied) object should be, > but from other side, especially for debugging purposes, this incurs a > major inconvenience, because you often need to differentiate between > the real object and object proxy while debugging. Because if proxy > behaves similar to proxied object while printing, you can't really > make a difference when looking at it. > > So, i thought that a nice solution would be to extend an Object > protocol especially for debugging purposes by adding > #debugPrintOn: > method > and change the debugger to use this message, instead of #printOn: for > displaying objects in inspector panels. > > Here is the default implementation of > > Object>>debugPrintOn: aStream > ^ self printOn: aStream > > And, as you may guess, now the proxy could choose to behave > differently depending on context. > > P.S. Maybe i'm missing a point, and there are already the existing > good practices how to get around this.. if so, then please tell me. > > -- > 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

Sept. 7, 2009

[Pharo-project] [update] 10440

by Marcus Denker

10440 ----- Issue 897: MethodPragmaTest>>testReformat failure Issue 1164: test failure: #testClassWithInvalidClassVariablesShouldNotBeReferencedByItsSuperclass -- Marcus Denker - http://marcusdenker.de PLEIAD Lab - Computer Science Department (DCC) - University of Chile

Sept. 7, 2009

[Pharo-project] The better debugger support by extending an Object protocol

by Igor Stasenko

Hello guys, i'd like to discuss with you an idea of having a specific methods in Object class for a better and more clever behavior when debugging. For those of you who are using different kinds of proxies, the main problem with them that you should override the #printOn: or #printString methods in order to behave them similar to what original(proxied) object should be, but from other side, especially for debugging purposes, this incurs a major inconvenience, because you often need to differentiate between the real object and object proxy while debugging. Because if proxy behaves similar to proxied object while printing, you can't really make a difference when looking at it. So, i thought that a nice solution would be to extend an Object protocol especially for debugging purposes by adding #debugPrintOn: method and change the debugger to use this message, instead of #printOn: for displaying objects in inspector panels. Here is the default implementation of Object>>debugPrintOn: aStream ^ self printOn: aStream And, as you may guess, now the proxy could choose to behave differently depending on context. P.S. Maybe i'm missing a point, and there are already the existing good practices how to get around this.. if so, then please tell me. -- Best regards, Igor Stasenko AKA sig.

Sept. 7, 2009

Re: [Pharo-project] problem with running Pharo under Solaris 10 9/05

by StÃ©phane Ducasse

first you should try squeak to run on solaris because there was a release on the new squeak vm. Then solaris this is 10 years I do not touch one :) Stef On Sep 7, 2009, at 3:58 PM, ivaylo.ganchev(a)univ-paris8.fr wrote: > Hello. > > I can't manage to run the virtual machine under solaris 10. I have > permanently the following output: > > -bash: ./squeak: Invalid argument > > Here is the output when I try to run the image with the vm of squeak: > > iconv_open: Invalid argument > This interpreter (vers. 6502) cannot read image file (vers. > 1746468864). > Press CR to quit... > > Could someone provide me with a solution or with instructions to > compile a > vm for Solaris 10? The makefile is somewhat obscure with plenty of > includes at /home/bryce/squeak/exupery without knowing whatś in > there. > > Help would be much appreciated. > > Thanks in advance, > Ivaylo > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Sept. 7, 2009