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 |