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

[Pharo-project] VNC on mac?

by Lawson English

I've been trying to test the RFBServer on a Mac using the Seaside 2.8.4 image. I'm using Chicken of the VNC as my VNC client, but all I get is a static iamge of the Squeak desktop. Can't referesh and certainly can't interact. The connection info says it IS an interactive session though. Any ideas for what I'm doing wrong? THanks Lawson

Sept. 7, 2009

Re: [Pharo-project] OSProcess and SqueakMap

by Ross Boylan

On Mon, 2009-09-07 at 16:00 -0400, David T. Lewis wrote: > On Mon, Sep 07, 2009 at 12:15:28PM -0700, Ross Boylan wrote: > > I want to run the magma tester, which is much easier if OS Process is > > around. It doesn't seem to be in the image or Monticello, and I think > > it is only available from SqueakMap. > > OSProcess and CommandShell (formerly part of OSProcess until I split it) > are both on SqueakSource. For Pharo, I recommend that you load the latest > versions from SqueakSource rather than from SqueakMap (I made a fix just > yesterday that is important for Pharo users). Be sure to get the unit tests > also, they are a good source of examples. OSProcess loaded fine, but CommandShell says PluggableTextController and PluggableTextView. > > I have not tested on the latest Pharo, but I did notice one test failure > for OSProcess the last time I checked. It was something involving coordinating > lots of (Smalltalk) processes. One of the CommandShell tests was not running > to completion either, probably for the same reason. I'm not sure if it is > still a problem on the latest Pharo or not (sorry, I have not had time to > track it down yet). > > Also, CommandShell will not show up in the menus on Pharo, so you will > need to evaluate "CommandShell open" to start a shell. > > > What's the best way to get OSProcess into the image? Is it already > > there? Not compatible? > > It should not be necessary to add it to the image. I meant into my image, not the baseline image. > I always intended for > OSProcess to be an external package, and it should be easy enough to load > for anyone who wants to use it. Do I need the OSProcess plugin? Thanks. Ross

Sept. 7, 2009

Re: [Pharo-project] CLFramework-UIBuilder

by nullPointer

I donÂ´t understand. The last dev image (10440) works for me in that point :( . Regards. Torsten Bergmann wrote: > >>i published the CLFramework package > > Nice! > > > First bug report: > In CLBuilderMainForm>>createNewView you send > #alert:text:title: to the current UI theme > > but this message is not in the latest core image. > > Bye > Torsten > > > -- > Neu: GMX Doppel-FLAT mit Internet-Flatrate + Telefon-Flatrate > fÃ¼r nur 19,99 Euro/mtl.!* http://portal.gmx.net/de/go/dsl02 > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > -- View this message in context: http://n2.nabble.com/CLFramework-UIBuilder-tp3596854p3599379.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Sept. 7, 2009

Re: [Pharo-project] OSProcess and SqueakMap

by David T. Lewis

On Mon, Sep 07, 2009 at 12:15:28PM -0700, Ross Boylan wrote: > I want to run the magma tester, which is much easier if OS Process is > around. It doesn't seem to be in the image or Monticello, and I think > it is only available from SqueakMap. OSProcess and CommandShell (formerly part of OSProcess until I split it) are both on SqueakSource. For Pharo, I recommend that you load the latest versions from SqueakSource rather than from SqueakMap (I made a fix just yesterday that is important for Pharo users). Be sure to get the unit tests also, they are a good source of examples. I have not tested on the latest Pharo, but I did notice one test failure for OSProcess the last time I checked. It was something involving coordinating lots of (Smalltalk) processes. One of the CommandShell tests was not running to completion either, probably for the same reason. I'm not sure if it is still a problem on the latest Pharo or not (sorry, I have not had time to track it down yet). Also, CommandShell will not show up in the menus on Pharo, so you will need to evaluate "CommandShell open" to start a shell. > What's the best way to get OSProcess into the image? Is it already > there? Not compatible? It should not be necessary to add it to the image. I always intended for OSProcess to be an external package, and it should be easy enough to load for anyone who wants to use it. Dave

Sept. 7, 2009

[Pharo-project] OSProcess and SqueakMap

by Ross Boylan

I want to run the magma tester, which is much easier if OS Process is around. It doesn't seem to be in the image or Monticello, and I think it is only available from SqueakMap. What's the best way to get OSProcess into the image? Is it already there? Not compatible? A few months ago the recommendation for SM seemed to be (Adrian Leinhard) "you can download the MCZ file using a web browser from http://map.squeak.org/ ". There were also indications of other alternatives present or on the way. Thanks. Ross Boylan

Sept. 7, 2009

[Pharo-project] confusion about where to look for sources file

by Ross Boylan

I got http://gforge.inria.fr/frs/download.php/23087/pharo1.0-10440-BETAdev09.09.1… and http://gforge.inria.fr/frs/download.php/22745/pharo-vm-0.15.2d-linux.zip. Both unzipped into subdirectories. In the top level directory I created symlinks to the image and changes file (from the first zip) and a sources file (already on my system). Then I ran pharo-vm-0.15.2d-linux/squeak pharo1.0-10418-BETAdev09.08.3.image & This gave me an error that I needed the sources file in the same directory as my image file. However, the path it gave was the directory of the squeak executable. When I installed a symlink to the sources in the the squeak executable directory, start up was without complaint. So, I think it is not looking for the sources in the image directory. Ideally, it would; alternately, the error message should be consistent with the current behavior. I'm not sure if this kind of report should go to this list or the bug tracker.... Ross Boylan

Sept. 7, 2009

Re: [Pharo-project] Closure review

by Michael Roberts

Hi yes I know. I was not clear enough. Pharo gas had closures for some time and I helped test the integration - but the debugger has been broken since they were integrated. I wanted the definitive source so I could check the integration. It turns out eliot knew the debugger was broken along with a few other things and gas kindly applied fixes to the squeak trunk. We are now integrating these in pharo cheers mike On Monday, September 7, 2009, Damien Cassou <damien.cassou(a)gmail.com> wrote: > 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 > > _______________________________________________ > 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] New Pharo based on core 10440

by Damien Cassou

I've just uploaded new Pharo and Pharo-web images based on 10440: http://pharo-project.org/pharo-download. Refactorings should work again. Please report any issue -- 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] Using Pharo from the command-line

by David T. Lewis

See class ShellSyntax in package CommandShell (be sure to load the unit tests also). The class comment for ShellSyntax is: My instances implement parsing of strings in a manner similar to a simple Unix command shell. I provide path name expansion in the context of an external file system, and support the syntax required for IO redirection. All file name globbing and PATH searching are implemented in Smalltalk rather than in C library functions or an external command shell. Most of my syntax is applicable for any operating system. Where needed, platform specific methods are in my "platform dependent" category. Currently, Unix and Windows are supported, and other platforms have not been tested. The primary difference between Unix and Windows support is that device names (such as 'C:') are used in Windows path strings. Separate current working directory strings are maintained for all Windows device names. For Unix, a single current working directory path is used. On Windows, this permits the CommandShell 'cd' command to support changing directories to another device without losing track of the current working directory for the previous device. Command pipeline syntax is not supported here. See CommandShell for the implementation of command pipelines. Dave On Mon, Sep 07, 2009 at 08:54:18AM -0700, Igor Stasenko wrote: > 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. > > _______________________________________________ > 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 Michael Roberts

I think it is a reasonable approach. GemStone has a few debugger switches which affect the debugging of proxies ( at least stubs) so I mention that since it is a similar area. Where your extension perhaps wouldn't scale is if this became an enthusiastic growth of API if you found other useful things to do as well. Another way to look at it would be to implement a per process or dynamic variable that objects could access like self debuggingContext where the object could find out about it's current execution environment. In your proxy objects you would access this in the print method. I'm not sure if it is a good idea or not but such an object could then hold onto more complex state. Eg stub debugging, print policy, debugging replication specs etc. Just a thought cheers mike On Monday, September 7, 2009, Igor Stasenko <siguctua(a)gmail.com> wrote: > 2009/9/7 Peter Hugosson-Miller <oldmanlink(a)gmail.com>: >> 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. >> > > AFAIK, debugger already having a work-arounds for this, so if > #printOn: throws an exception > it displays a reddish string , "object can't be printed, try debug > object printString" or similar. > > What is interesting about that, that at some point, the source of such > errors could be that an object which you > trying to print is not fully initialized because developer do not > expected the usage of #printString at early stages of object > initialization, but this often happens in Debugger when you evaluating > the code step-by-step. > This just another case, where separate #debugPrintOn: could be useful. > > But i don't want to make it too clever in the Object, as you > proposing, instead, i think it should be plain stupid and act as an > entry point, while one who overriding this message > could make sure that #debugPrintOn: never throws an exception... But > still, this doesn't means that debugger should not care about such > things by itself. > >> -- >> Cheers, >> Peter >> >> _______________________________________________ >> 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

Sept. 7, 2009