From larryl at imail.EECS.Berkeley.EDU  Sun Apr  6 23:18:22 2003
From: larryl at imail.EECS.Berkeley.EDU (Lawrence W. Leung)
Date: Mon Apr  7 09:44:03 2003
Subject: [Expat-discuss] expat "junk after element" parsing bug?
Message-ID: <Pine.SOL.4.44.0304062214500.15654-100000@cory.EECS.Berkeley.EDU>

I'm using a port of expat to pocketpc included in PocketSOAP 1.4 and
whenever I pass something like:

"<ContextTuple></ContextTuple><ContextTuple></ContextTuple>"

to XML_Parse() it fails, complaining of "junk after element" at the
beginning of the second ContextTuple start tag.  I'm not sure exactly what
version of expat this is.  Has there been a bug like this?  (If so, is
there any easy fix?) Or am I doing something wrong?

thanks,
--------------
-Larry


From fdrake at acm.org  Mon Apr  7 11:05:48 2003
From: fdrake at acm.org (Fred L. Drake, Jr.)
Date: Mon Apr  7 10:06:24 2003
Subject: [Expat-discuss] expat "junk after element" parsing bug?
In-Reply-To: <Pine.SOL.4.44.0304062214500.15654-100000@cory.EECS.Berkeley.EDU>
References: <Pine.SOL.4.44.0304062214500.15654-100000@cory.EECS.Berkeley.EDU>
Message-ID: <16017.34236.4744.340437@grendel.zope.com>


Lawrence W. Leung writes:
 > I'm using a port of expat to pocketpc included in PocketSOAP 1.4 and
 > whenever I pass something like:
 > 
 > "<ContextTuple></ContextTuple><ContextTuple></ContextTuple>"
 > 
 > to XML_Parse() it fails, complaining of "junk after element" at the
 > beginning of the second ContextTuple start tag.

It should.

 >                                                  I'm not sure exactly what
 > version of expat this is.  Has there been a bug like this?  (If so, is
 > there any easy fix?) Or am I doing something wrong?

You application code is not suspect at this point.  You're using an
invalid document; XML only allows one top-level element.  Only
comments, processing instructions, and whitespace are allowed after
the document element.


  -Fred

-- 
Fred L. Drake, Jr.  <fdrake at acm.org>
PythonLabs at Zope Corporation

From chris at chrisseaton.com  Mon Apr 14 21:36:04 2003
From: chris at chrisseaton.com (Chris Seaton)
Date: Mon Apr 14 15:36:19 2003
Subject: [Expat-discuss] Expat 1.95.6 headers
Message-ID: <3E9B0DA4.5020009@chrisseaton.com>

In expat.h with 1.95.6 GCC says that on line 657 enum XML_Status is used 
before it is declared. The enum in question is actually defined on line 735.

Am I missing something?

I'm using the static library, Windows XP, GCC 3.2

Chris



From fdrake at acm.org  Mon Apr 14 16:43:21 2003
From: fdrake at acm.org (Fred L. Drake, Jr.)
Date: Mon Apr 14 15:44:10 2003
Subject: [Expat-discuss] Expat 1.95.6 headers
In-Reply-To: <3E9B0DA4.5020009@chrisseaton.com>
References: <3E9B0DA4.5020009@chrisseaton.com>
Message-ID: <16027.3929.398388.777377@grendel.zope.com>


Chris Seaton writes:
 > In expat.h with 1.95.6 GCC says that on line 657 enum XML_Status is used 
 > before it is declared. The enum in question is actually defined on line 735.
 > 
 > Am I missing something?

No, it really does that.  Not all compilers treat this as an error,
but (I think) they should.  This has been fixed in Expat's CVS
repository, and we're hoping to release a version with the fix
included fairly soon; I'm afraid I've been the bottleneck.  ;-(


  -Fred

-- 
Fred L. Drake, Jr.  <fdrake at acm.org>
PythonLabs at Zope Corporation

From lphiri at nc.rr.com  Tue Apr 15 09:33:30 2003
From: lphiri at nc.rr.com (Lindani Phiri)
Date: Tue Apr 15 10:41:27 2003
Subject: [Expat-discuss] Newbie linking question
Message-ID: <001001c30364$5e613e30$013c8c2f@ldantec>

Hi all,
I am kinda new to C programming so bare with me if this is a basic question.
I am trying to compile the examples that come with expat (version 1.95.6) under Solaris 2.7 and cant't them to compile.
I have successfully installed the package (using configure --prefix=/home/phiril/xml/expat/expat-1.95.6/install/, make and make install).

When I use the makefile that comes with expat I get the following:

make examples/outline 
/bin/ksh ./libtool --silent --mode=link gcc -g -O2 -Wall -Wmissing-prototypes -Wstrict-prototypes -fexceptions   -I./lib -I.  -o examples/outline  libexpat.la 
Undefined               first referenced 
 symbol                     in file 
main                                /opt/corp/contrib/gcc-2.95.2/sw/sparc-solaris2.6/lib/gcc-lib/sparc-sun-solaris2.6/2.95.2/crt1.o 
ld: fatal: Symbol referencing errors. No output written to examples/.libs/outline 
collect2: ld returned 1 exit status 
*** Error code 1 
make: Fatal error: Command failed for target `examples/outline' 


I tried compiling this directly:

 gcc -I/home/phiril/xml/expat/expat-1.95.6/install/include 
 -L/home/phiril/expat/expat-1.95.6/install/lib outline.c -v 
Reading specs from /opt/corp/contrib/gcc-2.95.2/sw/sparc-solaris2.6/lib/gcc-lib/sparc-sun-solaris2.6/2.95.2/specs 
gcc version 2.95.2 19991024 (release) 
 /opt/corp/contrib/gcc-2.95.2/sw/sparc-solaris2.6/lib/gcc-lib/sparc-sun-solaris2.6/2.95.2/cpp -lang-c -v -I/home/phiril/xml/expat/expat-1.95.6/install/include -D__GNUC__=2 -D__GNUC_MINOR__=95 -Dsparc -Dsun -Dunix -D__svr4__ -D__SVR4 -D__sparc__ -D__sun__ -D__unix__ -D__svr4__ -D__SVR4 -D__sparc -D__sun -D__unix -Asystem(unix) -Asystem(svr4) -D__GCC_NEW_VARARGS__ -Acpu(sparc) -Amachine(sparc) outline.c /var/tmp/ccX2S3hb.i 
GNU CPP version 2.95.2 19991024 (release) (sparc) 
#include "..." search starts here: 
#include <...> search starts here: 
 /home/phiril/xml/expat/expat-1.95.6/install/include 
 /usr/local/include 
 /opt/corp/contrib/gcc-2.95.2/sw/sparc-solaris2.6/lib/gcc-lib/sparc-sun-solaris2.6/2.95.2/../../../../sparc-sun-solaris2.6/include 
 /opt/corp/contrib/gcc-2.95.2/sw/sparc-solaris2.6/lib/gcc-lib/sparc-sun-solaris2.6/2.95.2/include 
 /usr/include 
End of search list. 
The following default directories have been omitted from the search path: 
 /opt/corp/contrib/gcc-2.95.2/sw/sparc-solaris2.6/lib/gcc-lib/sparc-sun-solaris2.6/2.95.2/../../../../include/g++-3 
End of omitted list. 
 /opt/corp/contrib/gcc-2.95.2/sw/sparc-solaris2.6/lib/gcc-lib/sparc-sun-solaris2.6/2.95.2/cc1 /var/tmp/ccX2S3hb.i -quiet -dumpbase outline.c -version -o /var/tmp/cc1zLKSb.s 
GNU C version 2.95.2 19991024 (release) (sparc-sun-solaris2.6) compiled by GNU C version 2.95.2 19991024 (release). 
 /usr/ccs/bin/as -V -Qy -s -o /var/tmp/ccDihHCo.o /var/tmp/cc1zLKSb.s 
/usr/ccs/bin/as: WorkShop Compilers 5.0 98/12/21 
 /opt/corp/contrib/gcc-2.95.2/sw/sparc-solaris2.6/lib/gcc-lib/sparc-sun-solaris2.6/2.95.2/collect2 -V -Y P,/usr/ccs/lib:/usr/lib -Qy /opt/corp/contrib/gcc-2.95.2/sw/sparc-solaris2.6/lib/gcc-lib/sparc-sun-solaris2.6/2.95.2/crt1.o /opt/corp/contrib/gcc-2.95.2/sw/sparc-solaris2.6/lib/gcc-lib/sparc-sun-solaris2.6/2.95.2/crti.o /usr/ccs/lib/values-Xa.o /opt/corp/contrib/gcc-2.95.2/sw/sparc-solaris2.6/lib/gcc-lib/sparc-sun-solaris2.6/2.95.2/crtbegin.o -L/home/phiril/expat/expat-1.95.6/install/lib -L/opt/corp/contrib/gcc-2.95.2/sw/sparc-solaris2.6/lib/gcc-lib/sparc-sun-solaris2.6/2.95.2 -L/usr/ccs/bin -L/usr/ccs/lib -L/opt/corp/contrib/gcc-2.95.2/sw/sparc-solaris2.6/lib /var/tmp/ccDihHCo.o -lgcc -lc -lgcc /opt/corp/contrib/gcc-2.95.2/sw/sparc-solaris2.6/lib/gcc-lib/sparc-sun-solaris2.6/2.95.2/crtend.o /opt/corp/contrib/gcc-2.95.2/sw/sparc-solaris2.6/lib/gcc-lib/sparc-sun-solaris2.6/2.95.2/crtn.o 
ld: Software Generation Utilities - Solaris Link Editors: 5.7-1.280 
Undefined               first referenced 
 symbol                     in file 
XML_GetErrorCode                    /var/tmp/ccDihHCo.o 
XML_ErrorString                     /var/tmp/ccDihHCo.o 
XML_ParserCreate                    /var/tmp/ccDihHCo.o 
XML_GetCurrentLineNumber            /var/tmp/ccDihHCo.o 
XML_Parse                           /var/tmp/ccDihHCo.o 
XML_SetElementHandler               /var/tmp/ccDihHCo.o 
ld: fatal: Symbol referencing errors. No output written to a.out 
collect2: ld returned 1 exit status 

What am I missing?

Thanks,

Lindani

From lphiri at nc.rr.com  Tue Apr 15 12:01:54 2003
From: lphiri at nc.rr.com (Lindani Phiri)
Date: Wed Apr 16 09:04:44 2003
Subject: [Expat-discuss] Re: Newbie linking question
Message-ID: <000901c30379$1947fc20$013c8c2f@ldantec>

Got it. I forgot to add -lexpat in my compiler option...

L.
  ----- Original Message ----- 
  From: Lindani Phiri 
  To: expat-discuss@libexpat.org 
  Sent: Tuesday, April 15, 2003 8:33 AM
  Subject: Newbie linking question


  Hi all,
  I am kinda new to C programming so bare with me if this is a basic question.
  I am trying to compile the examples that come with expat (version 1.95.6) under Solaris 2.7 and cant't them to compile.
  I have successfully installed the package (using configure --prefix=/home/phiril/xml/expat/expat-1.95.6/install/, make and make install).

  When I use the makefile that comes with expat I get the following:

  make examples/outline 
  /bin/ksh ./libtool --silent --mode=link gcc -g -O2 -Wall -Wmissing-prototypes -Wstrict-prototypes -fexceptions   -I./lib -I.  -o examples/outline  libexpat.la 
  Undefined               first referenced 
   symbol                     in file 
  main                                /opt/corp/contrib/gcc-2.95.2/sw/sparc-solaris2.6/lib/gcc-lib/sparc-sun-solaris2.6/2.95.2/crt1.o 
  ld: fatal: Symbol referencing errors. No output written to examples/.libs/outline 
  collect2: ld returned 1 exit status 
  *** Error code 1 
  make: Fatal error: Command failed for target `examples/outline' 


  I tried compiling this directly:

   gcc -I/home/phiril/xml/expat/expat-1.95.6/install/include 
   -L/home/phiril/expat/expat-1.95.6/install/lib outline.c -v 
  Reading specs from /opt/corp/contrib/gcc-2.95.2/sw/sparc-solaris2.6/lib/gcc-lib/sparc-sun-solaris2.6/2.95.2/specs 
  gcc version 2.95.2 19991024 (release) 
   /opt/corp/contrib/gcc-2.95.2/sw/sparc-solaris2.6/lib/gcc-lib/sparc-sun-solaris2.6/2.95.2/cpp -lang-c -v -I/home/phiril/xml/expat/expat-1.95.6/install/include -D__GNUC__=2 -D__GNUC_MINOR__=95 -Dsparc -Dsun -Dunix -D__svr4__ -D__SVR4 -D__sparc__ -D__sun__ -D__unix__ -D__svr4__ -D__SVR4 -D__sparc -D__sun -D__unix -Asystem(unix) -Asystem(svr4) -D__GCC_NEW_VARARGS__ -Acpu(sparc) -Amachine(sparc) outline.c /var/tmp/ccX2S3hb.i 
  GNU CPP version 2.95.2 19991024 (release) (sparc) 
  #include "..." search starts here: 
  #include <...> search starts here: 
   /home/phiril/xml/expat/expat-1.95.6/install/include 
   /usr/local/include 
   /opt/corp/contrib/gcc-2.95.2/sw/sparc-solaris2.6/lib/gcc-lib/sparc-sun-solaris2.6/2.95.2/../../../../sparc-sun-solaris2.6/include 
   /opt/corp/contrib/gcc-2.95.2/sw/sparc-solaris2.6/lib/gcc-lib/sparc-sun-solaris2.6/2.95.2/include 
   /usr/include 
  End of search list. 
  The following default directories have been omitted from the search path: 
   /opt/corp/contrib/gcc-2.95.2/sw/sparc-solaris2.6/lib/gcc-lib/sparc-sun-solaris2.6/2.95.2/../../../../include/g++-3 
  End of omitted list. 
   /opt/corp/contrib/gcc-2.95.2/sw/sparc-solaris2.6/lib/gcc-lib/sparc-sun-solaris2.6/2.95.2/cc1 /var/tmp/ccX2S3hb.i -quiet -dumpbase outline.c -version -o /var/tmp/cc1zLKSb.s 
  GNU C version 2.95.2 19991024 (release) (sparc-sun-solaris2.6) compiled by GNU C version 2.95.2 19991024 (release). 
   /usr/ccs/bin/as -V -Qy -s -o /var/tmp/ccDihHCo.o /var/tmp/cc1zLKSb.s 
  /usr/ccs/bin/as: WorkShop Compilers 5.0 98/12/21 
   /opt/corp/contrib/gcc-2.95.2/sw/sparc-solaris2.6/lib/gcc-lib/sparc-sun-solaris2.6/2.95.2/collect2 -V -Y P,/usr/ccs/lib:/usr/lib -Qy /opt/corp/contrib/gcc-2.95.2/sw/sparc-solaris2.6/lib/gcc-lib/sparc-sun-solaris2.6/2.95.2/crt1.o /opt/corp/contrib/gcc-2.95.2/sw/sparc-solaris2.6/lib/gcc-lib/sparc-sun-solaris2.6/2.95.2/crti.o /usr/ccs/lib/values-Xa.o /opt/corp/contrib/gcc-2.95.2/sw/sparc-solaris2.6/lib/gcc-lib/sparc-sun-solaris2.6/2.95.2/crtbegin.o -L/home/phiril/expat/expat-1.95.6/install/lib -L/opt/corp/contrib/gcc-2.95.2/sw/sparc-solaris2.6/lib/gcc-lib/sparc-sun-solaris2.6/2.95.2 -L/usr/ccs/bin -L/usr/ccs/lib -L/opt/corp/contrib/gcc-2.95.2/sw/sparc-solaris2.6/lib /var/tmp/ccDihHCo.o -lgcc -lc -lgcc /opt/corp/contrib/gcc-2.95.2/sw/sparc-solaris2.6/lib/gcc-lib/sparc-sun-solaris2.6/2.95.2/crtend.o /opt/corp/contrib/gcc-2.95.2/sw/sparc-solaris2.6/lib/gcc-lib/sparc-sun-solaris2.6/2.95.2/crtn.o 
  ld: Software Generation Utilities - Solaris Link Editors: 5.7-1.280 
  Undefined               first referenced 
   symbol                     in file 
  XML_GetErrorCode                    /var/tmp/ccDihHCo.o 
  XML_ErrorString                     /var/tmp/ccDihHCo.o 
  XML_ParserCreate                    /var/tmp/ccDihHCo.o 
  XML_GetCurrentLineNumber            /var/tmp/ccDihHCo.o 
  XML_Parse                           /var/tmp/ccDihHCo.o 
  XML_SetElementHandler               /var/tmp/ccDihHCo.o 
  ld: fatal: Symbol referencing errors. No output written to a.out 
  collect2: ld returned 1 exit status 

  What am I missing?

  Thanks,

  Lindani

From PGATTU at bloomberg.net  Wed Apr 16 12:47:42 2003
From: PGATTU at bloomberg.net (PRAVEEN GATTU, BLOOMBERG/ 499 PARK)
Date: Wed Apr 16 12:15:58 2003
Subject: [Expat-discuss] Question with memory
Message-ID: <200304161547.h3GFlgX16734@p057.bloomberg.com>

Hi,
  I have just started using Expat XML parser and got a question with it. I have 
a file of the order of 50Mb, and I wanted to parse it. I ran a loop reading each
 line to a buffer I got from calling XML_GetBuffer(), but I have a concern here,
 does Expat free the space once it encounters the end tag? When i went through 
the code I got a impression that the freeing is done only after the entire 
document is parsed, but I am not sure of it. 
  I wrote a simple test module where I printed out the address which 
XML_GetBuffer() function returns and it looks to me that memeory is not reused. 
Can some one clarify about it. Thanks -Praveen



From karl at waclawek.net  Wed Apr 16 14:14:42 2003
From: karl at waclawek.net (Karl Waclawek)
Date: Wed Apr 16 13:14:49 2003
Subject: [Expat-discuss] Question with memory
References: <200304161547.h3GFlgX16734@p057.bloomberg.com>
Message-ID: <001101c3043b$ab9e0f70$9e539696@citkwaclaww2k>


>   I have just started using Expat XML parser and got a question with it. I have 
> a file of the order of 50Mb, and I wanted to parse it. I ran a loop reading each
>  line to a buffer I got from calling XML_GetBuffer(),

You should not really process line by line, since that may
alter the document if you consume the line breaks.
Just read the file buffer by buffer (in whatever buffer size you like)
and pass that to Expat. Check the demo apps in the Expat distribution.

> but I have a concern here,
>  does Expat free the space once it encounters the end tag? When i went through 
> the code I got a impression that the freeing is done only after the entire 
> document is parsed, but I am not sure of it. 

Don't free a buffer allocated by Expat. Expat will take care of it.

>   I wrote a simple test module where I printed out the address which 
> XML_GetBuffer() function returns and it looks to me that memeory is not reused. 
> Can some one clarify about it. Thanks -Praveen

That is internal to Expat - sometimes Expat will re-allocate
internally due to unused input at the end of the previous buffer.
Again, check the demo apps and follow their example.

Karl

From gp at familiehaase.de  Thu Apr 17 09:05:18 2003
From: gp at familiehaase.de (Gerrit P. Haase)
Date: Thu Apr 17 02:01:17 2003
Subject: [Expat-discuss] libtool-1.5, autoconf-2.57, automake-1.73,
	please upgrade
Message-ID: <88135067456.20030417080518@familiehaase.de>

Hallo,

Recently, libtool-1.5 was released.
Would be great if all of the expat maintainers could
update their build systems as soon as possible.

libtool-1.5 depends on autoconf 2.57 and (if someone
want to make another attempt to make use of automake)
automake-1.73

>From the Cygwin announcement:
===
At long last, the super spiffy auto-import-based, mostly "just like
unix" DLL support for cygwin is available in the official, stable, 
libtool release.  Now is the time to start bugging your favorite 
upstream maintainers to update their packages to the latest autotools -- 
and in most cases, they'll get cygwin and mingw DLLs for free.
===


Gerrit
-- 
=^..^=


From gstein at lyra.org  Thu Apr 17 01:09:10 2003
From: gstein at lyra.org (Greg Stein)
Date: Thu Apr 17 03:08:53 2003
Subject: [Expat-discuss] libtool-1.5, autoconf-2.57, automake-1.73,
	please upgrade
In-Reply-To: <88135067456.20030417080518@familiehaase.de>
References: <88135067456.20030417080518@familiehaase.de>
Message-ID: <20030417070910.GM18345@lyra.org>

On Thu, Apr 17, 2003 at 08:05:18AM +0200, Gerrit P. Haase wrote:
> Hallo,
> 
> Recently, libtool-1.5 was released.
> Would be great if all of the expat maintainers could
> update their build systems as soon as possible.

Hmm. Haven't looked at it yet. I don't know that we're really stressing for
a new libtool, but I'll put this on the backburner. It might be useful for
some other projects, too. But I'm also leery of switching something like
Expat over to "new" code. Expat gets installed all over the place by a great
many people. As a result, it seems prudent to be a bit conservative.

> libtool-1.5 depends on autoconf 2.57 and (if someone
> want to make another attempt to make use of automake)
> automake-1.73

Not a chance on automake. Don't even get me started...

> >From the Cygwin announcement:
> ===
> At long last, the super spiffy auto-import-based, mostly "just like
> unix" DLL support for cygwin is available in the official, stable, 
> libtool release.  Now is the time to start bugging your favorite 
> upstream maintainers to update their packages to the latest autotools -- 
> and in most cases, they'll get cygwin and mingw DLLs for free.
> ===

Ah. Interesting. Well, I'd be quite happy to see some patches for the new
libtool and autoconf, and then how those reflect out to the cygwin stuff.
But given that I don't use any of that technology, I won't be able to test
or develop the patches.

Cheers,
-g

-- 
Greg Stein, http://www.lyra.org/

From carlos at pehoe.civil.ist.utl.pt  Wed Apr 16 20:07:45 2003
From: carlos at pehoe.civil.ist.utl.pt (Carlos Pereira)
Date: Thu Apr 17 10:31:58 2003
Subject: [Expat-discuss] file pointers or descriptors?
Message-ID: <20030416180745.3B12A850@pehoe.civil.ist.utl.pt>

Hi,

I am reading both local and remote files,
using HTTP and FTP (anonymous) protocols,
and then sending the relevant contents to Expat.

For the sake of elegance and maintenance, I want
to handle all the three cases using the same
routine to read the file contents.

At the moment I am using file descriptors and is
working fine, but I think it would be better to
use file pointers instead, which is ansi standard,

Is this a good ideia, to convert the internet socket 
file descriptors to file pointers with fdopen and 
then just use the normal stdio.h functions? is there
something that I should be worried about?

According to K&R, BSD and System V Unixes even
use different headers (<unistd.h> and sys/file.h) 
to declare the open system call...

Thanks for the comments!

Carlos

From karl at waclawek.net  Thu Apr 17 11:41:37 2003
From: karl at waclawek.net (Karl Waclawek)
Date: Thu Apr 17 10:41:44 2003
Subject: [Expat-discuss] Question with memory
References: <200304171433.h3HEXPw20148@p057.bloomberg.com>
Message-ID: <003301c304ef$735b6450$9e539696@citkwaclaww2k>


> Karl - Thanks for your reply. -Praveen

I should add that there is one exception where Expat allocates a buffer
and the application has to free it. When an element declaration handler 
(set with XML_SetElementDeclHandler) returns a content model, then it is
the programmer's responsibility to free that content model using XML_FreeContentModel.

Karl


From gp at familiehaase.de  Thu Apr 17 23:49:19 2003
From: gp at familiehaase.de (Gerrit P. Haase)
Date: Thu Apr 17 16:53:28 2003
Subject: [Expat-discuss] Re: libtool-1.5, autoconf-2.57, automake-1.73,
	please upgrade
In-Reply-To: <20030417070910.GM18345@lyra.org>
References: <88135067456.20030417080518@familiehaase.de>
	<20030417070910.GM18345@lyra.org>
Message-ID: <4334655331.20030417224919@familiehaase.de>

Hallo Greg,

Am Donnerstag, 17. April 2003 um 09:09 schriebst du:
> On Thu, Apr 17, 2003 at 08:05:18AM +0200, Gerrit P. Haase wrote:
>> Recently, libtool-1.5 was released.
>> Would be great if all of the expat maintainers could
>> update their build systems as soon as possible.

> Hmm. Haven't looked at it yet. I don't know that we're really stressing for
> a new libtool, but I'll put this on the backburner. It might be useful for
> some other projects, too. But I'm also leery of switching something like
> Expat over to "new" code. Expat gets installed all over the place by a great
> many people. As a result, it seems prudent to be a bit conservative.

I use the 'new' libtool for the Cygwin releases since I do the
releases.  It wasn't possible to build Libexpat on Cygwin with the
provided libtool (1.42), without patching it, because libtool was
broken in some way (regarding Cygwin support).


>> libtool-1.5 depends on autoconf 2.57 and (if someone
>> want to make another attempt to make use of automake)
>> automake-1.73

> Not a chance on automake. Don't even get me started...

I remember...

>> >From the Cygwin announcement:
>> ===
>> At long last, the super spiffy auto-import-based, mostly "just like
>> unix" DLL support for cygwin is available in the official, stable, 
>> libtool release.  Now is the time to start bugging your favorite 
>> upstream maintainers to update their packages to the latest autotools -- 
>> and in most cases, they'll get cygwin and mingw DLLs for free.
>> ===

> Ah. Interesting. Well, I'd be quite happy to see some patches for the new
> libtool and autoconf, and then how those reflect out to the cygwin stuff.
> But given that I don't use any of that technology, I won't be able to test
> or develop the patches.

For a Cygwin release of Libexpat I need to do a reconf (libtoolize &
autoheader & autoconf) everytime with the special Cygwin libtool which
we used all the time before libtool-1.5 was released.  Then the build
succeeds.  Most of the Cygwin patches are now included in libtool-1.5,
so we arrived the point were we don't need a special version of
libtool anymore (well, I hope so).  As long as packages I'm
maintaining are building without changes to libtool I don't change
them (e.g. indent or enscript which are just executables and no
DLL's),  but all the lib packages were DLL's are builded and which are
depending on libtool need to be relibtoolized with a libtool version
that works with Cygwin (e.g. Libexpat or Berkeley DB).

I will happily test all available new verisons of Libexpat and make
releases for the Cygwin netrelease as I did before.


Gerrit
-- 
=^..^=


From Stephen.Beckwith at L-3com.com  Mon Apr 21 09:21:21 2003
From: Stephen.Beckwith at L-3com.com (Beckwith, Stephen @ GNS)
Date: Mon Apr 21 09:02:57 2003
Subject: [Expat-discuss] Newbie Question
Message-ID: <4118282C375DF64EA700135193EEB8CA4B0A3B@ACUSH02>

Greetings,
   I am a "C" programmer, interested in using Expat for an "embedded"
application.  I have read the documentation and learning about XML.  My
intention is to use XML to describe parameters being used to configure some
embedded equipment.  
  Being an embedded programmer, I have limited experience when it comes to
"parsing", though I have done some of this in the past (in a much more
simplistic way).  I get the general "hint" (I think) of what the Parser is
doing, but I have a problem with:
1.  Is there a "single" START and END Tag call back function in one's
program?  IF YES, then:
2.  How does one distinguish the possible "tags" that could be passed back?
I would think that one would setup the Parser with a list of the "expected"
tags to be parsed, and then equate each of these with a separate function.
However, my impression is that the parser is written to be "generic" in that
it only parses to the semantics of what a "tag" is (i.e. it looks for the
"<" and "/>") and you're left with handling the rest.  Am I correct in this
view? 
Thanks in advance for your insights.
Regards,
Stephen Beckwith,
Systems Engineer/Software Developer
L-3 Communications, GNS
Horsham, PA


From fdrake at acm.org  Mon Apr 21 10:17:12 2003
From: fdrake at acm.org (Fred L. Drake, Jr.)
Date: Mon Apr 21 09:19:09 2003
Subject: [Expat-discuss] Newbie Question
In-Reply-To: <4118282C375DF64EA700135193EEB8CA4B0A3B@ACUSH02>
References: <4118282C375DF64EA700135193EEB8CA4B0A3B@ACUSH02>
Message-ID: <16035.61272.364889.900589@grendel.zope.com>


Beckwith, Stephen @ GNS writes:
 > 1.  Is there a "single" START and END Tag call back function in one's
 > program?  IF YES, then:
 > 2.  How does one distinguish the possible "tags" that could be passed back?
 > I would think that one would setup the Parser with a list of the "expected"
 > tags to be parsed, and then equate each of these with a separate function.

You should review the documentation for XML_SetStartElementHandler();
it only sets one, and doesn't associate it with a tag name.  You can
easily wite a wrapper that does the kind of tag-based dispatch you're
suggesting.

 > However, my impression is that the parser is written to be "generic" in that
 > it only parses to the semantics of what a "tag" is (i.e. it looks for the
 > "<" and "/>") and you're left with handling the rest.  Am I correct in this
 > view? 

The tag name and attributes are parsed for you; so whether you're left
with "the rest" depends on how you define "the rest".  It's up to you
to perform dispatch based on tag name or other contextual information;
this is something that varies enough between applications that it
can't be fully general, though some widely useful idioms have been
employed (such as tag-name based dispatch).


  -Fred

-- 
Fred L. Drake, Jr.  <fdrake at acm.org>
PythonLabs at Zope Corporation

From brian.hall at vtenants.com  Thu Apr 24 19:41:02 2003
From: brian.hall at vtenants.com (brian.hall@vtenants.com)
Date: Thu Apr 24 19:43:02 2003
Subject: [Expat-discuss] Does anyone have a Solaris 7 for UltraSparc binary
	distribution?
Message-ID: <3EA8760E.1040000@vtenants.com>

I don't have shell access to the machine to build it, otherwise I'd do 
it myself...

Brian Hall



From fdrake at acm.org  Sat Apr 26 00:34:13 2003
From: fdrake at acm.org (Fred L. Drake, Jr.)
Date: Fri Apr 25 23:34:40 2003
Subject: [Expat-discuss] file pointers or descriptors?
In-Reply-To: <20030416180745.3B12A850@pehoe.civil.ist.utl.pt>
References: <20030416180745.3B12A850@pehoe.civil.ist.utl.pt>
Message-ID: <16041.65077.172836.133506@grendel.zope.com>


Carlos Pereira writes:
 > I am reading both local and remote files,
 > using HTTP and FTP (anonymous) protocols,
 > and then sending the relevant contents to Expat.
 > 
 > For the sake of elegance and maintenance, I want
 > to handle all the three cases using the same
 > routine to read the file contents.

It's not clear what interface you're using with each of the data
sources; perhaps that would help.

 > At the moment I am using file descriptors and is
 > working fine, but I think it would be better to
 > use file pointers instead, which is ansi standard,

Perhaps.  File descriptors are specified by POSIX, so you're on pretty
safe ground there as well.

 > Is this a good ideia, to convert the internet socket 
 > file descriptors to file pointers with fdopen and 
 > then just use the normal stdio.h functions? is there
 > something that I should be worried about?

My own inclination would be to use file descriptors directly.  Since
you're basically just reading chunks of data and passing them to
Expat, you don't benefit from the buffering added by the stdio library
(using FILE *s).  On Unix, using file descriptors is the native
iterface, so you're not going to beat it be adding an extra layer of
wrappers (stdio), and on Windows, both sets of APIs are wrappers
around the Win32 API.  Sockets are a similar story; the native API on
Unix uses file descriptors, and on Win32, everything's a wrapper
around Win32 anyway.

 > According to K&R, BSD and System V Unixes even
 > use different headers (<unistd.h> and sys/file.h) 
 > to declare the open system call...

Yes, but you'll need to deal with these issues on most large projects
that need to run on both.  You can use the autoconf stuff easily
enough for this.


  -Fred

-- 
Fred L. Drake, Jr.  <fdrake at acm.org>
PythonLabs at Zope Corporation