Re: Xerces-P problems

["Jason E. Stewart" <ja...@openinformatics.com>]

"ePrints Support" <su...@eprints.org> writes:

> Hi, 
>
> If you're not the right person to ask about this, sorry
> - I failed to subscribe to the mailing list (is it broken?)
> and I don't want to log this as a bug until I know that it
> is not just us being dim.

Hi Christopher, 

I'm the moderator for the mailing list, and the primary (only?)
developer for the project at the moment. So I gues that would make me
the correct person...

I, too, had trouble subscribing to the list.

Try this piece of advice:

  You can start a subscription for an alternate address, for example
  "john@host.domain", just add a hyphen and your address (with '='
  instead of '@') after the command word:
  <xe...@xml.apache.org> 

Send the subscription request from a different account than the one
you used (hint it seems that apache's listserv doesn't like dynamic IP
accounts, or addresses that don't properly reverse-resolve so use a
machine with a static IP).

> I'm developing a medium size free-software application
> for generating open archives on the web. I've been using
> the perl XML::DOM library. We're almost completely commited
> to using DOM but XML::DOM is horribly inefficient.

Yes, I had to leave it for that reason as well. Xerces-1.4 is better,
and Xerces-1.5 IDOM interface is *much* better (the only problem
being, I haven't built the interface to IDOM yet :-(

> My assistant suggested Xerces-P as a drop in alternative,

Well, almost drop-in... There are some differences (the namespace for
one), but I think they are minor. 

> but we've been having real trouble getting it to work. It 
> dumps core everytime.
> 
> Doing a bit of investigating with a debugger we found it
> is dying at some of the pthread code:
> 
> --<snip>--
> #0  __pthread_mutex_lock (mutex=0x818c780) at internals.h:371
> 371     internals.h: No such file or directory.
>         in internals.h
> (gdb) up
> #1  0x4034418d in XMLPlatformUtils::lockMutex (mtxHandle=0x818c780) at LinuxPlatformUtils.cpp:634
> 634             if (pthread_mutex_lock((pthread_mutex_t*) mtxHandle))
> --<snip>--
> 
> Does xerces-p require a threaded perl (sob)? 

No, not at all. It does need a working pthreads however which seems to
be your trouble. What version of Xerces-C and Xerces.pm are you using?

> We're using redhat 7.1 (upgraded machine from 6.2) and perl 5.6.1

This should be fine. Anyone else using 7.1 out there?

> Also we would like to use this as an integral component of our
> system, so we are keen to make it easy for people to install -
> currently it needs xerces-c xerces-p AND swig... any comments or
> suggestions welcome.

SWIG *should* be unnecessary. I include an already SWIG'ed version of
Xerces.pm and Xerces.C with each distribution. Someone commented that
they were having trouble, and it was trying to rebuild them anyway. 

The need for xerces-c will always be there, as the underlying C++ code
is all theirs (it makes Xerces.pm faster and more memory efficient
than XML::DOM). 

However, it is possible that I can bundle the Xerces-C source code and
configure Xerces.pm to create Xerces-C on the fly. That would save a
single installation. Would this be useful?

jas.

---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-p-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-p-dev-help@xml.apache.org

Re: Xerces-P problems

["Jason E. Stewart" <ja...@openinformatics.com>]

"Jason E. Stewart" <ja...@openinformatics.com> writes:

> Hey Chris,
> 
> "ePrints Support" <su...@eprints.org> writes:
> 
> > Which Versions of x-c and x-p? We tried a number of combinations.
> > 
> > It fails with all - Our aim was for the latest stable versions.
> > 
> > perl on my test machine does not load the pthreads.so and I think
> > that's the problem. I could be wrong... The test bin's in the 
> > xerces-c work fine, by the way.
> > 
> This seems like an issue with RedHat 7.1, since I currently run it on
> a 6.2 system with no trouble. When you say it *won't* load, I'm not
> sure what you mean. Must be perl if the xerces-c samples work. Give me
> more details and I'll see what I find out.
> 
> A friends giving me an account on a 7.1 box, and I'll try it there. 

As my previous post indicates, Once I recompiled Xerces-C from source
I had no trouble on RedHat7

jas.

---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-p-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-p-dev-help@xml.apache.org

Re: Xerces-P problems

["Jason E. Stewart" <ja...@openinformatics.com>]

"Mike Jewell" <mo...@ecs.soton.ac.uk> writes:

> > This is a must for me. I intend SWIG to be 105% unnecessary for
> > users. It's only a must for developers who want to modify the core
> > files and regenerate the interfaces. The issue is that MakeMaker has
> > gotten soooooooooo..... complicated, it seems to live its own life. I
> > get Makefile dependancies I can't control.
> 
> Would it be viable to put together an RPM package for the combined Xerces-C
> and Xerces-P? I'm willing to set the gears in motion - although I've only
> got until the end of September on on our project, so I'd need to hand over
> the files near the end of my stint. I'm sure I'd be able to keep
> contributing towards it after then, but I'll have other commitments to
> battle against :-)

I'd be lyrical if you'd do that! That would really help out the redhat
side of the world.

I'm in the process of becoming a debian maintainer, and they already
have a xerces-c maintainer, so by setting up a xerces-p package, all
people would have to do is:

apt-get install xerces-p

and it would do the rest...

Let me know how I can help.
jas.

---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-p-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-p-dev-help@xml.apache.org

Re: Xerces-P problems

[Mike Jewell <mo...@ecs.soton.ac.uk>]

Hi!

> This is a must for me. I intend SWIG to be 105% unnecessary for
> users. It's only a must for developers who want to modify the core
> files and regenerate the interfaces. The issue is that MakeMaker has
> gotten soooooooooo..... complicated, it seems to live its own life. I
> get Makefile dependancies I can't control.

Would it be viable to put together an RPM package for the combined Xerces-C
and Xerces-P? I'm willing to set the gears in motion - although I've only
got until the end of September on on our project, so I'd need to hand over
the files near the end of my stint. I'm sure I'd be able to keep
contributing towards it after then, but I'll have other commitments to
battle against :-)

Cheers,
Mike Jewell
[moj199@ecs.soton.ac.uk]


---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-p-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-p-dev-help@xml.apache.org

Re: Xerces-P problems

["Jason E. Stewart" <ja...@openinformatics.com>]

Hey Chris,

"ePrints Support" <su...@eprints.org> writes:

> Which Versions of x-c and x-p? We tried a number of combinations.
> 
> It fails with all - Our aim was for the latest stable versions.
> 
> perl on my test machine does not load the pthreads.so and I think
> that's the problem. I could be wrong... The test bin's in the 
> xerces-c work fine, by the way.
> 
This seems like an issue with RedHat 7.1, since I currently run it on
a 6.2 system with no trouble. When you say it *won't* load, I'm not
sure what you mean. Must be perl if the xerces-c samples work. Give me
more details and I'll see what I find out.

A friends giving me an account on a 7.1 box, and I'll try it there. 

> We are seriously considering our own Big Bad install package
> as our system requires about 6 non-default perl libs.
> 
> I'm hoping to abstract the DOM interface a little, so that 
> people wanting to play with our software can just use XML::DOM
> (slow, but easy to install), but people running on a production
> server can run your XML::Xerces DOM.

I think that would be an interesting approach. You could create
typeglob aliases to help. Alias a set of functions in your own
namespace to XML::Xerce::* if they want Xerces, otherwise use
XML::DOM::*. Anyplace where the API's differ from Xerces to XML::DOM,
you could just have a wrapper method delegate appropriately, or give a
warning/error for 'unimplimento'.

> As for your big-bad install, not a bad idea, esp. if you can 
> make it skip swig without resorting to editing the Makefile.PL

This is a must for me. I intend SWIG to be 105% unnecessary for
users. It's only a must for developers who want to modify the core
files and regenerate the interfaces. The issue is that MakeMaker has
gotten soooooooooo..... complicated, it seems to live its own life. I
get Makefile dependancies I can't control.

> All in all we're really hoping to get this working and easy for
> people to install - it looks very promising. I was afraid we might
> have to try and do a minimal perl module in C++ for DOM ourselves.

God forbid.... I hope that Xerces.pm can do it for you.

> Thanks for your help. I've been working hard on the eprints software
> for 6 months now, and the XML::DOM library could be a show-stopper as
> to generate a fairly simple web page it peaks the processor on my
> P3 833.

Wow... That's extreme. The whole reason I would up maintaining Xerces
was because we were using XML::DOM for a scientific DB project, and
when we did some tests on some reasonably big XML files (20Mb),
XML::DOM dove up to 600Mb of memory usage, and slowwwwwwwww. 

Most of the files I've been running through Xerces are much smaller,
though. I'd like to get the IDOM interface working (from Xerces 1.5)
and really test it out. Very low memory footprint, and much better
speed (and handles SMP and multi-threading).

---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-p-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-p-dev-help@xml.apache.org