flex-devel — development of flex itself

[Flex-devel] yyFlexLexer inheritance issue reports

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

Morning folks,

I'm writing more tests for the c++ scanner. A comment in the source says
you've had reports that the yyFlexLexer macro breaks inheritance.  Google
isn't helping me find those reports. Did they come to one of the listservs?

Thanks!

-Joe

Re: [Flex-devel] not-for-header and M4_YY_IN_HEADER

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

Thanks, Jo.

On Tuesday, 24 November 2015,  9:19 pm -0500, Mighty Jo <mig...@gm...> wrote:

> Hi all,
> 
> Today I learned that in flex.skl, this
> 
>   %not-for-header ... %ok-for-header
> 
> is an alias for
> 
>   m4_ifdef( [[M4_YY_IN_HEADER]],,[[ ... ]])
> 
> I've been playing with a custom skeleton that begins with "%ok-for-header"
> and which kept choking gcc on a stray "]])".  Now I know why.
> 
> I also learned that filter_tee_header() in filter.c is responsible for
> writing the #define guards in the generated .h file.
> 
> Hope I'm not spamming something you already know, but I couldn't find this
> truth nugget on google thanks to all the indexed copies of the source code
> junking up the first umpteen result pages.  (Oh, dear Google, please rank
> this humble listserve archive highly among thy links. Amen.)
> 
> -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=254741551&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] not-for-header and M4_YY_IN_HEADER

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

Hi all,

Today I learned that in flex.skl, this

  %not-for-header ... %ok-for-header

is an alias for

  m4_ifdef( [[M4_YY_IN_HEADER]],,[[ ... ]])

I've been playing with a custom skeleton that begins with "%ok-for-header"
and which kept choking gcc on a stray "]])".  Now I know why.

I also learned that filter_tee_header() in filter.c is responsible for
writing the #define guards in the generated .h file.

Hope I'm not spamming something you already know, but I couldn't find this
truth nugget on google thanks to all the indexed copies of the source code
junking up the first umpteen result pages.  (Oh, dear Google, please rank
this humble listserve archive highly among thy links. Amen.)

-Joe

[Flex-devel] flex 2.6.0 released

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

All,

Please find the latest release of flex, version 2.6.0from the following location:

https://sourceforge.net/projects/flex/files/

2.6.0 was about cleaning up flex. There are some new c++ features as well. In particular, flex now builds on OSX and a number of compiler warnings have been silenced in flex generated scanners.

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

Re: [Flex-devel] Bootstrapping flex

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

> > First up: that rc1 version number, lol.  The FLEX_BETA test in flex.skl
> > near line 90 does not like that.
>
> Oops! Didn't think of that. Could you open an issue on github so it gets
on the list of things to fix? (Albeit for "next release" as onceI bump
things up to 2.6.0 it'll go away for the moment.)
>

Will do.

Re: [Flex-devel] Bootstrapping flex

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

On Monday, 16 November 2015, 11:16 pm -0500, Mighty Jo <mig...@gm...> wrote:

> First up: that rc1 version number, lol.  The FLEX_BETA test in flex.skl
> near line 90 does not like that.

Oops! Didn't think of that. Could you open an issue on github so it gets on the list of things to fix? (Albeit for "next release" as onceI bump things up to 2.6.0 it'll go away for the moment.)

> 
> I noticed because I've been working on bootstrapping.
> 
> Will noticed a quirk in my recent pull requests in which it was necessary
> to bootstrap flex by compiling scan.l with the installed f/lex first, then
> again with the flex built by the first stage. I'm summarizing some of that
> conversation here.
> 
> Best practices for testing the build process including starting from a
> source tree prepared by
> 
> $ git clean -xdf
> 
> which removes everything that isn't known to version control.
> 
> Then run
> 
> $ ./autogen.sh && ./configure && make && make check && make distcheck
> 
> If all that works you're in pretty good shape. (If your shell complains
> that configure doesn't exist, change the '&&' after autogen.sh to a
> semicolon or run the commands separately.)
> 
> Bootstrapping is needed whenever scan.l changes. It's also needed when the
> skeleton changes, since that's involved in compiling scan.l. I haven't
> worked out whether that means a second bootstrap stage is needed but I
> don't think it is since flex.skl is independent of scan.l.
> 
> I've been playing with techniques for performing a bootstrap via automake
> and I'm getting close.  -local extensions and suffix rule games get you
> most of the way. I got sidetracked trying to understand how the VERSION
> variable in src/Makefile.am gets set.  It from AC_INIT, semi-obviously, but
> the autoconf manual says the variable is called PACKAGE_VERSION.  Turns out
> it also sets the VERSION variable to the same value but doesn't mention
> this in its manual.
> 
> That's all the brain dump I have for tonight.
> 
> -Joe

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

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


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

Re: [Flex-devel] Bootstrapping flex

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

Okay, one more thing.

I have flex bootstrapping in this branch:
https://github.com/Mightyjo/flex/tree/bootstrap at 4053d8b

It even passes distcheck on my machine.

The use of BUILT_SOURCES looks weird, but it's permissible according to the
automake manual.  What says the community?

-Joe

[Flex-devel] Bootstrapping flex

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

First up: that rc1 version number, lol.  The FLEX_BETA test in flex.skl
near line 90 does not like that.

I noticed because I've been working on bootstrapping.

Will noticed a quirk in my recent pull requests in which it was necessary
to bootstrap flex by compiling scan.l with the installed f/lex first, then
again with the flex built by the first stage. I'm summarizing some of that
conversation here.

Best practices for testing the build process including starting from a
source tree prepared by

$ git clean -xdf

which removes everything that isn't known to version control.

Then run

$ ./autogen.sh && ./configure && make && make check && make distcheck

If all that works you're in pretty good shape. (If your shell complains
that configure doesn't exist, change the '&&' after autogen.sh to a
semicolon or run the commands separately.)

Bootstrapping is needed whenever scan.l changes. It's also needed when the
skeleton changes, since that's involved in compiling scan.l. I haven't
worked out whether that means a second bootstrap stage is needed but I
don't think it is since flex.skl is independent of scan.l.

I've been playing with techniques for performing a bootstrap via automake
and I'm getting close.  -local extensions and suffix rule games get you
most of the way. I got sidetracked trying to understand how the VERSION
variable in src/Makefile.am gets set.  It from AC_INIT, semi-obviously, but
the autoconf manual says the variable is called PACKAGE_VERSION.  Turns out
it also sets the VERSION variable to the same value but doesn't mention
this in its manual.

That's all the brain dump I have for tonight.

-Joe

[Flex-devel] Char macro

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

Hi, everyone.

The flex codebase uses the macro Char, an alias for unsigned char. Both
the capitalization and the name are idiosyncratic and can be confusing.
For example, I found a few ctype function argument type issues (see
https://www.securecoding.cert.org/confluence/x/fAs) recently, and Char
obfuscated some.

I think two good options are:

 * remove Char and use unsigned char directly, or
 * rename Char to u_char (the BSDs already use this idiom)

Thoughts?

Thanks,
Michael

[Flex-devel] flex 2.6.0rc1 available

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

All,

Please find flex, version 2.6.0rc1 at the url:

https://sourceforge.net/projects/flex/files/flex-2.6.0rc1.tar.gz/download

There have been some recent changes committed that you all might want to tryout. In particular, #182's fix for OSX builds is included. There's also stuff that changes how c++ works, although that should just be internal to the generated scanners.

I've got a few documentation changes to make before calling an official 2.6.0, so here's your chance to give feedback on what's in the tree currently.

There's a tag for this in the github tree as well for those of you that want to work off of it.

After 2.6.0 is official, I'll be mining the github issues and pull requests and the sourceforge tickets to see what issues are still outstanding and what can be cleaned up / closed.

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

Re: [Flex-devel] Pull Request #16

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

On Nov 10, 2015 8:16 AM, "Will Estes" <wes...@gm...> wrote:
>
> Yeah, I need to draw up a road map, but that means clearing out the
backlog of bugs and patches and feature requests and such first.
>
> And then we need some time where the new flex locations are well known
and the big operating system vendors have time to catch up to where flex is
so we can see what other problems surface.
>
> So at the moment, there is no "3.0" plan.

Fair enough.  I only use the one feature regularly anyway. No need to
introduce a big change just for that.

-Joe

Re: [Flex-devel] Pull Request #16

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

Yeah, I need to draw up a road map, but that means clearing out the backlog of bugs and patches and feature requests and such first.

And then we need some time where the new flex locations are well known and the big operating system vendors have time to catch up to where flex is so we can see what other problems surface.

So at the moment, there is no "3.0" plan.

On Tuesday, 10 November 2015,  8:11 am -0500, Mighty Jo <mig...@gm...> wrote:

> On Nov 10, 2015 8:03 AM, "Will Estes" <wes...@gm...> wrote:
> > > > > The autoconf archive provides ax_cxx_compile_stdcxx_11.m4 for the
> c++11
> > > > feature test.  I've used it and
> > > > > it works well if we want to go that route.
> > > >
> > > > I'm becoming more a fan of the autoconf archive, yes.
> > >
> > >
> > > It's certainly better than the macros I write myself.
> >
> > So we'll get to this, but only after that next release happens--just
> because I'll need time to play with the new autoconf bits. There's one or
> two other things I'd like to add in terms of autoconf magic as well, so I'm
> thinking "I'd rather do it right".
> 
> Certainly. I was thinking this would be a consideration for 3.0 at the
> earliest.
> 
> -Joe

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

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


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

Re: [Flex-devel] Pull Request #16

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

On Nov 10, 2015 8:03 AM, "Will Estes" <wes...@gm...> wrote:
> > > > The autoconf archive provides ax_cxx_compile_stdcxx_11.m4 for the
c++11
> > > feature test.  I've used it and
> > > > it works well if we want to go that route.
> > >
> > > I'm becoming more a fan of the autoconf archive, yes.
> >
> >
> > It's certainly better than the macros I write myself.
>
> So we'll get to this, but only after that next release happens--just
because I'll need time to play with the new autoconf bits. There's one or
two other things I'd like to add in terms of autoconf magic as well, so I'm
thinking "I'd rather do it right".

Certainly. I was thinking this would be a consideration for 3.0 at the
earliest.

-Joe

Re: [Flex-devel] Pull Request #16

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

On Monday,  9 November 2015,  9:51 pm -0500, Mighty Jo <mig...@gm...> wrote:

> > > The autoconf archive provides ax_cxx_compile_stdcxx_11.m4 for the c++11
> > feature test.  I've used it and
> > > it works well if we want to go that route.
> >
> > I'm becoming more a fan of the autoconf archive, yes.
> 
> 
> It's certainly better than the macros I write myself.

So we'll get to this, but only after that next release happens--just because I'll need time to play with the new autoconf bits. There's one or two other things I'd like to add in terms of autoconf magic as well, so I'm thinking "I'd rather do it right".


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

Re: [Flex-devel] Status of the patch for bug 182?

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

Looks like you should be in src/ for that patch to apply.. So, from where you were:

$ cd src/
 $ patch < ../patchfile

As you can see from the lines that start with - and +, that patch is changing linker options (the *LDFLAGS variables in Makefile.am) for the libfl variants that get built. Apparently it needs the version info and since building this way was new to me, I likely copied whatever the manual said to do.

On Tuesday, 10 November 2015,  1:27 am -0800, Damian Rouson <da...@so...> wrote:

> 
> ________________________________
> Damian Rouson, Ph.D., P.E.
> President, Sourcery Institute
> http://www.sourceryinstitute.org
> +1-510-600-2992 (mobile)
> 
> > On Nov 9, 2015, at 7:41 AM, Will Estes <wes...@gm...> wrote:
> > 
> > That's the default medium priority assigned by sourceforge. I'll move this one up in the queue, though. Also note that there's a lot of work that has happened in flex's git tree that has not been released yet. I've got a handful of pull requests to work through in the next few days and I'll add #182 to that list as well. At that point I'll make a release.
> 
> Thanks for the update. 
> 
> > 
> > Can you also verify that the proposed patch works for you on OSX? I don't have an OSX machine to test on and the symptom doesn't manifest on my linux box.
> 
> 
> I’ve always had difficulty applying patches.  Here’s what the patch gives me, but I won’t be surprised if I’m doing something wrong:
> 
> localhost:flex-2.5.39 rouson$ cat file.patch
> --- Makefile.am copy    2014-10-27 16:41:46.000000000 +0900
> +++ Makefile.am 2014-10-27 16:48:56.000000000 +0900
> @@ -73,13 +73,13 @@
>     libmain.c \
>     libyywrap.c
> 
> -libfl_la_LDFLAGS = -no-undefined -version-info @SHARED_VERSION_INFO@
> +libfl_la_LDFLAGS = -version-info @SHARED_VERSION_INFO@
> 
>  libfl_pic_la_SOURCES = \
>     libmain.c \
>     libyywrap.c
> 
> -libfl_pic_la_LDFLAGS = -no-undefined -version-info @SHARED_VERSION_INFO@
> +libfl_pic_la_LDFLAGS = -version-info @SHARED_VERSION_INFO@
> 
>  noinst_HEADERS = \
>     flexdef.h \
> localhost:flex-2.5.39 rouson$ patch -p0 < file.patch 
> patching file Makefile.am
> Hunk #1 FAILED at 73.
> 1 out of 1 hunk FAILED -- saving rejects to file Makefile.am.re
> 
> If you can provide instructions about how to apply the patch, I’ll be glad to try again.
> 
> D

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

Re: [Flex-devel] Pull Request #16

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

On Sun, Nov 8, 2015 at 11:04 AM, Will Estes <wes...@gm...> wrote:
>
> > > > Make all & check weren't rebuilding all of the scanners in tests/
> when
> > > > files in src/, skel.c for example, had changed. Several of the tests'
> > > built
>
> the test suite tests the built version of flex in the build tree. So, in
> the case where flex source files change but flex has not been rebuilt, the
> correct thing to do is to test using the currently built version of flex.
> The test suit should consider "flex" as a black box that has to be tested.
>

Got it.  I usually end up building libtool convenience libraries and making
my tests depend on those.  Depending on the build binary does the same
thing in this case.  Nifty.  I've submitted PR#19 that does just that.


>
> > > > sources weren't listed as such and 'make clean' didn't reach them so
> I
> > > kept
> > > > having to delete them manually or touch the .l's to rebuild them.  I
> made
> > > > sure they were all listed in the right automake vars to let make
> clean
> > > > them.  I didn't fiddle with making them depend on skel.c yet.
>
> I'll look for the patch on this. If you're correct, then it's definitely a
> bug.
>
>
That was PR#18 for the google record.


> > >
> > > Oh, sorting out dependencies, that's different--and awesome. Thanks.
> > > That's likely an easy change to incorporate by the way.
> > >
> >
> > Haha, that's what I was thinking.  I'll still work on separating out the
> > change set.  I need the practice with Git.
>
> Branches are your friend ;) Ping me if you need help on this.
>
>
Figured it out. Git is much better about this kind of thing than SVN.  Love
the squash and fixup options when rebasing.

<snip>


> > The autoconf archive provides ax_cxx_compile_stdcxx_11.m4 for the c++11
> feature test.  I've used it and
> > it works well if we want to go that route.
>
> I'm becoming more a fan of the autoconf archive, yes.


It's certainly better than the macros I write myself.


> That being said, this sort of discussion should be on list so others can
> weigh in as they have expertise and so google can tape the show for the
> future.
>
>
Cool beans!

-Joe

Re: [Flex-devel] Status of the patch for bug 182?

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

On Monday,  9 November 2015,  7:25 am -0800, Damian Rouson <da...@so...> wrote:

> Hi All,
> 
> I’m new to flex and only have a need to install it because it is required for building GCC from source (https://gcc.gnu.org/install/prerequisites.html).  My flex build on OS fails for the same reason as the December 2014 bug report 182 (http://sourceforge.net/p/flex/bugs/182/), which contains a patch that Bastien Chevreux confirmed works on 18 October 2015. Could someone please let me know the status of the submitted patch?  Will this patch 
It's in the queue. I'm just gearing back up to get flex some time, so things will start moving again.

or another one that fixes the problem be applied to your repository and released soon?  

That is the plan, yes.

> 
> FYI, I’m supporting OS X users of OpenCoarrays (https://github.com/sourceryinstitute/opencoarrays), for which a recent build of GCC is a requirement.  I’ve written a script that can install all of our prerequisites, but the script currently fails on OS X because of the aforementioned bug.  I’d very much like to avoid having to apply this patch in the script, especially because of the potential for the patch to become out-of-date over time.
> 
> Also, the priority on the bug shows as 5.  Is that a high priority or a low priority?  If it’s low, is there any chance of someone bumping the status up?  The submitted patch is approaching one year old.

That's the default medium priority assigned by sourceforge. I'll move this one up in the queue, though. Also note that there's a lot of work that has happened in flex's git tree that has not been released yet. I've got a handful of pull requests to work through in the next few days and I'll add #182 to that list as well. At that point I'll make a release.

Can you also verify that the proposed patch works for you on OSX? I don't have an OSX machine to test on and the symptom doesn't manifest on my linux box.



> 
> Damian
> ------------------------------------------------------------------------------
> Presto, an open source distributed SQL query engine for big data, initially
> developed by Facebook, enables you to easily query your data on Hadoop in a 
> more interactive manner. Teradata is also now providing full enterprise
> support for Presto. Download a free open source copy now.
> http://pubads.g.doubleclick.net/gampad/clk?id=250295911&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] Status of the patch for bug 182?

[Damian R. <da...@so...>]

Hi All,

I’m new to flex and only have a need to install it because it is required for building GCC from source (https://gcc.gnu.org/install/prerequisites.html).  My flex build on OS fails for the same reason as the December 2014 bug report 182 (http://sourceforge.net/p/flex/bugs/182/), which contains a patch that Bastien Chevreux confirmed works on 18 October 2015. Could someone please let me know the status of the submitted patch?  Will this patch or another one that fixes the problem be applied to your repository and released soon?  

FYI, I’m supporting OS X users of OpenCoarrays (https://github.com/sourceryinstitute/opencoarrays), for which a recent build of GCC is a requirement.  I’ve written a script that can install all of our prerequisites, but the script currently fails on OS X because of the aforementioned bug.  I’d very much like to avoid having to apply this patch in the script, especially because of the potential for the patch to become out-of-date over time.

Also, the priority on the bug shows as 5.  Is that a high priority or a low priority?  If it’s low, is there any chance of someone bumping the status up?  The submitted patch is approaching one year old.

Damian

Re: [Flex-devel] Pull Request #16

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

On Sunday,  8 November 2015,  1:35 am -0500, Mighty Jo <mig...@gm...> wrote:

> On Sat, Nov 7, 2015 at 4:04 PM, Will Estes <wes...@gm...> wrote:
> 
> > > Make all & check weren't rebuilding all of the scanners in tests/ when
> > > files in src/, skel.c for example, had changed. Several of the tests'
> > built

the test suite tests the built version of flex in the build tree. So, in the case where flex source files change but flex has not been rebuilt, the correct thing to do is to test using the currently built version of flex. The test suit should consider "flex" as a black box that has to be tested.

> > > sources weren't listed as such and 'make clean' didn't reach them so I
> > kept
> > > having to delete them manually or touch the .l's to rebuild them.  I made
> > > sure they were all listed in the right automake vars to let make clean
> > > them.  I didn't fiddle with making them depend on skel.c yet.

I'll look for the patch on this. If you're correct, then it's definitely a bug.

> >
> > Oh, sorting out dependencies, that's different--and awesome. Thanks.
> > That's likely an easy change to incorporate by the way.
> >
> 
> Haha, that's what I was thinking.  I'll still work on separating out the
> change set.  I need the practice with Git.

Branches are your friend ;) Ping me if you need help on this.

> 
> 
> > As for depending on skel.c, that's a generated file, so you probably want
> > to list the dependencies of skel.c instead.
> >
> 
> Cool, that was going to be my question to the mailing list.  I'm always
> back and forth about how to handle this for tests in my own projects.

See above for my thoughts on testing.

> 
> 
> > Regarding c++, how widespread is c++11? Or what constraint does that imply
> > about compiler version or whatever the right way to ask that question is.
> > Is it easy to offer alternatives in a nicely ifdef-y way that would play
> > well with autoconf? You mentioned delegating certain methods and c++ is not
> > something I know more than the rudiments about.
> 
> 
> Delegating is just a fancy name for wrapper functions that change the
> argument types.  C++ handles them just like C does except when the function
> is a constructor.  Then GCC (v5.2.1) gives the error "delegating
> constructors only available with -std=c++11..."  The standard specifies the
> timing of object initialization such that delegated constructors would only
> work if they were lambda closures  - which C++ didn't have until C++11,
> Q.E.D.  It's common practice to work around that with an init method (which
> the optimizer usually inlines) but I prefer the wrapper construction
> aesthetically.  Still, I hate duplicating code worse than excess syntax, so
> I'll deal with it.
> 
> As for c++11, it's well supported on desktop and server targets (x86, x64,
> ppc, etc.) but not as well for embedded targets.  GCC's had good support
> since about v4.8, Visual C++ since 2013, CLANG since v3.3.  But Arduino
> support is still in beta, for example.  The autoconf archive provides
> ax_cxx_compile_stdcxx_11.m4 for the c++11 feature test.  I've used it and
> it works well if we want to go that route.

I'm becoming more a fan of the autoconf archive, yes. That being said, this sort of discussion should be on list so others can weigh in as they have expertise and so google can tape the show for the future.

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

Re: [Flex-devel] Pull Request #16

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

> > I tweaked the build system along the way to ensure built sources could
be
> > cleaned on demand and to give hints to make's dependency tracking.
>
> How does this effect the automake/autoconf/libtool stuff? In what ways
were the features you list missing?
>

Make all & check weren't rebuilding all of the scanners in tests/ when
files in src/, skel.c for example, had changed. Several of the tests' built
sources weren't listed as such and 'make clean' didn't reach them so I kept
having to delete them manually or touch the .l's to rebuild them.  I made
sure they were all listed in the right automake vars to let make clean
them.  I didn't fiddle with making them depend on skel.c yet.

> >
> > It's a small change, but I'll build on it.
>
> In general, the best practice is to segregate these sorts of changes. So,
the c++ stuff and the build system should be two separate pull requests so
that they can be handled independently--given that maybe one needs to be
handled before the other, especially if one of your change sets assumes the
existence of the other.

You're right, of course.  I got lazy.  I'll look at how to divide the
changes up cleanly this weekend and put in two fresh requests.

> Thanks!

You're welcome! I'm glad this is a living project.

-Joe

Re: [Flex-devel] Pull Request #16

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

Thanks for your interest. I've got this in my queue to review.

> I tweaked the build system along the way to ensure built sources could be
> cleaned on demand and to give hints to make's dependency tracking.

How does this effect the automake/autoconf/libtool stuff? In what ways were the features you list missing?

> 
> It's a small change, but I'll build on it.

In general, the best practice is to segregate these sorts of changes. So, the c++ stuff and the build system should be two separate pull requests so that they can be handled independently--given that maybe one needs to be handled before the other, especially if one of your change sets assumes the existence of the other.

Thanks!

--Will


On Saturday,  7 November 2015, 11:43 am -0500, Mighty Jo <mig...@gm...> wrote:

> All,
> 
> I have C++-idiomatic stream handing working in a branch even with
> master@HEAD.  I kept the old interface in addition to the new one - the
> old-style calls just delegate to the new ones.  Had to do something
> unwieldy with the constructors for yyFlexLexer since delegating
> constructors didn't become part of the standard until C++11 and I didn't
> want to add that as a dependency.
> 
> I tweaked the build system along the way to ensure built sources could be
> cleaned on demand and to give hints to make's dependency tracking.
> 
> It's a small change, but I'll build on it.
a> 
> -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] Pull Request #16

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

All,

I have C++-idiomatic stream handing working in a branch even with
master@HEAD.  I kept the old interface in addition to the new one - the
old-style calls just delegate to the new ones.  Had to do something
unwieldy with the constructors for yyFlexLexer since delegating
constructors didn't become part of the standard until C++11 and I didn't
want to add that as a dependency.

I tweaked the build system along the way to ensure built sources could be
cleaned on demand and to give hints to make's dependency tracking.

It's a small change, but I'll build on it.

-Joe

Re: [Flex-devel] does flex minimize DFAs?

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

Konstantin,

I'm new to the code, but I have been reading it.

Looks like dfa.c does do state minimization via partition refinement.  I
don't know the name of the algorithm being used.

-Joe

[Flex-devel] does flex minimize DFAs?

[akonsu <ak...@gm...>]

Hello,

does anyone know if flex performs DFA minimization? If so what algorithm is
used?

thanks
konstantin

Re: [Flex-devel] Greetings

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

Jo,

No, you'll not be violating any design decisions since there aren't any design decisions to be violated. Make sure you're diffing against the latest over in the github repo, as that makes the patch go in easier. The usual pull request magic can be done over there as well.

Thanks,

--Will


On Saturday, 24 October 2015,  8:24 pm -0400, Mighty Jo <mig...@gm...> wrote:

> Hi all,
> 
> I'm a C++ developer (among other things) who's been working with Flex.  I
> noticed some C quirks in the skeleton and I'm planning to ameliorate them.
> If I'm reading the mailing list archives correctly, I shouldn't be
> violating any designs you've set out, but I'll write to the list before
> overhauling anything major.  I'll be sticking to the C++ specific code to
> begin with (e.g. changing pointers to std::istream into references wherever
> the lexer doesn't take ownership).
> 
> Cheers!
> 
> -Joe Langley

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

> _______________________________________________
> 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