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

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

Issue with ZnMimeType>>#=

by Andy Kellens

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

June 4, 2013

Re: [Pharo-dev] MetacelloRepository

by Tudor Girba

Which is a good thing :) Thanks, Doru On Tue, Jun 4, 2013 at 9:28 AM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>wrote: > > On Jun 4, 2013, at 7:18 AM, Hilaire Fernandes <hilaire.fernandes(a)gmail.com> > wrote: > > > Stephane, > > > > The lack for me was the configurationOfXML with the XML-Parser version I > > use (#20, a bit old). > > As this is problably limited to my sistuation I recreate a > > configurationOfXML in my own repo. > > > > Btw, I use XML-Parser for both read and write of XML file. > > Was XML-support splited in two packages recently? > > yes > Normally when loading the parser you would get the writer but damien cut > it apart. > > Stef > > > > > Thanks > > > > Hilaire > > > > Le 03/06/2013 22:08, StÃ©phane Ducasse a Ã©crit : > >> Hilaire > >> > >> Normally this is XMLParser. I extracted just the XML parser and not all > the tools. > >> Now if you want to write you have XMLWriter. > >> > >> Let us know if it works. > >> > >> Stef > >> > >> On Jun 3, 2013, at 10:17 AM, Hilaire Fernandes < > hilaire.fernandes(a)gmail.com> wrote: > >> > >>> Hello, > >>> > >>> To build DrGeo I use the squeaksource MetacelloRepository (example > bellow). > >>> I can not find it in SmalltalkHub? > >>> I can see in PahroExtra/XMLParser ConfigurationOfXMLParser, is it the > >>> same as ConfigurationOfXMLSupport. Can I find equivalent of > >>> ConfigurationOfXMLSupport matching the exact same XML source version? > >>> Unhelpful, I did not find how to browse the source form Smalltalkhub to > >>> explore online the ConfigurationOf... code. > >>> > >>> Thanks > >>> > >>> Hilaire > >>> > >>> > >>> baseline1012: spec > >>> <version: '10.12-baseline'> > >>> spec for: #pharo do: [ > >>> spec blessing: #baseline. > >>> spec project: 'XML Parser' with: [ > >>> spec className: 'ConfigurationOfXMLSupport'; > >>> version: '1.0.1'; > >>> loads: #('default'); > >>> file: 'ConfigurationOfXMLSupport'; > >>> repository: ' > http://www.squeaksource.com/MetacelloRepository']. > >>> spec package: 'DrGeoII-Core' with: [ > >>> spec requires: 'XML Parser']] > >>> > >>> -- > >>> Dr. Geo - http://drgeo.eu > >>> > >>> > >> > > > > > > -- > > Dr. Geo - http://drgeo.eu > > > > > > > -- www.tudorgirba.com "Every thing has its own flow"

June 4, 2013

Re: [Pharo-dev] MetacelloRepository

by StÃ©phane Ducasse

On Jun 4, 2013, at 7:18 AM, Hilaire Fernandes <hilaire.fernandes(a)gmail.com> wrote: > Stephane, > > The lack for me was the configurationOfXML with the XML-Parser version I > use (#20, a bit old). > As this is problably limited to my sistuation I recreate a > configurationOfXML in my own repo. > > Btw, I use XML-Parser for both read and write of XML file. > Was XML-support splited in two packages recently? yes Normally when loading the parser you would get the writer but damien cut it apart. Stef > > Thanks > > Hilaire > > Le 03/06/2013 22:08, StÃ©phane Ducasse a Ã©crit : >> Hilaire >> >> Normally this is XMLParser. I extracted just the XML parser and not all the tools. >> Now if you want to write you have XMLWriter. >> >> Let us know if it works. >> >> Stef >> >> On Jun 3, 2013, at 10:17 AM, Hilaire Fernandes <hilaire.fernandes(a)gmail.com> wrote: >> >>> Hello, >>> >>> To build DrGeo I use the squeaksource MetacelloRepository (example bellow). >>> I can not find it in SmalltalkHub? >>> I can see in PahroExtra/XMLParser ConfigurationOfXMLParser, is it the >>> same as ConfigurationOfXMLSupport. Can I find equivalent of >>> ConfigurationOfXMLSupport matching the exact same XML source version? >>> Unhelpful, I did not find how to browse the source form Smalltalkhub to >>> explore online the ConfigurationOf... code. >>> >>> Thanks >>> >>> Hilaire >>> >>> >>> baseline1012: spec >>> <version: '10.12-baseline'> >>> spec for: #pharo do: [ >>> spec blessing: #baseline. >>> spec project: 'XML Parser' with: [ >>> spec className: 'ConfigurationOfXMLSupport'; >>> version: '1.0.1'; >>> loads: #('default'); >>> file: 'ConfigurationOfXMLSupport'; >>> repository: 'http://www.squeaksource.com/MetacelloRepository']. >>> spec package: 'DrGeoII-Core' with: [ >>> spec requires: 'XML Parser']] >>> >>> -- >>> Dr. Geo - http://drgeo.eu >>> >>> >> > > > -- > Dr. Geo - http://drgeo.eu > >

June 4, 2013