flexml-users — for users of FleXML - discuss setup, help, bugs, etc

Re: [FleXML-Users] What about a foreach tag?

[William F. D. <wil...@th...>]

On Sat, 2007-10-13 at 09:51 +0200, Martin Quinson wrote:
> Hello William,
> 
> What I have in mind is a sort of meta-tag, not needing to be
> specifyied in the DTD. Maybe a better way to express what I meant is
> to use this kind of notation:
> [FOREACH[A][list of elements][text to dupplicate]]
> just the same way we have [CDADAT[text to protect]]
> or we had the if construct in SGML (can't remember the syntax right
> now). But that's so awful, that's incredible.

<![CDATA[text to protect]]> is an XML construct described in the
standard: http://www.w3.org/TR/REC-xml/

I'd like to keep flexml as close as possible to the standard (I know
there are a few things we miss, but I'd rather move torward the
standard, not away from it.


> Or, you're right, maybe the solution is to do a new generator in the
> spirit of fleXML, but dedicated to xsl transformations. After all,
> these tags for kinda interpreting the XML are all part of the XSLT
> standard. They are a bit verbose in my taste, but that's the way every
> body does this out there. The name wouldn't even be hard to find:
> fleXSLT ;)

I like it (the name "fleXSLT", and the distinction between fleXML and
fleXSLT).  I am really conflicted about XSLT -- the idea is so good and
the syntax is so shitty!  I think "verbose" is the kindest thing you
could say about it.  So doing something in the spirit of xslt, but a
saner syntax, seems like a great idea.

> And once it's done, having a bit of xslt embeeded within the xml
> should be doable, I guess.

OK.

> But before that, I'm more concerned about the missing rules. I know
> better understand what you said to me about 2 years ago. The parsers
> never jam nowadays, but the default rule is not very appropriate. 

Correct.  It's a little embarrassing that we don't get better messages
out.  I'm glad you're looking into it.

> My last change set in the code was to have an elegant error message
> when a starting tag was misplaced. Previous one was somehting like
> "char '<' found when expecting </mytag>". Now, it's "Starting tag
> <something> not allowed here". That's a bit better, but I'd like to
> have both of the information ("Starting tag <something> found when
> expecting </mytag>"). For this I'll have to explicit much more
> transitions in the lex file.

I'm not sure I understand.  Could you please elaborate?

>  Now, I do one rule for all states where
> the tag is not allowed (check lines flexml.pl:1382-1397). But where
> the hell can I find what each state wants to get further? Those damn
> data structures are not friendly...

Man, I need some time to look into this.

> Another change direction I'd like to follow is the possible use of
> schema instead of DTD as input. Shouldn't be hard, and not intrusive
> either (only parsechildren needs to be changed). Just need some more
> time ;)

Schemas -- that's another area where I'm out of sync with the popular
view.  Everybody is moving to schemas (so you are right, supporting then
in flexml is a great idea) but personally I think they are so ugly and
avoid them when I can.

-- 
William F Dowling
wil...@th...
www.scientific.thomson.com

Re: [FleXML-Users] What about a foreach tag?

[Martin Q. <mar...@lo...>]

Hello William,

What I have in mind is a sort of meta-tag, not needing to be
specifyied in the DTD. Maybe a better way to express what I meant is
to use this kind of notation:
[FOREACH[A][list of elements][text to dupplicate]]
just the same way we have [CDADAT[text to protect]]
or we had the if construct in SGML (can't remember the syntax right
now). But that's so awful, that's incredible.

Or, you're right, maybe the solution is to do a new generator in the
spirit of fleXML, but dedicated to xsl transformations. After all,
these tags for kinda interpreting the XML are all part of the XSLT
standard. They are a bit verbose in my taste, but that's the way every
body does this out there. The name wouldn't even be hard to find:
fleXSLT ;)

And once it's done, having a bit of xslt embeeded within the xml
should be doable, I guess.

But before that, I'm more concerned about the missing rules. I know
better understand what you said to me about 2 years ago. The parsers
never jam nowadays, but the default rule is not very appropriate.=20

My last change set in the code was to have an elegant error message
when a starting tag was misplaced. Previous one was somehting like
"char '<' found when expecting </mytag>". Now, it's "Starting tag
<something> not allowed here". That's a bit better, but I'd like to
have both of the information ("Starting tag <something> found when
expecting </mytag>"). For this I'll have to explicit much more
transitions in the lex file. Now, I do one rule for all states where
the tag is not allowed (check lines flexml.pl:1382-1397). But where
the hell can I find what each state wants to get further? Those damn
data structures are not friendly...

Another change direction I'd like to follow is the possible use of
schema instead of DTD as input. Shouldn't be hard, and not intrusive
either (only parsechildren needs to be changed). Just need some more
time ;)

Bye, Mt.

On Thu, Oct 11, 2007 at 12:48:56PM -0400, William F. Dowling wrote:
> Hi Martin,
>=20
> This looks like something useful to have, but if I am understanding
> correctly, it does not belong in flexml.  The reason is that flexml
> makes no interpretation of any tag or attribute name.  But you are
> proposing that
>   1) the 'foreach' tag now has a specific meaning;
>   2) the 'variable' and 'values' attribute of the 'foreach' tag has a
> specific meaning.
>=20
> These thing will be surprising to someone expecting flexml to be an XML
> parser-generator, as we currently say.
>=20
> Some questions:
>=20
> What if my DTD does not have
>   <!ELEMENT foreach ...>
>=20
> Or are you saying that *if* my DTD has
>   <!ELEMENT foreach (plop)*>
>   <!ATTLIST foreach
>             variable CDATA #REQUIRED
>             values CDATA #REQUIRED>
>=20
> *then* flexml will interpret a document as you indicated?
>=20
> Or, suppose my DTD has
>   <!ELEMENT foreach (plop)*>
>   <!ATTLIST foreach
>             variable CDATA #IMPLIED
>             values CDATA #IMPLIED>
>=20
> what should flexml do?
>=20
> Or, suppose my DTD has
>   <!ELEMENT foreach (plop)*>
>   <!ATTLIST foreach
>             variable NMTOKEN #REQUIRED
>             values CDATA #IMPLIED>
>=20
> what should flexml do?
>=20
> Even if you specify the requirement on the DTD quite tightly, the result
> will be very surprising to somebody who just wants an XML parser.
>=20
> I think your proposal would move flexml from being a parser to being an
> interpretter or parser+interpretter, which would make it harder to
> document (describe), debug, and understand.
>=20
> Maybe some of the flexml codebase could be used to create an xml
> interpretter (I actually like your idea in the specific case of
> 'foerach', but other constructs could also be easily imagined).  Then we
> would might want to refactor out some common parts between the parser
> and the interpreter.
>=20
> Will
>=20
>=20
> On Thu, 2007-10-11 at 17:11 +0200, Martin Quinson wrote:
> > Hello,
> >=20
> > I was thinking about implementing a foreach tag able to multiplicate
> > the xml.
> >=20
> > For example, having the following in the file:
> >   <foreach variable=3D"i" values=3D"1 2 3 4">
> >    <plop key=3D"$i" />
> >   </foreach>
> > would be equivalent to having the following:
> >    <plop key=3D"1" />
> >    <plop key=3D"2" />
> >    <plop key=3D"3" />
> >    <plop key=3D"4" />
> >=20
> > It's somehow close to xsl transformation, but it would be embeeded
> > directly in the XML, not in a separate file. Also, the syntax would be
> > a bit different.
> >=20
> > I have ideas about how to implement the beast, I was just wondering
> > whether having this in flexml (maybe enabled by a command-line option)
> > was ok for you guys, or if it was too specific to my own needs to be
> > placed in the main tree.
> >=20
> > Bye, Mt.
> >=20
> > -----------------------------------------------------------------------=
--
> > This SF.net email is sponsored by: Splunk Inc.
> > Still grepping through log files to find problems?  Stop.
> > Now Search log events and configuration files using AJAX and a browser.
> > Download your FREE copy of Splunk now >> http://get.splunk.com/
> > _______________________________________________ FleXML-Users mailing li=
st Fle...@li... https://lists.sourceforge.net/lists/l=
istinfo/flexml-users
> --=20
> William F Dowling
> wil...@th...
> www.scientific.thomson.com

--=20
In the future, don't waste your time writing articles manually.=20
Use a generator such as http://pdos.csail.mit.edu/scigen/ to ensure
they are funny, if not instructive.    -- Bastard Reviewer From the Hell

Re: [FleXML-Users] What about a foreach tag?

[William F. D. <wil...@Th...>]

Hi Martin,

This looks like something useful to have, but if I am understanding
correctly, it does not belong in flexml.  The reason is that flexml
makes no interpretation of any tag or attribute name.  But you are
proposing that
  1) the 'foreach' tag now has a specific meaning;
  2) the 'variable' and 'values' attribute of the 'foreach' tag has a
specific meaning.

These thing will be surprising to someone expecting flexml to be an XML
parser-generator, as we currently say.

Some questions:

What if my DTD does not have
  <!ELEMENT foreach ...>

Or are you saying that *if* my DTD has
  <!ELEMENT foreach (plop)*>
  <!ATTLIST foreach
            variable CDATA #REQUIRED
            values CDATA #REQUIRED>

*then* flexml will interpret a document as you indicated?

Or, suppose my DTD has
  <!ELEMENT foreach (plop)*>
  <!ATTLIST foreach
            variable CDATA #IMPLIED
            values CDATA #IMPLIED>

what should flexml do?

Or, suppose my DTD has
  <!ELEMENT foreach (plop)*>
  <!ATTLIST foreach
            variable NMTOKEN #REQUIRED
            values CDATA #IMPLIED>

what should flexml do?

Even if you specify the requirement on the DTD quite tightly, the result
will be very surprising to somebody who just wants an XML parser.

I think your proposal would move flexml from being a parser to being an
interpretter or parser+interpretter, which would make it harder to
document (describe), debug, and understand.

Maybe some of the flexml codebase could be used to create an xml
interpretter (I actually like your idea in the specific case of
'foerach', but other constructs could also be easily imagined).  Then we
would might want to refactor out some common parts between the parser
and the interpretter.

Will


On Thu, 2007-10-11 at 17:11 +0200, Martin Quinson wrote:
> Hello,
> 
> I was thinking about implementing a foreach tag able to multiplicate
> the xml.
> 
> For example, having the following in the file:
>   <foreach variable="i" values="1 2 3 4">
>    <plop key="$i" />
>   </foreach>
> would be equivalent to having the following:
>    <plop key="1" />
>    <plop key="2" />
>    <plop key="3" />
>    <plop key="4" />
> 
> It's somehow close to xsl transformation, but it would be embeeded
> directly in the XML, not in a separate file. Also, the syntax would be
> a bit different.
> 
> I have ideas about how to implement the beast, I was just wondering
> whether having this in flexml (maybe enabled by a command-line option)
> was ok for you guys, or if it was too specific to my own needs to be
> placed in the main tree.
> 
> Bye, Mt.
> 
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc.
> Still grepping through log files to find problems?  Stop.
> Now Search log events and configuration files using AJAX and a browser.
> Download your FREE copy of Splunk now >> http://get.splunk.com/
> _______________________________________________ FleXML-Users mailing list Fle...@li... https://lists.sourceforge.net/lists/listinfo/flexml-users
-- 
William F Dowling
wil...@th...
www.scientific.thomson.com

[FleXML-Users] What about a foreach tag?

[Martin Q. <mar...@lo...>]

Hello,

I was thinking about implementing a foreach tag able to multiplicate
the xml.

For example, having the following in the file:
  <foreach variable=3D"i" values=3D"1 2 3 4">
   <plop key=3D"$i" />
  </foreach>
would be equivalent to having the following:
   <plop key=3D"1" />
   <plop key=3D"2" />
   <plop key=3D"3" />
   <plop key=3D"4" />

It's somehow close to xsl transformation, but it would be embeeded
directly in the XML, not in a separate file. Also, the syntax would be
a bit different.

I have ideas about how to implement the beast, I was just wondering
whether having this in flexml (maybe enabled by a command-line option)
was ok for you guys, or if it was too specific to my own needs to be
placed in the main tree.

Bye, Mt.

--=20
Testing can only prove the presence of bugs.     --- Dijkstra

Re: [FleXML-Users] Newbie question...

[William F. D. <wil...@th...>]

Very interesting Mike.  Thanks for the very clear example.  I am almost
positive that any code I had added to support attribute access from
end-tags did *not* keep a stack of attribute values, thus accounting
exactly for the behaviour you are seeing.

So this is a definite bug.

Until this bug gets fixed, I think you'll have to keep your own stack of
attribute values that you are interested in, pushed at start-tag time
and popped at end-tag time.  That's not ideal, but at least your code
could work that way.

Thanks again for the bug report,

Will

On Tue, 2007-03-20 at 16:12 +0000, Mike Aubury wrote:
> Long time - i know - but I've tracked the bug down to a minimal example (I 
> hope !), its down to 'recursive' tags : 
> 
> 
> 
> <expr_str e_expr_type='ET_EXPR_FCALL' nm='fcall' >
>  <s_expr_function_call>
>   <expr_str nm='list' />
>  </s_expr_function_call>
> </expr_str>
> 
> 
> In this example - when we get to the second expr_str end tag - '{nm}' will be 
> set to 'list' in the end tag - not 'fcall'...
> 
> 
> On Monday 08 January 2007 15:56, William F. Dowling wrote:
> > On Mon, 2007-01-08 at 15:20 +0000, Mike Aubury wrote:
> > > What version did this go in ?
> > >
> > > flexml --version reports I'm using
> > > 	FleXML version Id: flexml.pl,v 1.61 2006/09/13 16:34:33 wdowling Exp
> >
> > As of flexml.pl 1.58 you are supposed to have access to attributes from
> > inside the end-tag processing code.
> >
> > Please enter a bug in the sourceforge bug tracker for flexml if you can
> > confirm that attribute access inside end-tag processing is not working.
> > Ideally, could you submit an absolutely minimal example that shows the
> > failure?
> >
> > Thanks,
> >
> > Will
> >
> > > On Monday 08 January 2007 15:12, William F. Dowling wrote:
> > > > On Mon, 2007-01-08 at 08:54 +0000, Mike Aubury wrote:
> > > > > Follow up to this - am i right in assuming that we should not be
> > > > > accessing the attributes in an 'end' block ?
> > > > > If so - should doing this cause an error ?
> > > > >
> > > > >
> > > > > (My code wasn't working until I moved some of the checking to the
> > > > > 'start' block instead..)
> > > >
> > > > There was some discussion about this on on the flexml-users mailing
> > > > list a few months ago:
> > > >
> > > > http://sourceforge.net/mailarchive/forum.php?thread_id=30370096&forum_i
> > > >d=59 3
> > > >
> > > > I forget what the upshot was -- it looks like I investigated and at
> > > > least thought the change (to make attributes accessible from the
> > > > end-tag processing code) would be easy. Martin Quinson had asked for
> > > > that.
> > > >
> > > > Martin: as far as you know, was that change made?
> > > >
> > > > Will
> 
-- 
William F Dowling
wil...@th...
www.scientific.thomson.com

Re: [FleXML-Users] Newbie question...

[Mike A. <mik...@au...>]

Long time - i know - but I've tracked the bug down to a minimal example (I 
hope !), its down to 'recursive' tags : 



<expr_str e_expr_type='ET_EXPR_FCALL' nm='fcall' >
 <s_expr_function_call>
  <expr_str nm='list' />
 </s_expr_function_call>
</expr_str>


In this example - when we get to the second expr_str end tag - '{nm}' will be 
set to 'list' in the end tag - not 'fcall'...


On Monday 08 January 2007 15:56, William F. Dowling wrote:
> On Mon, 2007-01-08 at 15:20 +0000, Mike Aubury wrote:
> > What version did this go in ?
> >
> > flexml --version reports I'm using
> > 	FleXML version Id: flexml.pl,v 1.61 2006/09/13 16:34:33 wdowling Exp
>
> As of flexml.pl 1.58 you are supposed to have access to attributes from
> inside the end-tag processing code.
>
> Please enter a bug in the sourceforge bug tracker for flexml if you can
> confirm that attribute access inside end-tag processing is not working.
> Ideally, could you submit an absolutely minimal example that shows the
> failure?
>
> Thanks,
>
> Will
>
> > On Monday 08 January 2007 15:12, William F. Dowling wrote:
> > > On Mon, 2007-01-08 at 08:54 +0000, Mike Aubury wrote:
> > > > Follow up to this - am i right in assuming that we should not be
> > > > accessing the attributes in an 'end' block ?
> > > > If so - should doing this cause an error ?
> > > >
> > > >
> > > > (My code wasn't working until I moved some of the checking to the
> > > > 'start' block instead..)
> > >
> > > There was some discussion about this on on the flexml-users mailing
> > > list a few months ago:
> > >
> > > http://sourceforge.net/mailarchive/forum.php?thread_id=30370096&forum_i
> > >d=59 3
> > >
> > > I forget what the upshot was -- it looks like I investigated and at
> > > least thought the change (to make attributes accessible from the
> > > end-tag processing code) would be easy. Martin Quinson had asked for
> > > that.
> > >
> > > Martin: as far as you know, was that change made?
> > >
> > > Will

-- 
Mike Aubury

Aubit Computing Ltd is registered in England and Wales, Number: 3112827
Registered Address : Murlain Business Centre, Union Street, Chester, CH1 1QP

Re: [FleXML-Users] Newbie question...

[William F. D. <wil...@th...>]

On Mon, 2007-01-08 at 15:20 +0000, Mike Aubury wrote:
> What version did this go in ? 
> 
> flexml --version reports I'm using 
> 	FleXML version Id: flexml.pl,v 1.61 2006/09/13 16:34:33 wdowling Exp

As of flexml.pl 1.58 you are supposed to have access to attributes from
inside the end-tag processing code.

Please enter a bug in the sourceforge bug tracker for flexml if you can
confirm that attribute access inside end-tag processing is not working.
Ideally, could you submit an absolutely minimal example that shows the
failure?

Thanks,

Will

> 
> On Monday 08 January 2007 15:12, William F. Dowling wrote:
> > On Mon, 2007-01-08 at 08:54 +0000, Mike Aubury wrote:
> > > Follow up to this - am i right in assuming that we should not be
> > > accessing the attributes in an 'end' block ?
> > > If so - should doing this cause an error ?
> > >
> > >
> > > (My code wasn't working until I moved some of the checking to the 'start'
> > > block instead..)
> >
> > There was some discussion about this on on the flexml-users mailing list
> > a few months ago:
> >
> > http://sourceforge.net/mailarchive/forum.php?thread_id=30370096&forum_id=59
> >3
> >
> > I forget what the upshot was -- it looks like I investigated and at
> > least thought the change (to make attributes accessible from the end-tag
> > processing code) would be easy. Martin Quinson had asked for that.
> >
> > Martin: as far as you know, was that change made?
> >
> > Will
> 
-- 
William F Dowling
wil...@th...
www.scientific.thomson.com

Re: [FleXML-Users] Newbie question...

[Mike A. <mik...@au...>]

What version did this go in ? 

flexml --version reports I'm using 
	FleXML version Id: flexml.pl,v 1.61 2006/09/13 16:34:33 wdowling Exp


On Monday 08 January 2007 15:12, William F. Dowling wrote:
> On Mon, 2007-01-08 at 08:54 +0000, Mike Aubury wrote:
> > Follow up to this - am i right in assuming that we should not be
> > accessing the attributes in an 'end' block ?
> > If so - should doing this cause an error ?
> >
> >
> > (My code wasn't working until I moved some of the checking to the 'start'
> > block instead..)
>
> There was some discussion about this on on the flexml-users mailing list
> a few months ago:
>
> http://sourceforge.net/mailarchive/forum.php?thread_id=30370096&forum_id=59
>3
>
> I forget what the upshot was -- it looks like I investigated and at
> least thought the change (to make attributes accessible from the end-tag
> processing code) would be easy. Martin Quinson had asked for that.
>
> Martin: as far as you know, was that change made?
>
> Will

-- 
Mike Aubury

Re: [FleXML-Users] Newbie question...

[William F. D. <wil...@th...>]

On Mon, 2007-01-08 at 08:54 +0000, Mike Aubury wrote:
> Follow up to this - am i right in assuming that we should not be accessing the 
> attributes in an 'end' block ?
> If so - should doing this cause an error ?
> 
> 
> (My code wasn't working until I moved some of the checking to the 'start' 
> block instead..)

There was some discussion about this on on the flexml-users mailing list
a few months ago:

http://sourceforge.net/mailarchive/forum.php?thread_id=30370096&forum_id=593

I forget what the upshot was -- it looks like I investigated and at
least thought the change (to make attributes accessible from the end-tag
processing code) would be easy. Martin Quinson had asked for that.

Martin: as far as you know, was that change made?

Will

-- 
William F Dowling
wil...@th...
www.scientific.thomson.com

Re: [FleXML-Users] Newbie question...

[Mike A. <mik...@au...>]

Follow up to this - am i right in assuming that we should not be accessing the 
attributes in an 'end' block ?
If so - should doing this cause an error ?


(My code wasn't working until I moved some of the checking to the 'start' 
block instead..)

On Friday 05 January 2007 21:30, William F. Dowling wrote:
> Hi Mike,
>
> This must be a common app for flexml -- it's one of my own main uses for
> it.  I too need to do marshalling and the reverse for basic values, and
> recursive types built from them by vectoring and map (hash-table)
> formation, down to any depth.  (E.g. lists of lists of maps of strings,
> etc.)  My implementation language is C++, which (IMO) makes things a
> little cleaner than straight C since I don't need to use void*, or
> casting operations anyplace.
>
> It is a fundamental limitation of flex that the communication between
> actions can only take place by global variables.  There is no way around
> that.
>
> But you can structure your code so that it is quite clean by using stack
> operations. This strategy will work for any basic data types and any
> collection of type constructors (e.g. vector-formation,
> struct-formation, binding_comp_list-formation, etc.)  One global Stack
> object is all you need.
>
> When a start tag is seen in the XML, push onto the stack a placeholder
> object.  When an end tag is seen, you'll know how many objects to pop
> (and what types they should be); pop them and build your object, putting
> it into the placeholder you had pushed.  For type constructors (like
> vector<> in C++) that take a variable number of parameters, use the
> 'cons' strategy from LISP; that is, cons in each argument as you
> encounter it, as if you were building a right-branching binary tree.
>
> You definitely don't want to be allocating and freeing in every action
> -- let your stack operation (push/pop) definitions do that for you.
>
> I can send you some sample C++ code that implements these ideas if that
> would be useful.
>
> Will
>
> On Fri, 2007-01-05 at 17:10 +0000, Mike Aubury wrote:
> > Hi - i've managed to do some *really* nice things with this software -
> > but one thing keeps me back.
> > Is there anyway to pass data around within the actions ?
> >
> >
> > Background
> >
> > I'm trying to marshall (serialize) some C structures into XML.
> > I've got a program which parses a definition of a C structure (if you've
> > ever used RPCGEN or ONCRPC - it works on the same principle (and uses the
> > .x file syntax :-)) and generates some code which dumps the XML.
> >
> > I'm now trying to get my parser to generate the .dtd and .act files for
> > reading that file back in...
> >
> > Take this snippet of XML :
> >
> >                 <binding_comp_list>
> >                   <binding_comp_list__abind VALUE="0"/>
> >                   <binding_comp_list__type VALUE="70"/>
> >                   <binding_comp_list__data SET='TRUE' VALUE=""/>
> >                 </binding_comp_list>
> >
> > Ideally - I'd want to
> > 1) allocate some memory for the binding_comp_list structure
> > 	in the 'start' for 'binding_comp_list'
> > 2) use that parent to set the data..
> > 3) use that memory in the 'end' 'binding_comp_list' to set something
> > else..
> >
> > ATM - i've done it using a series of temporary variables - but its really
> > messy (because these things can recurse - so I can't just declare once
> > temporary binding_comp_list - I need to use a dynamic array..)
> > It gets even worse when the structure contains structure or an array ( or
> > an array of structures!)
> >
> >
> >
> > For reference - that binding_comp_list is defined as :
> >
> > 	struct binding_comp_list {
> > 	        long abind;
> > 	        int type;
> > 	        string data; // basically a char*
> > 	};
> >
> >
> >
> > My current actions look like this (excuse any errors - i've modified this
> > from the original for readability!):
> >
> > 	<start tag='something_using_a_binding_comp_list'>
> > 	<![CDATA[
> > 		Allocate("binding_comp_list", (void *)&tmp_binding_comp_list,
> > 			&tmp_binding_comp_list_cnt, sizeof(struct binding_comp_list));
> > 	]]>
> > 	</start>
> >
> >
> >
> > 	<end tag='something_using_a_binding_comp_list'>
> > 	<![CDATA[
> >
> > 		setsomething=tmp_binding_comp_list[tmp_binding_comp_list_cnt-1];
> >
> > 		FreeMemory("binding_comp_list",(void ***)&tmp_binding_comp_list,
> > 			&tmp_binding_comp_list_cnt,1);
> >
> > 	]]>
> > 	</end>
> >
> >
> >
> > 	<end tag='binding_comp_list__abind'>
> > 	<![CDATA[
> > 		tmp_binding_comp_list[tmp_binding_comp_list_cnt-1]->abind=atol({VALUE})
> >;
> >
> > 	]]>
> > 	</end>
> >
> >
> > 	<end tag='binding_comp_list__type'>
> > 	<![CDATA[
> > 		tmp_binding_comp_list[tmp_binding_comp_list_cnt-1]->type=atol({VALUE});
> > 	]]>
> > 	</end>
> >
> > 	<end tag='binding_comp_list__data'>
> > 	<![CDATA[
> > 	   if (isyes({SET})) {
> > 		
> > tmp_binding_comp_list[tmp_binding_comp_list_cnt-1]->data=strdup({VALUE});
> > } else {
> >                 
> > tmp_binding_comp_list[tmp_binding_comp_list_cnt-1]->data=0; }
> >
> > 	]]>
> > 	</end>
> >
> > Any thoughts ?
> >
> >
> > (Or alternative ways of marshalling the C to XML and back ?!)

-- 
Mike Aubury

Re: [FleXML-Users] Newbie question...

[William F. D. <wil...@th...>]

Hi Mike,

This must be a common app for flexml -- it's one of my own main uses for
it.  I too need to do marshalling and the reverse for basic values, and
recursive types built from them by vectoring and map (hash-table)
formation, down to any depth.  (E.g. lists of lists of maps of strings,
etc.)  My implementation language is C++, which (IMO) makes things a
little cleaner than straight C since I don't need to use void*, or
casting operations anyplace.

It is a fundamental limitation of flex that the communication between
actions can only take place by global variables.  There is no way around
that.

But you can structure your code so that it is quite clean by using stack
operations. This strategy will work for any basic data types and any
collection of type constructors (e.g. vector-formation,
struct-formation, binding_comp_list-formation, etc.)  One global Stack
object is all you need.

When a start tag is seen in the XML, push onto the stack a placeholder
object.  When an end tag is seen, you'll know how many objects to pop
(and what types they should be); pop them and build your object, putting
it into the placeholder you had pushed.  For type constructors (like
vector<> in C++) that take a variable number of parameters, use the
'cons' strategy from LISP; that is, cons in each argument as you
encounter it, as if you were building a right-branching binary tree.

You definitely don't want to be allocating and freeing in every action
-- let your stack operation (push/pop) definitions do that for you.

I can send you some sample C++ code that implements these ideas if that
would be useful.

Will


On Fri, 2007-01-05 at 17:10 +0000, Mike Aubury wrote:
> Hi - i've managed to do some *really* nice things with this software - but one 
> thing keeps me back.
> Is there anyway to pass data around within the actions ? 
> 
> 
> Background 
> 
> I'm trying to marshall (serialize) some C structures into XML.
> I've got a program which parses a definition of a C structure (if you've ever 
> used RPCGEN or ONCRPC - it works on the same principle (and uses the .x file 
> syntax :-)) and generates some code which dumps the XML.
> 
> I'm now trying to get my parser to generate the .dtd and .act files for 
> reading that file back in...
> 
> Take this snippet of XML : 
> 
>                 <binding_comp_list>
>                   <binding_comp_list__abind VALUE="0"/>
>                   <binding_comp_list__type VALUE="70"/>
>                   <binding_comp_list__data SET='TRUE' VALUE=""/>
>                 </binding_comp_list>
> 
> Ideally - I'd want to 
> 1) allocate some memory for the binding_comp_list structure 
> 	in the 'start' for 'binding_comp_list'
> 2) use that parent to set the data..
> 3) use that memory in the 'end' 'binding_comp_list' to set something else..
> 
> ATM - i've done it using a series of temporary variables - but its really 
> messy (because these things can recurse - so I can't just declare once 
> temporary binding_comp_list - I need to use a dynamic array..)
> It gets even worse when the structure contains structure or an array ( or an 
> array of structures!)
> 
> 
> 
> For reference - that binding_comp_list is defined as : 
> 
> 	struct binding_comp_list {
> 	        long abind;
> 	        int type;
> 	        string data; // basically a char*
> 	};
> 
> 
> 
> My current actions look like this (excuse any errors - i've modified this from 
> the original for readability!): 
> 
> 	<start tag='something_using_a_binding_comp_list'>
> 	<![CDATA[
> 		Allocate("binding_comp_list", (void *)&tmp_binding_comp_list, 	
> 			&tmp_binding_comp_list_cnt, sizeof(struct binding_comp_list));
> 	]]>
> 	</start>
> 
> 
> 
> 	<end tag='something_using_a_binding_comp_list'>
> 	<![CDATA[
> 
> 		setsomething=tmp_binding_comp_list[tmp_binding_comp_list_cnt-1];
> 
> 		FreeMemory("binding_comp_list",(void ***)&tmp_binding_comp_list, 		
> 			&tmp_binding_comp_list_cnt,1);
> 	
> 	]]>
> 	</end>
> 
> 
> 
> 	<end tag='binding_comp_list__abind'> 
> 	<![CDATA[
> 		tmp_binding_comp_list[tmp_binding_comp_list_cnt-1]->abind=atol({VALUE}); 
> 
> 	]]>
> 	</end>
> 
> 
> 	<end tag='binding_comp_list__type'>
> 	<![CDATA[
> 		tmp_binding_comp_list[tmp_binding_comp_list_cnt-1]->type=atol({VALUE}); 
> 	]]>
> 	</end>
> 
> 	<end tag='binding_comp_list__data'> 
> 	<![CDATA[
> 	   if (isyes({SET})) {
> 		 tmp_binding_comp_list[tmp_binding_comp_list_cnt-1]->data=strdup({VALUE}); 
> 	   } else {
>                  tmp_binding_comp_list[tmp_binding_comp_list_cnt-1]->data=0;
> 	   }
>            
> 	]]>
> 	</end>
> 	
> Any thoughts ?
> 
> 
> (Or alternative ways of marshalling the C to XML and back ?!)
> 
-- 
William F Dowling
wil...@th...
www.scientific.thomson.com

[FleXML-Users] Newbie question...

[Mike A. <mik...@au...>]

Hi - i've managed to do some *really* nice things with this software - but one 
thing keeps me back.
Is there anyway to pass data around within the actions ? 


Background 

I'm trying to marshall (serialize) some C structures into XML.
I've got a program which parses a definition of a C structure (if you've ever 
used RPCGEN or ONCRPC - it works on the same principle (and uses the .x file 
syntax :-)) and generates some code which dumps the XML.

I'm now trying to get my parser to generate the .dtd and .act files for 
reading that file back in...

Take this snippet of XML : 

                <binding_comp_list>
                  <binding_comp_list__abind VALUE="0"/>
                  <binding_comp_list__type VALUE="70"/>
                  <binding_comp_list__data SET='TRUE' VALUE=""/>
                </binding_comp_list>

Ideally - I'd want to 
1) allocate some memory for the binding_comp_list structure 
	in the 'start' for 'binding_comp_list'
2) use that parent to set the data..
3) use that memory in the 'end' 'binding_comp_list' to set something else..

ATM - i've done it using a series of temporary variables - but its really 
messy (because these things can recurse - so I can't just declare once 
temporary binding_comp_list - I need to use a dynamic array..)
It gets even worse when the structure contains structure or an array ( or an 
array of structures!)



For reference - that binding_comp_list is defined as : 

	struct binding_comp_list {
	        long abind;
	        int type;
	        string data; // basically a char*
	};



My current actions look like this (excuse any errors - i've modified this from 
the original for readability!): 

	<start tag='something_using_a_binding_comp_list'>
	<![CDATA[
		Allocate("binding_comp_list", (void *)&tmp_binding_comp_list, 	
			&tmp_binding_comp_list_cnt, sizeof(struct binding_comp_list));
	]]>
	</start>



	<end tag='something_using_a_binding_comp_list'>
	<![CDATA[

		setsomething=tmp_binding_comp_list[tmp_binding_comp_list_cnt-1];

		FreeMemory("binding_comp_list",(void ***)&tmp_binding_comp_list, 		
			&tmp_binding_comp_list_cnt,1);
	
	]]>
	</end>



	<end tag='binding_comp_list__abind'> 
	<![CDATA[
		tmp_binding_comp_list[tmp_binding_comp_list_cnt-1]->abind=atol({VALUE}); 

	]]>
	</end>


	<end tag='binding_comp_list__type'>
	<![CDATA[
		tmp_binding_comp_list[tmp_binding_comp_list_cnt-1]->type=atol({VALUE}); 
	]]>
	</end>

	<end tag='binding_comp_list__data'> 
	<![CDATA[
	   if (isyes({SET})) {
		 tmp_binding_comp_list[tmp_binding_comp_list_cnt-1]->data=strdup({VALUE}); 
	   } else {
                 tmp_binding_comp_list[tmp_binding_comp_list_cnt-1]->data=0;
	   }
           
	]]>
	</end>
	
Any thoughts ?


(Or alternative ways of marshalling the C to XML and back ?!)

-- 
Mike Aubury

[FleXML-Users] Handling non-ascii character references

[William F. D. <wil...@th...>]

It was pointed out to me by a user that flexml handles character
references to non-ascii characters incorrectly.  This is a little worse
than we admit in the BUGS section of the man page ("The character set is
merely ASCII...") because your document might have the (nine byte ascii)
sequence
    
but the only thing that will show up in {pcdata} is the single byte 0x0A
(that is, a \n character) -- flexml has thrown away the high byte
altogether.

Here is my question: what *should* flexml do with character references
like this?  Possible alternatives:

1) Issue a warning and insert nothing into {pcdata};
2) Issue a warning and insert a dummy character into {pcdata};
3) Put the two bytes (0x20, 0x0A) into {pcdata};
4) Put the UTF-8 encoding of 0x200A into {pcdata}.
5) something else?

What do you think?

-- 
William F Dowling
wil...@th...
www.scientific.thomson.com

Re: [FleXML-Users] your flexml change request

[William F. D. <wil...@th...>]

On Tue, 2006-09-12 at 14:15 -0400, William F. Dowling wrote:

> [...]
> I have checked in a change to flexml that should allow you to do what
> you want (sourceforge bug #1526054).  Specify
>    -h some_header.h

I meant
     -i some_header.h

Will

-- 
William F Dowling
wil...@th...
www.scientific.thomson.com

Re: [FleXML-Users] your flexml change request

[William F. D. <wil...@th...>]

Hi Staffan,

I have checked in a change to flexml that should allow you to do what
you want (sourceforge bug #1526054).  Specify
   -h some_header.h
on the flexml command line, and the generated file will have
   #include "some_header.h"
at the bottom of the %{...%} section in the generated .l file.

For example, you can put into the .h file something like
#define YY_DECL \
   static int static_lexer_param; int lexer(int lexer_param)
#define YY_USER_INIT \
   static_lexer_param =3D lexer_param;

to change the name and signature of the generated scanner (and in this
case, have access in the action code to a parameter passed into the
lexer.)

You could also redefine YY_INPUT here.

Cheers,
Will

On Sun, 2006-09-10 at 06:49 +0800, sea...@he... wrote:
> It's nice to see there's active development going on over at flexml
> headquarters!
>=20
> What you suggest, a way of putting a piece of user defined code at the
> top of the .l file, is basically what I had in mind (that's what I
> did, but manually). I cannot think of any scenarious where such an
> approach would not suffice or a better solution.
>=20
> Implementation-wise, I hope you can sort it out and wish you the best
> of luck.
>=20
> Sincerely,
> Staffan Gim=E5ker
>=20
--=20
William F Dowling
wil...@th...
www.scientific.thomson.com

Re: [FleXML-Users] Testcase for multiple run of the same scanner

[William F. D. <wil...@th...>]

On Wed, 2006-08-30 at 01:42 +0200, Martin Quinson wrote:
> Hello,
> 
> I commited a testcase which tries to run the same scanner on several files
> using the scanner control functions (create_buffer, switch_to_buffer and so
> on). 
> 
> I did so because this used to work fine with previous version of flexml, but
> in 1.6, there is some mess around default values of attributes. As usual, I
> have no idea of how to solve this.

I have checked in a fix to this problem; the multi-parser-run test is
now succeeding.

> I also noted that "make -C testbed" do not report any error when one of the
> tests fails. For example, "make dist" works even if it calls "make -C
> testbed" at some point. Is this intended?

I don't want 'make' in the testbed/ directory to fail, even if one or
more tests fail.  Testing should go on (even across several directories,
although in this case we only have one) and not be interrupted by the
failure of one test.

But in the flexml/ directory you could have dist depend on test like
this:

 dist:	test clean

then cause the test target to fail if any of the tests fail:

 test::;  make -C examples $@; \
	make -C testbed $@ > test.out 2>&1; ! grep '^fail' test.out && \
	echo "Tests succeeded."

You can make those changes if you think it's OK.  Also you might
integrate the results of the 'make' run in examples/ into this target.

Will

-- 
William F Dowling
wil...@th...
www.scientific.thomson.com

[FleXML-Users] Testcase for multiple run of the same scanner

[Martin Q. <mar...@lo...>]

Hello,

I commited a testcase which tries to run the same scanner on several files
using the scanner control functions (create_buffer, switch_to_buffer and so
on).=20

I did so because this used to work fine with previous version of flexml, but
in 1.6, there is some mess around default values of attributes. As usual, I
have no idea of how to solve this.


I also noted that "make -C testbed" do not report any error when one of the
tests fails. For example, "make dist" works even if it calls "make -C
testbed" at some point. Is this intended?

Bye, Mt.

--=20
All models are wrong. Some are useful.

[FleXML-Users] Testcase for multiple scanners in the same application

[Martin Q. <mar...@lo...>]

Ok, done. I just commited a testcase having 2 parsers embeeded. This code is
quite crude:

I failed to get the action files working in that case. We do not use them in
our project, so I dunno it is actually broken or whether I'm an idiot unable
to set this up properly. It would be really cool if you could double check.

I had to call flexml twice to generate the scanner and the header
separately. Again, we do so in SimGrid and it kinda breaks when I try to
do one run only.

Naturally, if you have 2 parsers, you need the parser controls functions
such as the following:
  extern int one_lex (void);
  extern void one_restart (FILE *input_file  );
  extern void one__switch_to_buffer (YY_BUFFER_STATE new_buffer  );
  YY_BUFFER_STATE one__create_buffer (FILE *file,int size  );
  extern void one__delete_buffer (YY_BUFFER_STATE b  );
  extern void one__flush_buffer (YY_BUFFER_STATE b  );
  extern void one_push_buffer_state (YY_BUFFER_STATE new_buffer  );
  extern void one_pop_buffer_state (void );
It may be cool if those function where added to the header file. Here and in
SimGrid, we declare them manually in a separate header file.

I cannot find anymore how we got the XML application entry points functions
prototypes (STag_* and ETag_*) declared properly so that it compile without
"implicit declaration of function" warning. We got this working in SimGrid,
but the commited example spits lots of warnings.


I think that's it. As you can see, it seems to be room for improvement both
in this testcase and in flexml to properly deal with multiple scanners...

Bye, Mt.


On Mon, Aug 28, 2006 at 10:42:23AM -0400, William F. Dowling wrote:
> Sorry I messed this up for you.  Would it be possible for you to check
> in a tiny test into the testbed/ directory, in the style of the ones
> that are there, that would fail before your change, but passes after
> your change?
>=20
> This way we would have 1) a documented case of using >1 flexer; and 2) a
> test that would hopefully fail if other changes are introduced that do
> not respect the need for $tagprefix.  Since I don't have any such cases
> yet, I didn't notice the failure I introduced.
>=20
> Will
>=20
> On Sun, 2006-08-27 at 20:47 +0000, Martin Quinson wrote:
> > Update of /cvsroot/flexml/flexml
> > In directory sc8-pr-cvs5.sourceforge.net:/tmp/cvs-serv5660
> >=20
> > Modified Files:
> > 	flexml.pl=20
> > Log Message:
> > Make sure bufferstack and bufferliteral play well wrt -P option: I have=
 2 flexers in the same application

--=20
L'informatique soit =E7a marche pas, soit ca marchait avant qu'on y touche.

Re: [FleXML-Users] Problem with the recent changes

[Martin Q. <mar...@lo...>]

On Mon, Aug 28, 2006 at 12:18:20PM -0400, William F. Dowling wrote:
> On Sun, 2006-08-27 at 23:23 +0200, Martin Quinson wrote:
> > Hello William,
> >=20
> > after your fixes around the memleak on bufferstack, it looks like tag
> > attributes are not available from the ETag_* functions, but only from t=
he
> > STag_* ones.=20
> >=20
> > I'm not sure this is a good thing, since I actually had a parser which =
used
> > this bug/feature. I fixed my code to only use attribute content in S_*_=
fun,
> > but it would be cool if you could change the way things are done to all=
ow us
> > to access attributes from the E_*_fun too.=20
>=20
> I have looked into this; and it looks like a very simple change for me
> to make.

Good news!

> However, I am a little puzzled how the generated parser was letting this
> through before my changes.  There is code in flexml.pl (lines 1680,
> 1687, 1695) that to me seems to prohibit refering to attributes inside
> the end-tag processing code:
>=20
>   die "\"$ACTIONS\", line $lineno: Attributes only allowed in
>     start tag.\n"
>   if not $isstart;
>=20
> Had you disabled this code somehow, or was there some case that was
> being missed, in the code around lines 1677-1702?

It's because we don't use an action file, but instead we override the
STag_*_fun pointer directly to put a function of ours there. In that case,
there is not much the perl parser can do against our misuses ;)

Bye, Mt.

--=20
Le cycliste zigzaguait sur la route, tant=F4t =E0 gauche, tant=F4t =E0 droi=
te,
avant que je puisse le t=E9lescoper.
  -- perles du courrier des assurances 2003

Re: [FleXML-Users] Problem with the recent changes

[William F. D. <wil...@th...>]

On Sun, 2006-08-27 at 23:23 +0200, Martin Quinson wrote:
> Hello William,
> 
> after your fixes around the memleak on bufferstack, it looks like tag
> attributes are not available from the ETag_* functions, but only from the
> STag_* ones. 
> 
> I'm not sure this is a good thing, since I actually had a parser which used
> this bug/feature. I fixed my code to only use attribute content in S_*_fun,
> but it would be cool if you could change the way things are done to allow us
> to access attributes from the E_*_fun too. 

I have looked into this; and it looks like a very simple change for me
to make.

However, I am a little puzzled how the generated parser was letting this
through before my changes.  There is code in flexml.pl (lines 1680,
1687, 1695) that to me seems to prohibit refering to attributes inside
the end-tag processing code:

  die "\"$ACTIONS\", line $lineno: Attributes only allowed in
    start tag.\n"
  if not $isstart;

Had you disabled this code somehow, or was there some case that was
being missed, in the code around lines 1677-1702?

Thanks,

Will



-- 
William F Dowling
wil...@th...
www.scientific.thomson.com

Re: [FleXML-Users] Problem with the recent changes

[William F. D. <wil...@th...>]

On Sun, 2006-08-27 at 23:23 +0200, Martin Quinson wrote:
> Hello William,
> 
> after your fixes around the memleak on bufferstack, it looks like tag
> attributes are not available from the ETag_* functions, but only from the
> STag_* ones. 

This is true.

> I'm not sure this is a good thing, since I actually had a parser which used
> this bug/feature. I fixed my code to only use attribute content in S_*_fun,
> but it would be cool if you could change the way things are done to allow us
> to access attributes from the E_*_fun too. 

OK, I'll look to see what needs to be changed to get that working.  I
was thinking that code that uses attributes should be in the start-tag
processing where the attributes exist, but I also see the convenience of
being able to refer to them later when processing the end tag.

This is another case where it would be nice to have a minimal example
test case in the testbed/ directory.

Thanks,

Will

-- 
William F Dowling
wil...@th...
www.scientific.thomson.com

Re: [FleXML-Users] [Flexml-commits] flexml flexml.pl,1.56,1.57

[William F. D. <wil...@th...>]

Sorry I messed this up for you.  Would it be possible for you to check
in a tiny test into the testbed/ directory, in the style of the ones
that are there, that would fail before your change, but passes after
your change?

This way we would have 1) a documented case of using >1 flexer; and 2) a
test that would hopefully fail if other changes are introduced that do
not respect the need for $tagprefix.  Since I don't have any such cases
yet, I didn't notice the failure I introduced.

Will

On Sun, 2006-08-27 at 20:47 +0000, Martin Quinson wrote:
> Update of /cvsroot/flexml/flexml
> In directory sc8-pr-cvs5.sourceforge.net:/tmp/cvs-serv5660
> 
> Modified Files:
> 	flexml.pl 
> Log Message:
> Make sure bufferstack and bufferliteral play well wrt -P option: I have 2 flexers in the same application
> 
> Index: flexml.pl
> ===================================================================
> RCS file: /cvsroot/flexml/flexml/flexml.pl,v
> retrieving revision 1.56
> retrieving revision 1.57
> diff -u -d -r1.56 -r1.57
> --- flexml.pl	24 Aug 2006 20:22:20 -0000	1.56
> +++ flexml.pl	27 Aug 2006 20:47:29 -0000	1.57
> @@ -249,8 +249,8 @@
>    my ($pre) = @_; # pre should be a storage class spec like 'static' or 'extern'
>    print "/* FleXML-provided data. */\n";
>    print $pre . "int ${tagprefix}pcdata_ix;\n";
> -  print "extern char *bufferstack;\n";
> -  print "#define ${tagprefix}pcdata (bufferstack + ${tagprefix}pcdata_ix)\n";
> +  print "extern char *${tagprefix}bufferstack;\n";
> +  print "#define ${tagprefix}pcdata (${tagprefix}bufferstack + ${tagprefix}pcdata_ix)\n";
>  
>    for (keys %atttype) {
>      if (m.($Nmtoken)[/]($Nmtoken).xo) {
> @@ -260,7 +260,7 @@
>  	  print "AX_${tagprefix}$ctag{$1}_$catt{$2}\n";
>        }
>        else {
> -	  print "(bufferstack + AX_${tagprefix}$ctag{$1}_$catt{$2})\n";
> +	  print "(${tagprefix}bufferstack + AX_${tagprefix}$ctag{$1}_$catt{$2})\n";
>        }
>      }
>    }
> @@ -1288,7 +1288,7 @@
>  
>        print "  /* FleXML_init */\n";
>        for my $att (@default_attributes) {
> -	  print "  bufferliteral('\\0', &bnext, \"$att\");\n";
> +	  print "  ${tagprefix}bufferliteral('\\0', &bnext, \"$att\");\n";
>        }
>        print "  if(!${tagprefix}statenames) {${tagprefix}statenames= (const char **)calloc(IMPOSSIBLE,sizeof(char*));\n";
>        for ('PROLOG','DOCTYPE','EPILOG','INCOMMENT','INPI','VALUE1','VALUE2','CDATA') {
> @@ -1593,6 +1593,8 @@
>        s/element_context/${tagprefix}element_context/g;
>        s/parse_err_msg/${tagprefix}parse_err_msg/g;
>        s/rcs_flexml_skeleton/rcs_${tagprefix}flexml_skeleton/g;
> +      s/bufferliteral/${tagprefix}bufferliteral/g;
> +      s/bufferstack/${tagprefix}bufferstack/g;
>        print;
>      }
>  
> 
> 
> -------------------------------------------------------------------------
> Using Tomcat but need to do more? Need to support web services, security?
> Get stuff done quickly with pre-integrated technology to make your job easier
> Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
> _______________________________________________
> Flexml-commits mailing list
> Fle...@li...
> https://lists.sourceforge.net/lists/listinfo/flexml-commits
-- 
William F Dowling
wil...@th...
www.scientific.thomson.com

Re: [FleXML-Users] [Flexml-commits] flexml skel,1.35,1.36

[William F. D. <wil...@th...>]

Making text be const char * is a definite improvement.  Thanks.

Would it work to avoid the cast by doing this in the body:
const char *s = (c ? strchr(text,c) : text-1), *e = strrchr(text,c);

Will

On Sun, 2006-08-27 at 20:46 +0000, Martin Quinson wrote:
> Update of /cvsroot/flexml/flexml
> In directory sc8-pr-cvs5.sourceforge.net:/tmp/cvs-serv5268
> 
> Modified Files:
> 	skel 
> Log Message:
> Circumvent constentness warnings in produced flexers (I use -Werror)
> 
> Index: skel
> ===================================================================
> RCS file: /cvsroot/flexml/flexml/skel,v
> retrieving revision 1.35
> retrieving revision 1.36
> diff -u -d -r1.35 -r1.36
> --- skel	24 Aug 2006 20:39:39 -0000	1.35
> +++ skel	27 Aug 2006 20:46:36 -0000	1.36
> @@ -123,9 +123,9 @@
>  }
>  
>  #ifdef FLEXML_NEED_BUFFERLIT
> -static void bufferliteral(char c, int* pp, char* text)
> +static void bufferliteral(char c, int* pp, const char* text)
>  {
> -  char *s = (c ? strchr(text,c) : text-1), *e = strrchr(text,c);
> +  char *s = (c ? strchr(text,c) : (char*)text-1), *e = strrchr(text,c);
>    assert(s <= e); BUFFERSET(*pp);
>    while (++s<e) {
>      if (isspace(*s) && c) { BUFFERPUTC(' '); while (isspace(*s)) ++s; }
> 
> 
> -------------------------------------------------------------------------
> Using Tomcat but need to do more? Need to support web services, security?
> Get stuff done quickly with pre-integrated technology to make your job easier
> Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
> _______________________________________________
> Flexml-commits mailing list
> Fle...@li...
> https://lists.sourceforge.net/lists/listinfo/flexml-commits
-- 
William F Dowling
wil...@th...
www.scientific.thomson.com

[FleXML-Users] Problem with the recent changes

[Martin Q. <mar...@lo...>]

Hello William,

after your fixes around the memleak on bufferstack, it looks like tag
attributes are not available from the ETag_* functions, but only from the
STag_* ones.=20

I'm not sure this is a good thing, since I actually had a parser which used
this bug/feature. I fixed my code to only use attribute content in S_*_fun,
but it would be cool if you could change the way things are done to allow us
to access attributes from the E_*_fun too.=20

Sorry, I have to confess one more time that my understanding of the flexml
internals don't allow me to do the change myself.

Bye, Mt.

--=20
Those are my principles, and if you don't like them... well, I have others.
  -- Groucho Marx

[FleXML-Users] Guess what? Flexml-1.5.2 and flexml-1.5.3 are both out

[Martin Q. <mar...@lo...>]

I'm sorry for not being able to get this right in the first shot, it took me
3 minor versions to make flexml fit my personal project again. I kinda
released too early each time, and we incremented the version number.

Not that it is cruxial, I guess. Here is the changelog anyway:

flexml (1.5.3-1) unstable; urgency=3Dlow

  * New option: --sysid to override the system id
  * Kill any non ascii char from the distrib. They were latin1, I use utf8
    so they annoyed me for not much benefit. I could have switched to utf8,
    but it would have annoyed other people, I'm sure.
  * Kill the EnlargeFlex.patch: was integrated into flex a few ages ago.

 -- Martin Quinson <mqu...@de...>  Tue, 18 Jul 2006 19:40:36 +0200

flexml (1.5.2-1) unstable; urgency=3Dlow

  * Bug fix: do find the skeleton file in installed distributions

 -- Martin Quinson <mqu...@de...>  Tue, 18 Jul 2006 14:06:50 +0200

Have fun,=20
Mt.

--=20
Everything should be made as simple as possible but not simpler.
  -- Albert Einstein