- Pharo-dev - lists.pharo.org

Re: [Pharo-project] #ifCurtailed:

by Lukas Renggli

They both behave the same way in that regard. The argument block is always executed in the owning process, unless an outside process is terminating the process. In this case it is the outside process that unwinds the stack and evaluates the unwind blocks. A long standing bug in my opinion. Lukas On 20 November 2011 15:19, Philippe Marschall <kustos(a)gmx.net> wrote: > Hi > > Am I right that the argument to #ifCurtailed: is run in a different process > (like #ensure: in an exception case)? > > Cheers > Philippe > > > -- Lukas Renggli www.lukas-renggli.ch

Nov. 20, 2011

[Pharo-project] #ifCurtailed:

by Philippe Marschall

Hi Am I right that the argument to #ifCurtailed: is run in a different process (like #ensure: in an exception case)? Cheers Philippe

Nov. 20, 2011

Re: [Pharo-project] [squeak-dev] OmniBrowser and ToolBuilder

by StÃ©phane Ducasse

On Nov 20, 2011, at 1:11 PM, Lukas Renggli wrote: > FYI: The mail of Colin Putney to the Squeak mailing list regarding the > future of OmniBrowser. > > For Pharo there are also some changes upcoming: > > The latest GUI takes better advantage of the standard Polymorph > widgets and brings resizable column and faster updates. cool! Stef > Lukas > > ---------- Forwarded message ---------- > From: Colin Putney <colin(a)wiresong.com> > Date: 20 November 2011 09:56 > Subject: [squeak-dev] OmniBrowser and ToolBuilder > To: Squeak-Dev <squeak-dev(a)lists.squeakfoundation.org> > > > Hi folks, > > Lately I've been working with Lukas Renggli on a new version of > OmniBrowser. The main focus has been on cleaning up and isolating > platform dependencies so that we can have a single version that works > well on both Squeak and Pharo, while fitting comfortably into each > platform's idioms. That part of it has been quite well. > > For proper integration with Squeak, I've been trying to get OB > building its interface using ToolBuilder. It *mostly* works, but there > are some areas where ToolBuilder doesn't provide the functionality > that OmniBrowser needs. I had planned to extend ToolBuilder a bit with > the additional functionality that OB needs, but that turns out to be > more work than I anticipated, and I wasn't able to get it done before > the 4.3 feature freeze. So, given the constraint of working with the > Squeak 4.3 feature set, I'm not quite sure how to proceed. > > Here are some of the options: > > 1) Abandon ToolBuilder and just deal with Morphic directly. This is > what OB has historically done, and I'd just be updating the old > Morphic code to fit better into modern Squeak conventions. There's no > longer any need to have this code work on Pharo, since Lukas is now > using a separate Polymorph-specific widget package on Pharo. > > 2) Use ToolBuilder where possible, but customize its output. This > misses the point of ToolBuilder, since it means OB won't be able to > work with MVC, but at least it reduces the chance that OB will get > left behind if someone adds a feature to ToolBuilder. It is a bit of > "worst of both worlds" situation. > > 3) Use ToolBuilder, and just accept that not all the features of OB > will be available until they get added to ToolBuilder. I'm not sure > how much graceful degradation I can acheive, but it might not be too > bad, and it'll give us (me) motivation to improve ToolBuilder for > Squeak 4.4. > > 4) Have the OB installation process patch the base image to add the > needed functionality. That would be the cleanest in terms of the OB > code, but has the potential to break other packages that users might > want to load. > > I'd really like to make this next release a solid toolset for Squeak, > and fix a lot of the little annoyances that cause Squeakers to avoid > it. Lukas' refactoring stuff is really excellent, better than the > VisualWorks refactoring browser IMHO, and I want to make it palatable > to more people in the Squeak community. I'm leaning towards option #1, > because I suspect it's the mostly likely to achieve that, but I > thought I'd put it out there and ask the community for advice. So, how > important is ToolBuilder? What options am I missing? > > > Cheers, > > Colin > > > > > -- > Lukas Renggli > www.lukas-renggli.ch >

Nov. 20, 2011

[Pharo-project] [Q] help with requesting a html page

by Edgar J. De Cleene

Friends: I have this code login | fields aPassword userName logged | fields := self request propertyAt: #postFields ifAbsent: []. fields ifNotNil:[ userName := (fields at: 'username'). aPassword := (fields at: 'password'). logged := HVNaughtieUsers new verifyPassword: aPassword forUser: userName ]. self halt. When I hit in the web browser , fields become nil. But if into Squeak I restart the method and do step by step, fields become populated with the right values. How I should do for the right values and avoid nil ? Thanks in advance Edgar

Nov. 20, 2011

[Pharo-project] Fwd: [squeak-dev] OmniBrowser and ToolBuilder

by Lukas Renggli

FYI: The mail of Colin Putney to the Squeak mailing list regarding the future of OmniBrowser. For Pharo there are also some changes upcoming: The latest GUI takes better advantage of the standard Polymorph widgets and brings resizable column and faster updates. Lukas ---------- Forwarded message ---------- From: Colin Putney <colin(a)wiresong.com> Date: 20 November 2011 09:56 Subject: [squeak-dev] OmniBrowser and ToolBuilder To: Squeak-Dev <squeak-dev(a)lists.squeakfoundation.org> Hi folks, Lately I've been working with Lukas Renggli on a new version of OmniBrowser. The main focus has been on cleaning up and isolating platform dependencies so that we can have a single version that works well on both Squeak and Pharo, while fitting comfortably into each platform's idioms. That part of it has been quite well. For proper integration with Squeak, I've been trying to get OB building its interface using ToolBuilder. It *mostly* works, but there are some areas where ToolBuilder doesn't provide the functionality that OmniBrowser needs. I had planned to extend ToolBuilder a bit with the additional functionality that OB needs, but that turns out to be more work than I anticipated, and I wasn't able to get it done before the 4.3 feature freeze. So, given the constraint of working with the Squeak 4.3 feature set, I'm not quite sure how to proceed. Here are some of the options: 1) Abandon ToolBuilder and just deal with Morphic directly. This is what OB has historically done, and I'd just be updating the old Morphic code to fit better into modern Squeak conventions. There's no longer any need to have this code work on Pharo, since Lukas is now using a separate Polymorph-specific widget package on Pharo. 2) Use ToolBuilder where possible, but customize its output. This misses the point of ToolBuilder, since it means OB won't be able to work with MVC, but at least it reduces the chance that OB will get left behind if someone adds a feature to ToolBuilder. It is a bit of "worst of both worlds" situation. 3) Use ToolBuilder, and just accept that not all the features of OB will be available until they get added to ToolBuilder. I'm not sure how much graceful degradation I can acheive, but it might not be too bad, and it'll give us (me) motivation to improve ToolBuilder for Squeak 4.4. 4) Have the OB installation process patch the base image to add the needed functionality. That would be the cleanest in terms of the OB code, but has the potential to break other packages that users might want to load. I'd really like to make this next release a solid toolset for Squeak, and fix a lot of the little annoyances that cause Squeakers to avoid it. Lukas' refactoring stuff is really excellent, better than the VisualWorks refactoring browser IMHO, and I want to make it palatable to more people in the Squeak community. I'm leaning towards option #1, because I suspect it's the mostly likely to achieve that, but I thought I'd put it out there and ask the community for advice. So, how important is ToolBuilder? What options am I missing? Cheers, Colin -- Lukas Renggli www.lukas-renggli.ch

Nov. 20, 2011

Re: [Pharo-project] Startup Preferences

by Schwab,Wilhelm K

Ben, Whatever you, Stef and others find helpful is fine by me. My guess would be that having one extra settings file to copy would be a minor hassle compared to providing sources (or symlink to same), a vm, and probably a shell script to make the thing go. Put another way, what do you do to make using "random" images so easy that copying a file is a big pain? I'm missing out on something :) Bill ________________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] on behalf of Benjamin [benjamin.vanryseghem.pharo(a)gmail.com] Sent: Saturday, November 19, 2011 1:20 PM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] Startup Preferences The problem is when you download 4-5 images per day, each in a different folder :) Ben On Nov 19, 2011, at 6:02 PM, Schwab,Wilhelm K wrote: > FWIW, I thought there is a way to put a preferences file in the image directory to achieve this?? I read that somewhere, I just never tried it. I typically use an image for a long time (still using 1.1.1 at the moment - it WORKS, ok<g>), so the prompts are perhaps less annoying to me than they would be to frequent image builders. > > Bill > > > ________________________________________ > From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] on behalf of StÃ©phane Ducasse [stephane.ducasse(a)inria.fr] > Sent: Saturday, November 19, 2011 11:01 AM > To: Pharo-project(a)lists.gforge.inria.fr > Subject: Re: [Pharo-project] Startup Preferences > > thanks ben > > I will wait for feedback before pushing that in the system but indeed, I'm tired to always type my password in all the images. > For script loader I did a hack but it would be better to have something nicer like what you did. > > Stef > > On Nov 19, 2011, at 2:13 PM, Benjamin wrote: > >> Hi guys, >> >> I did a little project which allow you to save a st script on your HDD in a preference folder (~/.pharo#{version} for unix based machine, not yet defined for windows) and run it each time an image is open. >> You can also decide for each item if you want it to be run each time or only once. >> >> I use it to set my author name, change the fonts, set some settings, add my password in some repo etc >> >> The code is here: >> >> Gofer new >> squeaksource: 'StartupPreferences'; >> package: 'StartupPreferences'; >> load. >> >> You can have a look at StartupLoader class>>#example and StartupLoader class>>#example2 >> >> >> If you have comments or ideas (by example, what is the path for preferences on windows ? ^^), you're welcome :) >> >> >> Ben > > >

Nov. 19, 2011

Re: [Pharo-project] New SmalltalkHub preview online

by nicolas petton

Hi, This is coming soon :) Cheers, Nico 2011/11/19 Herby VojÄÃk <herby(a)mailbox.sk> > In github when I click on the commit I see a diff. > > How can I see a difference that the commit brought up here (online, without > downloading)? > > Herby > > -- > View this message in context: > http://forum.world.st/The-SmalltalkHub-demo-is-online-tp4073806p4087229.html > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. > >

Nov. 19, 2011

Re: [Pharo-project] New SmalltalkHub preview online

by Herby VojÄÃk

In github when I click on the commit I see a diff. How can I see a difference that the commit brought up here (online, without downloading)? Herby -- View this message in context: http://forum.world.st/The-SmalltalkHub-demo-is-online-tp4073806p4087229.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Nov. 19, 2011

Re: [Pharo-project] Moving a file

by StÃ©phane Ducasse

Good. Did you write some tests? On Nov 3, 2011, at 4:09 PM, Sean P. DeNigris wrote: > I wrote a partial fix (move and rename now work for disk filesystems on my > mac) and uploaded it to sqs/fs. Here's the package comment for > FS-Core-SeanDeNigris.16 (the other affected package is > FS-Disk-SeanDeNigris.4): > > >> * Partially fixed FSReference>>renameAs:. It now works for disk >> filesystems. >> * added FSReference>>moveTo: >> >> WARNING: this introduces a slight change into the API. #renameAs: now is a >> shortcut to simply change a file's name while staying in the same parent >> directory. As such, it now takes a string (used to take a path or string). >> What renameAs: used to do (move to an arbitrary other location) is now >> done by #moveTo: which takes a target reference. >> > > I tested by hand, but at minimum, it's less broken than before :) It doesn't > touch any other parts of FS, so shouldn't have broken anything else. > > Sean > > -- > View this message in context: http://forum.world.st/Moving-a-file-tp3983916p3986244.html > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. >

Nov. 19, 2011

Re: [Pharo-project] Startup Preferences

by StÃ©phane Ducasse

I always build everything from a new image. It is my process. and I try to throw away images as fast as I can (but not fast enoughâ¦ when I see all the images I have around :). On Nov 19, 2011, at 6:02 PM, Schwab,Wilhelm K wrote: > FWIW, I thought there is a way to put a preferences file in the image directory to achieve this?? I read that somewhere, I just never tried it. I typically use an image for a long time (still using 1.1.1 at the moment - it WORKS, ok<g>), so the prompts are perhaps less annoying to me than they would be to frequent image builders. > > Bill > > > ________________________________________ > From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] on behalf of StÃ©phane Ducasse [stephane.ducasse(a)inria.fr] > Sent: Saturday, November 19, 2011 11:01 AM > To: Pharo-project(a)lists.gforge.inria.fr > Subject: Re: [Pharo-project] Startup Preferences > > thanks ben > > I will wait for feedback before pushing that in the system but indeed, I'm tired to always type my password in all the images. > For script loader I did a hack but it would be better to have something nicer like what you did. > > Stef > > On Nov 19, 2011, at 2:13 PM, Benjamin wrote: > >> Hi guys, >> >> I did a little project which allow you to save a st script on your HDD in a preference folder (~/.pharo#{version} for unix based machine, not yet defined for windows) and run it each time an image is open. >> You can also decide for each item if you want it to be run each time or only once. >> >> I use it to set my author name, change the fonts, set some settings, add my password in some repo etc >> >> The code is here: >> >> Gofer new >> squeaksource: 'StartupPreferences'; >> package: 'StartupPreferences'; >> load. >> >> You can have a look at StartupLoader class>>#example and StartupLoader class>>#example2 >> >> >> If you have comments or ideas (by example, what is the path for preferences on windows ? ^^), you're welcome :) >> >> >> Ben > > >

Nov. 19, 2011