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

Re: [Pharo-project] The SmalltalkHub demo is online!

by Sean P. DeNigris

Nicolas Petton wrote: > > You can follow the SmalltalkHub project here: > http://smalltalkhub.com/user/NicolasPetton/SmalltalkHub > > You can report bugs you encounter on the issue tracker there. > I reported 3 bugs as per these instructions, and they seem to have disappeared after the last update - doh! Sean -- View this message in context: http://forum.world.st/The-SmalltalkHub-demo-is-online-tp4073806p4089000.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Nov. 20, 2011

Re: [Pharo-project] Moving a file

by Sean P. DeNigris

fstephany wrote: > > I've tested it on my mac it seems to work fine. Have you tested it on > Linux? > If so, May I update the ConfigurationOfFilesytem to include your fix? > I only tested it on Mac. Feel free to include it as you see fit. Sean -- View this message in context: http://forum.world.st/Moving-a-file-tp3983916p4088990.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Nov. 20, 2011

Re: [Pharo-project] #ifCurtailed:

by StÃ©phane Ducasse

lukas can you open a bug entry? because we should fix this kind of problem. I will discuss it with igor. STef On Nov 20, 2011, at 3:52 PM, Lukas Renggli wrote: > 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] [update 1.4] #14232

by StÃ©phane Ducasse

14232 ----- - Issue 5002: Cleaned Transcripter + add a menu entry. http://code.google.com/p/pharo/issues/detail?id=5002 - Issue 4985: Object>>log: -> Object>>trace: http://code.google.com/p/pharo/issues/detail?id=4985 Stef

Nov. 20, 2011

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

by Max Leske

What does your render code look like? Do you use a form to submit the data? Or JavaScript? Max On 20.11.2011, at 14:52, Edgar J. De Cleene wrote: > 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

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