On 30 May 2010 19:31, Mike Caron <[email protected]> wrote:
> On 30/05/2010 3:19 AM, Ralph Versteegen wrote:
>>
>> On 30 May 2010 19:08, Mike Caron<[email protected]> wrote:
>>>
>>> On 30/05/2010 3:02 AM, Ralph Versteegen wrote:
>>>>
>>>> On 30 May 2010 18:37, Mike Caron<[email protected]> wrote:
>>>>>
>>>>> On 30/05/2010 2:33 AM, [email protected] wrote:
>>>>>>
>>>>>> teeemcee
>>>>>> 2010-05-29 23:33:46 -0700 (Sat, 29 May 2010)
>>>>>> 134
>>>>>> Converted Reload.SerializeBin to use BufferedFile instead of stdio
>>>>>> FILEs.
>>>>>>
>>>>>> It now runs nearly 400 times faster on that 64MB test case.
>>>>>> ---
>>>>>> U wip/makereload.bat
>>>>>> U wip/makereload.sh
>>>>>> U wip/reload.bas
>>>>>> U wip/util.bas
>>>>>
>>>>> You win! No one will ever be able to match 8 commits in the space of 17
>>>>> seconds!
>>>>>
>>>>> When I check out what you've done, I will comment on something
>>>>> relevant.
>>>>>
>>>>> --
>>>>> Mike
>>>>
>>>> Git is great. I have some HSpeak/script debugger work I could have
>>>> finished off and committed in several parts as well, but I'll leave it
>>>> for another day.
>>>
>>> Ah, you lazy git. That explains it. ;)
>>>
>>>> I meant to say somewhere: maybe you want to modify SerializeXML so
>>>> that it outputs valid XML (eg, print<> as<NULL> and<foo ="2">
>>>> as
>>>> <foo value="2">, and make xml2reload translate back) or whatever, I
>>>> left that up to you. I mostly changed it because it was misprinting
>>>> slicetrees.
>>>
>>> I'm not sure what to do in the face of null nodes, since<> and<NULL>
>>> are
>>> not the same thing. I'm not even sure than a Node with no name is even
>>> legal
>>> (it's quite possibly undefined).
>>
>> According to emacs' builtin XML validator (ha) it's not legal in XML,
>> but it's certainly legal in RELOAD. (Not sure which you're wondering.)
>
> I meant in RELOAD. I know it's possible in RELOAD, but I never really gave
> it any thought. And, I see that I optimized this case...
>
>>> I don't agree with the change to nodes with both values and children. The
>>> exact XML representation of that is:
>>>
>>> <node>
>>> value
>>> <children />
>>> <children />
>>> <children />
>>> </node>
>>
>> I'm not sure that's exact. What is
>>
>> <node>
>> value
>> <children />
>> othervalue
>> <children />
>> </node>
>
> Technically, the structure in XML is:
>
> <node>
> <xml:text>value</xml:text>
> <children />
> <xml:text>othervalue</xml:text>
> <children />
> </node>
>
> If you recall way back, this was the way RELOAD was going to work: A node
> could have children, or data, not both.
>
>> I made that change to avoid confusion between<node
>> ="foo"><b>bar</b></node> and what you get after running
>> "<node>foo<b>bar</b></node>" through xml2reload. Although admittedly
>> the --debug option I added to reload2xml is enough to distinguish
>> those two.
>
> I'm not really sure what the difference would be, assuming I'm interpreting
> your ="foo" notation correctly.
Representing <RELOAD Nodes>, it is:
<name="node" content="foo" children={
<name="b" content="bar">
}>
vs.
<name="node" children={
<name="" content="foo">
<name="b" content="bar">
}>
>>> I don't believe in magic attributes or node names, so if I were going to
>>> do
>>> that, I'd spit them out as:
>>>
>>> <rootnodewhatever xmlns:RELOAD="http://someurlthatIhaventdecidedyet.com";>
>>> ...
>>> <RELOAD:null />
>>> </rootnodewhatever>
>>
>> You lost me. Would this actually be useful (OK, so I suggested it in
>> the first place, so what)
>
> I meant, stick any magic attributes and nodes in a namespace to avoid
> misinterpreting a document which contains those names.
>
>>> I'm not sure that I want to commit to doing this yet, as I'm working on
>>> another big project with my spare time... Maybe soon though. If I become
>>> inspired.
>>> --
>>> Mike
>>
>> And I was meant to be working on term projects and assignments instead
>> of RELOAD.
>> _______________________________________________
>> Ohrrpgce mailing list
>> [email protected]
>> http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
>
>
> --
> Mike
> _______________________________________________
> Ohrrpgce mailing list
> [email protected]
> http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
>
_______________________________________________
Ohrrpgce mailing list
[email protected]
http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
