4 Mar
2010
4 Mar
'10
9:35 p.m.
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 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
Ok.
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 Bergel http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
> 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. 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.
> 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. 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
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.