flex-devel — development of flex itself

Re: [Flex-devel] GCC warning comparing signed and unsigned and possible bug

[Will E. <wes...@gm...>]

Which version of flex are you using? Looks like you've got an old version from the filenames you reference.

On Thursday, 15 September 2016, 11:10 am +1000, Timothy Arceri <tim...@co...> wrote:

> Hi guys,
> 
> I'm seeing a GCC waring in the output from lex which seems to be caused
> by the following line in flex.skl:
> 
>    YY_INPUT( (&YY_CURRENT_BUFFER_LVALUE->yy_ch_buf[number_to_move]),
> 			YY_G(yy_n_chars), num_to_read );
> 
> To fix it should be changed to:
> 
>    YY_INPUT( (&YY_CURRENT_BUFFER_LVALUE->yy_ch_buf[number_to_move]),
> 			YY_G(yy_n_chars), (unsigned) num_to_read );
> 
> 
> Something else I noticed is there are two flex.skl files, the output
> I'm getting seems to be generated by the one
> in flex/to.do/unicode/flex.skl where num_to_read is defined as int
> which is fine. However the one in flex/flex.skl defines num_to_read
> as yy_size_t which is unsigned which means the while loop while (
> num_to_read <= 0 ) might not get executed, this looks like a bug.
> 
> Tim
> 
> 
> 
> ------------------------------------------------------------------------------
> _______________________________________________
> Flex-devel mailing list
> Fle...@li...
> https://lists.sourceforge.net/lists/listinfo/flex-devel

-- 
Will Estes
Flex Project Maintainer
wes...@gm...
https://github.com/westes/flex

[Flex-devel] GCC warning comparing signed and unsigned and possible bug

[Timothy A. <tim...@co...>]

Hi guys,

I'm seeing a GCC waring in the output from lex which seems to be caused
by the following line in flex.skl:

   YY_INPUT( (&YY_CURRENT_BUFFER_LVALUE->yy_ch_buf[number_to_move]),
			YY_G(yy_n_chars), num_to_read );

To fix it should be changed to:

   YY_INPUT( (&YY_CURRENT_BUFFER_LVALUE->yy_ch_buf[number_to_move]),
			YY_G(yy_n_chars), (unsigned) num_to_read );


Something else I noticed is there are two flex.skl files, the output
I'm getting seems to be generated by the one
in flex/to.do/unicode/flex.skl where num_to_read is defined as int
which is fine. However the one in flex/flex.skl defines num_to_read
as yy_size_t which is unsigned which means the while loop while (
num_to_read <= 0 ) might not get executed, this looks like a bug.

Tim

Re: [Flex-devel] Any memory limitations to consider?

[Will E. <wes...@gm...>]

There's always going to be something somewhere that has a constraint.

But for most applications, a few more mb of memory is barely going to register as noise these days. I'd think that if you're choosing to do your tables in memory, you'd be aware of and generally ok with that trade off.

On Sunday, 21 August 2016,  5:41 pm -0400, Mighty Jo <mig...@gm...> wrote:

> Hi all!
> 
> I'm playing with some solutions that involve storing table definition
> strings in memory temporarily during the execution of make_tables instead
> of emitting them immediately. That will take a relatively large chuck of
> memory (compared to the binary forms). Are there any applications known to
> the mailing list that would suffer from flex consuming a few more MB?
> 
> -Joe

> ------------------------------------------------------------------------------

> _______________________________________________
> Flex-devel mailing list
> Fle...@li...
> https://lists.sourceforge.net/lists/listinfo/flex-devel


-- 
Will Estes
Flex Project Maintainer
wes...@gm...
https://github.com/westes/flex

[Flex-devel] Any memory limitations to consider?

[Mighty Jo <mig...@gm...>]

Hi all!

I'm playing with some solutions that involve storing table definition
strings in memory temporarily during the execution of make_tables instead
of emitting them immediately. That will take a relatively large chuck of
memory (compared to the binary forms). Are there any applications known to
the mailing list that would suffer from flex consuming a few more MB?

-Joe

Re: [Flex-devel] [Flex-help] Some flex patch snippets for Solaris.

[Will E. <wes...@gm...>]

Glad the two changes that are in the post-2.6.1 tree are helpful. I have plans to put out a 2.6.2 in the near future. It's not scheduled yet, but "in the next couple weeks" seems the most likely time frame.

On Sunday, 22 May 2016,  7:48 am -0700, Rich Burridge <ric...@or...> wrote:

> On 05/20/16 03:12 PM, Will Estes wrote:
> > The bootstrapping of flex was reworked after 2.6.1 was released. I -think- it's immune to the vpath build that you do. If you can verify that against the current git tree, let me know the results. Ditto the building of the man page.
> 
> Confirmed. Both are now fine.
> 
> >
> > As for finding m4, the solution needs to be more general. While what you do works for people who want to use the stock setup on Solaris, I can easily see other situations where it doesn't do enough.
> 
> Agreed.
> 
> >
> > I'll open an issue to describe the problem.
> >
> > What should happen is that configure should have an option that accepts a path to a suitable m4 binary. If that option is passed, then configure sets a variable that gets put into config.h which main.c reads. If that option is not passed, then configure should try to find a suitable m4 and set the symbol as previously. The M4 environment variable is handy for certain situations that might arise as well.
> 
> Sounds good.
> 
> >
> > Thanks for your report and interest in flex.
> 
> You're welcome. And thank you for your quick response.
> 
> 
> ------------------------------------------------------------------------------
> Mobile security can be enabling, not merely restricting. Employees who
> bring their own devices (BYOD) to work are irked by the imposition of MDM
> restrictions. Mobile Device Manager Plus allows you to control only the
> apps on BYO-devices by containerizing them, leaving personal data untouched!
> https://ad.doubleclick.net/ddm/clk/304595813;131938128;j
> -- 
> Flex-help mailing list
> Fle...@li...
> https://lists.sourceforge.net/lists/listinfo/flex-help

-- 
Will Estes
wes...@gm...

Re: [Flex-devel] [Flex-help] Some flex patch snippets for Solaris.

[Will E. <wes...@gm...>]

The bootstrapping of flex was reworked after 2.6.1 was released. I -think- it's immune to the vpath build that you do. If you can verify that against the current git tree, let me know the results. Ditto the building of the man page.

As for finding m4, the solution needs to be more general. While what you do works for people who want to use the stock setup on Solaris, I can easily see other situations where it doesn't do enough.

I'll open an issue to describe the problem.

What should happen is that configure should have an option that accepts a path to a suitable m4 binary. If that option is passed, then configure sets a variable that gets put into config.h which main.c reads. If that option is not passed, then configure should try to find a suitable m4 and set the symbol as previously. The M4 environment variable is handy for certain situations that might arise as well.

Thanks for your report and interest in flex.

On Friday, 20 May 2016,  8:02 am -0700, Rich Burridge <ric...@or...> wrote:

> Hi,
> 
> In trying to get flex 2.6.1 working in the build environment we
> use for FOSS components in Solaris, I encountered three problems
> which I was easily able to patch around. Please consider these
> changes for a future version of flex.
> 
> 1/ In flex-2.6.1/src/Makefile.am there is a rule:
> 
>    stage1scan.l: scan.l
>           cp $(srcdir)/scan.l $(srcdir)/stage1scan.l
> 
>    For Solaris, we don't build things directly in the original source
>    directories, but use a separate build directory. So we need to apply
>    the following patch:
> 
> --- flex-2.6.1/src/Makefile.am.orig     2016-05-19 06:21:16.631609293 -0700
> +++ flex-2.6.1/src/Makefile.am  2016-05-19 14:19:29.394717203 -0700
> @@ -87,7 +87,7 @@
>          mv skel.c.tmp $(srcdir)/skel.c
> 
>   stage1scan.l: scan.l
> -       cp $(srcdir)/scan.l $(srcdir)/stage1scan.l
> +       cp $(srcdir)/scan.l $(top_builddir)/src/stage1scan.l
> 
>   stage1scan.c: stage1scan.l stage1flex$(EXEEXT)
>          $(top_builddir)/src/stage1flex$(EXEEXT) -o $@ $<
> 
> 2/ Similarly, in flex-2.6.1/doc/Makefile.am we need to run help2man on
>     a flex file that's been created in the build directory not the source
>     directory, so we need to apply this patch:
> 
> --- flex-2.6.1/doc/Makefile.am.orig     2016-05-19 06:45:26.670565152 -0700
> +++ flex-2.6.1/doc/Makefile.am  2016-05-19 06:45:45.734263762 -0700
> @@ -26,5 +26,5 @@
>          for i in $(dist_man_MANS) ; do \
>          $(help2man) --name='$(PACKAGE_NAME)' \
>          --section=`echo $$i | sed -e 's/.*\.\([^.]*\)$$/\1/'` \
> -        $(top_srcdir)/src/flex$(EXEEXT) > $$i || rm -f $$i ; \
> +        $(top_builddir)/src/flex$(EXEEXT) > $$i || rm -f $$i ; \
>          done
> 
> 3/ The third one is a Solaris specific problem. In /usr/bin, the Solaris 
> version
>     of m4 doesn't understand the -P command line option, so fails when it's
>     part of the chain in flex. We have the GNU m4 binary under /usr/gnu/bin.
>     We can't rely on the M4 environment variable always being set, or that
>     /usr/gnu/bin will be found in the PATH environment variable before 
> /usr/bin,
>     so the existing logic in flex-2.6.1/src/main.c to find m4 doesn't 
> work correctly
>     on Solaris. I've fixed this by using the following patch:
> 
> --- flex-2.6.1/src/main.c.orig  2016-05-19 14:36:18.569346881 -0700
> +++ flex-2.6.1/src/main.c       2016-05-20 07:59:04.169569771 -0700
> @@ -348,6 +348,7 @@
> 
>       /* Setup the filter chain. */
>       output_chain = filter_create_int(NULL, filter_tee_header, 
> headerfilename);
> +#ifndef __sun
>       if ( !(m4 = getenv("M4"))) {
>              char *slash;
>                  m4 = M4;
> @@ -389,6 +390,9 @@
>                  }
>          }
>       filter_create_ext(output_chain, m4, "-P", 0);
> +#else
> +    filter_create_ext(output_chain, "/usr/gnu/bin/m4", "-P", 0);
> +#endif
>       filter_create_int(output_chain, filter_fix_linedirs, NULL);
> 
>       /* For debugging, only run the requested number of filters. */
> 
> 
> 
> Thanks.
> 
> 
> ------------------------------------------------------------------------------
> Mobile security can be enabling, not merely restricting. Employees who
> bring their own devices (BYOD) to work are irked by the imposition of MDM
> restrictions. Mobile Device Manager Plus allows you to control only the
> apps on BYO-devices by containerizing them, leaving personal data untouched!
> https://ad.doubleclick.net/ddm/clk/304595813;131938128;j
> -- 
> Flex-help mailing list
> Fle...@li...
> https://lists.sourceforge.net/lists/listinfo/flex-help

-- 
Will Estes
Flex Project Maintainer
wes...@gm...
https://github.com/westes/flex

[Flex-devel] flex 2.6.1

[Will E. <wes...@gm...>]

All,

Please find the latest release of flex at:

https://github.com/westes/flex/releases/tag/v2.6.1

We're transitioning flex away from sourceforge and this release steps up that transition.

Here is a summary of the changes since 2.6.0.

* version 2.6.1 released 2016-03-01

** flex resources

*** The flex project is now hosted at github. Consider this a "period of transition". In particular, you should start at https://github.com/westes/flex for the flex codebase, issue tracking and pull requests.

*** New releases of flex are to be found at https://github.com/westes/flex/releases.

** flex internals

*** Flex now uses more modern and more standard names for variable types. There's more work to be done on that front yet, though.

*** A number of compiler warnings have been remedied.

*** Line directives should now  work as expected and be absent when that is expected.

** test suite

*** When running the test suite, c++ files are compiled with the c++ header inside the flex distribution, rather than relying on the build system's flex header , which might not be installed yet or which might be out of date with respect to what flex tests expect.

*** Some portability fixes in the test suite such as opening files for reading in binary mode

** Building flex

*** The file src/scan.c asdistributed  with flex source is now built with the current version of flex. Occasionally this had to be done manually to pick up new flex features. It's now just a part of flex's build system.

*** The pdf version of the manual is no longer distributed with flex, although if you have the texinfo package installed, you can still build it.

*** lots of general build system cleanup

*** the build system tries a bit harder to find libtoolize and texi2dvi.

*** When help2man and texi2dvi are missing, the error messages are now much more helpful.

** bug fixes

*** resolved github issues #53, #54, #55, #61.

*** Resolved sf bugs #128, #129, #155, #160, #184, #187, #195.

I've got additional submitted patches to review as well, so watch the tip of master to see the additional changes.

-- 
Will Estes
Flex Project Maintainer
wes...@gm...
https://github.com/westes/flex

Re: [Flex-devel] comment in generated C code that has C++ style

[Will E. <wes...@gm...>]

This is already fixed in the flex source tree on github and will be included in the next release.

On Sunday,  3 January 2016,  4:57 pm -0800, "Scott C. Livingston" <sli...@cd...> wrote:

> Using flex 2.6.0, I found that the generated file lex.yy.c contains a
> comment in C++ style, which causes `gcc -std=c90` (equivalently, `gcc
> -ansi`) to fail. The line of code is
> 
>     num_to_alloc = 1; // After all that talk, this was set to 1 anyways...
> 
> It occurs in the function yyensure_buffer_stack(). Is this known
> behavior? If so, are there plans to change it, e.g., to be of the form
> /* ... */?
> 
> ~Scott
> 
> ------------------------------------------------------------------------------
> _______________________________________________
> Flex-devel mailing list
> Fle...@li...
> https://lists.sourceforge.net/lists/listinfo/flex-devel

-- 
Will Estes
Flex Project Maintainer
wes...@gm...
https://github.com/westes/flex

[Flex-devel] comment in generated C code that has C++ style

[Scott C. L. <sli...@cd...>]

Using flex 2.6.0, I found that the generated file lex.yy.c contains a
comment in C++ style, which causes `gcc -std=c90` (equivalently, `gcc
-ansi`) to fail. The line of code is

    num_to_alloc = 1; // After all that talk, this was set to 1 anyways...

It occurs in the function yyensure_buffer_stack(). Is this known
behavior? If so, are there plans to change it, e.g., to be of the form
/* ... */?

~Scott

Re: [Flex-devel] flexint.h

[Will E. <wes...@gm...>]

As I recall when it was first created, it was not so obvious that you'd always have the appropriate types laying around. I gather that's long since changed, though.

What you outline below sounds right to me. I look forward to the pr. (Even though it'll be longish.)

On Sunday, 13 December 2015,  6:00 pm -0500, Michael McConville <mm...@my...> wrote:

> Is there any reason for it to continue existing? It seems like we could
> just drop the useless typedef aliases, define __STDC_LIMIT_MACROS and
> include stdint.h in flexdef.h, and delete flexint.h.
> 
> ------------------------------------------------------------------------------
> _______________________________________________
> Flex-devel mailing list
> Fle...@li...
> https://lists.sourceforge.net/lists/listinfo/flex-devel

-- 
Will Estes
Flex Project Maintainer
wes...@gm...
https://github.com/westes/flex

[Flex-devel] flexint.h

[Michael M. <mm...@my...>]

Is there any reason for it to continue existing? It seems like we could
just drop the useless typedef aliases, define __STDC_LIMIT_MACROS and
include stdint.h in flexdef.h, and delete flexint.h.

Re: [Flex-devel] Style conventions

[Will E. <wes...@gm...>]

There's an indent profile in the flex tree. I haven't run it on the
code in I don't know how long. I'm not committed to what's there, but
to the extent that there is an official style for flex, that's it. I'd
say that for now, cleaning up white space is lower priority than
cleaning up code. But any whitespace changes that you slip in along
the way of doing that are likely going to be fine. I don't recall off
hand the thought process that went into the indent profile, though. It
was some mix of "this is what we have" and "this is what we would like
to have" but beyond that, I do not remember the specifics. The
decision was likely made over email, but it was almost certainly done
on a mailing list that no longer exists or perhaps it was done privately in direct correspondence.

If you wanted to suggest changes tothe indent profile, that's fine
by me. If you want to style the C as you go on the parts you're
touching in the way you think best, that's also fine by me.

In general, there's been contributions by lots of folks with lots of
varying levels of attention to -that- sort of detail, so drift in
style is to be expected.

The one thing I'd say, though, is that we don't want to do a big white
space commit as that's going to lose a bunch of git blame information
that we'd probably like for now. I can see putting it on the list for
flex 3.0 (whatever that is; it's "undefined" at the moment). Anything
that gets called "flex 3.0" has probably been re-thought-out at a
fairly deep level and so losing the git blame information is not going to matter as much.

On Wednesday,  9 December 2015, 12:53 pm -0500, Michael McConville <mm...@my...> wrote:

> We don't have defined style conventions, right? It'd help, considering
> that the current style is from the early 90's and needs some serious
> scrubbing.
> 
> Being an OpenBSD dev, I'm partial to our KNF:
> 
> http://www.openbsd.org/cgi-bin/man.cgi/OpenBSD-current/man9/style.9
> 
> I think it's pretty clean standard C and is similar to what we already
> have.
> 
> Thoughts?
> 
> ------------------------------------------------------------------------------
> _______________________________________________
> Flex-devel mailing list
> Fle...@li...
> https://lists.sourceforge.net/lists/listinfo/flex-devel

-- 
Will Estes
Flex Project Maintainer
wes...@gm...
https://github.com/westes/flex

[Flex-devel] Style conventions

[Michael M. <mm...@my...>]

We don't have defined style conventions, right? It'd help, considering
that the current style is from the early 90's and needs some serious
scrubbing.

Being an OpenBSD dev, I'm partial to our KNF:

http://www.openbsd.org/cgi-bin/man.cgi/OpenBSD-current/man9/style.9

I think it's pretty clean standard C and is similar to what we already
have.

Thoughts?

Re: [Flex-devel] Skeleton question

[Will E. <wes...@gm...>]

m4 is newer. m4 because that's the one language that's really available lots of places. Although we do require a few things on top of "generic" m4, and we're generally careful about doing any m ore of that than we absolutely have to.

On Tuesday,  8 December 2015,  8:40 am -0500, Mighty Jo <mig...@gm...> wrote:

> > Done actually. ;)
> 
> Woot!
> 
> > We should explore your "almost" though. And see what it would take to
> turn it into an "all".
> 
> Will do. I'll report back once I'm further along.
> 
> > Given the above, it should be m4 only.
> >
> > I.e. the migration pattern is "new things done the new way and move the
> old things into the new way when that's convenient".
> 
> Excellent. I was having trouble determining which way was newer. Thanks!
> 
> -Joe

> ------------------------------------------------------------------------------
> Go from Idea to Many App Stores Faster with Intel(R) XDK
> Give your users amazing mobile app experiences with Intel(R) XDK.
> Use one codebase in this all-in-one HTML5 development environment.
> Design, debug & build mobile apps & 2D/3D high-impact games for multiple OSs.
> http://pubads.g.doubleclick.net/gampad/clk?id=254741911&iu=/4140

> _______________________________________________
> Flex-devel mailing list
> Fle...@li...
> https://lists.sourceforge.net/lists/listinfo/flex-devel


-- 
Will Estes
Flex Project Maintainer
wes...@gm...
https://github.com/westes/flex

Re: [Flex-devel] Skeleton question

[Mighty Jo <mig...@gm...>]

> Done actually. ;)

Woot!

> We should explore your "almost" though. And see what it would take to
turn it into an "all".

Will do. I'll report back once I'm further along.

> Given the above, it should be m4 only.
>
> I.e. the migration pattern is "new things done the new way and move the
old things into the new way when that's convenient".

Excellent. I was having trouble determining which way was newer. Thanks!

-Joe

Re: [Flex-devel] Allocation functions

[Will E. <wes...@gm...>]

Ah, yeah, I am guessing this is old stuff that used to be necessary.

so yes, those functions can come out.

On Monday,  7 December 2015,  8:31 pm -0500, Michael McConville <mm...@my...> wrote:

> Will Estes wrote:
> > Michael McConville wrote:
> > > Is there any reason for the allocation functions like flex_alloc()
> > > to stay around?
> > 
> > Context, please?
> > 
> > Probably not, and I'm all for making the flex codebase more readable,
> > but what, specifically, do you have in mind? (Keeping in mind that I
> > haven't read your latest pr yet.)
> 
> flex_alloc, flex_free, and flex_realloc are just aliases for stdlib
> functions.* Unless there's a good reason for this, I think it'd be best
> to just replace them with the corresponding stdlib functions.
> 
> * flex_free includes a NULL-check, but this is unnecessary. POSIX 
>   specifies that free() be NULL-safe and all modern platforms comply.
> 
> ------------------------------------------------------------------------------
> Go from Idea to Many App Stores Faster with Intel(R) XDK
> Give your users amazing mobile app experiences with Intel(R) XDK.
> Use one codebase in this all-in-one HTML5 development environment.
> Design, debug & build mobile apps & 2D/3D high-impact games for multiple OSs.
> http://pubads.g.doubleclick.net/gampad/clk?id=254741911&iu=/4140
> _______________________________________________
> Flex-devel mailing list
> Fle...@li...
> https://lists.sourceforge.net/lists/listinfo/flex-devel

-- 
Will Estes
wes...@gm...

Re: [Flex-devel] Allocation functions

[Michael M. <mm...@my...>]

Will Estes wrote:
> Michael McConville wrote:
> > Is there any reason for the allocation functions like flex_alloc()
> > to stay around?
> 
> Context, please?
> 
> Probably not, and I'm all for making the flex codebase more readable,
> but what, specifically, do you have in mind? (Keeping in mind that I
> haven't read your latest pr yet.)

flex_alloc, flex_free, and flex_realloc are just aliases for stdlib
functions.* Unless there's a good reason for this, I think it'd be best
to just replace them with the corresponding stdlib functions.

* flex_free includes a NULL-check, but this is unnecessary. POSIX 
  specifies that free() be NULL-safe and all modern platforms comply.

Re: [Flex-devel] Allocation functions

[Will E. <wes...@gm...>]

Context, please?

Probably not, and I'm all for  making the flex codebase more readable, but what, specifically, do you have in mind? (Keeping in mind that I haven't read your latest pr yet.)

On Monday,  7 December 2015,  7:49 pm -0500, Michael McConville <mm...@my...> wrote:

> Is there any reason for the allocation functions like flex_alloc() to
> stay around?
> 
> ------------------------------------------------------------------------------
> Go from Idea to Many App Stores Faster with Intel(R) XDK
> Give your users amazing mobile app experiences with Intel(R) XDK.
> Use one codebase in this all-in-one HTML5 development environment.
> Design, debug & build mobile apps & 2D/3D high-impact games for multiple OSs.
> http://pubads.g.doubleclick.net/gampad/clk?id=254741911&iu=/4140
> _______________________________________________
> Flex-devel mailing list
> Fle...@li...
> https://lists.sourceforge.net/lists/listinfo/flex-devel

-- 
Will Estes
wes...@gm...

[Flex-devel] Allocation functions

[Michael M. <mm...@my...>]

Is there any reason for the allocation functions like flex_alloc() to
stay around?

Re: [Flex-devel] Skeleton question

[Will E. <wes...@gm...>]

On Sunday,  6 December 2015,  9:42 pm -0500, Mighty Jo <mig...@gm...> wrote:

> Fair enough.  I'll still try to persuade you :-)
> 
> Emitting code via two mechanisms is the one big thing standing in the way
> of supporting scanner generation in more than one language.  It pretty much
> works right now for C/C++ because they're so similar. Still, the header
> option doesn't work for C++ because of hard coded C emissions. If we're
> keeping the C++ generator, those have to be suppressed somehow.
> 
> In reading the code, I see that very similar conditional emissions are made
> both from C and m4. The benefit of moving (almost) all emission to m4 is it
> simplifies supporting scanner skeletons for different languages
> independently. (With the obvious downside that you have two sources to
> maintain, but that may be a disguised blessing in this case.)
> 
> End of persuasion.

Done actually. ;)

If it lets us do more and would be easier, then yeah, that's a win.

We should explore your "almost" though. And see what it would take to turn it into an "all".

> 
> At any rate, I want to experiment with a new generator condition with the
> semantic, "for header only."  The existing %ok-for-header doesn't suffice
> because the block it guards also gets emitted into the non-header file.
> Should such a thing be m4-only or also have a %control-code form?

Given the above, it should be m4 only.

I.e. the migration pattern is "new things done the new way and move the old things into the new way when that's convenient".

> 
> -Joe
> On Dec 5, 2015 5:06 AM, "Will Estes" <wes...@gm...> wrote:
> 
> > I think I prefer that we do things in C where we can.
> >
> > On Friday,  4 December 2015,  9:26 pm -0500, Mighty Jo <mig...@gm...>
> > wrote:
> >
> > > Good evening folks,
> > >
> > > I've been working on overhauling the scanner generation code to move all
> > of
> > > the target language emissions into the skeleton.  I don't know yet
> > whether
> > > the state tables can be generalized this way, but I've identified a few
> > > dozen sites where C code emissions can be converted to setting m4
> > > definitions and performing checks in the skeleton.
> > >
> > > In the skeleton itself I've found similar checks coded two ways.  One is
> > > the collection of m4_check_something macros.  The other is the set of
> > > %check_something statements which are translated into m4 macro calls by
> > > skelout().
> > >
> > > Which style do you prefer going forward?   I won't remove either of them
> > in
> > > my work, but I have to augment at least one of them and I'd like to know
> > > the community's thoughts.
> > >
> > > -Joe
> >
> > >
> > ------------------------------------------------------------------------------
> > > Go from Idea to Many App Stores Faster with Intel(R) XDK
> > > Give your users amazing mobile app experiences with Intel(R) XDK.
> > > Use one codebase in this all-in-one HTML5 development environment.
> > > Design, debug & build mobile apps & 2D/3D high-impact games for multiple
> > OSs.
> > > http://pubads.g.doubleclick.net/gampad/clk?id=254741911&iu=/4140
> >
> > > _______________________________________________
> > > Flex-devel mailing list
> > > Fle...@li...
> > > https://lists.sourceforge.net/lists/listinfo/flex-devel
> >
> >
> > --
> > Will Estes
> > Flex Project Maintainer
> > wes...@gm...
> > https://github.com/westes/flex
> >

> ------------------------------------------------------------------------------
> Go from Idea to Many App Stores Faster with Intel(R) XDK
> Give your users amazing mobile app experiences with Intel(R) XDK.
> Use one codebase in this all-in-one HTML5 development environment.
> Design, debug & build mobile apps & 2D/3D high-impact games for multiple OSs.
> http://pubads.g.doubleclick.net/gampad/clk?id=254741911&iu=/4140

> _______________________________________________
> Flex-devel mailing list
> Fle...@li...
> https://lists.sourceforge.net/lists/listinfo/flex-devel


-- 
Will Estes
wes...@gm...

Re: [Flex-devel] Skeleton question

[Mighty Jo <mig...@gm...>]

Fair enough.  I'll still try to persuade you :-)

Emitting code via two mechanisms is the one big thing standing in the way
of supporting scanner generation in more than one language.  It pretty much
works right now for C/C++ because they're so similar. Still, the header
option doesn't work for C++ because of hard coded C emissions. If we're
keeping the C++ generator, those have to be suppressed somehow.

In reading the code, I see that very similar conditional emissions are made
both from C and m4. The benefit of moving (almost) all emission to m4 is it
simplifies supporting scanner skeletons for different languages
independently. (With the obvious downside that you have two sources to
maintain, but that may be a disguised blessing in this case.)

End of persuasion.

At any rate, I want to experiment with a new generator condition with the
semantic, "for header only."  The existing %ok-for-header doesn't suffice
because the block it guards also gets emitted into the non-header file.
Should such a thing be m4-only or also have a %control-code form?

-Joe
On Dec 5, 2015 5:06 AM, "Will Estes" <wes...@gm...> wrote:

> I think I prefer that we do things in C where we can.
>
> On Friday,  4 December 2015,  9:26 pm -0500, Mighty Jo <mig...@gm...>
> wrote:
>
> > Good evening folks,
> >
> > I've been working on overhauling the scanner generation code to move all
> of
> > the target language emissions into the skeleton.  I don't know yet
> whether
> > the state tables can be generalized this way, but I've identified a few
> > dozen sites where C code emissions can be converted to setting m4
> > definitions and performing checks in the skeleton.
> >
> > In the skeleton itself I've found similar checks coded two ways.  One is
> > the collection of m4_check_something macros.  The other is the set of
> > %check_something statements which are translated into m4 macro calls by
> > skelout().
> >
> > Which style do you prefer going forward?   I won't remove either of them
> in
> > my work, but I have to augment at least one of them and I'd like to know
> > the community's thoughts.
> >
> > -Joe
>
> >
> ------------------------------------------------------------------------------
> > Go from Idea to Many App Stores Faster with Intel(R) XDK
> > Give your users amazing mobile app experiences with Intel(R) XDK.
> > Use one codebase in this all-in-one HTML5 development environment.
> > Design, debug & build mobile apps & 2D/3D high-impact games for multiple
> OSs.
> > http://pubads.g.doubleclick.net/gampad/clk?id=254741911&iu=/4140
>
> > _______________________________________________
> > Flex-devel mailing list
> > Fle...@li...
> > https://lists.sourceforge.net/lists/listinfo/flex-devel
>
>
> --
> Will Estes
> Flex Project Maintainer
> wes...@gm...
> https://github.com/westes/flex
>

Re: [Flex-devel] Skeleton question

[Will E. <wes...@gm...>]

I think I prefer that we do things in C where we can.

On Friday,  4 December 2015,  9:26 pm -0500, Mighty Jo <mig...@gm...> wrote:

> Good evening folks,
> 
> I've been working on overhauling the scanner generation code to move all of
> the target language emissions into the skeleton.  I don't know yet whether
> the state tables can be generalized this way, but I've identified a few
> dozen sites where C code emissions can be converted to setting m4
> definitions and performing checks in the skeleton.
> 
> In the skeleton itself I've found similar checks coded two ways.  One is
> the collection of m4_check_something macros.  The other is the set of
> %check_something statements which are translated into m4 macro calls by
> skelout().
> 
> Which style do you prefer going forward?   I won't remove either of them in
> my work, but I have to augment at least one of them and I'd like to know
> the community's thoughts.
> 
> -Joe

> ------------------------------------------------------------------------------
> Go from Idea to Many App Stores Faster with Intel(R) XDK
> Give your users amazing mobile app experiences with Intel(R) XDK.
> Use one codebase in this all-in-one HTML5 development environment.
> Design, debug & build mobile apps & 2D/3D high-impact games for multiple OSs.
> http://pubads.g.doubleclick.net/gampad/clk?id=254741911&iu=/4140

> _______________________________________________
> Flex-devel mailing list
> Fle...@li...
> https://lists.sourceforge.net/lists/listinfo/flex-devel


-- 
Will Estes
Flex Project Maintainer
wes...@gm...
https://github.com/westes/flex

[Flex-devel] Skeleton question

[Mighty Jo <mig...@gm...>]

Good evening folks,

I've been working on overhauling the scanner generation code to move all of
the target language emissions into the skeleton.  I don't know yet whether
the state tables can be generalized this way, but I've identified a few
dozen sites where C code emissions can be converted to setting m4
definitions and performing checks in the skeleton.

In the skeleton itself I've found similar checks coded two ways.  One is
the collection of m4_check_something macros.  The other is the set of
%check_something statements which are translated into m4 macro calls by
skelout().

Which style do you prefer going forward?   I won't remove either of them in
my work, but I have to augment at least one of them and I'd like to know
the community's thoughts.

-Joe

Re: [Flex-devel] texi2dvi dependency

[Mighty Jo <mig...@gm...>]

Very welcome. Something I learned about missing: it only supports a handful
of programs. If you try to use it with something it doesn't support it
won't rewrite the exit code for missing programs - which is the whole
point. In those cases a colon (:) works just as well but doesn't produce
help text.

You can get the list of missing's supported programs with

./build-aux/missing -h

from the distro root.
On Dec 3, 2015 7:20 AM, "Will Estes" <wes...@gm...> wrote:

> Thanks for this. The only change I made is to put gtexi2dvi before
> texi2dvi.
>
> Otherwise, that's a great pattern to notify better about missing programs
> and use "missing" when it's relevant.
>
> On Wednesday,  2 December 2015,  9:32 pm -0500, Mighty Jo <
> mig...@gm...> wrote:
>
> > I just sent up PR#23 which patches configure.ac to support both texi2dvi
> > and gtexi2dvi.  It fixes similar issues with the bison and help2man
> > programs as well.
> >
> > On Wed, Dec 2, 2015 at 6:38 PM, Michael McConville <mm...@my...>
> > wrote:
> >
> > > Mighty Jo wrote:
> > > > I didn't initially have the tools to build the docs installed. It's
> > > > likely users won't either.
> > > >
> > > > I think it's reasonable to pull the pdf and html out of the
> repository
> > > > since they're build products, but I'd leave them in the distro
> > > > tarball.
> > >
> > > Yeah, I think most package maintainers will find the additional
> > > dependencies unfortunate.
> > >
>
> >
> ------------------------------------------------------------------------------
> > Go from Idea to Many App Stores Faster with Intel(R) XDK
> > Give your users amazing mobile app experiences with Intel(R) XDK.
> > Use one codebase in this all-in-one HTML5 development environment.
> > Design, debug & build mobile apps & 2D/3D high-impact games for multiple
> OSs.
> > http://pubads.g.doubleclick.net/gampad/clk?id=254741911&iu=/4140
>
> > _______________________________________________
> > Flex-devel mailing list
> > Fle...@li...
> > https://lists.sourceforge.net/lists/listinfo/flex-devel
>
>
> --
> Will Estes
> Flex Project Maintainer
> wes...@gm...
> https://github.com/westes/flex
>

Re: [Flex-devel] texi2dvi dependency

[Will E. <wes...@gm...>]

Thanks for this. The only change I made is to put gtexi2dvi before texi2dvi. 

Otherwise, that's a great pattern to notify better about missing programs and use "missing" when it's relevant.

On Wednesday,  2 December 2015,  9:32 pm -0500, Mighty Jo <mig...@gm...> wrote:

> I just sent up PR#23 which patches configure.ac to support both texi2dvi
> and gtexi2dvi.  It fixes similar issues with the bison and help2man
> programs as well.
> 
> On Wed, Dec 2, 2015 at 6:38 PM, Michael McConville <mm...@my...>
> wrote:
> 
> > Mighty Jo wrote:
> > > I didn't initially have the tools to build the docs installed. It's
> > > likely users won't either.
> > >
> > > I think it's reasonable to pull the pdf and html out of the repository
> > > since they're build products, but I'd leave them in the distro
> > > tarball.
> >
> > Yeah, I think most package maintainers will find the additional
> > dependencies unfortunate.
> >

> ------------------------------------------------------------------------------
> Go from Idea to Many App Stores Faster with Intel(R) XDK
> Give your users amazing mobile app experiences with Intel(R) XDK.
> Use one codebase in this all-in-one HTML5 development environment.
> Design, debug & build mobile apps & 2D/3D high-impact games for multiple OSs.
> http://pubads.g.doubleclick.net/gampad/clk?id=254741911&iu=/4140

> _______________________________________________
> Flex-devel mailing list
> Fle...@li...
> https://lists.sourceforge.net/lists/listinfo/flex-devel


-- 
Will Estes
Flex Project Maintainer
wes...@gm...
https://github.com/westes/flex