You can subscribe to this list here.
2001 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(1) |
Oct
|
Nov
|
Dec
|
---|---|---|---|---|---|---|---|---|---|---|---|---|
2002 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(1) |
Sep
|
Oct
|
Nov
|
Dec
|
2004 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(1) |
Dec
|
2005 |
Jan
(14) |
Feb
(13) |
Mar
(4) |
Apr
(3) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2006 |
Jan
|
Feb
(2) |
Mar
(1) |
Apr
|
May
|
Jun
|
Jul
(3) |
Aug
(9) |
Sep
(2) |
Oct
(1) |
Nov
|
Dec
|
2007 |
Jan
(6) |
Feb
|
Mar
(2) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(4) |
Nov
|
Dec
|
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-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: Dowling, W. (W. (TS USA) <wil...@th...> - 2005-01-24 22:06:37
|
One limitation of the flexml-generated parser is that its prototype is fixed within flexml: int yylex() In order to pass in a parameter to the generated parser, I had to resort to a flex command line that contained this (I am generating C++ code, hence the class declaration) -PLinksXML \ -DYY_DECL='"class LinksAPIStart; static LinksAPIStart * private_Start_ptr; int LinksXMLlex(LinksAPIStart *LinksAPIStart_ptr)"' \ -DYY_USER_INIT='"private_Start_ptr=LinksAPIStart_ptr;"' This trick allows me to refer to the parameter passed into the parser (LinksAPIStart_ptr) using the name private_Start_ptr in my .act file. I sure would like a cleaner way to do this. Any ideas? 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: 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-06 19:47:12
|
[answer to a public list with Will's agreement] On Wed, Jan 05, 2005 at 02:30:25PM -0500, William F. Dowling wrote: > I am on the flexml-users mailing list. >=20 > I have not checked in all the changes to flexml that I am currently > using. In particular, I have not checked in changes to the skeleton > file (since that is user-specifiable anyway). These changes include >=20 > - replacement of 'new' identifier so flexml-generated code compiles > under C++ >=20 > - modifiy logic weakly so 'flex scanner jammed' cannot occur. >=20 > - some new error message control >=20 > - modification so multiple calls to flexml-generated scanner work. >=20 > - (I think I made a mod so flexml-generated code is OK for current flex > rev; but I'm not sure because I had to downgrade to old flex for > independent reasons.) >=20 > BTW with the mods I have made I am using a flexml-generated scanner in a > production environment.) Let's work together because I think flexml is a > great tool and it's too bad that it has sort of languished. =20 >=20 > Will Hello, those changes all look good. I hope you will find the time to commit them, so that we all can get them. At the first glance, there is no dupplicate work with Arnaud's last changes, which is a good news :) I also think that flexml is too neat to die slowly the way it used to do, and I'm very happy to see that we are one more around flexml. Thanks for your time, Mt. |
From: Martin Q. <mar...@im...> - 2005-01-06 19:41:18
|
[Both Arnaud and I are on -users, now -- at least -- cutting CC] On Wed, Jan 05, 2005 at 09:38:37PM -0500, Kristoffer H Rose wrote: > No problem. I am actually the maintainer of the debian package so keep m= e=20 > posted. :) OOoops, sorry, I was sure that Pierre took over the maintainanceship last summer, that's why I didn't spoke about that with you. Sorry. Would you mind if I upload a new version containing the recent changes, adding myself to the uploaders? Or maybe you prefer me to take over the maintainanceship? [I don't really care] Thanks for your time,=20 Mt. |
From: Kristoffer H R. <kri...@us...> - 2005-01-06 02:39:34
|
No problem. I am actually the maintainer of the debian package so keep me posted. :) __ Kristoffer H Rose, Ph.D. <kri...@us...> +1(914)784-7642 (fax 6324) IBM T. J. Watson Research Center, PO Box 704, Yorktown Heights, NY 10598 |
From: Arnaud L. <Arn...@im...> - 2005-01-05 20:45:47
|
Today Kritoffer wrote: > I have made you administrator...are any of you also debian developers or > would you prefer if I upload flexml to debian myself? Martin is a debian developer. So I think he'll take care of everything with migus from now on. Cheers, Arnaud -- Beware of bugs in the above code; I have only proved it correct, not tried it. -- D.E.Knuth |
From: Kristoffer H R. <kri...@us...> - 2005-01-05 20:39:35
|
I have made you administrator...are any of you also debian developers or would you prefer if I upload flexml to debian myself? Cheers, Kristoffer __ Kristoffer H Rose, Ph.D. <kri...@us...> +1(914)784-7642 (fax 6324) IBM T. J. Watson Research Center, PO Box 704, Yorktown Heights, NY 10598 |
From: Martin Q. <mar...@im...> - 2005-01-05 19:52:21
|
Dear Kristoffer, I would like to create a new list to which cvs commit messages could be sent. Unfortunately, I cannot do so because you gave us the developer status within the project. As I understand things, you don't have that much time to devote to flexml and I would like not to rely on you for such tasks. That's why I would appreciate if you could give me the administrator status within the project, please ? Thanks in advance, Mt. On Tue, Jan 04, 2005 at 04:53:20PM -0500, Kristoffer H Rose wrote: > Dear Arnaud and Martin, >=20 > I've added you; I look forward to development starting again! >=20 > Cheers, > Kristoffer <kri...@us...> >=20 > __ > Kristoffer H Rose, Ph.D. <kri...@us...> +1(914)784-7642 (fax 6324) > IBM T. J. Watson Research Center, PO Box 704, Yorktown Heights, NY 10598 >=20 |
From: Arnaud L. <Arn...@im...> - 2005-01-05 19:32:52
|
Hello, I have just finished committing my modifications. I have updated the debian changelog accordingly. Feel free to check my modifications from the CVS (they are much more detailed as I did them step by step so that everybody can easily check) before publishing it. flexml (1-6.2) unstable; urgency=low * Fix a few bugs and make gcc happy. * Make flexml work with the current flex (closes: #192692, #192243). * Change the build-dep to flex and make lintian happy. -- Arnaud Legrand <Arn...@im...> Wed, 5 Jan 2005 10:27:58 -0800 Migus, I let you close #192692 and #192243 by yourself. Cheers, Arnaud Legrand -- Failure is not an option. It comes bundled with software. |
From: Pierre M. <pma...@de...> - 2005-01-04 22:10:02
|
Hi guys, On Tue, Jan 04, 2005 at 10:07:06PM +0100, Martin Quinson wrote: > Hello, >=20 > I come to you about the FlexML project you are member of. Me and a friend= of > mine (Arnaud, in CC) are very interested in this project and decided to > partially base our academic project on flexml.=20 >=20 > As you all know, there is some issues with the current version, such as t= he > incompatibility with the newest versions of flex. The fact is that our > locally hacked version does solve this issue. We browsed the bug list, and > we think that we should be able to tackle some other bugs. I am very pleased that you worked on flexml. I worked on it last summer, but unfortunately I had not the time to enhance it. > This is why we would like to be given the cvs write right. The easiest for > us would be if you could add both of us ('mquinson' and 'legranda') to the > list of the developpers of the project. Of course, we will proceed carefu= lly > afterward and not trash anything (at least, not on purpose :). >=20 > Pierre, at least you know me, I think you can speakup in my favor if you > cannot do the work yourself... Of course I am very pleased to help you. Martin and Arnaud are wonderful. I think that you already have write access to the cvsroot. I would like to wish everybody an happy new year.=20 Thanks a lot, --=20 Pierre Machard <pma...@de...> http://debian.org GPG: 1024D/23706F87 : B906 A53F 84E0 49B6 6CF7 82C2 B3A0 2D66 2370 6F87 |
From: Kristoffer H R. <kri...@us...> - 2005-01-04 21:55:11
|
Dear Arnaud and Martin, I've added you; I look forward to development starting again! Cheers, Kristoffer <kri...@us...> __ Kristoffer H Rose, Ph.D. <kri...@us...> +1(914)784-7642 (fax 6324) IBM T. J. Watson Research Center, PO Box 704, Yorktown Heights, NY 10598 |
From: Martin Q. <mar...@im...> - 2005-01-04 21:09:38
|
Hello, I come to you about the FlexML project you are member of. Me and a friend of mine (Arnaud, in CC) are very interested in this project and decided to partially base our academic project on flexml.=20 As you all know, there is some issues with the current version, such as the incompatibility with the newest versions of flex. The fact is that our locally hacked version does solve this issue. We browsed the bug list, and we think that we should be able to tackle some other bugs. This is why we would like to be given the cvs write right. The easiest for us would be if you could add both of us ('mquinson' and 'legranda') to the list of the developpers of the project. Of course, we will proceed carefully afterward and not trash anything (at least, not on purpose :). Pierre, at least you know me, I think you can speakup in my favor if you cannot do the work yourself... Thanks for your time, and for this neat tool. Mt. |
From: Benoit G. <gu...@th...> - 2004-11-18 10:05:18
|
Hello, I'm trying to use flexml and I see that some error cases are not catched. I've seen that the section 'FLEXML_FINAL' is not set in the default skeleton so that the global error catching code is not expanded in the generated lex file. I can understand that since the rules are really general (and in most cases cannot be reached) but I think that at least the all functionnal error cases should be catched by default. The patch I did in the flexml file is the following : elsif ( /^FLEXML_FINAL$/ and not $nofail ) { # Catch-all "real" error cases. for my $tag (@tags) { for (split ',',$states{$tag}) { # The error cases for end states are managed somewhere else if (not exists $mixed{$tag} and not ($endstates{$tag} =3D~ /$_/)) { print "<$_>{\n"; print " \"<\"{Name} FAIL(\"Unexpected tag `%s'.\", yytext+1);\n"; print " . FAIL(\"Unexpected CDATA `%c' in $tag.\",yytext[0]);\n"; print "}\n"; } } } } But I am not sur it works in all cases... Regards, -- Beno=EEt Guillon TRT/SML THALES RESEARCH & TECHNOLOGY |
From: Devin K. <de...@SD...> - 2002-08-14 21:57:07
|
First a minor bug report. when flexml generates the header file from a DTD it doesn't put a full #ifndef gard in the header. So you get: #ifndef _FLEXML_blah_H ... stuff ... #endif where as it needs a #define right after the #ifndef. I'd submit a patch but it's probably easier to just do by hand. Are the mailing lists still active? Also I've had some problems with the parser that flexml generates, all of which I managed to fix by tweaking the skel file and a sed run over the generated lex file. Basically the problem is that the XML that I want to parse is being read off a network connection and doesn't contain the <!DOCTYPE ...> header. The fix I came up with was to not use the ROOT_<tag> states and just match the begining of the tags in the PROLOG state instead. Is this reasonable? Would this a feature worth putting into FleXML? I would be willing to do the coding if I can find the time. The final question is on user defined skeleton files. From my perspective it would be very nice if I could specify a skeleton file *in additon to* the default one. Basically insert it between %{ and %} in the lex file. Also wrap some of the macros like FAIL in #ifndef's so that the user can override them. Any interest/thoughts? thanks, -- Devin Kowatch de...@sd... |
From: Stephen H. <sh...@us...> - 2001-09-01 14:51:26
|
As I have been going through the flexml generated flex code, I found a few state transitions that were a) unnessesary, or others b) missing. The unnessesary states and edges were generated from the translation of * into +?. So, instead of looking for zero or more (aka, *), it looked for ( one or more(+) ) or zero(?) This lead to some additional state changes that could be optimized out. Another way of representing the +?* combo is to represent a+ as a(a)*. Anyway, I've hacked up the code to output state diagrams that are drawn by AT&T lab's dot program (part of the graphviz package). The missing edges are more for error catching / not using the flex default rule, bug 457550, need to be added. https://sourceforge.net/tracker/index.php?func=detail&aid=457550&group_id=34654&atid=411869 |