- Pharo-dev - lists.pharo.org

Re: [Pharo-project] [ENH] About NonInteractive UI manager

by HernÃ¡n Morales Durand

2011/1/27 Igor Stasenko <siguctua(a)gmail.com>: > On 27 January 2011 05:59, HernÃ¡n Morales Durand > <hernan.morales(a)gmail.com> wrote: >> Hi Igor, >> >> It seems to be nice work, just a question: if my image ruins and I >> want to send Cmd + . at some point (let's say some code which triggers >> the keystroke combination in myscript.st), if I understood right that >> would raise an error too... do your changes permit exceptions for >> actually wanted "popup" behaviors like those necessary for reparing? >> Cheers, >> > > what should happen in headless image when you pressing cmd+. ? Or what > you wanna achieve? > Why you need to trigger interrupt by simulating such keystrokes? So I can provide manually highest priority to the interrupt code (sometimes "Cmd + ." from the keyboard doesn't work) > I think there is many ways how to interrupt a program (throw an > exception for instance). > > And since usual pressing cmd-. leads to opening window, then in > non-interactive mode it should raise a ErrorNonInteractive (if not > handled by UI manager before). > I see, what I want to know is if with your changes there is a way to distinguish unwanted popups from wanted for special purposes, or every UI request in all situations is considered an Error. HernÃ¡n

Jan. 27, 2011

[Pharo-project] Issue 3601 in pharo: Recommended Seaside version in Pharo-1.2 outdated

by pharo＠googlecode.com

Status: Accepted Owner: Torsten....(a)astares.de CC: renggli, philippe...(a)gmail.com, marianopeck, stephane...(a)gmail.com, da...(a)teleport.com, marcus.d...(a)gmail.com Labels: Milestone-1.2-DevImage New issue 3601 by Torsten....(a)astares.de: Recommended Seaside version in Pharo-1.2 outdated http://code.google.com/p/pharo/issues/detail?id=3601 Use a prebuilt Pharo 1.2 from the hudson server. When you run "DEVImageWorkspaces openExternalProjectWorkspace" it is suggested to load ConfigurationOfSeaside30 and load ((Smalltalk at: #ConfigurationOfSeaside30) project version: '3.0.0-alpha5.15') load. it comes up with: "Deprecation: The method SmalltalkImage platformName has been deprecated. Use Smalltalk os platformName" Thats not nice for newbees ;) We should also check the other recommended load scripts ... QUESTION: I think a newer version of Seaside like 3.0.3 would help ... Can anyone confirm that Seaside 3.0.3 is OK for Pharo-dev 1.2

Jan. 27, 2011

Re: [Pharo-project] About FileSystem (probably not for 1.3)

by Tudor Girba

Hi Stef, I think your mail can easily be misunderstood to say that Filesystem is crap and that the authors did a bad job. I believe your intention was simply to push people to write more comments and give Filesystem as an example of a fine system that does not have comments :). Filesystem is a nice piece of work and the authors did a good job. I understand that there are no comments, but the documentation found on Lukas' website provides a better overview than most class comments in Pharo: http://www.lukas-renggli.ch/blog/filesystem-1 http://www.lukas-renggli.ch/blog/filesystem-2 So, why not just copy these into the help system? Cheers, Doru On 27 Jan 2011, at 09:59, Igor Stasenko wrote: > On 26 January 2011 21:45, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: >> Hi guys, >> >> I was checking the state of FileSystem and we cannot push it into pharo like that! >> Sad but we should not put code where not a single method has a comment. >> So instead of crying and bashing colin, I started a while ago to understand (great pain) >> and write comments probably wrong, of course. Now I did several iterations but not enough. >> So I will read the blog entries of lukas and try to continue. >> > >> http://www.lukas-renggli.ch/blog/filesystem >> >> Now if you want pharo to evolve, then this is clearly a place to help. We should get better class comments, >> and all the methods with a comment. Else FileSystem will not get integrated. I will veto it. >> > > Is it incomplete , or it just not well documented? I understand that > new things require documentation because people won't know how to use > it, > but what about functionality? > >> Colin lost all the changes he did after ESUG so we will have to live with that (for example >> FSPath not being a class for public consumption and others). >> >> Stef >> > > > > -- > Best regards, > Igor Stasenko AKA sig. > -- www.tudorgirba.com "Yesterday is a fact. Tomorrow is a possibility. Today is a challenge."

Jan. 27, 2011

Re: [Pharo-project] About FileSystem (probably not for 1.3)

by Max Leske

I had to make some changes / additions (only very few though) to Filesystem myself. You can find the changes here: http://www.squeaksource.com/GitFS. A few of the changes have been integrated into the main branch by Lukas I think. I'd be happy to help with Filesystem especially since I've worked with it quite a bit. Unfortunately, I won't have time for another three or four weeks. Anyway, I'll keep following this thread. I'd really like to see a refined version of Filesystem pushed into Pharo. Max On 27.01.2011, at 09:59, Igor Stasenko wrote: > On 26 January 2011 21:45, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: >> Hi guys, >> >> I was checking the state of FileSystem and we cannot push it into pharo like that! >> Sad but we should not put code where not a single method has a comment. >> So instead of crying and bashing colin, I started a while ago to understand (great pain) >> and write comments probably wrong, of course. Now I did several iterations but not enough. >> So I will read the blog entries of lukas and try to continue. >> > >> http://www.lukas-renggli.ch/blog/filesystem >> >> Now if you want pharo to evolve, then this is clearly a place to help. We should get better class comments, >> and all the methods with a comment. Else FileSystem will not get integrated. I will veto it. >> > > Is it incomplete , or it just not well documented? I understand that > new things require documentation because people won't know how to use > it, > but what about functionality? > >> Colin lost all the changes he did after ESUG so we will have to live with that (for example >> FSPath not being a class for public consumption and others). >> >> Stef >> > > > > -- > Best regards, > Igor Stasenko AKA sig. >

Jan. 27, 2011

Re: [Pharo-project] About FileSystem (probably not for 1.3)

by Igor Stasenko

On 26 January 2011 21:45, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > Hi guys, > > I was checking the state of FileSystem and we cannot push it into pharo like that! > Sad but we should not put code where not a single method has a comment. > So instead of crying and bashing colin, I started a while ago to understand (great pain) > and write comments probably wrong, of course. Now I did several iterations but not enough. > So I will read the blog entries of lukas and try to continue. > > http://www.lukas-renggli.ch/blog/filesystem > > Now if you want pharo to evolve, then this is clearly a place to help. We should get better class comments, > and all the methods with a comment. Else FileSystem will not get integrated. I will veto it. > Is it incomplete , or it just not well documented? I understand that new things require documentation because people won't know how to use it, but what about functionality? > Colin lost all the changes he did after ESUG so we will have to live with that (for example > FSPath not being a class for public consumption and others). > > Stef > -- Best regards, Igor Stasenko AKA sig.

Jan. 27, 2011

Re: [Pharo-project] [ENH] About NonInteractive UI manager

by Igor Stasenko

On 27 January 2011 05:59, HernÃ¡n Morales Durand <hernan.morales(a)gmail.com> wrote: > Hi Igor, > > It seems to be nice work, just a question: if my image ruins and I > want to send Cmd + . at some point (let's say some code which triggers > the keystroke combination in myscript.st), if I understood right that > would raise an error too... do your changes permit exceptions for > actually wanted "popup" behaviors like those necessary for reparing? > Cheers, > what should happen in headless image when you pressing cmd+. ? Or what you wanna achieve? Why you need to trigger interrupt by simulating such keystrokes? I think there is many ways how to interrupt a program (throw an exception for instance). And since usual pressing cmd-. leads to opening window, then in non-interactive mode it should raise a ErrorNonInteractive (if not handled by UI manager before). > HernÃ¡n > -- Best regards, Igor Stasenko AKA sig.

Jan. 27, 2011

Re: [Pharo-project] Issue 1057 in pharo: SerialPlugin doesn't handle arbitrary nodes names

by pharo＠googlecode.com

Comment #10 on issue 1057 by serge.st...(a)gmail.com: SerialPlugin doesn't handle arbitrary nodes names http://code.google.com/p/pharo/issues/detail?id=1057 Normally it works, but this is quite difficult to test because you need a serial device connected.

Jan. 27, 2011

Re: [Pharo-project] Issue 1057 in pharo: SerialPlugin doesn't handle arbitrary nodes names

by pharo＠googlecode.com

Comment #9 on issue 1057 by stephane...(a)gmail.com: SerialPlugin doesn't handle arbitrary nodes names http://code.google.com/p/pharo/issues/detail?id=1057 let us make it work. Now I do not know how I can test it Stef

Jan. 27, 2011

[Pharo-project] Issue 3600 in pharo: Enhancement : Refactorings and tests on Balloon-Collections.

by pharo＠googlecode.com

Status: New Owner: ---- New issue 3600 by daliot...(a)gmail.com: Enhancement : Refactorings and tests on Balloon-Collections. http://code.google.com/p/pharo/issues/detail?id=3600 Refactoring is mainly about moval of a set of methods that PointArray and ShortPointArray share its definition. Both classes does not share common superclass, therefore a helper class named "FriendOfPointArray"is introduced. Attachments: Balloon-hjo.73.mcz 83.0 KB

Jan. 27, 2011

Re: [Pharo-project] First commit to Pharoinbox. Need advice.

by HwaJong Oh

Yes, you are right. I was wrong. There is nothing super send. I had error editing my trait codes around "super", so i thought trait can super send. http://screencast.com/t/yyjLLm0S MoveMethod: FriendOfPointArray >> at: index ^(pointArray superAt: index * 2 - 1) @ (pointArray superAt: index * 2) to PointArrayTrait >> at: index ^(super at: index * 2 - 1) @ (super at: index * 2) while editing "pointArray superAt:" to "super at:", the editor made error. Copying the code to native Mac editor, edit them, then copy back to Pharo editor suceeded. -- View this message in context: http://forum.world.st/First-commit-to-Pharoinbox-Need-advice-tp3237535p3241… Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Jan. 27, 2011