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

Re: [Pharo-project] OSProcess - working on gnuplot

by David T. Lewis

On Sun, Nov 15, 2009 at 03:04:49PM -0500, Schwab,Wilhelm K wrote: > > I am slowly gathering ideas on how to write an interface to gnuplot. > It will probably be enough to use PipeableOSPRocess class>>command: to > grab output from it, but it will be inefficient for producing large > numbers of graphs. > > Ideally, I would like to run the program and obtain output without > creating so much as a named pipe; it appears to be possible to route > output to standard out, so there is a potential for it to work. For > a single graph, think I see how to make that go. > > For large numbers of graphs, one could allow gnuplot to write the files; > that might even be preferred in many situations, but right now I appear > to be designing that way because I don't know another way - I'm trying > to leave Windows behind me :) Hi Bill, You should probably first check out the suggestion from Levente: > You don't have to reinvent the wheel all the time: > http://www.squeaksource.com/GNUPlot.html But your question is interesting to me, because the first free software thing I ever wrote was gl_plot, which appeared in comp.sources.unix volume 18, and was used for generating graphics to support gnuplot on PC unix (Microport System V/AT) back before PC unix had graphics support. It's still out there in case you want to run gnuplot on your 286 unix pc: http://ftp.isc.org/pub/usenet/comp.sources.unix/volume18/gl_plot Anyway, back to the new millenium. Yes you should definitely be able to control a gnuplot process with a connected PipeableOSProcess. That's what it is designed for. > Is there a clean way to start gnuplot, leave it running, write to its > stdin, read from its stdout almost as if it were a TCP server, and then > close it when I'm ready to do so? Sure, see PipeableOSProcess class>>tkExample for an example of how to do this. Use /usr/bin/gnuplot instead of /usr/bin/wish of course. However (and this is a big caveat at the moment), OSProcess and CommandShell currently do not work properly on Pharo for reasons that I don't yet understand. So definitely check out Levente's suggestion as a first step. > I tried running CommandShell thinking > that might let me demo it, but appears to be stuck back in MVC?? CommandShell has user interfaces for both Morphic and MVC. Pharo does not have MVC, but that should not effect the Morphic side, other than the annoyance of having to skip over the errors when you load it. Dave

Nov. 15, 2009

[Pharo-project] Printing block contents in inspector, debugger

by CÃ©drick BÃ©ler

Hi, http://code.google.com/p/pharo/issues/detail?id=1450 I find annoying that the content of Blocks are not displayed when debugging. So by adding this last line, I can see the content without variable names (but that's ok to me) BlockClosure>>printOn: aStream aStream nextPutAll: '[closure] in '. outerContext printOn: aStream. aStream cr; nextPutAll: self decompile printString. What do you think of it ? Has the decompile method some limitations that will prevent to use it for such a usage ? A variation (second file): BlockClosure>>printOn: aStream aStream nextPutAll: self decompile printString. aStream nextPutAll: ' in '. outerContext printOn: aStream. that gives by inspecting [1000 factorial]: {[1000 factorial]} in UndefinedObject>>DoIt --- When it's not very nice is when inspecting: [:x :y | | temp | 1 + x@y. ^temp] {[:t1 :t2 | | t3 | 1 + t1 @ t2. ^ t3]} in UndefinedObject>>DoIt so here maybe the first version is better. Last point, I don't know how to get the real variable names and also how to remove the code formatting, but that's details. Thanks -- CÃ©drick

Nov. 15, 2009

Re: [Pharo-project] broken package browser

by Adrian Lienhard

Yes, I noticed that too. I created an issue in the tracker: http://code.google.com/p/pharo/issues/detail?id=1445 Adrian On Nov 15, 2009, at 22:38 , Tudor Girba wrote: > The package browser is broken in the 10495 dev image. > > For some reason, the cmdFactories array contained nil objects, so I > had to patch it: > scanNodeCommands: ann > (cmdFactories select: [:ea | ea notNil and: [ea takesNodes]]) > do: [:ea | ann addFactory: ea] > > I am not sure whether the problem is really in OB or in the image. > > Cheers, > Doru > > > -- > www.tudorgirba.com > > "Obvious things are difficult to teach." > > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Nov. 15, 2009

[Pharo-project] broken package browser

by Tudor Girba

The package browser is broken in the 10495 dev image. For some reason, the cmdFactories array contained nil objects, so I had to patch it: scanNodeCommands: ann (cmdFactories select: [:ea | ea notNil and: [ea takesNodes]]) do: [:ea | ann addFactory: ea] I am not sure whether the problem is really in OB or in the image. Cheers, Doru -- www.tudorgirba.com "Obvious things are difficult to teach."

Nov. 15, 2009

Re: [Pharo-project] Profile It - Use of TimeProfiler instead + general information displayed by default

by CÃ©drick BÃ©ler

http://code.google.com/p/pharo/issues/detail?id=1449

Nov. 15, 2009

Re: [Pharo-project] OSProcess - working on gnuplot

by Levente Uzonyi

It runs on all platforms, including win32. Levente On Sun, 15 Nov 2009, Schwab,Wilhelm K wrote: > It makes explicit reference to win32, so I excluded it on that basis. Are you saying it runs elsewhere? > > > > -----Original Message----- > From: pharo-project-bounces(a)lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Levente Uzonyi > Sent: Sunday, November 15, 2009 3:26 PM > To: Pharo-project(a)lists.gforge.inria.fr > Subject: Re: [Pharo-project] OSProcess - working on gnuplot > > Hi, > > You don't have to reinvent the wheel all the time: > http://www.squeaksource.com/GNUPlot.html > > Cheers, > Levente > > On Sun, 15 Nov 2009, Schwab,Wilhelm K wrote: > >> Dave, >> >> I am slowly gathering ideas on how to write an interface to gnuplot. It will probably be enough to use PipeableOSPRocess class>>command: to grab output from it, but it will be inefficient for producing large numbers of graphs. >> >> Ideally, I would like to run the program and obtain output without creating so much as a named pipe; it appears to be possible to route output to standard out, so there is a potential for it to work. For a single graph, think I see how to make that go. >> >> For large numbers of graphs, one could allow gnuplot to write the >> files; that might even be preferred in many situations, but right now >> I appear to be designing that way because I don't know another way - >> I'm trying to leave Windows behind me :) >> >> Is there a clean way to start gnuplot, leave it running, write to its stdin, read from its stdout almost as if it were a TCP server, and then close it when I'm ready to do so? I tried running CommandShell thinking that might let me demo it, but appears to be stuck back in MVC?? >> >> Bill >> >> >> >> _______________________________________________ >> 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 >

Nov. 15, 2009

Re: [Pharo-project] OSProcess - working on gnuplot

by Schwab,Wilhelm K

It makes explicit reference to win32, so I excluded it on that basis. Are you saying it runs elsewhere? -----Original Message----- From: pharo-project-bounces(a)lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Levente Uzonyi Sent: Sunday, November 15, 2009 3:26 PM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] OSProcess - working on gnuplot Hi, You don't have to reinvent the wheel all the time: http://www.squeaksource.com/GNUPlot.html Cheers, Levente On Sun, 15 Nov 2009, Schwab,Wilhelm K wrote: > Dave, > > I am slowly gathering ideas on how to write an interface to gnuplot. It will probably be enough to use PipeableOSPRocess class>>command: to grab output from it, but it will be inefficient for producing large numbers of graphs. > > Ideally, I would like to run the program and obtain output without creating so much as a named pipe; it appears to be possible to route output to standard out, so there is a potential for it to work. For a single graph, think I see how to make that go. > > For large numbers of graphs, one could allow gnuplot to write the > files; that might even be preferred in many situations, but right now > I appear to be designing that way because I don't know another way - > I'm trying to leave Windows behind me :) > > Is there a clean way to start gnuplot, leave it running, write to its stdin, read from its stdout almost as if it were a TCP server, and then close it when I'm ready to do so? I tried running CommandShell thinking that might let me demo it, but appears to be stuck back in MVC?? > > Bill > > > > _______________________________________________ > 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

Nov. 15, 2009

Re: [Pharo-project] OSProcess - working on gnuplot

by Levente Uzonyi

Hi, You don't have to reinvent the wheel all the time: http://www.squeaksource.com/GNUPlot.html Cheers, Levente On Sun, 15 Nov 2009, Schwab,Wilhelm K wrote: > Dave, > > I am slowly gathering ideas on how to write an interface to gnuplot. It will probably be enough to use PipeableOSPRocess class>>command: to grab output from it, but it will be inefficient for producing large numbers of graphs. > > Ideally, I would like to run the program and obtain output without creating so much as a named pipe; it appears to be possible to route output to standard out, so there is a potential for it to work. For a single graph, think I see how to make that go. > > For large numbers of graphs, one could allow gnuplot to write the files; that might even be preferred in many situations, but right now I appear to be designing that way because I don't know another way - I'm trying to leave Windows behind me :) > > Is there a clean way to start gnuplot, leave it running, write to its stdin, read from its stdout almost as if it were a TCP server, and then close it when I'm ready to do so? I tried running CommandShell thinking that might let me demo it, but appears to be stuck back in MVC?? > > Bill > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Nov. 15, 2009

[Pharo-project] OSProcess - working on gnuplot

by Schwab,Wilhelm K

Dave, I am slowly gathering ideas on how to write an interface to gnuplot. It will probably be enough to use PipeableOSPRocess class>>command: to grab output from it, but it will be inefficient for producing large numbers of graphs. Ideally, I would like to run the program and obtain output without creating so much as a named pipe; it appears to be possible to route output to standard out, so there is a potential for it to work. For a single graph, think I see how to make that go. For large numbers of graphs, one could allow gnuplot to write the files; that might even be preferred in many situations, but right now I appear to be designing that way because I don't know another way - I'm trying to leave Windows behind me :) Is there a clean way to start gnuplot, leave it running, write to its stdin, read from its stdout almost as if it were a TCP server, and then close it when I'm ready to do so? I tried running CommandShell thinking that might let me demo it, but appears to be stuck back in MVC?? Bill

Nov. 15, 2009

Re: [Pharo-project] Trailer format

by Michael Roberts

The Decompiler definitely has bugs. We disabled its tests because it needs quite a lot of work post closure integration. Do you know what is referencing these compiled methods? i.e can they possibly be run. Or is it just a question of clean up? thanks, Mike On Sun, Nov 15, 2009 at 6:30 PM, Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com> wrote: > 2009/11/15 HernÃ¡n Morales Durand <hernan.morales(a)gmail.com>: >> Hi Nicolas, >> Â Thanks for your comments. I've checked all CompiledMethods in a Core image >> >> | col | >> col := OrderedCollection new: 20. >> CompiledMethod allInstancesDo: [: cm | >> Â Â Â Â [ RBParser >> Â Â Â Â Â Â Â Â parseMethod: cm getSource asString >> Â Â Â Â Â Â Â Â onError: [ :msg :pos | Â col add: (msg -> cm) ] ] >> Â Â Â Â on: Error do: [: ex | ] ]. >> col explore >> >> which gave me 9 instances with problems, 8 of them have source pointer >> problems and they are uninstalled, in explorer : >> >> self collect: [: assoc | assoc value getSource asString ] >> > > I recommend trying: > Â Â ScriptLoader new cleanUpMethods. > That should eliminate most copies of CompiledMethod and replace with > an original. > > >> After applying your patch and condensing changes and source files, >> I've tried again >> >> CompiledMethod allInstances first getSource asString >> >> and the Decompiler raises now an exception, is this expected? >> It would be too hard to correct the source pointer numbers of >> uninstalled compiled methods? >> >> Cheers, >> >> HernÃ¡n >> > > Decompiler might have bugs, some since closure refactorings, some > older, but at least we know something is wrong. > I always prefer a Debugger to a false response ! > > Instead of simply erasing the source pointer of un-installed > CompiledMethod during condenseChanges/condenseSources, we could log > their source. > But it was already too late when I discovered this (while chasing > MethodProperties)... > >> 2009/11/15 Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com>: >>> You should check this: >>> Â CompiledMethod allInstances first isInstalled. >>> >>> If false, the answer probably is at >>> http://code.google.com/p/pharo/issues/detail?id=1423 >>> >>> 2009/11/15 HernÃ¡n Morales Durand <hernan.morales(a)gmail.com>: >>>> Hi all, >>>> Â Possibly this is a bug. To reproduce it download a Pharo-Core (I'm >>>> using #11045), update from servers and evaluate: >>>> >>>> CompiledMethod allInstances first getSource asString >>>> >>>> if you see something like the following result, some things could be wrong: >>>> >>>> Â '(firstCollection at: index) equals: Â a. >>>> Â Â Â Â Â Â Â Â self assert: (secondCollection at: index) equals: Â b.] >>>> >>>> Â Â Â Â ' >>>> >>>> because that isn't a message pattern. The compiled method instance is >>>> >>>> (BlockClosure>>#newProcess "a CompiledMethod(1962)") >>>> >>>> and the source string is in PharoV10.sources, but >>>> #fileIndexFromSourcePointer: is answering "2" which is the changes >>>> file and should answer "1"... someone with a better understanding of >>>> sources arithmetic may comment. >>>> Cheers, >>>> >>>> HernÃ¡n >>>> >>>> _______________________________________________ >>>> 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 >

Nov. 15, 2009