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

[Pharo-project] Pharo 1.0 RC1 feedback.

by Michael van der Gulik

Hi. Here's some feedback for Pharo. I've been using Squeak 3.10, but because I want to use the NewCompiler, I'm going to move development of SecureSqueak to Pharo. I go to http://pharo.org/. Woops. He he. I find my way to the Pharo home page. Getting Pharo up and running could be a lot easier; I'm using Ubuntu Linux, and I got it up and running quickly because I've a fairly experienced Squeak developer. If I was less familiar with image files and VMs, I would be lost and probably give up. I recommend making the release for each platform one large .zip file containing the images, sources and VM. This will reduce confusion, and if you put the executable in the root directory of the zip file, most people will easily be able to work it out. The VM has a README file - good, but it assumes a lot of experience from the user. Again, if I was not a programmer, I'd be lost. The image zip file has a lot of extra stuff in it (fonts?) and no README file. I start up the VM - I get a white window, the Pharo logo and that's it. I'm able to just jump in and start using this because I'm familiar with Squeak, but if I was a new user to Pharo, this would be rather intimidating. I recommend having a workspace with nicely formatted fonts saying "Welcome to Pharo, go read Pharo by Example". The project menu / desktop menu / whatever menu that comes up is badly formatted. The last four items ("Save", "Save As", "Save and quit" and "Quit") have icons and more spacing between them than the items above them. The vertical size of each menu item should be constant. Menu entries still use the small font that Squeak uses, making them hard to click on (for fumble-fingers like me). The menu structure is a vast improvement over Squeak! I open up a browser. It looks nice, but I can't understand the red/yellow/green buttons in the top left corner. What are they meant to be? The tooltips help, but I find it odd to use coloured buttons. I use a slowish Celeron-based computer (if you could call 1.6 BILLION operations per second slow!). The whole environment feels a bit sluggish. I spend some time in the preferences and manage to make it a bit more reactive by disabling some eye-candy. I come across a dialog: "Changes have not been saved, bla bla". The dialog is odd; it needs the attention of a graphic designer. It has a text entry box in it for no reason? I make a class and begin typing in its comment; I get continuous annoying drop-down lists which aren't relevant for documentation. The text is badly lagged; I count 5 seconds before what I type appears on the screen. I get a dialog asking me for my full name (nice! Much better than initials). The text in the dialog is badly aligned and not word-wrapped correctly. Text should be left-aligned or fully justified, unless it's Right-to-Left text. Also, use real right-arrows! Pharo supports Unicode! The dialog did not appear until after I had already made three classes - surely it should ask for my name as soon as I start making any source changes to the system? I type in some code. The auto-drop-down thing keeps guessing what I'm typing, even when I'm typing comments. It is starting to annoy me. Some more time disabling preferences seems to fix this. I think that's enough for now. The new user experience needs to be worked on, in particular by making the downloading and setting up more intuitive, and by having a welcome message when the image is started. Perhaps the auto-completion stuff works better on faster computers. The environment is a lot better after disabling it. Gulik. -- http://gulik.pbwiki.com/

Nov. 17, 2009

[Pharo-project] Connectors

by Andrew P. Black

I was recommending to a student that they look at Ned Konz's Connectors package to help with a drawing project. I eventually tracked downa fairly recent version in a SqueakSOurce project or mine ... but it's very Squeak dependent. Specifically, it has dependencies on: ObjectPropertiesMorph PartsBin Vocabulary PhraseTileMorph TileMorph SymbolListType QHsmMorphicEventHandler ObjectsTool BookMorph GraphicalDictionaryMenu QHsmMorph GenericPropertiesMorph Player TwoWayScrollPane A lot of these are incidental, e,g, the dependency on BookMorph is there because the Connectors package Extends BookMorph with a method that answers false to the question "isConnectable"? Still, the code can't be loaded as-is. And some of the dependencies are clearly deeper. Does anyone know if there is version of the Connectors package for Pharo? Ned, if you are listening, would you be willing to put this under the MIT license so that someone else could port it? Andrew

Nov. 17, 2009

Re: [Pharo-project] simulating morphic events

by Tudor Girba

Thanks Gary, Indeed, this raises the local menu. So maybe the morph I am testing has some problems. But, if we are at it, I have a question regarding the mouse buttons. I thought that "which: 4" will raise a left click event (which is what I would like to target), but by running your code I get a menu popping out. What am I missing? Cheers, Doru On 16 Nov 2009, at 14:57, Gary Chambers wrote: > Your original code seems ok. > > Try the following via inspecting the PluggableTextMorph of a > Workspace, for > example (changed to do mouse down...) > > | mouseDown morph | > morph := self scroller submorphs first. > mouseDown := MouseButtonEvent basicNew > setType: #mouseDown > position: (morph bounds origin + (1@1)) > which: 4 > buttons: 7 > hand: (HandMorph new mouseFocus: morph; yourself) > stamp: Time millisecondClockValue. > morph handleMouseDown: mouseDown. > > Regards, Gary > > ----- Original Message ----- > From: "Tudor Girba" <tudor.girba(a)gmail.com> > To: <Pharo-project(a)lists.gforge.inria.fr> > Sent: Monday, November 16, 2009 1:21 PM > Subject: Re: [Pharo-project] simulating morphic events > > >> Interesting, but I am also looking for a mouse event. Anyone has >> other >> examples? >> >> Doru >> >> >> On 16 Nov 2009, at 13:57, Lukas Renggli wrote: >> >>>> At this moment it looks like the problem is that the eventHandler >>>> in >>>> the morph is nil. Can anyone point me into the right direction? >>> >>> Have a look at OBKeyBindingsTest>>modifier:keycode: in OB-Morphic- >>> Tests. >>> >>> Lukas >>> >>> -- >>> Lukas Renggli >>> http://www.lukas-renggli.ch >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> Pharo-project(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> -- >> www.tudorgirba.com >> >> "Some battles are better lost than fought." >> >> >> >> >> _______________________________________________ >> 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 -- www.tudorgirba.com "Problem solving efficiency grows with the abstractness level of problem understanding."

Nov. 17, 2009

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

by Schwab,Wilhelm K

Dave, That works - thanks! Knowing how much data to read will be a problem. My assumption was that I would have an image reader pull from the stream, taking the hint when it finds a complete image. Sadly, they do bad things to the stream, and I am not sure how to correct that. Bill -----Original Message----- From: pharo-project-bounces(a)lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Schwab,Wilhelm K Sent: Monday, November 16, 2009 7:59 PM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] OSProcess - working on gnuplot Dave, Thanks for the examples, and the reminder about Squeak/Pharo differences. I'll see what I can figure out. You might have already explained why one of my tests failed. I do want the option to keep gnuplot running. It might turn out that the cases in which that matters are precisely the ones in which gnuplot should be allowed to write the output files, but I'd rather not start out with that approach. Re the problems in Pharo, one perhaps completely worthless point: I ran some of the unit tests with Pharo launched from a terminal, and got Ipv6 related messages. It made no sense to me, but (I think) that code is whacked, and if there is any relationship, it *might* be the problem. Usual caveats about this being a potential red herring apply. Bill -----Original Message----- From: pharo-project-bounces(a)lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of David T. Lewis Sent: Monday, November 16, 2009 7:40 PM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] OSProcess - working on gnuplot On Mon, Nov 16, 2009 at 05:36:08PM -0500, Schwab,Wilhelm K wrote: > Dave, > > ProcessWrapper looks like a win32-only project to me, and Sig's gnuplot package > appears to use OSProcess for unix. Please let me know if I am missing something. > > It is true that OSProcess' unit tests cause Pharo to experience an > ugly death, but a lot seems to work. I am having some success with > code such as > > gp := PipeableOSProcess command:'gnuplot'. > gp > exec:'set output ""'; > exec:'set terminal png'; > exec:'plot sin(x)'. > > but I cannot get any output without shutting down the process. Are > any of the problems you describe relevant to that, or am I asking too > much, or perhaps just going about this incorrectly? > > Bill You may be hanging up trying to read a blocking stream from the gnuplot program. Try using #setNonBlockingOutput to prevent this. The following three examples all work for me (but I ran this on a Squeak image). Your original example, but with #setNonBlockingOutput: gp := PipeableOSProcess command:'gnuplot'. gp setNonBlockingOutput. gp exec:'set output ""'; exec:'set terminal png'; exec:'plot sin(x)'. gp close. "close stdin to gnuplot, like <ctl>D" gp upToEndOfFile inspect. "stdout, the graphics output" gp errorUpToEndOfFile inspect. "stderr output if any" If you want to keep gnuplot running in background, you will have to read data as it becomes available using #upToEnd rather than #upToEndOfFile: gp := PipeableOSProcess command:'gnuplot'. gp setNonBlockingOutput. gp exec:'set output ""'; exec:'set terminal png'; exec:'plot sin(x)'. (Delay forMilliseconds: 1000) wait. "allow gnuplot to send data" gp upToEnd inspect. "all available stdout data" gp errorUpToEnd inspect. "all available stderr data" gp close. You can cause the background gnuplot interpreter to exit by sending it the "exit" command, or by doing "gp close" as in the examples above: gp := PipeableOSProcess command:'gnuplot'. gp setNonBlockingOutput. gp exec:'set output ""'; exec:'set terminal png'; exec:'plot sin(x)'; exec: 'exit'. "exit gnuplot, similar effect to gp close" gp upToEndOfFile inspect. gp errorUpToEndOfFile inspect. If the above examples do not work for you, it is very likely due to the current inconsistencies between OSProcess and Pharo, for which I do not yet have a solution (I would welcome any tips here, I tried again last night to figure out what's wrong and gave up in frustration :-/ ). HTH, Dave _______________________________________________ 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. 17, 2009

[Pharo-project] Speech Klatt package on SqueakSource (was: Package name "SharedPool-Speech", "SharedPool-FFI", etc ?)

by David T. Lewis

On Sun, Nov 15, 2009 at 10:48:49AM -0500, David T. Lewis wrote: > There is currently a package dependency for VMMaker that requires the > entire Speech package (for KlattSynthesizerPlugin). This can be resolved > through a minor refactoring of Speech, mainly to move the shared pool > class KlattResonatorIndices into a separate package, e.g. "SharedPool-Speech". > > Are there any objections to adopting the package name "SharedPool-Speech" > for this? By implication, we might also have "SharedPool-FFI" and so forth. > > If no objections, I'll make a SqueakSource project for Speech, starting > with the Speech-md.9.mcz from Squeak 3.9a, and updating it as described. > With that in place, VMMaker will be loadable with just the shared pool > prerequisite, rather than the entire Speech package. I opened a SqueakSource project for the Speech Klatt package: MCHttpRepository location: 'http://www.squeaksource.com/Speech' user: '' password: '' This is the speech package that is present in Squeak images up to and including Squeak 3.9. It is packaged here to make it available as a MC package, and allow the VMMaker package to access the Speech shared pool for use in KlattSynthesizerPlugin. The initial version in the repository is the Squeak 3.9a version that I copied from http://source.squeak.org/39a. I have updated it to recategorize the shared pool and other references needed for VMMaker. I picked a couple of reputable soundings names out of a hat, thereby nominating Marcus Denker and Andreas Raab as "developers". If anyone has any sense of ownership over the Speech package, please speak up and I'll turn the package over to you. The purpose of this change is to enable "VMMaker updateFromServer" to first load the Klatt shared pools, then load VMMaker and various related plugins. A similar update will be needed for FFI shared pools. Dave

Nov. 17, 2009

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

by Schwab,Wilhelm K

Dave, Thanks for the examples, and the reminder about Squeak/Pharo differences. I'll see what I can figure out. You might have already explained why one of my tests failed. I do want the option to keep gnuplot running. It might turn out that the cases in which that matters are precisely the ones in which gnuplot should be allowed to write the output files, but I'd rather not start out with that approach. Re the problems in Pharo, one perhaps completely worthless point: I ran some of the unit tests with Pharo launched from a terminal, and got Ipv6 related messages. It made no sense to me, but (I think) that code is whacked, and if there is any relationship, it *might* be the problem. Usual caveats about this being a potential red herring apply. Bill -----Original Message----- From: pharo-project-bounces(a)lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of David T. Lewis Sent: Monday, November 16, 2009 7:40 PM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] OSProcess - working on gnuplot On Mon, Nov 16, 2009 at 05:36:08PM -0500, Schwab,Wilhelm K wrote: > Dave, > > ProcessWrapper looks like a win32-only project to me, and Sig's gnuplot package > appears to use OSProcess for unix. Please let me know if I am missing something. > > It is true that OSProcess' unit tests cause Pharo to experience an > ugly death, but a lot seems to work. I am having some success with > code such as > > gp := PipeableOSProcess command:'gnuplot'. > gp > exec:'set output ""'; > exec:'set terminal png'; > exec:'plot sin(x)'. > > but I cannot get any output without shutting down the process. Are > any of the problems you describe relevant to that, or am I asking too > much, or perhaps just going about this incorrectly? > > Bill You may be hanging up trying to read a blocking stream from the gnuplot program. Try using #setNonBlockingOutput to prevent this. The following three examples all work for me (but I ran this on a Squeak image). Your original example, but with #setNonBlockingOutput: gp := PipeableOSProcess command:'gnuplot'. gp setNonBlockingOutput. gp exec:'set output ""'; exec:'set terminal png'; exec:'plot sin(x)'. gp close. "close stdin to gnuplot, like <ctl>D" gp upToEndOfFile inspect. "stdout, the graphics output" gp errorUpToEndOfFile inspect. "stderr output if any" If you want to keep gnuplot running in background, you will have to read data as it becomes available using #upToEnd rather than #upToEndOfFile: gp := PipeableOSProcess command:'gnuplot'. gp setNonBlockingOutput. gp exec:'set output ""'; exec:'set terminal png'; exec:'plot sin(x)'. (Delay forMilliseconds: 1000) wait. "allow gnuplot to send data" gp upToEnd inspect. "all available stdout data" gp errorUpToEnd inspect. "all available stderr data" gp close. You can cause the background gnuplot interpreter to exit by sending it the "exit" command, or by doing "gp close" as in the examples above: gp := PipeableOSProcess command:'gnuplot'. gp setNonBlockingOutput. gp exec:'set output ""'; exec:'set terminal png'; exec:'plot sin(x)'; exec: 'exit'. "exit gnuplot, similar effect to gp close" gp upToEndOfFile inspect. gp errorUpToEndOfFile inspect. If the above examples do not work for you, it is very likely due to the current inconsistencies between OSProcess and Pharo, for which I do not yet have a solution (I would welcome any tips here, I tried again last night to figure out what's wrong and gave up in frustration :-/ ). HTH, Dave _______________________________________________ Pharo-project mailing list Pharo-project(a)lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Nov. 17, 2009

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

by David T. Lewis

On Mon, Nov 16, 2009 at 05:36:08PM -0500, Schwab,Wilhelm K wrote: > Dave, > > ProcessWrapper looks like a win32-only project to me, and Sig's gnuplot package > appears to use OSProcess for unix. Please let me know if I am missing something. > > It is true that OSProcess' unit tests cause Pharo to experience an ugly death, > but a lot seems to work. I am having some success with code such as > > gp := PipeableOSProcess command:'gnuplot'. > gp > exec:'set output ""'; > exec:'set terminal png'; > exec:'plot sin(x)'. > > but I cannot get any output without shutting down the process. Are any of the > problems you describe relevant to that, or am I asking too much, or perhaps just > going about this incorrectly? > > Bill You may be hanging up trying to read a blocking stream from the gnuplot program. Try using #setNonBlockingOutput to prevent this. The following three examples all work for me (but I ran this on a Squeak image). Your original example, but with #setNonBlockingOutput: gp := PipeableOSProcess command:'gnuplot'. gp setNonBlockingOutput. gp exec:'set output ""'; exec:'set terminal png'; exec:'plot sin(x)'. gp close. "close stdin to gnuplot, like <ctl>D" gp upToEndOfFile inspect. "stdout, the graphics output" gp errorUpToEndOfFile inspect. "stderr output if any" If you want to keep gnuplot running in background, you will have to read data as it becomes available using #upToEnd rather than #upToEndOfFile: gp := PipeableOSProcess command:'gnuplot'. gp setNonBlockingOutput. gp exec:'set output ""'; exec:'set terminal png'; exec:'plot sin(x)'. (Delay forMilliseconds: 1000) wait. "allow gnuplot to send data" gp upToEnd inspect. "all available stdout data" gp errorUpToEnd inspect. "all available stderr data" gp close. You can cause the background gnuplot interpreter to exit by sending it the "exit" command, or by doing "gp close" as in the examples above: gp := PipeableOSProcess command:'gnuplot'. gp setNonBlockingOutput. gp exec:'set output ""'; exec:'set terminal png'; exec:'plot sin(x)'; exec: 'exit'. "exit gnuplot, similar effect to gp close" gp upToEndOfFile inspect. gp errorUpToEndOfFile inspect. If the above examples do not work for you, it is very likely due to the current inconsistencies between OSProcess and Pharo, for which I do not yet have a solution (I would welcome any tips here, I tried again last night to figure out what's wrong and gave up in frustration :-/ ). HTH, Dave

Nov. 17, 2009

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

by Levente Uzonyi

Hi! On Mon, 16 Nov 2009, Schwab,Wilhelm K wrote: > Dave, > > ProcessWrapper looks like a win32-only project to me, and Sig's gnuplot package appears to use OSProcess for unix. Please let me know if I am missing something. > Though I'm not Dave, I can tell you that ProcessWrapper is for win32 only. It exists because PipeableOSProcess doesn't work under win32. > It is true that OSProcess' unit tests cause Pharo to experience an ugly death, but a lot seems to work. I am having some success with code such as > > gp := PipeableOSProcess command:'gnuplot'. > gp > exec:'set output ""'; > exec:'set terminal png'; > exec:'plot sin(x)'. > You still don't have to reinvent the wheel. If you don't want to use Igor's project - which you should IMO - you can still check out his code and see how he uses PipeableOSProcess to do the thing you want to do. Levente

Nov. 16, 2009

Re: [Pharo-project] Spreading the word about Pharo

by csrabak＠bol.com.br

Sadly this happens more often with Smalltalk related pages. . . Em 16/11/2009 17:50, Oscar Nierstrasz <oscar(a)iam.unibe.ch> escreveu: LOL! That web 1.0 page has not been modified since Oct 1999. - on On Nov 12, 2009, at 19:31, StÃ©phane Ducasse wrote: > yes > > On Nov 12, 2009, at 7:27 PM, csrabak(a)bol.com.br wrote: > >> Do you think it is time to ask maintainers of pages about Smalltalk, like http://www.engin.umd.umich.edu/CIS/course.des/cis400/smalltalk/smalltalk.ht… to include Pharo be it as an entry or at least a link? >> >> -- >> Cesar Rabak >> >> _______________________________________________ >> 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. 16, 2009

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

by Schwab,Wilhelm K

Dave, ProcessWrapper looks like a win32-only project to me, and Sig's gnuplot package appears to use OSProcess for unix. Please let me know if I am missing something. It is true that OSProcess' unit tests cause Pharo to experience an ugly death, but a lot seems to work. I am having some success with code such as gp := PipeableOSProcess command:'gnuplot'. gp exec:'set output ""'; exec:'set terminal png'; exec:'plot sin(x)'. but I cannot get any output without shutting down the process. Are any of the problems you describe relevant to that, or am I asking too much, or perhaps just going about this incorrectly? Bill -----Original Message----- From: pharo-project-bounces(a)lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of David T. Lewis Sent: Sunday, November 15, 2009 6:57 PM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] OSProcess - working on gnuplot 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 _______________________________________________ Pharo-project mailing list Pharo-project(a)lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Nov. 16, 2009