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

Re: [Pharo-project] Zinc Post requests

by Lukas Renggli

On 20 November 2011 22:07, Sven Van Caekenberghe <sven(a)beta9.be> wrote: > Well I guess this would then do the trick: > > requestBodyFor: aZincRequest > Â Â Â Â ^ String streamContents: [ :stream | > Â Â Â Â Â Â Â Â aZincRequest entity writeOn: (ZnBivalentWriteStream on: stream) ] > > but it hurts: at this point Zn has already parsed/interpreted the entity from bytes and the above code reencodes it again to bytes. That is why I asked if this is needed in all cases, I guess the body will not be used later on if it is either application/x-www-form-urlencoded or multipart/form-data (since these are handled in #requestFieldsFor:). If that is true, a faster fallback based on #contents should be possible (but with some ugly tests). Also a guard testing for entity #isEmpty and non-POST requests will probably be more efficient. > > Should I try to write a version and commit it ? Yes please, because the current Zinc does not work otherwise for POST requests. I understand the current behavior of Seaside is not ideal and it is cool that Zinc is more powerful than what Seaside expects, but then we have to find a way to expose that in compatible way. Lukas > > Sven > > On 20 Nov 2011, at 20:35, Lukas Renggli wrote: > >>> 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 >> > > > -- Lukas Renggli www.lukas-renggli.ch

Nov. 20, 2011

Re: [Pharo-project] Decompiler writing to a ReadStream

by Nicolas Cellier

http://code.google.com/p/pharo/issues/detail?id=5004 2011/11/17 Martin McClure <martin(a)hand2mouse.com>: > I'm seeing the following in 1.3 and a 1.4 build from a couple of weeks ago: > > ============== > > ***System error handling failed*** > > [...] > > ReadStream(Object)>>shouldNotImplement > ReadStream>>nextPut: > EncoderForV3PlusClosures(Encoder)>>allLiterals > MethodNode>>generate: > MethodNode>>generate > MethodNode>>schematicTempNamesString > CompiledMethod>>decompileWithTemps > Decompiler>>decompileBlock: > > > =============== > > > Since the debugger can't open, I don't have much more information than > this. Looking at the decompiler, it's clear that it sometimes > initializes the Encoder's literalStream to a ReadStream, although that > stream is never read from, only written to. Changing the initialization > to a WriteStream just sends the system into infinite recursion. > > Any ideas on how to debug this? > > Thanks, > > -Martin > >

Nov. 20, 2011

Re: [Pharo-project] Zinc Post requests

by Sven Van Caekenberghe

Well I guess this would then do the trick: requestBodyFor: aZincRequest ^ String streamContents: [ :stream | aZincRequest entity writeOn: (ZnBivalentWriteStream on: stream) ] but it hurts: at this point Zn has already parsed/interpreted the entity from bytes and the above code reencodes it again to bytes. That is why I asked if this is needed in all cases, I guess the body will not be used later on if it is either application/x-www-form-urlencoded or multipart/form-data (since these are handled in #requestFieldsFor:). If that is true, a faster fallback based on #contents should be possible (but with some ugly tests). Also a guard testing for entity #isEmpty and non-POST requests will probably be more efficient. Should I try to write a version and commit it ? Sven On 20 Nov 2011, at 20:35, Lukas Renggli wrote: >> 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] [Q] help with requesting a html page

by Edgar J. De Cleene

On 11/20/11 13:11 PM, "Max Leske" <maxleske(a)gmail.com> wrote: > 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: > >> [Q] help with requesting a html page >> 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 > > I use HV2 so could mix html forms and external/internal JavaScript. > Very thanks for your attention > > Found the answer to my own question and is: > > login > | fields aPassword userName logged | > > fields := self request fields. > fields ifNotNil:[ userName := (fields at: 'username') first. > aPassword := (fields at: 'password') first. > logged := HVNaughtieUsers new verifyPassword: aPassword forUser: userName > ]. > self halt. > > > > Edgar > > PS- My goal is reverse engineering Mantis for a Squeak + Kom + HV2 + external > Javascript. > I called Sapis, see atached

Nov. 20, 2011

Re: [Pharo-project] #ifCurtailed:

by StÃ©phane Ducasse

[tx] ensure: [tx] On Nov 20, 2011, at 8:53 PM, Lukas Renggli wrote: > 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] #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