From: Dowling, W. (W. (TS USA) <wil...@th...> - 2005-01-24 20:49:39
|
I have checked in mods to the files skel: - Handle ']' at end of CDATA like: <![CDATA[val xxx]]]>; - Do not print to stderr: add primitive error message facility; - Allow multiple calls/multiple returns, so flexml-generated parsers can parse document sequences (>1 document in a stream); - Allow failure from all states (<*>) so flex scanner jammed does not occur. flexml.pl - Remove compiler complaint about (void *) <-> (const char **). conversion. -- William F. Dowling Thomson/ISI (www.isinet.com) 215-386-0100 x-1156 ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ |
From: Martin Q. <mar...@im...> - 2005-01-25 08:12:11
|
Hello, On Mon, Jan 24, 2005 at 03:49:13PM -0500, Dowling, William (Will) (TS USA) = wrote: > I have checked in mods to the files > skel: > - Handle ']' at end of CDATA like: <![CDATA[val xxx]]]>; > - Do not print to stderr: add primitive error message facility; > - Allow multiple calls/multiple returns, so flexml-generated parsers > can parse document sequences (>1 document in a stream); > - Allow failure from all states (<*>) so flex scanner jammed does > not occur. >=20 > flexml.pl > - Remove compiler complaint about (void *) <-> (const char **). > conversion. I was reading the changes by curiosity mainly, and I have some questions. (plus an extra changelog entry: do not use the "new" identifier since it breaks in C++ ;) +enum {flexml_max_err_msg_size =3D 512}; Why is flexml_max_err_msg_size an enum and not a const int? I understand that it makes very little difference, but I would find the latter cleaner, wouldn't it? +static char flexml_err_msg[flexml_max_err_msg_size]; +const char * parse_err_msg() +{ + return flexml_err_msg; +} + +static void reset_parse_err_msg() +{ + flexml_err_msg[0] =3D '\0'; +} Would it be possible to create some sort of option somewhere stating whether we're going to display the errors as some as they appear (former behaviour) or if we put them into this mecanism, expecting the user to pool it from there ? Or, more precisely, do we want to do so (since I know how to do so ;)? Thanks a lot for this commit, I'll try to add this option soonish and release a new version right after. Bye, Mt. |
From: William F. D. <wil...@th...> - 2005-01-25 14:30:59
|
On Tue, 2005-01-25 at 03:11, Martin Quinson wrote: > > I was reading the changes by curiosity mainly, and I have some questions. > (plus an extra changelog entry: do not use the "new" identifier since it > breaks in C++ ;) > > +enum {flexml_max_err_msg_size = 512}; > > Why is flexml_max_err_msg_size an enum and not a const int? I understand > that it makes very little difference, but I would find the latter cleaner, > wouldn't it? Just a habit of coding style consistent with local (where I work) code standard, historically arising from the need for the "enum hack" when using older C++ compilers. See Scott Meyers on this quoted at http://www.geocities.com/lgol27/CPlusPlus.htm. (That's an answer, not a justification -- const int would be better. So feel free to change it if you want.) > +static char flexml_err_msg[flexml_max_err_msg_size]; > +const char * parse_err_msg() > +{ > + return flexml_err_msg; > +} > + > +static void reset_parse_err_msg() > +{ > + flexml_err_msg[0] = '\0'; > +} > > Would it be possible to create some sort of option somewhere stating whether > we're going to display the errors as some as they appear (former behaviour) > or if we put them into this mecanism, expecting the user to pool it from > there ? > > Or, more precisely, do we want to do so (since I know how to do so ;)? As an option it would be OK. My bias is toward writing library code, so I would prefer if the default was silence (not writing to stderr). You don't want your library writing to stderr -- that would make it less general and harder to document. Cheers, Will -- William F. Dowling Thomson/ISI (www.isinet.com) 215-386-0100 x-1156 ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ |
From: Martin Q. <mar...@im...> - 2005-02-10 12:19:55
|
Ok, I finally devoted some time to flexml. Sorry for the delay. On Tue, Jan 25, 2005 at 09:30:44AM -0500, William F. Dowling wrote: > On Tue, 2005-01-25 at 03:11, Martin Quinson wrote: >=20 > >=20 > > I was reading the changes by curiosity mainly, and I have some question= s. > > (plus an extra changelog entry: do not use the "new" identifier since it > > breaks in C++ ;) > >=20 > > +enum {flexml_max_err_msg_size =3D 512}; > >=20 > > Why is flexml_max_err_msg_size an enum and not a const int? I understand > > that it makes very little difference, but I would find the latter clean= er, > > wouldn't it? >=20 > Just a habit of coding style consistent with local (where I work) code > standard, historically arising from the need for the "enum hack" when > using older C++ compilers. See Scott Meyers on this quoted at > http://www.geocities.com/lgol27/CPlusPlus.htm. (That's an answer, not a > justification -- const int would be better. So feel free to change it if > you want.) I tried to change this, and had to revert the change since gcc complains about the flexml_err_msg array being dynamically sized. It should be a define, but defines are crude. > > Would it be possible to create some sort of option somewhere stating wh= ether > > we're going to display the errors as some as they appear (former behavi= our) > > or if we put them into this mecanism, expecting the user to pool it from > > there ? > >=20 > > Or, more precisely, do we want to do so (since I know how to do so ;)? >=20 > As an option it would be OK. My bias is toward writing library code, so > I would prefer if the default was silence (not writing to stderr). You > don't want your library writing to stderr -- that would make it less > general and harder to document. I added a -q option which goes to your direction, and left the default being the previous behaviour. I also fixed some long standing trivial bugs against the debian package. We now only have a bunch of open bugs on sourceforge. I closed two of them, but I unfortunately need some help for the remaining... Please people, have a look at https://sourceforge.net/tracker/?group_id=3D34654&atid=3D411869 and see if you can fix some of them... Thanks, Mt. |
From: Dowling, W. (TS USA) <wil...@th...> - 2005-02-14 17:38:56
|
I'd like to modify the Makefile a bit. The principle goal would be to allow >1 version of flexml to exist on a system at the same time. I think this would require putting the 'skel' file in a directory with the version embedded in the path, for example /usr/share/flexml/1.2/skel I would also have the installed executable be flexml-$(VER) and have a symlink in $(BINDIR) from flexml to flexml-$(VER) (mimicking what debian does with /etc/alternatives, but not requiring that.) Perhaps one would do similarly with the documentation and examples. What do people think about that? Will -- William F. Dowling Thomson/ISI (www.thomsonisi.com) 215-386-0100 x-1156 ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ |
From: Martin Q. <mar...@im...> - 2005-02-15 00:58:06
|
On Mon, Feb 14, 2005 at 12:38:29PM -0500, Dowling, Will (TS USA) wrote: > I'd like to modify the Makefile a bit. The principle goal would be to > allow >1 version of flexml to exist on a system at the same time. I > think this would require putting the 'skel' file in a directory with the > version embedded in the path, for example > /usr/share/flexml/1.2/skel >=20 > I would also have the installed executable be flexml-$(VER) and have a > symlink in $(BINDIR) from flexml to flexml-$(VER) (mimicking what debian > does with /etc/alternatives, but not requiring that.) >=20 > Perhaps one would do similarly with the documentation and examples. >=20 > What do people think about that?=20 I don't feel the need to add this by default to the code, but as an option, it would be welcome, I guess. Please make it a specific target of the Makefile so that it doesn't trouble the other targets. You don't want to convert your ton of existing parsers right now, do you ? = hehe. Thanks for your time, Mt. |
From: Dowling, W. (TS USA) <wil...@th...> - 2005-02-15 16:31:07
|
On Mon, 2005-02-14 at 19:56, Martin Quinson wrote: > On Mon, Feb 14, 2005 at 12:38:29PM -0500, Dowling, Will (TS USA) wrote: > > I'd like to modify the Makefile a bit. The principle goal would be to > > allow >1 version of flexml to exist on a system at the same time. [...] > > I don't feel the need to add this by default to the code, but as an option, > it would be welcome, I guess. Please make it a specific target of the > Makefile so that it doesn't trouble the other targets. [...] > You don't want to convert your ton of existing parsers right now, do you ? hehe. No parsers will have to be modified. I'm only talking about modifying the installation location of various flexml components. The output from 'make install' (setting the base directory to /tmp/foo) will be mkdir -p /tmp/foo/bin /tmp/foo/lib \ /tmp/foo/share/man/man1 /tmp/foo/share/doc/flexml-1.2 \ /tmp/foo/share/flexml-1.2 \ /tmp/foo/share/doc/flexml-1.2/html \ /tmp/foo/share/doc/flexml-1.2/examples install -m555 flexml-1.2 /tmp/foo/bin/ install -m555 flexml-act-1.2 /tmp/foo/lib/ install -m444 skel /tmp/foo/share/flexml-1.2/ install -m444 flexml.1 /tmp/foo/share/man/man1/ install -m444 README NOTES TODO flexml-act.dtd EnlargeFlex.patch /tmp/foo/share/doc/flexml-1.2/ install -m444 FleXML.html /tmp/foo/share/doc/flexml-1.2/html/ rm -f /tmp/foo/bin/flexml ln -s /tmp/foo/bin/flexml-1.2 /tmp/foo/bin/flexml make -C examples install make[1]: Entering directory `/links/extern/src/flexml-1.2/examples' mkdir -p /tmp/foo/share/doc/flexml-1.2/flexml/examples install -m444 my.dtd my-show.act my-joke.xml my-joke2.xml my-joke3.xml tricky.dtd tricky.act tricky.xml test.html /tmp/foo/share/doc/flexml-1.2/flexml/examples/ Note /tmp/foo/bin/flexml still exists as a symlink to flexml-1.2. flexml.pl will be changed to make sure it picks up the default skel file from the new place where it was installed. I'd also like to pull out the common definitions in Makefile and examples/Makefile into a single file Makefile.defs, then use include Makefile.defs Any objections? (Do non-gnu make programs handle "include"?) Thanks, Will -- William F. Dowling Thomson/ISI (www.thomsonisi.com) 215-386-0100 x-1156 ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ |
From: Martin Q. <mar...@im...> - 2005-02-15 17:01:23
|
On Tue, Feb 15, 2005 at 11:30:39AM -0500, Dowling, Will (TS USA) wrote: > On Mon, 2005-02-14 at 19:56, Martin Quinson wrote: > > On Mon, Feb 14, 2005 at 12:38:29PM -0500, Dowling, Will (TS USA) wrote: > > > I'd like to modify the Makefile a bit. The principle goal would be to > > > allow >1 version of flexml to exist on a system at the same time. [..= =2E] > >=20 > > I don't feel the need to add this by default to the code, but as an opt= ion, > > it would be welcome, I guess. Please make it a specific target of the > > Makefile so that it doesn't trouble the other targets. [...] > > You don't want to convert your ton of existing parsers right now, do yo= u ? hehe. >=20 > No parsers will have to be modified. I'm only talking about modifying > the installation location of various flexml components. The output from > 'make install' (setting the base directory to /tmp/foo) will be [snip] > Note /tmp/foo/bin/flexml still exists as a symlink to flexml-1.2. > flexml.pl will be changed to make sure it picks up the default skel file > from the new place where it was installed. Yeah, that's what I understood. I'm only faintly interested in this becoming the default mode of installation. If you manage to get it running as a specific make target (ideally, without duplicating too much code), you should commit it. You may even want to commit it anyway so that I can see i= t. If not, we will need the advice of something else (ie, I'm not a fan, but it's only my advice).=20 > I'd also like to pull out the common definitions in Makefile and > examples/Makefile into a single file Makefile.defs, then use > include Makefile.defs >=20 > Any objections? (Do non-gnu make programs handle "include"?) I don't think so, because if so, automake would use it more extensively.=20 But I'm not sure we care about really prehistoric make :) I'd say it's a go= od idea. My last modifications to the Makefile were mainly hacks to get it running quickly. Cleanup is really welcome. Thanks for your time,=20 Mt. |
From: William F. D. <wil...@th...> - 2005-02-15 19:46:30
|
I have commited the changes discussed. If you can think of a better way to allow >1 version to exist on a system at one time, go ahead and back these out and put that in. Also did a few stray Makefile cleanups. Thanks, Will -- William F. Dowling Thomson/ISI (www.thomsonisi.com) 215-386-0100 x-1156 ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ |
From: Martin Q. <mar...@im...> - 2005-02-15 20:35:14
|
On Tue, Feb 15, 2005 at 02:46:10PM -0500, William F. Dowling wrote: > I have commited the changes discussed. If you can think of a better way > to allow >1 version to exist on a system at one time, go ahead and back > these out and put that in. Also did a few stray Makefile cleanups. Looks good to me. If we define a variable=20 SUF :=3D -$(VER) and use it, and then I can do a regular install with=20 make install SUF=3D And then we should be both happy. I'll be offline for a few days, see you when I come back. Have a good one, Mt. PS: I'm on the list... |