Re: XML Parser / Pastell
Locked
 
|
Hi,
I exchanged a number of emails with Jaayer and Norbert regarding some improvements of XMLSupport and its port to Gemstone. It may be a bit difficult for people to follow this, but I think it is important to not discuss privately. >>>>> I already changed >>>>> >>>>> XMLTokenizer>>nextName >>>>> .... >>>>> ^ self fastStreamStringContents: nameBuffer >>>>> >>>>> to >>>>> >>>>> XMLTokenizer>>nextName >>>>> .... >>>>> ^ (self fastStreamStringContents: nameBuffer) asSymbol >>>>> >>>>> in the gemstone parser to be more consistent. >>>> >>>> Have you noticed any slow down for this? >>>> >>> No I didn't do any tests. But if internally all names are symbols >>> than I guess converting it while reading is the best way to do. >> >> I added benchmark1 in XMLParserTest. Really simple way to measure >> progress (or slowdown). >> On my machine, I have: >> XMLParserTest new benchmark1 >> => 2097 >> >> Adding "(self fastStreamStringContents: nameBuffer) asSymbol" >> increase the bench to 2273 >> > I don't believe this ;) you read them as string from the stream. If > they are managed as symbols somehow they need to be converted. If > not at this place then on some other. I would suspect that there are > doubled calls to asSymbol. Could you check the sources? There is indeed a slowdown. I am not sure where it comes from however. Executing twice "XMLParserTest new benchmark1" does not return the same result. Actually, it increases at each execution! I thought that a garbage collect before running the bench would help, does apparently it does not. Calling asSymbol on a symbol should not be perceptible I believe. Cheers, Alexandre >>> anElement attributes class (I wrote species but that will fail in >>> gemstone too I guess. Hell!) >> >> I just committed with species. Let me know. This is easy to adjust. >> > Ok. > >>>>> The gemstone XML Parser decides somehow to use >>>>> IdentityDictionary internally. I think this should be allowed. I >>>>> just changed Dictionary to IdentityDictionary so the = test >>>>> reflects the right type. If you change it it is clear that it >>>>> fails. Because pharo uses Dictionary internally. So you might >>>>> see that it is not a question of using Dictionary or >>>>> IdentityDictionary but a question of the wrongness of using = >>>> >>>> How the XMLNodeTest should look like to accommodate your situation? >>>> >>> I need to recheck this. The problem is really that the XML Parser >>> creatios instances of class Association but { #key->'value' } >>> creates an instance of class SymbolAssociation. That means I would >>> know how to fix the test but I want to understand the implications >>> of all of this. I'll get to you if I know anything new. >> >> Ok. >> > My mail to the gemstone list led to a ticket about removing class > checks from Association. That would be easing the handling a lot. > > Norbert >>> >>> >>>> Alexandre >>>> >>>>> >>>>>>> Here there is an assumption about the allAttributes collection >>>>>>> while using = as comparsion. But there is also an assumption >>>>>>> about the order of the content. I changed this to >>>>>>> >>>>>>> self assert: (firstPerson allAttributes includesAllOf: >>>>>>> #(#'first-name' #'employee-number' #'family-name')). >>>>>>> self assert: (firstPerson allAttributeAssociations asArray >>>>>>> includesAllOf: {(#'first-name'->'Bob'). (#'employee-number'- >>>>>>> >'A0000'). (#'family-name'->'Gates')}). >>>>>> >>>>>> Very right. My mistake. But wouldn't an asSortedCollection do >>>>>> the thing? Do you not test the size of the array. >>>>>> >>>>>>> This is not the best way to do because the check is only in >>>>>>> one direction but for this test it is ok. Somehow the second >>>>>>> assert fails and I have to check what is going on here. >>>>>> >>>>>> Yeah, my mistake. Sorry. The elements may be differently >>>>>> ordered. Would a asSortedCollection help? >>>>>> >>>>>> I have now granted you an access to the repository. You should >>>>>> be able to directly commit in it. >>>>>> >>>>>> Jaayer, what is your Squeaksource account? >>>>>> >>>>>> Cheers, >>>>>> Alexandre >>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> On 28.02.2010, at 02:01, Alexandre Bergel wrote: >>>>>>> >>>>>>>>> thanks for now. I did a first merge attempt. It will be >>>>>>>>> quite a bit of work. For me the xml parser is an important >>>>>>>>> component. With the newest changes it became biased towards >>>>>>>>> pharo. There are things like ClassTestCase, Unicode >>>>>>>>> CharacterSet. These are for sure improvements/changes in >>>>>>>>> pharo you like to use. But they make porting a lot more >>>>>>>>> difficult. I would be glad if we could find some way to >>>>>>>>> lower the porting barrier. The necessary class I could put >>>>>>>>> in the squeak compat package in gemstone. But then the xml >>>>>>>>> parser will depend on the squeak package which I don't like. >>>>>>>> >>>>>>>> >>>>>>>> Hi Norbert, >>>>>>>> >>>>>>>> XMLParser effectively depends on Squeak specific classes. I >>>>>>>> wrote a small script that identify the squeak classes used in >>>>>>>> XML-Support. Here is the list: LanguageEnvironment, Unicode, >>>>>>>> LocaleID, CharacterSet >>>>>>>> >>>>>>>> I guess that porting the whole multilingual support may not >>>>>>>> be that easy. The tag xml:lang is used to select the proper >>>>>>>> support. It should be easy for you to ignore it I guess. >>>>>>>> >>>>>>>> CharacterSet seems to be one that has to be ported. It is not >>>>>>>> a big class. It depends on WideCharacterSet. I am not sure >>>>>>>> whether this is useful in your case however. >>>>>>>> >>>>>>>> Cheers, >>>>>>>> Alexandre >>>>>>>> >>>>>>>> -- >>>>>>>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >>>>>>>> Alexandre Bergel http://www.bergel.eu >>>>>>>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>>> -- >>>>>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >>>>>> Alexandre Bergel http://www.bergel.eu >>>>>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>> >>>> >>>> -- >>>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >>>> Alexandre Bergel http://www.bergel.eu >>>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >>>> >>>> >>>> >>>> >>>> >>> >> >> -- >> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >> Alexandre Bergel http://www.bergel.eu >> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >> >> >> >> >> > -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. _______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
|
|
---- On Thu, 04 Mar 2010 12:35:39 -0800 Alexandre Bergel <[hidden email]> wrote ---- >Hi, > >I exchanged a number of emails with Jaayer and Norbert regarding some >improvements of XMLSupport and its port to Gemstone. >It may be a bit difficult for people to follow this, but I think it is >important to not discuss privately. > >>>>>> I already changed >>>>>> >>>>>> XMLTokenizer>>nextName >>>>>> .... >>>>>> ^ self fastStreamStringContents: nameBuffer >>>>>> >>>>>> to >>>>>> >>>>>> XMLTokenizer>>nextName >>>>>> .... >>>>>> ^ (self fastStreamStringContents: nameBuffer) asSymbol >>>>>> >>>>>> in the gemstone parser to be more consistent. >>>>> >>>>> Have you noticed any slow down for this? >>>>> >>>> No I didn't do any tests. But if internally all names are symbols >>>> than I guess converting it while reading is the best way to do. >>> >>> I added benchmark1 in XMLParserTest. Really simple way to measure >>> progress (or slowdown). >>> On my machine, I have: >>> XMLParserTest new benchmark1 >>> => 2097 >>> >>> Adding "(self fastStreamStringContents: nameBuffer) asSymbol" >>> increase the bench to 2273 >>> >> I don't believe this ;) you read them as string from the stream. If >> they are managed as symbols somehow they need to be converted. If >> not at this place then on some other. I would suspect that there are >> doubled calls to asSymbol. Could you check the sources? > >There is indeed a slowdown. I am not sure where it comes from however. >Executing twice "XMLParserTest new benchmark1" does not return the >same result. Actually, it increases at each execution! I thought that >a garbage collect before running the bench would help, does apparently >it does not. > >Calling asSymbol on a symbol should not be perceptible I believe. > >Cheers, >Alexandre _______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
|
|
In reply to this post by Alexandre Bergel
send that to pharo.
Stef On Mar 4, 2010, at 9:35 PM, Alexandre Bergel wrote: > Hi, > > I exchanged a number of emails with Jaayer and Norbert regarding some improvements of XMLSupport and its port to Gemstone. > It may be a bit difficult for people to follow this, but I think it is important to not discuss privately. > >>>>>> I already changed >>>>>> >>>>>> XMLTokenizer>>nextName >>>>>> .... >>>>>> ^ self fastStreamStringContents: nameBuffer >>>>>> >>>>>> to >>>>>> >>>>>> XMLTokenizer>>nextName >>>>>> .... >>>>>> ^ (self fastStreamStringContents: nameBuffer) asSymbol >>>>>> >>>>>> in the gemstone parser to be more consistent. >>>>> >>>>> Have you noticed any slow down for this? >>>>> >>>> No I didn't do any tests. But if internally all names are symbols than I guess converting it while reading is the best way to do. >>> >>> I added benchmark1 in XMLParserTest. Really simple way to measure progress (or slowdown). >>> On my machine, I have: >>> XMLParserTest new benchmark1 >>> => 2097 >>> >>> Adding "(self fastStreamStringContents: nameBuffer) asSymbol" increase the bench to 2273 >>> >> I don't believe this ;) you read them as string from the stream. If they are managed as symbols somehow they need to be converted. If not at this place then on some other. I would suspect that there are doubled calls to asSymbol. Could you check the sources? > > There is indeed a slowdown. I am not sure where it comes from however. Executing twice "XMLParserTest new benchmark1" does not return the same result. Actually, it increases at each execution! I thought that a garbage collect before running the bench would help, does apparently it does not. > > Calling asSymbol on a symbol should not be perceptible I believe. > > Cheers, > Alexandre > > >>>> anElement attributes class (I wrote species but that will fail in gemstone too I guess. Hell!) >>> >>> I just committed with species. Let me know. This is easy to adjust. >>> >> Ok. >> >>>>>> The gemstone XML Parser decides somehow to use IdentityDictionary internally. I think this should be allowed. I just changed Dictionary to IdentityDictionary so the = test reflects the right type. If you change it it is clear that it fails. Because pharo uses Dictionary internally. So you might see that it is not a question of using Dictionary or IdentityDictionary but a question of the wrongness of using = >>>>> >>>>> How the XMLNodeTest should look like to accommodate your situation? >>>>> >>>> I need to recheck this. The problem is really that the XML Parser creatios instances of class Association but { #key->'value' } creates an instance of class SymbolAssociation. That means I would know how to fix the test but I want to understand the implications of all of this. I'll get to you if I know anything new. >>> >>> Ok. >>> >> My mail to the gemstone list led to a ticket about removing class checks from Association. That would be easing the handling a lot. >> >> Norbert >>>> >>>> >>>>> Alexandre >>>>> >>>>>> >>>>>>>> Here there is an assumption about the allAttributes collection while using = as comparsion. But there is also an assumption about the order of the content. I changed this to >>>>>>>> >>>>>>>> self assert: (firstPerson allAttributes includesAllOf: #(#'first-name' #'employee-number' #'family-name')). >>>>>>>> self assert: (firstPerson allAttributeAssociations asArray includesAllOf: {(#'first-name'->'Bob'). (#'employee-number'->'A0000'). (#'family-name'->'Gates')}). >>>>>>> >>>>>>> Very right. My mistake. But wouldn't an asSortedCollection do the thing? Do you not test the size of the array. >>>>>>> >>>>>>>> This is not the best way to do because the check is only in one direction but for this test it is ok. Somehow the second assert fails and I have to check what is going on here. >>>>>>> >>>>>>> Yeah, my mistake. Sorry. The elements may be differently ordered. Would a asSortedCollection help? >>>>>>> >>>>>>> I have now granted you an access to the repository. You should be able to directly commit in it. >>>>>>> >>>>>>> Jaayer, what is your Squeaksource account? >>>>>>> >>>>>>> Cheers, >>>>>>> Alexandre >>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On 28.02.2010, at 02:01, Alexandre Bergel wrote: >>>>>>>> >>>>>>>>>> thanks for now. I did a first merge attempt. It will be quite a bit of work. For me the xml parser is an important component. With the newest changes it became biased towards pharo. There are things like ClassTestCase, Unicode CharacterSet. These are for sure improvements/changes in pharo you like to use. But they make porting a lot more difficult. I would be glad if we could find some way to lower the porting barrier. The necessary class I could put in the squeak compat package in gemstone. But then the xml parser will depend on the squeak package which I don't like. >>>>>>>>> >>>>>>>>> >>>>>>>>> Hi Norbert, >>>>>>>>> >>>>>>>>> XMLParser effectively depends on Squeak specific classes. I wrote a small script that identify the squeak classes used in XML-Support. Here is the list: LanguageEnvironment, Unicode, LocaleID, CharacterSet >>>>>>>>> >>>>>>>>> I guess that porting the whole multilingual support may not be that easy. The tag xml:lang is used to select the proper support. It should be easy for you to ignore it I guess. >>>>>>>>> >>>>>>>>> CharacterSet seems to be one that has to be ported. It is not a big class. It depends on WideCharacterSet. I am not sure whether this is useful in your case however. >>>>>>>>> >>>>>>>>> Cheers, >>>>>>>>> Alexandre >>>>>>>>> >>>>>>>>> -- >>>>>>>>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >>>>>>>>> Alexandre Bergel http://www.bergel.eu >>>>>>>>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>>> -- >>>>>>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >>>>>>> Alexandre Bergel http://www.bergel.eu >>>>>>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>> >>>>> -- >>>>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >>>>> Alexandre Bergel http://www.bergel.eu >>>>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >>>>> >>>>> >>>>> >>>>> >>>>> >>>> >>> >>> -- >>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >>> Alexandre Bergel http://www.bergel.eu >>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >>> >>> >>> >>> >>> >> > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > > _______________________________________________ > Moose-dev mailing list > [hidden email] > https://www.iam.unibe.ch/mailman/listinfo/moose-dev _______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
|
|
In reply to this post by jaayer
>
> You should run those benchmarks longer, perhaps 600 times instead of > 300, to get a more stable result. I loaded your most-recent package > into a clean image and got similar results to what you got, with the > current non-converting version being slightly faster. However, in my > development image (with all of the changes I have made since my last > release), the converting version is slightly faster, and both > versions are overall faster. I haven't been able to work much on the > parsers and tokenizer yet, but it appears they are still largely > string-based, so I am not sure if making changes like this is good > idea at this point. Ok, I will increase it to 600. And leave this story about convertion for later. Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. _______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
|
|
In reply to this post by Alexandre Bergel
---- On Thu, 04 Mar 2010 12:35:39 -0800 Alexandre Bergel <[hidden email]> wrote ---- >Hi, > >I exchanged a number of emails with Jaayer and Norbert regarding some >improvements of XMLSupport and its port to Gemstone. >It may be a bit difficult for people to follow this, but I think it is >important to not discuss privately. > >>>>>> I already changed >>>>>> >>>>>> XMLTokenizer>>nextName >>>>>> .... >>>>>> ^ self fastStreamStringContents: nameBuffer >>>>>> >>>>>> to >>>>>> >>>>>> XMLTokenizer>>nextName >>>>>> .... >>>>>> ^ (self fastStreamStringContents: nameBuffer) asSymbol >>>>>> >>>>>> in the gemstone parser to be more consistent. >>>>> >>>>> Have you noticed any slow down for this? >>>>> >>>> No I didn't do any tests. But if internally all names are symbols >>>> than I guess converting it while reading is the best way to do. >>> >>> I added benchmark1 in XMLParserTest. Really simple way to measure >>> progress (or slowdown). >>> On my machine, I have: >>> XMLParserTest new benchmark1 >>> => 2097 >>> >>> Adding "(self fastStreamStringContents: nameBuffer) asSymbol" >>> increase the bench to 2273 >>> >> I don't believe this ;) you read them as string from the stream. If >> they are managed as symbols somehow they need to be converted. If >> not at this place then on some other. I would suspect that there are >> doubled calls to asSymbol. Could you check the sources? > >There is indeed a slowdown. I am not sure where it comes from however. >Executing twice "XMLParserTest new benchmark1" does not return the >same result. Actually, it increases at each execution! I thought that >a garbage collect before running the bench would help, does apparently >it does not. > >Calling asSymbol on a symbol should not be perceptible I believe. > >Cheers, >Alexandre Alexandre, you should see an improvement in your benchmarks now. >>>> anElement attributes class (I wrote species but that will fail in >>>> gemstone too I guess. Hell!) >>> >>> I just committed with species. Let me know. This is easy to adjust. >>> >> Ok. >> >>>>>> The gemstone XML Parser decides somehow to use >>>>>> IdentityDictionary internally. I think this should be allowed. I >>>>>> just changed Dictionary to IdentityDictionary so the = test >>>>>> reflects the right type. If you change it it is clear that it >>>>>> fails. Because pharo uses Dictionary internally. So you might >>>>>> see that it is not a question of using Dictionary or >>>>>> IdentityDictionary but a question of the wrongness of using = >>>>> >>>>> How the XMLNodeTest should look like to accommodate your situation? >>>>> >>>> I need to recheck this. The problem is really that the XML Parser >>>> creatios instances of class Association but { #key->'value' } >>>> creates an instance of class SymbolAssociation. That means I would >>>> know how to fix the test but I want to understand the implications >>>> of all of this. I'll get to you if I know anything new. >>> >>> Ok. >>> >> My mail to the gemstone list led to a ticket about removing class >> checks from Association. That would be easing the handling a lot. >> >> Norbert >>>> >>>> >>>>> Alexandre >>>>> >>>>>> >>>>>>>> Here there is an assumption about the allAttributes collection >>>>>>>> while using = as comparsion. But there is also an assumption >>>>>>>> about the order of the content. I changed this to >>>>>>>> >>>>>>>> self assert: (firstPerson allAttributes includesAllOf: >>>>>>>> #(#'first-name' #'employee-number' #'family-name')). >>>>>>>> self assert: (firstPerson allAttributeAssociations asArray >>>>>>>> includesAllOf: {(#'first-name'->'Bob'). (#'employee-number'- >>>>>>>> >'A0000'). (#'family-name'->'Gates')}). >>>>>>> >>>>>>> Very right. My mistake. But wouldn't an asSortedCollection do >>>>>>> the thing? Do you not test the size of the array. >>>>>>> >>>>>>>> This is not the best way to do because the check is only in >>>>>>>> one direction but for this test it is ok. Somehow the second >>>>>>>> assert fails and I have to check what is going on here. >>>>>>> >>>>>>> Yeah, my mistake. Sorry. The elements may be differently >>>>>>> ordered. Would a asSortedCollection help? >>>>>>> >>>>>>> I have now granted you an access to the repository. You should >>>>>>> be able to directly commit in it. >>>>>>> >>>>>>> Jaayer, what is your Squeaksource account? >>>>>>> >>>>>>> Cheers, >>>>>>> Alexandre >>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On 28.02.2010, at 02:01, Alexandre Bergel wrote: >>>>>>>> >>>>>>>>>> thanks for now. I did a first merge attempt. It will be >>>>>>>>>> quite a bit of work. For me the xml parser is an important >>>>>>>>>> component. With the newest changes it became biased towards >>>>>>>>>> pharo. There are things like ClassTestCase, Unicode >>>>>>>>>> CharacterSet. These are for sure improvements/changes in >>>>>>>>>> pharo you like to use. But they make porting a lot more >>>>>>>>>> difficult. I would be glad if we could find some way to >>>>>>>>>> lower the porting barrier. The necessary class I could put >>>>>>>>>> in the squeak compat package in gemstone. But then the xml >>>>>>>>>> parser will depend on the squeak package which I don't like. >>>>>>>>> >>>>>>>>> >>>>>>>>> Hi Norbert, >>>>>>>>> >>>>>>>>> XMLParser effectively depends on Squeak specific classes. I >>>>>>>>> wrote a small script that identify the squeak classes used in >>>>>>>>> XML-Support. Here is the list: LanguageEnvironment, Unicode, >>>>>>>>> LocaleID, CharacterSet >>>>>>>>> >>>>>>>>> I guess that porting the whole multilingual support may not >>>>>>>>> be that easy. The tag xml:lang is used to select the proper >>>>>>>>> support. It should be easy for you to ignore it I guess. >>>>>>>>> >>>>>>>>> CharacterSet seems to be one that has to be ported. It is not >>>>>>>>> a big class. It depends on WideCharacterSet. I am not sure >>>>>>>>> whether this is useful in your case however. >>>>>>>>> >>>>>>>>> Cheers, >>>>>>>>> Alexandre >>>>>>>>> >>>>>>>>> -- >>>>>>>>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >>>>>>>>> Alexandre Bergel http://www.bergel.eu >>>>>>>>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>>> -- >>>>>>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >>>>>>> Alexandre Bergel http://www.bergel.eu >>>>>>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>> >>>>> -- >>>>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >>>>> Alexandre Bergel http://www.bergel.eu >>>>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >>>>> >>>>> >>>>> >>>>> >>>>> >>>> >>> >>> -- >>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >>> Alexandre Bergel http://www.bergel.eu >>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >>> >>> >>> >>> >>> >> > >-- >_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >Alexandre Bergel http://www.bergel.eu >^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
|
|
> The most recent version is completely string-based. The performance of the symbol-based predecessors was erratic; it would be terribly slow at first in a clean image and improve only after saving the image at least once.
This is cool. These symbols everywhere were so totally out of place and caused all kind of weird things to happen ... Lukas -- Lukas Renggli http://www.lukas-renggli.ch _______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
|
|
In reply to this post by jaayer
Jaayer, some methods are now deprecated. For example
#forwardToDeprecatedHandler:withArgumentOrder:orTo: says to 'use startElement:attributes: instead' But the sender of this fonction #forward... are in SAX itself. I guess all these calls need to be updated? > > The most recent version is completely string-based. The performance > of the symbol-based predecessors was erratic; it would be terribly > slow at first in a clean image and improve only after saving the > image at least once. Even then my tests indicated that a purely > string-based version would be faster. This is likely due to the > initial overhead of interning symbols and then the subsequent > overhead of looking them up. I did honestly prefer the #symbol > syntax for naming things, but considering that the things so-named > and the names themselves all begin life (from the tokenizer) as > strings, it makes more sense (and requires less code) to keep them > that way. It is also more portable, as we no longer need assume that > Symbol is a subclass of String. I don't think this will cause issues > in Squeak/Pharo code, as both systems (for now) assume #name = > 'name'. Hopefully it will not cause too much trouble for Norbert. > > Alexandre, you should see an improvement in your benchmarks now. Indeed! Cool! Alexandre > >>>>> anElement attributes class (I wrote species but that will fail in >>>>> gemstone too I guess. Hell!) >>>> >>>> I just committed with species. Let me know. This is easy to adjust. >>>> >>> Ok. >>> >>>>>>> The gemstone XML Parser decides somehow to use >>>>>>> IdentityDictionary internally. I think this should be allowed. I >>>>>>> just changed Dictionary to IdentityDictionary so the = test >>>>>>> reflects the right type. If you change it it is clear that it >>>>>>> fails. Because pharo uses Dictionary internally. So you might >>>>>>> see that it is not a question of using Dictionary or >>>>>>> IdentityDictionary but a question of the wrongness of using = >>>>>> >>>>>> How the XMLNodeTest should look like to accommodate your >>>>>> situation? >>>>>> >>>>> I need to recheck this. The problem is really that the XML Parser >>>>> creatios instances of class Association but { #key->'value' } >>>>> creates an instance of class SymbolAssociation. That means I would >>>>> know how to fix the test but I want to understand the implications >>>>> of all of this. I'll get to you if I know anything new. >>>> >>>> Ok. >>>> >>> My mail to the gemstone list led to a ticket about removing class >>> checks from Association. That would be easing the handling a lot. >>> >>> Norbert >>>>> >>>>> >>>>>> Alexandre >>>>>> >>>>>>> >>>>>>>>> Here there is an assumption about the allAttributes collection >>>>>>>>> while using = as comparsion. But there is also an assumption >>>>>>>>> about the order of the content. I changed this to >>>>>>>>> >>>>>>>>> self assert: (firstPerson allAttributes includesAllOf: >>>>>>>>> #(#'first-name' #'employee-number' #'family-name')). >>>>>>>>> self assert: (firstPerson allAttributeAssociations asArray >>>>>>>>> includesAllOf: {(#'first-name'->'Bob'). (#'employee-number'- >>>>>>>>>> 'A0000'). (#'family-name'->'Gates')}). >>>>>>>> >>>>>>>> Very right. My mistake. But wouldn't an asSortedCollection do >>>>>>>> the thing? Do you not test the size of the array. >>>>>>>> >>>>>>>>> This is not the best way to do because the check is only in >>>>>>>>> one direction but for this test it is ok. Somehow the second >>>>>>>>> assert fails and I have to check what is going on here. >>>>>>>> >>>>>>>> Yeah, my mistake. Sorry. The elements may be differently >>>>>>>> ordered. Would a asSortedCollection help? >>>>>>>> >>>>>>>> I have now granted you an access to the repository. You should >>>>>>>> be able to directly commit in it. >>>>>>>> >>>>>>>> Jaayer, what is your Squeaksource account? >>>>>>>> >>>>>>>> Cheers, >>>>>>>> Alexandre >>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> On 28.02.2010, at 02:01, Alexandre Bergel wrote: >>>>>>>>> >>>>>>>>>>> thanks for now. I did a first merge attempt. It will be >>>>>>>>>>> quite a bit of work. For me the xml parser is an important >>>>>>>>>>> component. With the newest changes it became biased towards >>>>>>>>>>> pharo. There are things like ClassTestCase, Unicode >>>>>>>>>>> CharacterSet. These are for sure improvements/changes in >>>>>>>>>>> pharo you like to use. But they make porting a lot more >>>>>>>>>>> difficult. I would be glad if we could find some way to >>>>>>>>>>> lower the porting barrier. The necessary class I could put >>>>>>>>>>> in the squeak compat package in gemstone. But then the xml >>>>>>>>>>> parser will depend on the squeak package which I don't like. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Hi Norbert, >>>>>>>>>> >>>>>>>>>> XMLParser effectively depends on Squeak specific classes. I >>>>>>>>>> wrote a small script that identify the squeak classes used in >>>>>>>>>> XML-Support. Here is the list: LanguageEnvironment, Unicode, >>>>>>>>>> LocaleID, CharacterSet >>>>>>>>>> >>>>>>>>>> I guess that porting the whole multilingual support may not >>>>>>>>>> be that easy. The tag xml:lang is used to select the proper >>>>>>>>>> support. It should be easy for you to ignore it I guess. >>>>>>>>>> >>>>>>>>>> CharacterSet seems to be one that has to be ported. It is not >>>>>>>>>> a big class. It depends on WideCharacterSet. I am not sure >>>>>>>>>> whether this is useful in your case however. >>>>>>>>>> >>>>>>>>>> Cheers, >>>>>>>>>> Alexandre >>>>>>>>>> >>>>>>>>>> -- >>>>>>>>>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >>>>>>>>>> Alexandre Bergel http://www.bergel.eu >>>>>>>>>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >>>>>>>> Alexandre Bergel http://www.bergel.eu >>>>>>>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>>> -- >>>>>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >>>>>> Alexandre Bergel http://www.bergel.eu >>>>>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>> >>>> >>>> -- >>>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >>>> Alexandre Bergel http://www.bergel.eu >>>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >>>> >>>> >>>> >>>> >>>> >>> >> >> -- >> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >> Alexandre Bergel http://www.bergel.eu >> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > _______________________________________________ > Moose-dev mailing list > [hidden email] > https://www.iam.unibe.ch/mailman/listinfo/moose-dev -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. _______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
|
|
---- On Tue, 09 Mar 2010 03:09:55 -0800 Alexandre Bergel <[hidden email]> wrote ---- >Jaayer, some methods are now deprecated. For example >#forwardToDeprecatedHandler:withArgumentOrder:orTo: says to 'use >startElement:attributes: instead' >But the sender of this fonction #forward... are in SAX itself. > >I guess all these calls need to be updated? Normally when you want to deprecate a method and discourage people from using it you need only insert a "self deprecated: description" line into it. When someone invokes such a method, they receive a warning of its deprecation listing specifically its name and class. I wanted to rename some of the handler messages in SAXHandler so they would be more consistent with each other (note, for example, the different argument order between #startElement:namespaceURI:namesapce- and #endElement:namespace:namespaceURI-) and also with other parts of the API (-attributeList: vs. -atttributes:). Unfortunately, there is no easy way to deprecate such messages. Users do not send them; instead they override them in subclasses and expect the overridden versions to be invoked by SAXDriver. Another problem is that the handlers must degrade in a specific order, with each form invoking the one taking the most arguments after it until the one taking the fewest arguments (e.g., #startElement:attributes:) is reached. That unusual #forwardToDeprecatedHandler:withArgumentOrder:orTo: message you discovered is the ad hoc solution. In renamed handlers it checks to see if the old, deprecated version is implemented in the class of the receiver and if it is, warns that it has been deprecated and suggests using the new form--the caller--prior to invoking the old form with the caller's arguments (reordered if needed). If the deprecated version is not present, then it either degrades in the normal fashion, invoking the version taking next-most arguments after itself (which may also check for a deprecated version of itself) or do nothing if no other handler needs to be invoked. >> >> The most recent version is completely string-based. The performance >> of the symbol-based predecessors was erratic; it would be terribly >> slow at first in a clean image and improve only after saving the >> image at least once. Even then my tests indicated that a purely >> string-based version would be faster. This is likely due to the >> initial overhead of interning symbols and then the subsequent >> overhead of looking them up. I did honestly prefer the #symbol >> syntax for naming things, but considering that the things so-named >> and the names themselves all begin life (from the tokenizer) as >> strings, it makes more sense (and requires less code) to keep them >> that way. It is also more portable, as we no longer need assume that >> Symbol is a subclass of String. I don't think this will cause issues >> in Squeak/Pharo code, as both systems (for now) assume #name = >> 'name'. Hopefully it will not cause too much trouble for Norbert. >> >> Alexandre, you should see an improvement in your benchmarks now. > >Indeed! >Cool! > >Alexandre > >> >>>>>> anElement attributes class (I wrote species but that will fail in >>>>>> gemstone too I guess. Hell!) >>>>> >>>>> I just committed with species. Let me know. This is easy to adjust. >>>>> >>>> Ok. >>>> >>>>>>>> The gemstone XML Parser decides somehow to use >>>>>>>> IdentityDictionary internally. I think this should be allowed. I >>>>>>>> just changed Dictionary to IdentityDictionary so the = test >>>>>>>> reflects the right type. If you change it it is clear that it >>>>>>>> fails. Because pharo uses Dictionary internally. So you might >>>>>>>> see that it is not a question of using Dictionary or >>>>>>>> IdentityDictionary but a question of the wrongness of using = >>>>>>> >>>>>>> How the XMLNodeTest should look like to accommodate your >>>>>>> situation? >>>>>>> >>>>>> I need to recheck this. The problem is really that the XML Parser >>>>>> creatios instances of class Association but { #key->'value' } >>>>>> creates an instance of class SymbolAssociation. That means I would >>>>>> know how to fix the test but I want to understand the implications >>>>>> of all of this. I'll get to you if I know anything new. >>>>> >>>>> Ok. >>>>> >>>> My mail to the gemstone list led to a ticket about removing class >>>> checks from Association. That would be easing the handling a lot. >>>> >>>> Norbert >>>>>> >>>>>> >>>>>>> Alexandre >>>>>>> >>>>>>>> >>>>>>>>>> Here there is an assumption about the allAttributes collection >>>>>>>>>> while using = as comparsion. But there is also an assumption >>>>>>>>>> about the order of the content. I changed this to >>>>>>>>>> >>>>>>>>>> self assert: (firstPerson allAttributes includesAllOf: >>>>>>>>>> #(#'first-name' #'employee-number' #'family-name')). >>>>>>>>>> self assert: (firstPerson allAttributeAssociations asArray >>>>>>>>>> includesAllOf: {(#'first-name'->'Bob'). (#'employee-number'- >>>>>>>>>>> 'A0000'). (#'family-name'->'Gates')}). >>>>>>>>> >>>>>>>>> Very right. My mistake. But wouldn't an asSortedCollection do >>>>>>>>> the thing? Do you not test the size of the array. >>>>>>>>> >>>>>>>>>> This is not the best way to do because the check is only in >>>>>>>>>> one direction but for this test it is ok. Somehow the second >>>>>>>>>> assert fails and I have to check what is going on here. >>>>>>>>> >>>>>>>>> Yeah, my mistake. Sorry. The elements may be differently >>>>>>>>> ordered. Would a asSortedCollection help? >>>>>>>>> >>>>>>>>> I have now granted you an access to the repository. You should >>>>>>>>> be able to directly commit in it. >>>>>>>>> >>>>>>>>> Jaayer, what is your Squeaksource account? >>>>>>>>> >>>>>>>>> Cheers, >>>>>>>>> Alexandre >>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On 28.02.2010, at 02:01, Alexandre Bergel wrote: >>>>>>>>>> >>>>>>>>>>>> thanks for now. I did a first merge attempt. It will be >>>>>>>>>>>> quite a bit of work. For me the xml parser is an important >>>>>>>>>>>> component. With the newest changes it became biased towards >>>>>>>>>>>> pharo. There are things like ClassTestCase, Unicode >>>>>>>>>>>> CharacterSet. These are for sure improvements/changes in >>>>>>>>>>>> pharo you like to use. But they make porting a lot more >>>>>>>>>>>> difficult. I would be glad if we could find some way to >>>>>>>>>>>> lower the porting barrier. The necessary class I could put >>>>>>>>>>>> in the squeak compat package in gemstone. But then the xml >>>>>>>>>>>> parser will depend on the squeak package which I don't like. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Hi Norbert, >>>>>>>>>>> >>>>>>>>>>> XMLParser effectively depends on Squeak specific classes. I >>>>>>>>>>> wrote a small script that identify the squeak classes used in >>>>>>>>>>> XML-Support. Here is the list: LanguageEnvironment, Unicode, >>>>>>>>>>> LocaleID, CharacterSet >>>>>>>>>>> >>>>>>>>>>> I guess that porting the whole multilingual support may not >>>>>>>>>>> be that easy. The tag xml:lang is used to select the proper >>>>>>>>>>> support. It should be easy for you to ignore it I guess. >>>>>>>>>>> >>>>>>>>>>> CharacterSet seems to be one that has to be ported. It is not >>>>>>>>>>> a big class. It depends on WideCharacterSet. I am not sure >>>>>>>>>>> whether this is useful in your case however. >>>>>>>>>>> >>>>>>>>>>> Cheers, >>>>>>>>>>> Alexandre >>>>>>>>>>> >>>>>>>>>>> -- >>>>>>>>>>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >>>>>>>>>>> Alexandre Bergel http://www.bergel.eu >>>>>>>>>>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>>> -- >>>>>>>>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >>>>>>>>> Alexandre Bergel http://www.bergel.eu >>>>>>>>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>>> -- >>>>>>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >>>>>>> Alexandre Bergel http://www.bergel.eu >>>>>>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>> >>>>> -- >>>>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >>>>> Alexandre Bergel http://www.bergel.eu >>>>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >>>>> >>>>> >>>>> >>>>> >>>>> >>>> >>> >>> -- >>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >>> Alexandre Bergel http://www.bergel.eu >>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >> _______________________________________________ >> Moose-dev mailing list >> [hidden email] >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev > >-- >_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >Alexandre Bergel http://www.bergel.eu >^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > >_______________________________________________ >Moose-dev mailing list >[hidden email] >https://www.iam.unibe.ch/mailman/listinfo/moose-dev > Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
|
|
In reply to this post by jaayer
On 09.03.2010, at 10:43, jaayer wrote: > The most recent version is completely string-based. The performance of the symbol-based predecessors was erratic; it would be terribly slow at first in a clean image and improve only after saving the image at least once. Even then my tests indicated that a purely string-based version would be faster. This is likely due to the initial overhead of interning symbols and then the subsequent overhead of looking them up. I did honestly prefer the #symbol syntax for naming things, but considering that the things so-named and the names themselves all begin life (from the tokenizer) as strings, it makes more sense (and requires less code) to keep them that way. It is also more portable, as we no longer need assume that Symbol is a subclass of String. I don't think this will cause issues in Squeak/Pharo code, as both systems (for now) assume #name = 'name'. Hopefully it will not cause too much trouble for Norbert. I don't think it is a big problem. The other way round I had to check all over the place that symbols are created before requested as name at the xml classes. In gemstone it is even the case that #key->'value' creates an object of class SymbolAssociation and testing equality is checking for class identity as well (unlike isKindOf: in squeak/pharo). It took me a while to solve some of the failing tests just because of this. While my feeling tells me that symbols would be the appropriate thing to use it seems they are just to troublesome. Regarding the "shortlivedness" of a DOM the effort of converting to symbols is hard to justify. I'm planning to incorporate the latest changes by next week. I'll start complaining if I hit another wall. thanks for your work (and the tests!) Norbert _______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
|
|
> I don't think it is a big problem. The other way round I had to
> check all over the place that symbols are created before requested > as name at the xml classes. In gemstone it is even the case that > #key->'value' creates an object of class SymbolAssociation and > testing equality is checking for class identity as well (unlike > isKindOf: in squeak/pharo). It took me a while to solve some of the > failing tests just because of this. > While my feeling tells me that symbols would be the appropriate > thing to use it seems they are just to troublesome. Regarding the > "shortlivedness" of a DOM the effort of converting to symbols is > hard to justify. > > I'm planning to incorporate the latest changes by next week. I'll > start complaining if I hit another wall. Sure, no problem > thanks for your work (and the tests!) I plan to integrate the one Michael sent me. I hope to do it soon. Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. _______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
«
Return to Moose
|
1 view|%1 views
| Free forum by Nabble | Edit this page |