- Pharo-dev - lists.pharo.org

Re: [Pharo-project] #ifCurtailed:

by Lukas Renggli

http://code.google.com/p/pharo/issues/detail?id=5003 On 20 November 2011 17:42, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > 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 >> > > > -- Lukas Renggli www.lukas-renggli.ch

Nov. 20, 2011

Re: [Pharo-project] Zinc Post requests

by Lukas Renggli

> Given the current implementation: > > requestBodyFor: aZincRequest > ^ aZincRequest entity > > you get a ZnEntity subclass back, not a String which WARequest>>#setBody: seems to expect. > > As you certainly known, many different kinds of things could be uploaded in a POST, depending on the mime type, some of the important ones are in the subclasses of ZnEntity. I don't think a general conversion to String is possible, unless the idea is that that String should contain the byte representation of what got posted. Seaside expects a string containing the byte representation of what got posted. > The #contents method does try to return something useful (sometimes higher level Smalltalk objects). > > BTW, what is the difference between #requestBodyFor: and #requestFieldsFor: ? Have a look at the Kom adaptor: requestFieldsFor: aNativeRequest | fields | fields := WARequestFields new. aNativeRequest isPostRequest ifTrue: [ self postFieldsOf: aNativeRequest into: fields ]. ^ fields requestBodyFor: aNativeRequest ^ aNativeRequest rawRequestContents Lukas

Nov. 20, 2011

Re: [Pharo-project] Zinc Post requests

by Sven Van Caekenberghe

Lukas, On 20 Nov 2011, at 18:45, Lukas Renggli wrote: > Hi Sven, > > Does #requestBodyFor: in the Zinc server adaptor for Seaside work? > > Instead of a String I keep on getting strange things back :-) Given the current implementation: requestBodyFor: aZincRequest ^ aZincRequest entity you get a ZnEntity subclass back, not a String which WARequest>>#setBody: seems to expect. As you certainly known, many different kinds of things could be uploaded in a POST, depending on the mime type, some of the important ones are in the subclasses of ZnEntity. I don't think a general conversion to String is possible, unless the idea is that that String should contain the byte representation of what got posted. The #contents method does try to return something useful (sometimes higher level Smalltalk objects). BTW, what is the difference between #requestBodyFor: and #requestFieldsFor: ? Summary: if you known what should be passed in the different cases, I might be able to tell you how to get to it. Sven PS: which Seaside tests touch this ?

Nov. 20, 2011

[Pharo-project] Zinc Post requests

by Lukas Renggli

Hi Sven, Does #requestBodyFor: in the Zinc server adaptor for Seaside work? Instead of a String I keep on getting strange things back :-) Lukas -- Lukas Renggli www.lukas-renggli.ch

Nov. 20, 2011

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

by Tudor Girba

Excellent! Doru On 20 Nov 2011, at 14:53, StÃ©phane Ducasse wrote: > > 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 >> > > -- www.tudorgirba.com "It's not how it is, it is how we see it."

Nov. 20, 2011

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