June 2013 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Trait exclusions

by Sebastian Tleye

Hi Frank, Discussing with DamienC and Stef we agree it's a bug, we will fix it. 2013/6/4 Frank Shearar <frank.shearar(a)gmail.com> > 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

[regression reporter]regression occurred

by no-reply＠ci.inria.fr

https://ci.inria.fr/pharo/job/Pharo-3.0-Update-Step-2-Validation/./label=li… 1 regressions found. FileSystem.Tests.Disk.FileHandleTest.testTruncate

June 4, 2013

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

by Sven Van Caekenberghe

On 04 Jun 2013, at 14:13, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > OK: I have a Pharo 2.0 + Seaside 3.1 image with Zn all up to date. What is the simplest thing that I can do to trigger the problem ? Can I use one of the builtin functional tests ? Found it, I broke about every Seaside request ;-)

June 4, 2013

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

by Sven Van Caekenberghe

Development by proxy is hard ;-) OK: I have a Pharo 2.0 + Seaside 3.1 image with Zn all up to date. What is the simplest thing that I can do to trigger the problem ? Can I use one of the builtin functional tests ? On 04 Jun 2013, at 13:40, Andy Kellens <akellens(a)vub.ac.be> wrote: > > On 04 Jun 2013, at 12:56, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > >> >> On 04 Jun 2013, at 11:20, Andy Kellens <akellens(a)vub.ac.be> wrote: >> >>> >>> 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. >> >> I will go into a Seaside image myself later on, but I think I didn't make myself clear enough with my last remark. I meant to change your code: >> >> 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 ] ] >> >> to >> >> ZnEntity>>contentType: object >> "We only allow assignment compatible with our designated mime type" >> >> | newType | >> newType := object asZnMimeType. >> (contentType notNil and: [ contentType = newType ]) >> ifTrue: [ ^ self ] >> ifFalse: [ >> (self class designatedMimeType isNil or: [ self class designatedMimeType matches: newType ]) >> ifTrue: [ contentType := newType ] ] > > Yes., that is exactly what I tried. > When doing this, the entity of the request has the wrong type (it is a ZnByteArrayEntity instead of a ZnApplicationFormUrlEncodedEntity). > I do not know the code well enough however to see whether using the #matches: is a good solution, or whether something has to be changed elsewhere. > > >> >>>> >>>>> 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

On 04 Jun 2013, at 12:56, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > On 04 Jun 2013, at 11:20, Andy Kellens <akellens(a)vub.ac.be> wrote: > >> >> 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. > > I will go into a Seaside image myself later on, but I think I didn't make myself clear enough with my last remark. I meant to change your code: > > 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 ] ] > > to > > ZnEntity>>contentType: object > "We only allow assignment compatible with our designated mime type" > > | newType | > newType := object asZnMimeType. > (contentType notNil and: [ contentType = newType ]) > ifTrue: [ ^ self ] > ifFalse: [ > (self class designatedMimeType isNil or: [ self class designatedMimeType matches: newType ]) > ifTrue: [ contentType := newType ] ] Yes., that is exactly what I tried. When doing this, the entity of the request has the wrong type (it is a ZnByteArrayEntity instead of a ZnApplicationFormUrlEncodedEntity). I do not know the code well enough however to see whether using the #matches: is a good solution, or whether something has to be changed elsewhere. > >>> >>>> 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 Sven Van Caekenberghe

On 04 Jun 2013, at 11:20, Andy Kellens <akellens(a)vub.ac.be> wrote: > > 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. I will go into a Seaside image myself later on, but I think I didn't make myself clear enough with my last remark. I meant to change your code: 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 ] ] to ZnEntity>>contentType: object "We only allow assignment compatible with our designated mime type" | newType | newType := object asZnMimeType. (contentType notNil and: [ contentType = 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 ] ] >> >> 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] [Pharo-project] Understanding NBOpenGL

by Igor Stasenko

On 4 June 2013 11:40, kilon <thekilon(a)yahoo.co.uk> wrote: > 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. > NB uses a VM API to look for a function in library. That function provides no error feedback (just success or not). and also, it combines with loading library as well. So it is hard to say what exactly happened: did library failed to load or library loaded fine, but function not found. (see #loadSymbol:fromModule: implementation) To put an end to endless mystery, i propose you to implement a small diagnostic tool.. There is not much to do: - call dlopen() - if it fails, call dlerror() , and get details about failure. - call dlsym - if it fails, call dlerror() , and get details about failure. > 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. > -- Best regards, Igor Stasenko.

June 4, 2013

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