vtd-xml-users

Re: [Vtd-xml-users] Random Access Proposal (take 2)

[Jimmy Z. <cra...@co...>]

Give me a few days to come up with a proposal/draft and I will
send you guys URL...
----- Original Message ----- 
From: "Rodrigo Cunha" <rn...@gm...>
To: "Mark Swanson" <ma...@Sc...>; "Jimmy Zhang" 
<cra...@co...>
Cc: <vtd...@li...>
Sent: Tuesday, March 06, 2007 8:24 AM
Subject: Re: [Vtd-xml-users] Random Access Proposal (take 2)


> Hum, thanks for the hint also Mark. I normally use java.util collections, 
> but i'll give fastutils a look, since they might be better for some of my 
> problems.
>
> Jimmy, a context can be imported/exported as an array of integers, this 
> being a bit raw perhaps... and leaving the programmer with the job of 
> storing that array. I just created SimpleContext as a way of abstracting 
> that implementation detail, but since you like performance, perhaps you 
> could leave that raw. I still prefer the abstracted version... besides, 
> the internal representation might change and the abstracted version would 
> still work.
>
> So, yes, go ahead with my API even if you decide to change it later.
>
> Just as a little silly footnote I found my API is also useful in cases 
> where you have:
>
> push();
> // do something
> pop();
> push();
> // do something
> pop();
> push();
> // do something
> pop();
> push();
> // do something
> pop();
>
> Can be abreviated to:
>
> setCtxFromNav(ctx);
> // do something
> setNavFromCtx(ctx);
> // do something
> setNavFromCtx(ctx);
> // do something
> setNavFromCtx(ctx);
> // do something
> setNavFromCtx(ctx);
>
> This is both faster and more readable.
>
> It's also useful for things like:
>
> xpto = getComplexToFindTransmissionPath(VTDNav n, String s); // might even 
> use caching!
> push();
> nav.setNavFromCtx(xpto);
> // Do something
> pop();
>
> and also for exception handling:
>
> {
> setCtxFromNav(xpto);
> // do something complex and error-prone,
> // so I won't use the stack, but a few locally declared contexts instead
> // oops! crash! go to handler!
> finally {
>    setNavFromCtx(xpto)
>    // we are now clean
> }
>
> So, it made using VTD much more enjoyable to me, even in rather trivial 
> situations.
>
> Mark Swanson wrote:
>> Jimmy Zhang wrote:
>>>
>>>> Just a FYI: I have cases where the key is an Integer, and cases where
>>>> it's a string.
>>>
>>> By Integer is it a java class? or just a primitive data type? Maybe I 
>>> can
>>> modify Rodrigo's class and put it into CVS so you guys can use 
>>> immediately...
>>> however, I can't guarantee that it will be included in the next 
>>> release...
>>> Would that work?
>>
>> Oh, I always use native ints and fastutil wherever possible.
>>
>> Just a thought: I use autojar on my code to build a tiny fastutil jar 
>> that just has the code I need. You could do the same thing to get 
>> excellent native collections instead of writing your own. I see you 
>> already wrote your own, but in case you need more.. Fastutil uses the 
>> LGPL.
>>
>> Cheers.
>>
>
> 

Re: [Vtd-xml-users] Random Access Proposal (take 2)

[Jimmy Z. <cra...@co...>]

Rodrigo, How about add a method (tentatively called set()) that basically
does pop() and push() in one shot , so your
example

 push();
 // do something
 pop();
 push();
 // do something
 pop();
 push();
 // do something
 pop();
 push();
 // do something
 pop();

becomes

push();
// do something
set();
// do something
set();
// do something
set();
// do something
pop();


----- Original Message ----- 
From: "Rodrigo Cunha" <rn...@gm...>
To: "Mark Swanson" <ma...@Sc...>; "Jimmy Zhang" 
<cra...@co...>
Cc: <vtd...@li...>
Sent: Tuesday, March 06, 2007 9:24 AM
Subject: Re: [Vtd-xml-users] Random Access Proposal (take 2)


> Hum, thanks for the hint also Mark. I normally use java.util collections, 
> but i'll give fastutils a look, since they might be better for some of my 
> problems.
>
> Jimmy, a context can be imported/exported as an array of integers, this 
> being a bit raw perhaps... and leaving the programmer with the job of 
> storing that array. I just created SimpleContext as a way of abstracting 
> that implementation detail, but since you like performance, perhaps you 
> could leave that raw. I still prefer the abstracted version... besides, 
> the internal representation might change and the abstracted version would 
> still work.
>
> So, yes, go ahead with my API even if you decide to change it later.
>
> Just as a little silly footnote I found my API is also useful in cases 
> where you have:
>
> push();
> // do something
> pop();
> push();
> // do something
> pop();
> push();
> // do something
> pop();
> push();
> // do something
> pop();
>
> Can be abreviated to:
>
> setCtxFromNav(ctx);
> // do something
> setNavFromCtx(ctx);
> // do something
> setNavFromCtx(ctx);
> // do something
> setNavFromCtx(ctx);
> // do something
> setNavFromCtx(ctx);
>
> This is both faster and more readable.
>
> It's also useful for things like:
>
> xpto = getComplexToFindTransmissionPath(VTDNav n, String s); // might even 
> use caching!
> push();
> nav.setNavFromCtx(xpto);
> // Do something
> pop();
>
> and also for exception handling:
>
> {
> setCtxFromNav(xpto);
> // do something complex and error-prone,
> // so I won't use the stack, but a few locally declared contexts instead
> // oops! crash! go to handler!
> finally {
>    setNavFromCtx(xpto)
>    // we are now clean
> }
>
> So, it made using VTD much more enjoyable to me, even in rather trivial 
> situations.
>
> Mark Swanson wrote:
>> Jimmy Zhang wrote:
>>>
>>>> Just a FYI: I have cases where the key is an Integer, and cases where
>>>> it's a string.
>>>
>>> By Integer is it a java class? or just a primitive data type? Maybe I 
>>> can
>>> modify Rodrigo's class and put it into CVS so you guys can use 
>>> immediately...
>>> however, I can't guarantee that it will be included in the next 
>>> release...
>>> Would that work?
>>
>> Oh, I always use native ints and fastutil wherever possible.
>>
>> Just a thought: I use autojar on my code to build a tiny fastutil jar 
>> that just has the code I need. You could do the same thing to get 
>> excellent native collections instead of writing your own. I see you 
>> already wrote your own, but in case you need more.. Fastutil uses the 
>> LGPL.
>>
>> Cheers.
>>
>
> 

Re: [Vtd-xml-users] Random Access Proposal (take 2)

[Jimmy Z. <cra...@co...>]

Cool!
----- Original Message ----- 
From: "Rodrigo Cunha" <rn...@gm...>
To: "Jimmy Zhang" <cra...@co...>
Cc: "Mark Swanson" <ma...@Sc...>; 
<vtd...@li...>
Sent: Thursday, March 29, 2007 3:10 AM
Subject: Re: [Vtd-xml-users] Random Access Proposal (take 2)


> Jimmy,
>
> getNavigator would be used in some of my code to avoid passing yet another 
> parameter to methods, I just don't use it right now because my bookmark 
> class does not keep the navigator reference. If it did I would use it 
> right away.
>
> Also the method is so simple no one would be confused. Why hide this 
> rather obvious feature?
>
> This works just like the Pattern class in Java: you create it using a 
> string, and later if you really want to get the string back you also can, 
> since it's probably there in the class anyway.  Only that is useless, and 
> this feature is useful.
>
> getNavigator: returns the navigator to witch the bookmark is bound, 
> otherwise returns null.
>
> I can test the implementation, sure. Just give me a few days :-)
>
> Also, I'll include the rather trivial getNavigator in the test, ok?
>
> Jimmy Zhang wrote:
>> Yes, BookMark will go into the next release as an experimental
>> feature ... with more user feedback/discussion, we can officially
>> introduce it later
>>
>> regarding getNavigator().. if  non-critical, I prefer to keep it
>> out for now... if we keep it in, then later decide to drop it,
>> it will break people's code... so it is easier to add a method than
>> taking it out... plus one less method makes the documentation shorter
>> and a bit less confusing ...
>>
>> regarding equals() and hashCode(), the methods are there, we
>> can alway change the implementation...
>>
>> In the meantime, could you give the implementation a bit testing?
>>
>>
>> ----- Original Message ----- From: "Rodrigo Cunha" <rn...@gm...>
>> To: "Jimmy Zhang" <cra...@co...>
>> Cc: "Mark Swanson" <ma...@Sc...>; 
>> <vtd...@li...>
>> Sent: Wednesday, March 28, 2007 3:16 AM
>> Subject: Re: [Vtd-xml-users] Random Access Proposal (take 2)
>>
>>
>>> Hi!
>>>
>>> The getNavigator() method might spare some parameter passing, since if 
>>> I'm gona pass a bookmark around to another object I'll need to pass the 
>>> navigator also, somehow. It's not critical, but since it can be done 
>>> trivially, why not? Also, being able to ask the bookmark "hey you, to 
>>> witch navigator do you belong?" seems the phylosophically correct thing 
>>> to do.
>>>
>>> equals() and hashCode() are religious issues, just keep them your way 
>>> :-)
>>>
>>> A hashCode function should ideally spread the input amongst all the 
>>> hashcodes space, since collections using hashcodes might, or might not, 
>>> use all bits in the hashcode. But just don't bother with that.
>>>
>>> Jimmy Zhang wrote:
>>>> Rodrigo, I just checked in a quick update into CVS
>>>>
>>>> Regarding some of prior comments, my questions are
>>>>
>>>> 1. When would a user call getNavigator() any way? I kinda had
>>>> a tough time coming up the scenario...
>>>>
>>>> 2. Regarding equals(), I think that the current bookMark implementation
>>>> should be fine in that the only time two bookMark instances are equal
>>>> is when they contains node position of the same VTDNav instance, and
>>>> the node indices are equal...
>>>>
>>>> 3.  I am still not sure about hashCode, what is the purpose of the 
>>>> spread?
>>>> For the current implementation, there will never be colision for the 
>>>> bookmarks
>>>> corresponding to the same document (the node index is ideal)...
>>>>
>>>> Let me know your thoughts..
>>>> Regards,
>>>> jimmy
>>>>
>>>
>>>
>>
>>
>>
>
> 

Re: [Vtd-xml-users] Random Access Proposal (take 2)

[Jimmy Z. <cra...@co...>]

What if a bookmark object is created, but not yet bind to 
a  non-null VTDNav object...

recordCursorPosition() and setCursorPosition() would throw
NullPointerException.. would that bother you?
----- Original Message ----- 
From: "Rodrigo Cunha" <rn...@gm...>
To: "Jimmy Zhang" <cra...@co...>
Sent: Wednesday, April 04, 2007 3:00 AM
Subject: Re: [Vtd-xml-users] Random Access Proposal (take 2)


> Jimmy Zhang wrote:
>> I just added getNav() and checked into CVS... anything else
>> you have in mind?
> 
> Yes:
> 
> unbind(), or bind(vn) accepting null, but I think unbind is better, 
> leads to less errors.
> 
> recordCursorPosition() with no parameters
> 
> equivalent to xpto.recordCursorPosition(xpto.getNav()); but more elegant 
> and faster, especially if directly implemented with less checks.
> 
> setCursorPosition() with no parameters
> equivalent to xpto.setCursorPosition(xpto.getNav()); but more elegant 
> and faster, especially if directly implemented with less checks.
> 
> 
> Cheers,
> 
> Rodrigo
>

Re: [Vtd-xml-users] Random Access Proposal (take 2)

[Jimmy Z. <cra...@co...>]

setCursorPosition() and getCursroPosition() have been added in CVS

but the benefit of unbind() is still not clear

if GC of VTDnav is the goal then one can simply call "setCursorPosition()" 
on
a different VTDNav object and the mission is accomplished without having a
unbind method for bookMark...


----- Original Message ----- 
From: "Rodrigo Cunha" <rn...@gm...>
To: "Jimmy Zhang" <cra...@co...>
Sent: Thursday, April 05, 2007 2:41 AM
Subject: Re: [Vtd-xml-users] Random Access Proposal (take 2)


> Jimmy Zhang wrote:
>
> > What if a bookmark object is created, but not yet bind to a  non-null
> VTDNav object...
>
> That's for unbind, right? The unbind rationale is to allow GC of VTDNav 
> objects while still allowing easy reusing of bookmark. Obviously you could 
> bind them to a dummy VTDNav instead, but that's a kludge, and requires 
> more processing. Or you could allow binding to null, but that could lead 
> to unnoticed errors.
>
> > recordCursorPosition() and setCursorPosition() would throw
> NullPointerException.. would that bother you?
>
> No, that's what would happen really, and seems perfectly correct.
>
> --
> Rodrigo
>
> 

Re: [Vtd-xml-users] Random Access Proposal (take 2)

[Rodrigo C. <rn...@gm...>]

Sorry about the delay but I've been sick with a nasty upper respiratory 
tract infection ... back to work now!

Yes, you're right, I can bind to another VTDNav object, but that sounds 
like a kludge when the objective is really unbinding, and may imply 
internal bufer allocation inside the bookmark object if the depth increases.


Jimmy Zhang wrote:
> setCursorPosition() and getCursroPosition() have been added in CVS
>
> but the benefit of unbind() is still not clear
>
> if GC of VTDnav is the goal then one can simply call 
> "setCursorPosition()" on
> a different VTDNav object and the mission is accomplished without 
> having a
> unbind method for bookMark...
>
>
> ----- Original Message ----- From: "Rodrigo Cunha" <rn...@gm...>
> To: "Jimmy Zhang" <cra...@co...>
> Sent: Thursday, April 05, 2007 2:41 AM
> Subject: Re: [Vtd-xml-users] Random Access Proposal (take 2)
>
>
>> Jimmy Zhang wrote:
>>
>> > What if a bookmark object is created, but not yet bind to a  non-null
>> VTDNav object...
>>
>> That's for unbind, right? The unbind rationale is to allow GC of 
>> VTDNav objects while still allowing easy reusing of bookmark. 
>> Obviously you could bind them to a dummy VTDNav instead, but that's a 
>> kludge, and requires more processing. Or you could allow binding to 
>> null, but that could lead to unnoticed errors.
>>
>> > recordCursorPosition() and setCursorPosition() would throw
>> NullPointerException.. would that bother you?
>>
>> No, that's what would happen really, and seems perfectly correct.
>>
>> -- 
>> Rodrigo
>>
>>
>
>
>

Re: [Vtd-xml-users] Random Access Proposal (take 2)

[Jimmy Z. <cra...@co...>]

If the goal of unbinding is not for reuse, then it is reasonable that
there is no need for unbinding.. in other words, if you don't want
a bookmark object to bind to another VTDNav object, then
it is very likely that it is the end of the application, and those bookmarks
should be gc'ed ... any comment?

----- Original Message ----- 
From: "Rodrigo Cunha" <rn...@gm...>
To: "Jimmy Zhang" <cra...@co...>
Cc: <vtd...@li...>
Sent: Monday, April 16, 2007 2:14 AM
Subject: Re: [Vtd-xml-users] Random Access Proposal (take 2)


> Sorry about the delay but I've been sick with a nasty upper respiratory 
> tract infection ... back to work now!
>
> Yes, you're right, I can bind to another VTDNav object, but that sounds 
> like a kludge when the objective is really unbinding, and may imply 
> internal bufer allocation inside the bookmark object if the depth 
> increases.
>
>
> Jimmy Zhang wrote:
>> setCursorPosition() and getCursroPosition() have been added in CVS
>>
>> but the benefit of unbind() is still not clear
>>
>> if GC of VTDnav is the goal then one can simply call 
>> "setCursorPosition()" on
>> a different VTDNav object and the mission is accomplished without having 
>> a
>> unbind method for bookMark...
>>
>>
>> ----- Original Message ----- From: "Rodrigo Cunha" <rn...@gm...>
>> To: "Jimmy Zhang" <cra...@co...>
>> Sent: Thursday, April 05, 2007 2:41 AM
>> Subject: Re: [Vtd-xml-users] Random Access Proposal (take 2)
>>
>>
>>> Jimmy Zhang wrote:
>>>
>>> > What if a bookmark object is created, but not yet bind to a  non-null
>>> VTDNav object...
>>>
>>> That's for unbind, right? The unbind rationale is to allow GC of VTDNav 
>>> objects while still allowing easy reusing of bookmark. Obviously you 
>>> could bind them to a dummy VTDNav instead, but that's a kludge, and 
>>> requires more processing. Or you could allow binding to null, but that 
>>> could lead to unnoticed errors.
>>>
>>> > recordCursorPosition() and setCursorPosition() would throw
>>> NullPointerException.. would that bother you?
>>>
>>> No, that's what would happen really, and seems perfectly correct.
>>>
>>> -- 
>>> Rodrigo
>>>
>>>
>>
>>
>>
>
> 

Re: [Vtd-xml-users] Random Access Proposal (take 2)

[Jimmy Z. <cra...@co...>]

I see... in last email you asked why VTD-XML 1.0 contains 
the bookmark class that you described ... actually this question
was very much part of the discussion early on around 1.0 release...
The reason is that, if you care to dig into VTD-XML's XPath release..
you will find that the bookmark class is not necessary to implement
the entire XPath 1.0 spec... that kinda shifted our decision towards 
not offering this feature...
besides the design of the core VTD-XML API (especially methods
within VTDNav) needs to be well-thought  out as it is something 
that affects every VTD-XML user...Let me think about this a bit more 
on how to address this issue that you raised.. one way may be to implement
this feature in an added-on module...

----- Original Message ----- 
From: "Rodrigo Cunha" <rn...@gm...>
To: "Jimmy Zhang" <cra...@co...>
Cc: <vtd...@li...>
Sent: Monday, March 05, 2007 3:39 PM
Subject: Re: [Vtd-xml-users] Random Access Proposal (take 2)


>I keep them in a HashMap, for example, or in a TreeMap, etc... rarely on 
> a simple list.
> 
> The key is generally a string I would need to get in more or less 
> convoluted ways from the node during a sequencial search. The node 
> itself contains a lot more info I only want to retrieve in the future if 
> it's needed, or else I would cache the info itself  :-D
> 
> If instead of keeping a context I can keep a simple integer and then 
> order a VTDNav "hey you, get this integer you told me to keep and go to 
> node you bookmarked" I would say it's ok, if the operation "get to the 
> node" is fast.
> 
> So, you're suggesting an API that would work like this:
> 
> RandomNodeRecorder xpto = new RandomNodeRecorder(navigator);
> // xpto is the bookmark keeper organized in a way Jimmy likes :-)
> int mark = xpto.keepPos();
> /* do some stuff here */
> boolean xpto.fetchPos(mark); // back to the bookmarked node
> xpto.del(mark); // don't need the mark any longer
> 
> I still fail to understand why shoudn't a context be kept outside the 
> structures you seem to like :-)
> 
> Memory is cheap, and for example, if I keep a hash of NEs, and each NE 
> occupies a few KB itself, it's irrelevant if I'm gona use a few more 
> bytes for each NE.
> 
> I'm not suggesting one should keep large structures containing any 
> single node in the document, ok? But the random access to a cached node 
> must be fast. I emphasize: fast random access to cached nodes.
> 
> As far as I understand the SimpleContext structure grows 4 bytes for 
> each depth level, so a deeper node consumes more space, right? So a 
> really deep node, let's say, at level 10, will consume 40 extra bytes, 
> plus the base consumption... that's 48 bytes, quite small, unless the 
> node is small and irrelevant.
> 
> --
> Rodrigo
> 
> Jimmy Zhang wrote:
>> Rodrigo, in one of the early emails you mentioned that
>> your app sometimes keeps thousands of those nodes (or context),
>> how do you tell them apart? There got to be some data
>> structures to store those context info, right?
>> What if it is implemented such that
>> 1. those contexts/nodes are stored in a linear buffer, which
>> is more space efficient than allocating individual objects
>> 2. You can address those nodes by using an integer, sort
>> like a VTD record...
>> would you consider the design outlined above can be useful
>> to your app?
>>
>> Jimmy
>

Re: [Vtd-xml-users] Random Access Proposal (take 2)

[Rodrigo C. <rn...@gm...>]

Hum, thanks for the hint also Mark. I normally use java.util 
collections,  but i'll give fastutils a look, since they might be better 
for some of my problems.

Jimmy, a context can be imported/exported as an array of integers, this 
being a bit raw perhaps... and leaving the programmer with the job of 
storing that array. I just created SimpleContext as a way of abstracting 
that implementation detail, but since you like performance, perhaps you 
could leave that raw. I still prefer the abstracted version... besides, 
the internal representation might change and the abstracted version 
would still work.

So, yes, go ahead with my API even if you decide to change it later.

Just as a little silly footnote I found my API is also useful in cases 
where you have:

push();
// do something
pop();
push();
// do something
pop();
push();
// do something
pop();
push();
// do something
pop();

Can be abreviated to:

setCtxFromNav(ctx);
// do something
setNavFromCtx(ctx);
// do something
setNavFromCtx(ctx);
// do something
setNavFromCtx(ctx);
// do something
setNavFromCtx(ctx);

This is both faster and more readable.

It's also useful for things like:

xpto = getComplexToFindTransmissionPath(VTDNav n, String s); // might 
even use caching!
push();
nav.setNavFromCtx(xpto);
// Do something
pop();

and also for exception handling:

{
setCtxFromNav(xpto);
// do something complex and error-prone,
// so I won't use the stack, but a few locally declared contexts instead
// oops! crash! go to handler!
finally {
    setNavFromCtx(xpto)
    // we are now clean
}

So, it made using VTD much more enjoyable to me, even in rather trivial 
situations.

Mark Swanson wrote:
> Jimmy Zhang wrote:
>>
>>> Just a FYI: I have cases where the key is an Integer, and cases where
>>> it's a string.
>>
>> By Integer is it a java class? or just a primitive data type? Maybe I 
>> can
>> modify Rodrigo's class and put it into CVS so you guys can use 
>> immediately...
>> however, I can't guarantee that it will be included in the next 
>> release...
>> Would that work?
>
> Oh, I always use native ints and fastutil wherever possible.
>
> Just a thought: I use autojar on my code to build a tiny fastutil jar 
> that just has the code I need. You could do the same thing to get 
> excellent native collections instead of writing your own. I see you 
> already wrote your own, but in case you need more.. Fastutil uses the 
> LGPL.
>
> Cheers.
>

[Vtd-xml-users] XPath tutorial

[Jimmy Z. <cra...@co...>]

Here is an article focuing exclusive on XPath aspect of VTD-XML...

Re: [Vtd-xml-users] XPath tutorial

[Jimmy Z. <cra...@co...>]

Sorry... Here is URL,
http://docs.google.com/Doc?id=dhdt7pxf_12g425c3

----- Original Message ----- 
From: "Jimmy Zhang" <cra...@co...>
To: <vtd...@li...>
Sent: Tuesday, March 13, 2007 6:37 PM
Subject: [Vtd-xml-users] XPath tutorial


> Here is an article focuing exclusive on XPath aspect of VTD-XML...
>
>
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share 
> your
> opinions on IT & business topics through brief surveys-and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> Vtd-xml-users mailing list
> Vtd...@li...
> https://lists.sourceforge.net/lists/listinfo/vtd-xml-users
> 

Re: [Vtd-xml-users] XPath tutorial

[Mark S. <ma...@Sc...>]

Jimmy Zhang wrote:
> Sorry... Here is URL,
> http://docs.google.com/Doc?id=dhdt7pxf_12g425c3

Nice article Jimmy.


-- 
http://www.ScheduleWorld.com/
Free Google Calendar synchronization with Outlook, Evolution,
cell phones, BlackBerry, PalmOS, Exchange, Mozilla, Thunderbird,
Pocket PC/Windows Mobile. Also sync tasks, notes and contacts!
WebDAV, vfreebusy, RSS, LDAP, iCalendar, iTIP, iMIP support.

Re: [Vtd-xml-users] XPath tutorial

[Jimmy Z. <cra...@co...>]

Thank... This is a preview of an article for DevX... there is another one 
"Index XML documents with VTD-XML" coming up ...


----- Original Message ----- 
From: "Mark Swanson" <ma...@Sc...>
To: "Jimmy Zhang" <cra...@co...>
Cc: <vtd...@li...>
Sent: Tuesday, March 13, 2007 8:22 PM
Subject: Re: [Vtd-xml-users] XPath tutorial


> Jimmy Zhang wrote:
>> Sorry... Here is URL,
>> http://docs.google.com/Doc?id=dhdt7pxf_12g425c3
> 
> Nice article Jimmy.
> 
> 
> -- 
> http://www.ScheduleWorld.com/
> Free Google Calendar synchronization with Outlook, Evolution,
> cell phones, BlackBerry, PalmOS, Exchange, Mozilla, Thunderbird,
> Pocket PC/Windows Mobile. Also sync tasks, notes and contacts!
> WebDAV, vfreebusy, RSS, LDAP, iCalendar, iTIP, iMIP support.
>

[Vtd-xml-users] latest benchmark numbers comparing C, C# and Java client/server JVM

[Jimmy Z. <cra...@co...>]

The latest piece on vtd-xml blog

http://vtd-xml.blogspot.com/2007/05/in-this-article-you-will-see-parsing.html 

Re: [Vtd-xml-users] Random Access Proposal (take 2)

[Rodrigo C. <rn...@gm...>]

Yes, that would be a nice add :-)

Wouldn't solve the exception handling or true random access issues 
tought, but would be a nice addon.

I propose "plup()" hehe

Jimmy Zhang wrote:
> Rodrigo, How about add a method (tentatively called set()) that basically
> does pop() and push() in one shot , so your
> example
>
> push();
> // do something
> pop();
> push();
> // do something
> pop();
> push();
> // do something
> pop();
> push();
> // do something
> pop();
>
> becomes
>
> push();
> // do something
> set();
> // do something
> set();
> // do something
> set();
> // do something
> pop();
>
>
> ----- Original Message ----- From: "Rodrigo Cunha" <rn...@gm...>
> To: "Mark Swanson" <ma...@Sc...>; "Jimmy Zhang" 
> <cra...@co...>
> Cc: <vtd...@li...>
> Sent: Tuesday, March 06, 2007 9:24 AM
> Subject: Re: [Vtd-xml-users] Random Access Proposal (take 2)
>
>
>> Hum, thanks for the hint also Mark. I normally use java.util 
>> collections, but i'll give fastutils a look, since they might be 
>> better for some of my problems.
>>
>> Jimmy, a context can be imported/exported as an array of integers, 
>> this being a bit raw perhaps... and leaving the programmer with the 
>> job of storing that array. I just created SimpleContext as a way of 
>> abstracting that implementation detail, but since you like 
>> performance, perhaps you could leave that raw. I still prefer the 
>> abstracted version... besides, the internal representation might 
>> change and the abstracted version would still work.
>>
>> So, yes, go ahead with my API even if you decide to change it later.
>>
>> Just as a little silly footnote I found my API is also useful in 
>> cases where you have:
>>
>> push();
>> // do something
>> pop();
>> push();
>> // do something
>> pop();
>> push();
>> // do something
>> pop();
>> push();
>> // do something
>> pop();
>>
>> Can be abreviated to:
>>
>> setCtxFromNav(ctx);
>> // do something
>> setNavFromCtx(ctx);
>> // do something
>> setNavFromCtx(ctx);
>> // do something
>> setNavFromCtx(ctx);
>> // do something
>> setNavFromCtx(ctx);
>>
>> This is both faster and more readable.
>>
>> It's also useful for things like:
>>
>> xpto = getComplexToFindTransmissionPath(VTDNav n, String s); // might 
>> even use caching!
>> push();
>> nav.setNavFromCtx(xpto);
>> // Do something
>> pop();
>>
>> and also for exception handling:
>>
>> {
>> setCtxFromNav(xpto);
>> // do something complex and error-prone,
>> // so I won't use the stack, but a few locally declared contexts instead
>> // oops! crash! go to handler!
>> finally {
>>    setNavFromCtx(xpto)
>>    // we are now clean
>> }
>>
>> So, it made using VTD much more enjoyable to me, even in rather 
>> trivial situations.
>>
>> Mark Swanson wrote:
>>> Jimmy Zhang wrote:
>>>>
>>>>> Just a FYI: I have cases where the key is an Integer, and cases where
>>>>> it's a string.
>>>>
>>>> By Integer is it a java class? or just a primitive data type? Maybe 
>>>> I can
>>>> modify Rodrigo's class and put it into CVS so you guys can use 
>>>> immediately...
>>>> however, I can't guarantee that it will be included in the next 
>>>> release...
>>>> Would that work?
>>>
>>> Oh, I always use native ints and fastutil wherever possible.
>>>
>>> Just a thought: I use autojar on my code to build a tiny fastutil 
>>> jar that just has the code I need. You could do the same thing to 
>>> get excellent native collections instead of writing your own. I see 
>>> you already wrote your own, but in case you need more.. Fastutil 
>>> uses the LGPL.
>>>
>>> Cheers.
>>>
>>
>>
>
>
>

Re: [Vtd-xml-users] Random Access Proposal (take 2)

[Jimmy Z. <cra...@co...>]

hmm...interesting... "plup" sounds like a tennis racket hitting the 
ground...
it may work :-)

Please take a look the file below and let me know what you think of it ...

http://vtd-xml.cvs.sourceforge.net/*checkout*/vtd-xml/ximple-dev/com/ximpleware/BookMark.java


----- Original Message ----- 
From: "Rodrigo Cunha" <rn...@gm...>
To: "Jimmy Zhang" <cra...@co...>
Cc: "Mark Swanson" <ma...@Sc...>; 
<vtd...@li...>
Sent: Wednesday, March 14, 2007 4:19 AM
Subject: Re: [Vtd-xml-users] Random Access Proposal (take 2)


> Yes, that would be a nice add :-)
>
> Wouldn't solve the exception handling or true random access issues tought, 
> but would be a nice addon.
>
> I propose "plup()" hehe
>
> Jimmy Zhang wrote:
>> Rodrigo, How about add a method (tentatively called set()) that basically
>> does pop() and push() in one shot , so your
>> example
>>
>> push();
>> // do something
>> pop();
>> push();
>> // do something
>> pop();
>> push();
>> // do something
>> pop();
>> push();
>> // do something
>> pop();
>>
>> becomes
>>
>> push();
>> // do something
>> set();
>> // do something
>> set();
>> // do something
>> set();
>> // do something
>> pop();
>>
>>
>> ----- Original Message ----- From: "Rodrigo Cunha" <rn...@gm...>
>> To: "Mark Swanson" <ma...@Sc...>; "Jimmy Zhang" 
>> <cra...@co...>
>> Cc: <vtd...@li...>
>> Sent: Tuesday, March 06, 2007 9:24 AM
>> Subject: Re: [Vtd-xml-users] Random Access Proposal (take 2)
>>
>>
>>> Hum, thanks for the hint also Mark. I normally use java.util 
>>> collections, but i'll give fastutils a look, since they might be better 
>>> for some of my problems.
>>>
>>> Jimmy, a context can be imported/exported as an array of integers, this 
>>> being a bit raw perhaps... and leaving the programmer with the job of 
>>> storing that array. I just created SimpleContext as a way of abstracting 
>>> that implementation detail, but since you like performance, perhaps you 
>>> could leave that raw. I still prefer the abstracted version... besides, 
>>> the internal representation might change and the abstracted version 
>>> would still work.
>>>
>>> So, yes, go ahead with my API even if you decide to change it later.
>>>
>>> Just as a little silly footnote I found my API is also useful in cases 
>>> where you have:
>>>
>>> push();
>>> // do something
>>> pop();
>>> push();
>>> // do something
>>> pop();
>>> push();
>>> // do something
>>> pop();
>>> push();
>>> // do something
>>> pop();
>>>
>>> Can be abreviated to:
>>>
>>> setCtxFromNav(ctx);
>>> // do something
>>> setNavFromCtx(ctx);
>>> // do something
>>> setNavFromCtx(ctx);
>>> // do something
>>> setNavFromCtx(ctx);
>>> // do something
>>> setNavFromCtx(ctx);
>>>
>>> This is both faster and more readable.
>>>
>>> It's also useful for things like:
>>>
>>> xpto = getComplexToFindTransmissionPath(VTDNav n, String s); // might 
>>> even use caching!
>>> push();
>>> nav.setNavFromCtx(xpto);
>>> // Do something
>>> pop();
>>>
>>> and also for exception handling:
>>>
>>> {
>>> setCtxFromNav(xpto);
>>> // do something complex and error-prone,
>>> // so I won't use the stack, but a few locally declared contexts instead
>>> // oops! crash! go to handler!
>>> finally {
>>>    setNavFromCtx(xpto)
>>>    // we are now clean
>>> }
>>>
>>> So, it made using VTD much more enjoyable to me, even in rather trivial 
>>> situations.
>>>
>>> Mark Swanson wrote:
>>>> Jimmy Zhang wrote:
>>>>>
>>>>>> Just a FYI: I have cases where the key is an Integer, and cases where
>>>>>> it's a string.
>>>>>
>>>>> By Integer is it a java class? or just a primitive data type? Maybe I 
>>>>> can
>>>>> modify Rodrigo's class and put it into CVS so you guys can use 
>>>>> immediately...
>>>>> however, I can't guarantee that it will be included in the next 
>>>>> release...
>>>>> Would that work?
>>>>
>>>> Oh, I always use native ints and fastutil wherever possible.
>>>>
>>>> Just a thought: I use autojar on my code to build a tiny fastutil jar 
>>>> that just has the code I need. You could do the same thing to get 
>>>> excellent native collections instead of writing your own. I see you 
>>>> already wrote your own, but in case you need more.. Fastutil uses the 
>>>> LGPL.
>>>>
>>>> Cheers.
>>>>
>>>
>>>
>>
>>
>>
> 

Re: [Vtd-xml-users] Random Access Proposal (take 2)

[Rodrigo C. <rn...@gm...>]

Jimmy, the API itself seems quite OK to me.

I had made the decision not to keep a pointer to VN inside the context 
but for extra safety this is both highly recomended and adds little 
extra fat, so let's keep it your way. Ah... since you keep a pointer do 
VTDNav you should add a method "getNavigator". This will spare some 
parameter passing to functions that might use a Bookmark. It's 
functionally irrelevant but convenient and might even add some efficiency.

Now the inner workings:

The implementation of both equals and hashcode could be different. Note 
that in typical usage inside data structures my complex methods 
assymptotically get as fast as yours, since they end up comparing 
pre-calculated hashCodes, considering there are probably no collisions.

Also, for maximum efficiency hashCode should be a spread function. Using 
index numbers does not typically spread the hashCode amonsgst the 
available 2^32 values, still this is a minor observation, don't bother 
with that :-) And we don't have collisions, so it's quite ok.

If Mark also agrees I think this new class is ready for prime time.

Jimmy Zhang wrote:
> hmm...interesting... "plup" sounds like a tennis racket hitting the 
> ground...
> it may work :-)
>
> Please take a look the file below and let me know what you think of it 
> ...
>
> http://vtd-xml.cvs.sourceforge.net/*checkout*/vtd-xml/ximple-dev/com/ximpleware/BookMark.java 
>
>
>
> ----- Original Message ----- From: "Rodrigo Cunha" <rn...@gm...>
> To: "Jimmy Zhang" <cra...@co...>
> Cc: "Mark Swanson" <ma...@Sc...>; 
> <vtd...@li...>
> Sent: Wednesday, March 14, 2007 4:19 AM
> Subject: Re: [Vtd-xml-users] Random Access Proposal (take 2)
>
>
>> Yes, that would be a nice add :-)
>>
>> Wouldn't solve the exception handling or true random access issues 
>> tought, but would be a nice addon.
>>
>> I propose "plup()" hehe
>>
>> Jimmy Zhang wrote:
>>> Rodrigo, How about add a method (tentatively called set()) that 
>>> basically
>>> does pop() and push() in one shot , so your
>>> example
>>>
>>> push();
>>> // do something
>>> pop();
>>> push();
>>> // do something
>>> pop();
>>> push();
>>> // do something
>>> pop();
>>> push();
>>> // do something
>>> pop();
>>>
>>> becomes
>>>
>>> push();
>>> // do something
>>> set();
>>> // do something
>>> set();
>>> // do something
>>> set();
>>> // do something
>>> pop();
>>>
>>>
>>> ----- Original Message ----- From: "Rodrigo Cunha" <rn...@gm...>
>>> To: "Mark Swanson" <ma...@Sc...>; "Jimmy Zhang" 
>>> <cra...@co...>
>>> Cc: <vtd...@li...>
>>> Sent: Tuesday, March 06, 2007 9:24 AM
>>> Subject: Re: [Vtd-xml-users] Random Access Proposal (take 2)
>>>
>>>
>>>> Hum, thanks for the hint also Mark. I normally use java.util 
>>>> collections, but i'll give fastutils a look, since they might be 
>>>> better for some of my problems.
>>>>
>>>> Jimmy, a context can be imported/exported as an array of integers, 
>>>> this being a bit raw perhaps... and leaving the programmer with the 
>>>> job of storing that array. I just created SimpleContext as a way of 
>>>> abstracting that implementation detail, but since you like 
>>>> performance, perhaps you could leave that raw. I still prefer the 
>>>> abstracted version... besides, the internal representation might 
>>>> change and the abstracted version would still work.
>>>>
>>>> So, yes, go ahead with my API even if you decide to change it later.
>>>>
>>>> Just as a little silly footnote I found my API is also useful in 
>>>> cases where you have:
>>>>
>>>> push();
>>>> // do something
>>>> pop();
>>>> push();
>>>> // do something
>>>> pop();
>>>> push();
>>>> // do something
>>>> pop();
>>>> push();
>>>> // do something
>>>> pop();
>>>>
>>>> Can be abreviated to:
>>>>
>>>> setCtxFromNav(ctx);
>>>> // do something
>>>> setNavFromCtx(ctx);
>>>> // do something
>>>> setNavFromCtx(ctx);
>>>> // do something
>>>> setNavFromCtx(ctx);
>>>> // do something
>>>> setNavFromCtx(ctx);
>>>>
>>>> This is both faster and more readable.
>>>>
>>>> It's also useful for things like:
>>>>
>>>> xpto = getComplexToFindTransmissionPath(VTDNav n, String s); // 
>>>> might even use caching!
>>>> push();
>>>> nav.setNavFromCtx(xpto);
>>>> // Do something
>>>> pop();
>>>>
>>>> and also for exception handling:
>>>>
>>>> {
>>>> setCtxFromNav(xpto);
>>>> // do something complex and error-prone,
>>>> // so I won't use the stack, but a few locally declared contexts 
>>>> instead
>>>> // oops! crash! go to handler!
>>>> finally {
>>>>    setNavFromCtx(xpto)
>>>>    // we are now clean
>>>> }
>>>>
>>>> So, it made using VTD much more enjoyable to me, even in rather 
>>>> trivial situations.
>>>>
>>>> Mark Swanson wrote:
>>>>> Jimmy Zhang wrote:
>>>>>>
>>>>>>> Just a FYI: I have cases where the key is an Integer, and cases 
>>>>>>> where
>>>>>>> it's a string.
>>>>>>
>>>>>> By Integer is it a java class? or just a primitive data type? 
>>>>>> Maybe I can
>>>>>> modify Rodrigo's class and put it into CVS so you guys can use 
>>>>>> immediately...
>>>>>> however, I can't guarantee that it will be included in the next 
>>>>>> release...
>>>>>> Would that work?
>>>>>
>>>>> Oh, I always use native ints and fastutil wherever possible.
>>>>>
>>>>> Just a thought: I use autojar on my code to build a tiny fastutil 
>>>>> jar that just has the code I need. You could do the same thing to 
>>>>> get excellent native collections instead of writing your own. I 
>>>>> see you already wrote your own, but in case you need more.. 
>>>>> Fastutil uses the LGPL.
>>>>>
>>>>> Cheers.
>>>>>
>>>>
>>>>
>>>
>>>
>>>
>>
>
>
>

Re: [Vtd-xml-users] Random Access Proposal (take 2)

[Jimmy Z. <cra...@co...>]

Rodrigo, I just checked in a quick update into CVS

Regarding some of prior comments, my questions are

1. When would a user call getNavigator() any way? I kinda had
a tough time coming up the scenario...

2. Regarding equals(), I think that the current bookMark implementation
should be fine in that the only time two bookMark instances are equal
is when they contains node position of the same VTDNav instance, and
the node indices are equal...

3.  I am still not sure about hashCode, what is the purpose of the spread?
For the current implementation, there will never be colision for the 
bookmarks
corresponding to the same document (the node index is ideal)...

Let me know your thoughts..
Regards,
jimmy


----- Original Message ----- 
From: "Rodrigo Cunha" <rn...@gm...>
To: "Jimmy Zhang" <cra...@co...>
Cc: "Mark Swanson" <ma...@Sc...>; 
<vtd...@li...>
Sent: Thursday, March 15, 2007 8:46 AM
Subject: Re: [Vtd-xml-users] Random Access Proposal (take 2)


> Jimmy, the API itself seems quite OK to me.
>
> I had made the decision not to keep a pointer to VN inside the context but 
> for extra safety this is both highly recomended and adds little extra fat, 
> so let's keep it your way. Ah... since you keep a pointer do VTDNav you 
> should add a method "getNavigator". This will spare some parameter passing 
> to functions that might use a Bookmark. It's functionally irrelevant but 
> convenient and might even add some efficiency.
>
> Now the inner workings:
>
> The implementation of both equals and hashcode could be different. Note 
> that in typical usage inside data structures my complex methods 
> assymptotically get as fast as yours, since they end up comparing 
> pre-calculated hashCodes, considering there are probably no collisions.
>
> Also, for maximum efficiency hashCode should be a spread function. Using 
> index numbers does not typically spread the hashCode amonsgst the 
> available 2^32 values, still this is a minor observation, don't bother 
> with that :-) And we don't have collisions, so it's quite ok.
>
> If Mark also agrees I think this new class is ready for prime time.
>
> Jimmy Zhang wrote:
>> hmm...interesting... "plup" sounds like a tennis racket hitting the 
>> ground...
>> it may work :-)
>>
>> Please take a look the file below and let me know what you think of it 
>> ...
>>
>> http://vtd-xml.cvs.sourceforge.net/*checkout*/vtd-xml/ximple-dev/com/ximpleware/BookMark.java
>>
>>
>> ----- Original Message ----- From: "Rodrigo Cunha" <rn...@gm...>
>> To: "Jimmy Zhang" <cra...@co...>
>> Cc: "Mark Swanson" <ma...@Sc...>; 
>> <vtd...@li...>
>> Sent: Wednesday, March 14, 2007 4:19 AM
>> Subject: Re: [Vtd-xml-users] Random Access Proposal (take 2)
>>
>>
>>> Yes, that would be a nice add :-)
>>>
>>> Wouldn't solve the exception handling or true random access issues 
>>> tought, but would be a nice addon.
>>>
>>> I propose "plup()" hehe
>>>
>>> Jimmy Zhang wrote:
>>>> Rodrigo, How about add a method (tentatively called set()) that 
>>>> basically
>>>> does pop() and push() in one shot , so your
>>>> example
>>>>
>>>> push();
>>>> // do something
>>>> pop();
>>>> push();
>>>> // do something
>>>> pop();
>>>> push();
>>>> // do something
>>>> pop();
>>>> push();
>>>> // do something
>>>> pop();
>>>>
>>>> becomes
>>>>
>>>> push();
>>>> // do something
>>>> set();
>>>> // do something
>>>> set();
>>>> // do something
>>>> set();
>>>> // do something
>>>> pop();
>>>>
>>>>
>>>> ----- Original Message ----- From: "Rodrigo Cunha" <rn...@gm...>
>>>> To: "Mark Swanson" <ma...@Sc...>; "Jimmy Zhang" 
>>>> <cra...@co...>
>>>> Cc: <vtd...@li...>
>>>> Sent: Tuesday, March 06, 2007 9:24 AM
>>>> Subject: Re: [Vtd-xml-users] Random Access Proposal (take 2)
>>>>
>>>>
>>>>> Hum, thanks for the hint also Mark. I normally use java.util 
>>>>> collections, but i'll give fastutils a look, since they might be 
>>>>> better for some of my problems.
>>>>>
>>>>> Jimmy, a context can be imported/exported as an array of integers, 
>>>>> this being a bit raw perhaps... and leaving the programmer with the 
>>>>> job of storing that array. I just created SimpleContext as a way of 
>>>>> abstracting that implementation detail, but since you like 
>>>>> performance, perhaps you could leave that raw. I still prefer the 
>>>>> abstracted version... besides, the internal representation might 
>>>>> change and the abstracted version would still work.
>>>>>
>>>>> So, yes, go ahead with my API even if you decide to change it later.
>>>>>
>>>>> Just as a little silly footnote I found my API is also useful in cases 
>>>>> where you have:
>>>>>
>>>>> push();
>>>>> // do something
>>>>> pop();
>>>>> push();
>>>>> // do something
>>>>> pop();
>>>>> push();
>>>>> // do something
>>>>> pop();
>>>>> push();
>>>>> // do something
>>>>> pop();
>>>>>
>>>>> Can be abreviated to:
>>>>>
>>>>> setCtxFromNav(ctx);
>>>>> // do something
>>>>> setNavFromCtx(ctx);
>>>>> // do something
>>>>> setNavFromCtx(ctx);
>>>>> // do something
>>>>> setNavFromCtx(ctx);
>>>>> // do something
>>>>> setNavFromCtx(ctx);
>>>>>
>>>>> This is both faster and more readable.
>>>>>
>>>>> It's also useful for things like:
>>>>>
>>>>> xpto = getComplexToFindTransmissionPath(VTDNav n, String s); // might 
>>>>> even use caching!
>>>>> push();
>>>>> nav.setNavFromCtx(xpto);
>>>>> // Do something
>>>>> pop();
>>>>>
>>>>> and also for exception handling:
>>>>>
>>>>> {
>>>>> setCtxFromNav(xpto);
>>>>> // do something complex and error-prone,
>>>>> // so I won't use the stack, but a few locally declared contexts 
>>>>> instead
>>>>> // oops! crash! go to handler!
>>>>> finally {
>>>>>    setNavFromCtx(xpto)
>>>>>    // we are now clean
>>>>> }
>>>>>
>>>>> So, it made using VTD much more enjoyable to me, even in rather 
>>>>> trivial situations.
>>>>>
>>>>> Mark Swanson wrote:
>>>>>> Jimmy Zhang wrote:
>>>>>>>
>>>>>>>> Just a FYI: I have cases where the key is an Integer, and cases 
>>>>>>>> where
>>>>>>>> it's a string.
>>>>>>>
>>>>>>> By Integer is it a java class? or just a primitive data type? Maybe 
>>>>>>> I can
>>>>>>> modify Rodrigo's class and put it into CVS so you guys can use 
>>>>>>> immediately...
>>>>>>> however, I can't guarantee that it will be included in the next 
>>>>>>> release...
>>>>>>> Would that work?
>>>>>>
>>>>>> Oh, I always use native ints and fastutil wherever possible.
>>>>>>
>>>>>> Just a thought: I use autojar on my code to build a tiny fastutil jar 
>>>>>> that just has the code I need. You could do the same thing to get 
>>>>>> excellent native collections instead of writing your own. I see you 
>>>>>> already wrote your own, but in case you need more.. Fastutil uses the 
>>>>>> LGPL.
>>>>>>
>>>>>> Cheers.
>>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>
>>
>>
>>
>
> 

Re: [Vtd-xml-users] Random Access Proposal (take 2)

[Rodrigo C. <rn...@gm...>]

Hi!

The getNavigator() method might spare some parameter passing, since if 
I'm gona pass a bookmark around to another object I'll need to pass the 
navigator also, somehow. It's not critical, but since it can be done 
trivially, why not? Also, being able to ask the bookmark "hey you, to 
witch navigator do you belong?" seems the phylosophically correct thing 
to do.

equals() and hashCode() are religious issues, just keep them your way :-)

A hashCode function should ideally spread the input amongst all the 
hashcodes space, since collections using hashcodes might, or might not, 
use all bits in the hashcode. But just don't bother with that.

Jimmy Zhang wrote:
> Rodrigo, I just checked in a quick update into CVS
>
> Regarding some of prior comments, my questions are
>
> 1. When would a user call getNavigator() any way? I kinda had
> a tough time coming up the scenario...
>
> 2. Regarding equals(), I think that the current bookMark implementation
> should be fine in that the only time two bookMark instances are equal
> is when they contains node position of the same VTDNav instance, and
> the node indices are equal...
>
> 3.  I am still not sure about hashCode, what is the purpose of the 
> spread?
> For the current implementation, there will never be colision for the 
> bookmarks
> corresponding to the same document (the node index is ideal)...
>
> Let me know your thoughts..
> Regards,
> jimmy
>

Re: [Vtd-xml-users] Random Access Proposal (take 2)

[Jimmy Z. <cra...@co...>]

Yes, BookMark will go into the next release as an experimental
feature ... with more user feedback/discussion, we can officially
introduce it later

regarding getNavigator().. if  non-critical, I prefer to keep it
out for now... if we keep it in, then later decide to drop it,
it will break people's code... so it is easier to add a method than
taking it out... plus one less method makes the documentation shorter
and a bit less confusing ...

regarding equals() and hashCode(), the methods are there, we
can alway change the implementation...

In the meantime, could you give the implementation a bit testing?


----- Original Message ----- 
From: "Rodrigo Cunha" <rn...@gm...>
To: "Jimmy Zhang" <cra...@co...>
Cc: "Mark Swanson" <ma...@Sc...>; 
<vtd...@li...>
Sent: Wednesday, March 28, 2007 3:16 AM
Subject: Re: [Vtd-xml-users] Random Access Proposal (take 2)


> Hi!
>
> The getNavigator() method might spare some parameter passing, since if I'm 
> gona pass a bookmark around to another object I'll need to pass the 
> navigator also, somehow. It's not critical, but since it can be done 
> trivially, why not? Also, being able to ask the bookmark "hey you, to 
> witch navigator do you belong?" seems the phylosophically correct thing to 
> do.
>
> equals() and hashCode() are religious issues, just keep them your way :-)
>
> A hashCode function should ideally spread the input amongst all the 
> hashcodes space, since collections using hashcodes might, or might not, 
> use all bits in the hashcode. But just don't bother with that.
>
> Jimmy Zhang wrote:
>> Rodrigo, I just checked in a quick update into CVS
>>
>> Regarding some of prior comments, my questions are
>>
>> 1. When would a user call getNavigator() any way? I kinda had
>> a tough time coming up the scenario...
>>
>> 2. Regarding equals(), I think that the current bookMark implementation
>> should be fine in that the only time two bookMark instances are equal
>> is when they contains node position of the same VTDNav instance, and
>> the node indices are equal...
>>
>> 3.  I am still not sure about hashCode, what is the purpose of the 
>> spread?
>> For the current implementation, there will never be colision for the 
>> bookmarks
>> corresponding to the same document (the node index is ideal)...
>>
>> Let me know your thoughts..
>> Regards,
>> jimmy
>>
>
> 

Re: [Vtd-xml-users] Random Access Proposal (take 2)

[Rodrigo C. <rn...@gm...>]

Jimmy,

getNavigator would be used in some of my code to avoid passing yet 
another parameter to methods, I just don't use it right now because my 
bookmark class does not keep the navigator reference. If it did I would 
use it right away.

Also the method is so simple no one would be confused. Why hide this 
rather obvious feature?

This works just like the Pattern class in Java: you create it using a 
string, and later if you really want to get the string back you also 
can, since it's probably there in the class anyway.  Only that is 
useless, and this feature is useful.

getNavigator: returns the navigator to witch the bookmark is bound, 
otherwise returns null.

I can test the implementation, sure. Just give me a few days :-)

Also, I'll include the rather trivial getNavigator in the test, ok?

Jimmy Zhang wrote:
> Yes, BookMark will go into the next release as an experimental
> feature ... with more user feedback/discussion, we can officially
> introduce it later
>
> regarding getNavigator().. if  non-critical, I prefer to keep it
> out for now... if we keep it in, then later decide to drop it,
> it will break people's code... so it is easier to add a method than
> taking it out... plus one less method makes the documentation shorter
> and a bit less confusing ...
>
> regarding equals() and hashCode(), the methods are there, we
> can alway change the implementation...
>
> In the meantime, could you give the implementation a bit testing?
>
>
> ----- Original Message ----- From: "Rodrigo Cunha" <rn...@gm...>
> To: "Jimmy Zhang" <cra...@co...>
> Cc: "Mark Swanson" <ma...@Sc...>; 
> <vtd...@li...>
> Sent: Wednesday, March 28, 2007 3:16 AM
> Subject: Re: [Vtd-xml-users] Random Access Proposal (take 2)
>
>
>> Hi!
>>
>> The getNavigator() method might spare some parameter passing, since 
>> if I'm gona pass a bookmark around to another object I'll need to 
>> pass the navigator also, somehow. It's not critical, but since it can 
>> be done trivially, why not? Also, being able to ask the bookmark "hey 
>> you, to witch navigator do you belong?" seems the phylosophically 
>> correct thing to do.
>>
>> equals() and hashCode() are religious issues, just keep them your way 
>> :-)
>>
>> A hashCode function should ideally spread the input amongst all the 
>> hashcodes space, since collections using hashcodes might, or might 
>> not, use all bits in the hashcode. But just don't bother with that.
>>
>> Jimmy Zhang wrote:
>>> Rodrigo, I just checked in a quick update into CVS
>>>
>>> Regarding some of prior comments, my questions are
>>>
>>> 1. When would a user call getNavigator() any way? I kinda had
>>> a tough time coming up the scenario...
>>>
>>> 2. Regarding equals(), I think that the current bookMark implementation
>>> should be fine in that the only time two bookMark instances are equal
>>> is when they contains node position of the same VTDNav instance, and
>>> the node indices are equal...
>>>
>>> 3.  I am still not sure about hashCode, what is the purpose of the 
>>> spread?
>>> For the current implementation, there will never be colision for the 
>>> bookmarks
>>> corresponding to the same document (the node index is ideal)...
>>>
>>> Let me know your thoughts..
>>> Regards,
>>> jimmy
>>>
>>
>>
>
>
>

[Vtd-xml-users] VTD-XML v2.1

[Jimmy Z. <cra...@co...>]

VTD-XML 2.1 is released. This version contains a number of features and bug 
fixes.
* The BookMark class is introduced into all available plaforms of VTD-XML.
* C# and Java port of VTD-XML fix the bug of unicode chars in XPath 
expression.
* C version of VTD-XML has numerous code clean-ups.

Downloads available at

http://sourceforge.net/project/showfiles.php?group_id=110612 

Re: [Vtd-xml-users] VTD-XML v2.1

[Rodrigo C. <rn...@gm...>]

Thanks! I'll try to test it today or tomorrow.

Jimmy Zhang wrote:
> VTD-XML 2.1 is released. This version contains a number of features and bug 
> fixes.
> * The BookMark class is introduced into all available plaforms of VTD-XML.
> * C# and Java port of VTD-XML fix the bug of unicode chars in XPath 
> expression.
> * C version of VTD-XML has numerous code clean-ups.
>
> Downloads available at
>
> http://sourceforge.net/project/showfiles.php?group_id=110612 
>
>
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by DB2 Express
> Download DB2 Express C - the FREE version of DB2 express and take
> control of your XML. No limits. Just data. Click to get it now.
> http://sourceforge.net/powerbar/db2/
> _______________________________________________
> Vtd-xml-users mailing list
> Vtd...@li...
> https://lists.sourceforge.net/lists/listinfo/vtd-xml-users
>
>   

Re: [Vtd-xml-users] Random Access Proposal (take 2)

[Mark S. <ma...@Sc...>]

Jimmy Zhang wrote:
> hmm...interesting... "plup" sounds like a tennis racket hitting the 
> ground...
> it may work :-)
> 
> Please take a look the file below and let me know what you think of it ...
> 
> http://vtd-xml.cvs.sourceforge.net/*checkout*/vtd-xml/ximple-dev/com/ximpleware/BookMark.java 

It looks fine on the surface.
I am thinking of incorporating it into something I'm working on right 
now - if I can just get through the 'other stuff' first...

Cheers.

-- 
http://www.ScheduleWorld.com/
Free Google Calendar synchronization with Outlook, Evolution,
cell phones, BlackBerry, PalmOS, Exchange, Mozilla, Thunderbird,
Pocket PC/Windows Mobile. Also sync tasks, notes and contacts!
WebDAV, vfreebusy, RSS, LDAP, iCalendar, iTIP, iMIP support.

Re: [Vtd-xml-users] Random Access Proposal (take 2)

[Mark S. <ma...@Sc...>]

<snip>
> In order to navigate the file efficiently and produce interactive 
> results I was forced to maintain positions caches for both <ne> and 
> <tpath> indexed by those nice very-inner atributes.
> 
> For example, a task that took 36 seconds using unhelped navigation can 
> now be done in 1 or 2 seconds.

Interesting.

> Any comments?

I like it. I have a project coming up that is going to require ripping 
through the same 1mb-5mb xml documents a lot. All of the required 
queries will be able to start from a unique position 
(nice_indexing_attribute) and will not need to traverse more than a 
dozen elements on average.

If I could cache the starting positions in a HashMap and force the 
VTD-XML xpath query to start at a specific position that would save the 
xpath query engine from having to walk through a lot of unnecessary data.

Just thinking out loud. I'm not sure if I understood if this is coming 
in 2.0 or not.

Cheers.


-- 
http://www.ScheduleWorld.com/
Free Google Calendar synchronization with Outlook, Evolution,
cell phones, BlackBerry, PalmOS, Exchange, Mozilla, Thunderbird,
Pocket PC/Windows Mobile. Also sync tasks, notes and contacts!
WebDAV, vfreebusy, RSS, LDAP, iCalendar, iTIP, iMIP support.