- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] [rmod] sprint in June: 21 or 28?

by phil＠highoctane.be

28 +1 On Tue, Jun 4, 2013 at 11:22 AM, Marcus Denker <marcus.denker(a)inria.fr>wrote: > > On Jun 4, 2013, at 11:21 AM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> > wrote: > > > Hi guys > > > > when do we do the june sprint? > > > > I just put in holidays for the 21, so I vote for the 28th :-) > > Marcus > > >

June 4, 2013

Re: [Pharo-dev] [Pharo-project] Understanding NBOpenGL

by kilon

Ok new problem, NBOpengl seems to not work at all on my UBUNTU 12.10 machine. I was trying to do GLViewportMorph new openInWorld , which works fine on my iMac and it gave me error: function unavailable. So I assumed it cannot find some dynamic library , so I checked around the code and found that in package NBXLib-Core NBXlibHandle>>nbLibraryNameOrHandle class method, it returns '/usr/lib/libX11.so'. However browsing through the directories its clear that the library is not located in there but rather is located as a symlink in a) /usr/lib/i386-linux-gnu b) /usr/lib/x86_64-linux-gnu. Both symlink point to libx11.so.6.3.0 libraries. So knowning that pharo is 32 bit I went for option (a) however still it gives me the same error. Any idea what it may be ? Another question I have is does it not NB check first to see if the library is available ? Because it looks weird that it complains about non existent functions but does not complain about non existent library. Here is the stack NBFFICallout(Object)>>error: NBFFICallout>>generateCall:module: NBGlxAPI>>call: in Block: [...] NBFFICallout class(NBNativeCodeGen class)>>generateCode:andRetry: in Block: [...] BlockClosure>>on:do: NBRecursionDetect class>>in:during: NBFFICallout class(NBNativeCodeGen class)>>generateCode:andRetry: NBFFICallout class(NBNativeCodeGen class)>>handleFailureIn:nativeCode: NBGlxAPI>>call: NBGlxAPI>>queryExtension:errorBase:eventBase: NBGLXContextDriver>>createContext: NBGLContextDriver class>>createContext: NBGLDisplay class>>extent: GLViewportMorph>>initializeForNewSession GLViewportMorph>>initialize GLViewportMorph class(Behavior)>>new UndefinedObject>>DoIt Compiler>>evaluate:in:to:notifying:ifFail:logged: SmalltalkEditor>>evaluateSelectionAndDo: SmalltalkEditor>>evaluateSelection PluggableTextMorph>>doIt in Block: [...] PluggableTextMorph>>handleEdit: in Block: [...] TextMorphForEditView(TextMorph)>>handleEdit: PluggableTextMorph>>handleEdit: PluggableTextMorph>>doIt Workspace(Object)>>perform:orSendTo: ToggleMenuItemMorph(MenuItemMorph)>>invokeWithEvent: in Block: [...] BlockClosure>>ensure: CursorWithMask(Cursor)>>showWhile: ToggleMenuItemMorph(MenuItemMorph)>>invokeWithEvent: -- View this message in context: http://forum.world.st/Understanding-NBOpenGL-tp4686514p4691549.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

June 4, 2013

Re: [Pharo-dev] Trait exclusions

by Frank Shearar

On 4 June 2013 10:19, Sebastian Tleye <stleye(a)gmail.com> wrote: > Hi Frank, i am currently working improving the implementation of traits in > Pharo, Excellent! > 2013/5/31 Frank Shearar <frank.shearar(a)gmail.com> >> >> On 31 May 2013 12:32, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: >> > >> > On May 31, 2013, at 1:28 PM, Frank Shearar <frank.shearar(a)gmail.com> >> > wrote: >> > >> >> On 31 May 2013 12:01, Damien Cassou <damien.cassou(a)gmail.com> wrote: >> >>> Hi Frank, >> >>> >> >>> On Wed, May 29, 2013 at 11:45 PM, Frank Shearar >> >>> <frank.shearar(a)gmail.com> wrote: >> >>>> I have a Trait TGroup that requires #*, #identity and #inverse. I >> >>>> want >> >>>> to construct a TField by composing TGroup with itself. One TGroup >> >>>> will >> >>>> form the operations #*, #one, and #reciprocal while the other will >> >>>> form #+, #zero and #negated. >> >>>> >> >>>> I don't want #identity or #inverse, because these apply to one >> >>>> operation, and it makes TField's API ambiguous. That's what >> >>>> TraitExclusion is for. >> >>> >> >>> maybe a diagram would help >> >> >> >> In explaining the problem, or an an alternative to the crazy >> >> composition? I rather think that this - which doesn't work, and >> >> prompted the question in the first place - is rather readable... _and >> >> executable_: >> >> >> >> (TGroup @ {#* -> #+. #inverse -> #negated. #identity -> #zero} + >> >> TGroup @ {#inverse -> #reciprocal. #identity -> #zero}) - {#identity. >> >> #inverse} >> >> >> >> What I don't understand is >> >> (a) why exclusion only applies to the rightmost trait in the >> >> composition and >> >> (b) why aliases either break (in Pharo [1]) >> > >> > do they? >> >> I'm not sure what "they" refers to. Assuming you meant "do aliases >> break in Pharo?" yes they do: the alias expects the new name to >> already exist in the method dictionary. So if you write your trait >> >> Trait named: #TMyTrait >> uses: TSomething @ {#aMethod -> #notWrittenYet} >> category: 'Thing' >> >> then you get a KeyNotFound because TMyTrait doesn't have >> #notWrittenYet in its method dictionary. It should be fairly easy to >> fix; I just raised the ticket. > > > Yes, i think this is a bug, i'll fix it. Thanks! >> If you meant "do exclusions only apply to the rightmost trait?", yes >> they do. The comment in both Pharo and Squeak say that - binds tighter >> than @ or +. That's fine. To me, that would mean that S + T @ {#m -> >> #z} - {#m} would remove #m from T. But I thought that (S + T @ {#m - >> #z}) - {#m} would mean "remove m from S + T @ {#m - #z}", but it >> doesn't. That might simply be a TraitComposition bug. I don't know, >> which is why I'm asking :) > > > It looks like a bug, > > a trait using > (S + T @ {#m->#z}) - {#m} > > is the same that a trait using > S + (T @ {#m->#z} - {#m}) > > it seems it is not respecting parentheses... Yes, that's exactly it. frank >> >> or do nothing (in Squeak), >> >> where I'd expected to see implementations saying "self requirement". >> > >> > we removed self requirement because it was slow to compute in >> > interactive mode. >> >> Ah, ok. Fair enough! >> >> frank >> >> >> frank >> >> >> >> [1] https://pharo.fogbugz.com/default.asp?10803#78542

June 4, 2013

Re: [Pharo-dev] [rmod] sprint in June: 21 or 28?

by Marcus Denker

On Jun 4, 2013, at 11:21 AM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > Hi guys > > when do we do the june sprint? > I just put in holidays for the 21, so I vote for the 28th :-) Marcus

June 4, 2013

sprint in June: 21 or 28?

by StÃ©phane Ducasse

Hi guys when do we do the june sprint? Stef

June 4, 2013

Re: [Pharo-dev] Issue with ZnMimeType>>#=

by Andy Kellens

On 04 Jun 2013, at 11:13, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > On 04 Jun 2013, at 11:04, Andy Kellens <akellens(a)vub.ac.be> wrote: > >> Hi Sven, >> >> Thanks for the quick response! >> >> A slightly altered version of your patch (it is #matches: instead of #match:) results in that the code goes into the right branch. >> >> ZnZincServerAdaptor>>requestFieldsFor: aZincRequest >> | fields | >> fields := WARequestFields new. >> (aZincRequest method = #POST and: [ aZincRequest hasEntity ]) >> ifTrue: [ >> (aZincRequest entity contentType matches: ZnMimeType applicationFormUrlEncoded) >> ifTrue: [ >> fields addAll: aZincRequest entity fields ]. >> (aZincRequest entity contentType matches: ZnMimeType multiPartFormData) >> ifTrue: [ >> fields addAll: (self convertMultipart: aZincRequest entity) ] ]. >> ^ fields > > Yes, sorry for the typo. > >> Now, to fix my problem I still had to patch two other methods to also use #matches: instead of #= >> ZnEntity>>contentType: object >> "We only allow assignment compatible with our designated mime type" >> >> | newType | >> newType := object asZnMimeType. >> (contentType notNil and:[contentType matches: newType]) >> ifTrue: [ ^ self ] >> ifFalse: [ >> (self class designatedMimeType isNil or: [ self class designatedMimeType matches: newType ]) >> ifTrue: [ contentType := newType ] ] > > That makes sense, but I would say that the first condition should still use #= otherwise it would no longer be possible to change the mime type from text/plain to text/plain;charset=ascii for example (they types then match and nothing will be done). If you make that change, does it still work for you ? If I change it back to #=, the entity of the request is no longer a ZnApplicationFormUrlEncodedEntity but a ZnByteArrayEntity. When retrieving the fields, I get a #DNU that ZnByteArrayEntity does not understand #fields. > >> and: >> ZnEntity class>>concreteSubclassForType: mimeType binary: forceBinary >> "Answer the concrete ZnEntity subclass that handles mimeType" >> >> ^ self allSubclasses >> detect: [ :each | >> each designatedMimeType matches: mimeType ] >> ifNone: [ >> (mimeType isBinary or: [ forceBinary ]) >> ifTrue: [ self byteArrayEntityClass ] >> ifFalse: [ self stringEntityClass ] ] > > That one makes sense indeed. > >> With these changes, everything works like a charm again. >> >> Kind regards, >> >> Andy >> >> >> On 04 Jun 2013, at 10:44, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: >> >>> Hi Andy, >>> >>> Yes, I forgot about ZnZincServerAdaptor when refactoring/changing ZnMimeType>>#= - sorry about that. The solution is actually quite easy: ZnMimeType>>#match: does a comparison while ignoring additional mime type parameters like charset, in addition to its wild card matching. >>> >>> So the patch then would be: >>> >>> ZnZincServerAdaptor>>requestFieldsFor: aZincRequest >>> | fields | >>> fields := WARequestFields new. >>> (aZincRequest method = #POST and: [ aZincRequest hasEntity ]) >>> ifTrue: [ >>> (aZincRequest entity contentType match: ZnMimeType applicationFormUrlEncoded) >>> ifTrue: [ >>> fields addAll: aZincRequest entity fields ]. >>> (aZincRequest entity contentType match: ZnMimeType multiPartFormData) >>> ifTrue: [ >>> fields addAll: (self convertMultipart: aZincRequest entity) ] ]. >>> ^ fields >>> >>> If you confirm that this works, I will check in the change later today. >>> >>> Thanks again for the cristal clear bug report ! >>> >>> Regards, >>> >>> Sven >>> >>> On 04 Jun 2013, at 10:34, Andy Kellens <akellens(a)vub.ac.be> wrote: >>> >>>> Hi, >>>> >>>> Yesterday, I stumbled across a bug when using the Zinc Seaside adaptor that resulted in that the post fields of a request were not present in the WARequest. >>>> I found out that the problem occurred when converting a Zinc request into a WARequest. >>>> >>>> More particular: >>>> ZnZincServerAdaptor>>requestFieldsFor: aZincRequest >>>> | fields | >>>> fields := WARequestFields new. >>>> (aZincRequest method = #POST and: [ aZincRequest hasEntity ]) >>>> ifTrue: [ >>>> aZincRequest entity contentType = ZnMimeType applicationFormUrlEncoded >>>> ifTrue: [ >>>> fields addAll: aZincRequest entity fields ]. >>>> aZincRequest entity contentType = ZnMimeType multiPartFormData >>>> ifTrue: [ >>>> fields addAll: (self convertMultipart: aZincRequest entity) ] ]. >>>> ^ fields >>>> >>>> >>>> This method checks if the Mime Type is either applicationFormUrlEncoded or multiPartFormData in order to extract the post fields. >>>> >>>> Recently, ZnMimeType>>= got changed >>>> from: >>>> ZnMimeType>>= other >>>> ^ (self class == other class) >>>> and: [ self main = other main >>>> and: [ self sub = other sub ] ] >>>> >>>> to: >>>> ZnMimeType>>= other >>>> ^ (self class == other class) >>>> and: [ self main = other main >>>> and: [ self sub = other sub >>>> and: [ self hasParameters not & other hasParameters not >>>> or: [ self parameters = other parameters ] ] ] ] >>>> >>>> As my request had an additional parameter charset=utf-8, the equality with ZnMimeType applicationFormUrlEncoded failed and hence the fields were not extract. >>>> >>>> While I assume that the comparison of the Mime type parameters in #= is there for a good reason, and the best way to fix this problem is to change the #requestFieldsFor: method in order to match the Mime type differently, I wanted to briefly check with the mailing list before opening an issue + submitting a patch. >>>> >>>> Kind regards, >>>> >>>> Andy >>> >>> >>> >>> -- >>> Sven Van Caekenberghe >>> Proudly supporting Pharo >>> http://pharo.org >>> http://association.pharo.org >>> http://consortium.pharo.org >>> >>> >>> >>> >>> >> >> > >

June 4, 2013

Re: [Pharo-dev] Trait exclusions

by Sebastian Tleye

Hi Frank, i am currently working improving the implementation of traits in Pharo, 2013/5/31 Frank Shearar <frank.shearar(a)gmail.com> > On 31 May 2013 12:32, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > > > > On May 31, 2013, at 1:28 PM, Frank Shearar <frank.shearar(a)gmail.com> > wrote: > > > >> On 31 May 2013 12:01, Damien Cassou <damien.cassou(a)gmail.com> wrote: > >>> Hi Frank, > >>> > >>> On Wed, May 29, 2013 at 11:45 PM, Frank Shearar < > frank.shearar(a)gmail.com> wrote: > >>>> I have a Trait TGroup that requires #*, #identity and #inverse. I want > >>>> to construct a TField by composing TGroup with itself. One TGroup will > >>>> form the operations #*, #one, and #reciprocal while the other will > >>>> form #+, #zero and #negated. > >>>> > >>>> I don't want #identity or #inverse, because these apply to one > >>>> operation, and it makes TField's API ambiguous. That's what > >>>> TraitExclusion is for. > >>> > >>> maybe a diagram would help > >> > >> In explaining the problem, or an an alternative to the crazy > >> composition? I rather think that this - which doesn't work, and > >> prompted the question in the first place - is rather readable... _and > >> executable_: > >> > >> (TGroup @ {#* -> #+. #inverse -> #negated. #identity -> #zero} + > >> TGroup @ {#inverse -> #reciprocal. #identity -> #zero}) - {#identity. > >> #inverse} > >> > >> What I don't understand is > >> (a) why exclusion only applies to the rightmost trait in the > composition and > >> (b) why aliases either break (in Pharo [1]) > > > > do they? > > I'm not sure what "they" refers to. Assuming you meant "do aliases > break in Pharo?" yes they do: the alias expects the new name to > already exist in the method dictionary. So if you write your trait > > Trait named: #TMyTrait > uses: TSomething @ {#aMethod -> #notWrittenYet} > category: 'Thing' > > then you get a KeyNotFound because TMyTrait doesn't have > #notWrittenYet in its method dictionary. It should be fairly easy to > fix; I just raised the ticket. > Yes, i think this is a bug, i'll fix it. > > If you meant "do exclusions only apply to the rightmost trait?", yes > they do. The comment in both Pharo and Squeak say that - binds tighter > than @ or +. That's fine. To me, that would mean that S + T @ {#m -> > #z} - {#m} would remove #m from T. But I thought that (S + T @ {#m - > #z}) - {#m} would mean "remove m from S + T @ {#m - #z}", but it > doesn't. That might simply be a TraitComposition bug. I don't know, > which is why I'm asking :) It looks like a bug, a trait using (S + T @ {#m->#z}) - {#m} is the same that a trait using S + (T @ {#m->#z} - {#m}) it seems it is not respecting parentheses... > >> or do nothing (in Squeak), > >> where I'd expected to see implementations saying "self requirement". > > > > we removed self requirement because it was slow to compute in > interactive mode. > > Ah, ok. Fair enough! > > frank > > >> frank > >> > >> [1] https://pharo.fogbugz.com/default.asp?10803#78542 > >

June 4, 2013

Re: [Pharo-dev] Issue with ZnMimeType>>#=

by Sven Van Caekenberghe

On 04 Jun 2013, at 11:04, Andy Kellens <akellens(a)vub.ac.be> wrote: > Hi Sven, > > Thanks for the quick response! > > A slightly altered version of your patch (it is #matches: instead of #match:) results in that the code goes into the right branch. > > ZnZincServerAdaptor>>requestFieldsFor: aZincRequest > | fields | > fields := WARequestFields new. > (aZincRequest method = #POST and: [ aZincRequest hasEntity ]) > ifTrue: [ > (aZincRequest entity contentType matches: ZnMimeType applicationFormUrlEncoded) > ifTrue: [ > fields addAll: aZincRequest entity fields ]. > (aZincRequest entity contentType matches: ZnMimeType multiPartFormData) > ifTrue: [ > fields addAll: (self convertMultipart: aZincRequest entity) ] ]. > ^ fields Yes, sorry for the typo. > Now, to fix my problem I still had to patch two other methods to also use #matches: instead of #= > ZnEntity>>contentType: object > "We only allow assignment compatible with our designated mime type" > > | newType | > newType := object asZnMimeType. > (contentType notNil and:[contentType matches: newType]) > ifTrue: [ ^ self ] > ifFalse: [ > (self class designatedMimeType isNil or: [ self class designatedMimeType matches: newType ]) > ifTrue: [ contentType := newType ] ] That makes sense, but I would say that the first condition should still use #= otherwise it would no longer be possible to change the mime type from text/plain to text/plain;charset=ascii for example (they types then match and nothing will be done). If you make that change, does it still work for you ? > and: > ZnEntity class>>concreteSubclassForType: mimeType binary: forceBinary > "Answer the concrete ZnEntity subclass that handles mimeType" > > ^ self allSubclasses > detect: [ :each | > each designatedMimeType matches: mimeType ] > ifNone: [ > (mimeType isBinary or: [ forceBinary ]) > ifTrue: [ self byteArrayEntityClass ] > ifFalse: [ self stringEntityClass ] ] That one makes sense indeed. > With these changes, everything works like a charm again. > > Kind regards, > > Andy > > > On 04 Jun 2013, at 10:44, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > >> Hi Andy, >> >> Yes, I forgot about ZnZincServerAdaptor when refactoring/changing ZnMimeType>>#= - sorry about that. The solution is actually quite easy: ZnMimeType>>#match: does a comparison while ignoring additional mime type parameters like charset, in addition to its wild card matching. >> >> So the patch then would be: >> >> ZnZincServerAdaptor>>requestFieldsFor: aZincRequest >> | fields | >> fields := WARequestFields new. >> (aZincRequest method = #POST and: [ aZincRequest hasEntity ]) >> ifTrue: [ >> (aZincRequest entity contentType match: ZnMimeType applicationFormUrlEncoded) >> ifTrue: [ >> fields addAll: aZincRequest entity fields ]. >> (aZincRequest entity contentType match: ZnMimeType multiPartFormData) >> ifTrue: [ >> fields addAll: (self convertMultipart: aZincRequest entity) ] ]. >> ^ fields >> >> If you confirm that this works, I will check in the change later today. >> >> Thanks again for the cristal clear bug report ! >> >> Regards, >> >> Sven >> >> On 04 Jun 2013, at 10:34, Andy Kellens <akellens(a)vub.ac.be> wrote: >> >>> Hi, >>> >>> Yesterday, I stumbled across a bug when using the Zinc Seaside adaptor that resulted in that the post fields of a request were not present in the WARequest. >>> I found out that the problem occurred when converting a Zinc request into a WARequest. >>> >>> More particular: >>> ZnZincServerAdaptor>>requestFieldsFor: aZincRequest >>> | fields | >>> fields := WARequestFields new. >>> (aZincRequest method = #POST and: [ aZincRequest hasEntity ]) >>> ifTrue: [ >>> aZincRequest entity contentType = ZnMimeType applicationFormUrlEncoded >>> ifTrue: [ >>> fields addAll: aZincRequest entity fields ]. >>> aZincRequest entity contentType = ZnMimeType multiPartFormData >>> ifTrue: [ >>> fields addAll: (self convertMultipart: aZincRequest entity) ] ]. >>> ^ fields >>> >>> >>> This method checks if the Mime Type is either applicationFormUrlEncoded or multiPartFormData in order to extract the post fields. >>> >>> Recently, ZnMimeType>>= got changed >>> from: >>> ZnMimeType>>= other >>> ^ (self class == other class) >>> and: [ self main = other main >>> and: [ self sub = other sub ] ] >>> >>> to: >>> ZnMimeType>>= other >>> ^ (self class == other class) >>> and: [ self main = other main >>> and: [ self sub = other sub >>> and: [ self hasParameters not & other hasParameters not >>> or: [ self parameters = other parameters ] ] ] ] >>> >>> As my request had an additional parameter charset=utf-8, the equality with ZnMimeType applicationFormUrlEncoded failed and hence the fields were not extract. >>> >>> While I assume that the comparison of the Mime type parameters in #= is there for a good reason, and the best way to fix this problem is to change the #requestFieldsFor: method in order to match the Mime type differently, I wanted to briefly check with the mailing list before opening an issue + submitting a patch. >>> >>> Kind regards, >>> >>> Andy >> >> >> >> -- >> Sven Van Caekenberghe >> Proudly supporting Pharo >> http://pharo.org >> http://association.pharo.org >> http://consortium.pharo.org >> >> >> >> >> > >

June 4, 2013

Re: [Pharo-dev] Issue with ZnMimeType>>#=

by Andy Kellens

Hi Sven, Thanks for the quick response! A slightly altered version of your patch (it is #matches: instead of #match:) results in that the code goes into the right branch. ZnZincServerAdaptor>>requestFieldsFor: aZincRequest | fields | fields := WARequestFields new. (aZincRequest method = #POST and: [ aZincRequest hasEntity ]) ifTrue: [ (aZincRequest entity contentType matches: ZnMimeType applicationFormUrlEncoded) ifTrue: [ fields addAll: aZincRequest entity fields ]. (aZincRequest entity contentType matches: ZnMimeType multiPartFormData) ifTrue: [ fields addAll: (self convertMultipart: aZincRequest entity) ] ]. ^ fields Now, to fix my problem I still had to patch two other methods to also use #matches: instead of #= ZnEntity>>contentType: object "We only allow assignment compatible with our designated mime type" | newType | newType := object asZnMimeType. (contentType notNil and:[contentType matches: newType]) ifTrue: [ ^ self ] ifFalse: [ (self class designatedMimeType isNil or: [ self class designatedMimeType matches: newType ]) ifTrue: [ contentType := newType ] ] and: ZnEntity class>>concreteSubclassForType: mimeType binary: forceBinary "Answer the concrete ZnEntity subclass that handles mimeType" ^ self allSubclasses detect: [ :each | each designatedMimeType matches: mimeType ] ifNone: [ (mimeType isBinary or: [ forceBinary ]) ifTrue: [ self byteArrayEntityClass ] ifFalse: [ self stringEntityClass ] ] With these changes, everything works like a charm again. Kind regards, Andy On 04 Jun 2013, at 10:44, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > Hi Andy, > > Yes, I forgot about ZnZincServerAdaptor when refactoring/changing ZnMimeType>>#= - sorry about that. The solution is actually quite easy: ZnMimeType>>#match: does a comparison while ignoring additional mime type parameters like charset, in addition to its wild card matching. > > So the patch then would be: > > ZnZincServerAdaptor>>requestFieldsFor: aZincRequest > | fields | > fields := WARequestFields new. > (aZincRequest method = #POST and: [ aZincRequest hasEntity ]) > ifTrue: [ > (aZincRequest entity contentType match: ZnMimeType applicationFormUrlEncoded) > ifTrue: [ > fields addAll: aZincRequest entity fields ]. > (aZincRequest entity contentType match: ZnMimeType multiPartFormData) > ifTrue: [ > fields addAll: (self convertMultipart: aZincRequest entity) ] ]. > ^ fields > > If you confirm that this works, I will check in the change later today. > > Thanks again for the cristal clear bug report ! > > Regards, > > Sven > > On 04 Jun 2013, at 10:34, Andy Kellens <akellens(a)vub.ac.be> wrote: > >> Hi, >> >> Yesterday, I stumbled across a bug when using the Zinc Seaside adaptor that resulted in that the post fields of a request were not present in the WARequest. >> I found out that the problem occurred when converting a Zinc request into a WARequest. >> >> More particular: >> ZnZincServerAdaptor>>requestFieldsFor: aZincRequest >> | fields | >> fields := WARequestFields new. >> (aZincRequest method = #POST and: [ aZincRequest hasEntity ]) >> ifTrue: [ >> aZincRequest entity contentType = ZnMimeType applicationFormUrlEncoded >> ifTrue: [ >> fields addAll: aZincRequest entity fields ]. >> aZincRequest entity contentType = ZnMimeType multiPartFormData >> ifTrue: [ >> fields addAll: (self convertMultipart: aZincRequest entity) ] ]. >> ^ fields >> >> >> This method checks if the Mime Type is either applicationFormUrlEncoded or multiPartFormData in order to extract the post fields. >> >> Recently, ZnMimeType>>= got changed >> from: >> ZnMimeType>>= other >> ^ (self class == other class) >> and: [ self main = other main >> and: [ self sub = other sub ] ] >> >> to: >> ZnMimeType>>= other >> ^ (self class == other class) >> and: [ self main = other main >> and: [ self sub = other sub >> and: [ self hasParameters not & other hasParameters not >> or: [ self parameters = other parameters ] ] ] ] >> >> As my request had an additional parameter charset=utf-8, the equality with ZnMimeType applicationFormUrlEncoded failed and hence the fields were not extract. >> >> While I assume that the comparison of the Mime type parameters in #= is there for a good reason, and the best way to fix this problem is to change the #requestFieldsFor: method in order to match the Mime type differently, I wanted to briefly check with the mailing list before opening an issue + submitting a patch. >> >> Kind regards, >> >> Andy > > > > -- > Sven Van Caekenberghe > Proudly supporting Pharo > http://pharo.org > http://association.pharo.org > http://consortium.pharo.org > > > > >

June 4, 2013

Re: [Pharo-dev] Issue with ZnMimeType>>#=

by Sven Van Caekenberghe

Hi Andy, Yes, I forgot about ZnZincServerAdaptor when refactoring/changing ZnMimeType>>#= - sorry about that. The solution is actually quite easy: ZnMimeType>>#match: does a comparison while ignoring additional mime type parameters like charset, in addition to its wild card matching. So the patch then would be: ZnZincServerAdaptor>>requestFieldsFor: aZincRequest | fields | fields := WARequestFields new. (aZincRequest method = #POST and: [ aZincRequest hasEntity ]) ifTrue: [ (aZincRequest entity contentType match: ZnMimeType applicationFormUrlEncoded) ifTrue: [ fields addAll: aZincRequest entity fields ]. (aZincRequest entity contentType match: ZnMimeType multiPartFormData) ifTrue: [ fields addAll: (self convertMultipart: aZincRequest entity) ] ]. ^ fields If you confirm that this works, I will check in the change later today. Thanks again for the cristal clear bug report ! Regards, Sven On 04 Jun 2013, at 10:34, Andy Kellens <akellens(a)vub.ac.be> wrote: > Hi, > > Yesterday, I stumbled across a bug when using the Zinc Seaside adaptor that resulted in that the post fields of a request were not present in the WARequest. > I found out that the problem occurred when converting a Zinc request into a WARequest. > > More particular: > ZnZincServerAdaptor>>requestFieldsFor: aZincRequest > | fields | > fields := WARequestFields new. > (aZincRequest method = #POST and: [ aZincRequest hasEntity ]) > ifTrue: [ > aZincRequest entity contentType = ZnMimeType applicationFormUrlEncoded > ifTrue: [ > fields addAll: aZincRequest entity fields ]. > aZincRequest entity contentType = ZnMimeType multiPartFormData > ifTrue: [ > fields addAll: (self convertMultipart: aZincRequest entity) ] ]. > ^ fields > > > This method checks if the Mime Type is either applicationFormUrlEncoded or multiPartFormData in order to extract the post fields. > > Recently, ZnMimeType>>= got changed > from: > ZnMimeType>>= other > ^ (self class == other class) > and: [ self main = other main > and: [ self sub = other sub ] ] > > to: > ZnMimeType>>= other > ^ (self class == other class) > and: [ self main = other main > and: [ self sub = other sub > and: [ self hasParameters not & other hasParameters not > or: [ self parameters = other parameters ] ] ] ] > > As my request had an additional parameter charset=utf-8, the equality with ZnMimeType applicationFormUrlEncoded failed and hence the fields were not extract. > > While I assume that the comparison of the Mime type parameters in #= is there for a good reason, and the best way to fix this problem is to change the #requestFieldsFor: method in order to match the Mime type differently, I wanted to briefly check with the mailing list before opening an issue + submitting a patch. > > Kind regards, > > Andy -- Sven Van Caekenberghe Proudly supporting Pharo http://pharo.org http://association.pharo.org http://consortium.pharo.org

June 4, 2013