jflex-devel Mailing List for JFlex
The fast lexer generator for Java
Brought to you by:
lsf37,
steve_rowe
Menu
▾
▴
jflex-devel — developers mailing list for JFlex
You can subscribe to this list here.
| 2008 |
Jan
(11) |
Feb
(17) |
Mar
(18) |
Apr
(4) |
May
(15) |
Jun
|
Jul
|
Aug
(5) |
Sep
|
Oct
|
Nov
|
Dec
(2) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2009 |
Jan
(11) |
Feb
(21) |
Mar
(3) |
Apr
|
May
|
Jun
(8) |
Jul
(5) |
Aug
(24) |
Sep
(8) |
Oct
(5) |
Nov
(23) |
Dec
|
| 2010 |
Jan
|
Feb
|
Mar
|
Apr
(5) |
May
(5) |
Jun
(2) |
Jul
(2) |
Aug
|
Sep
|
Oct
(10) |
Nov
|
Dec
|
| 2011 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(8) |
Jul
|
Aug
|
Sep
(2) |
Oct
|
Nov
|
Dec
(1) |
| 2012 |
Jan
(2) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(3) |
Sep
|
Oct
|
Nov
|
Dec
|
| 2013 |
Jan
|
Feb
(1) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(19) |
Oct
(26) |
Nov
(5) |
Dec
(4) |
| 2014 |
Jan
(20) |
Feb
(15) |
Mar
(14) |
Apr
|
May
(6) |
Jun
(28) |
Jul
|
Aug
(2) |
Sep
|
Oct
|
Nov
|
Dec
|
| 2015 |
Jan
(3) |
Feb
(4) |
Mar
(4) |
Apr
(18) |
May
|
Jun
(2) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2016 |
Jan
|
Feb
(3) |
Mar
(2) |
Apr
(1) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2017 |
Jan
|
Feb
(1) |
Mar
(4) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(10) |
Dec
(1) |
| 2018 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(7) |
Oct
(18) |
Nov
|
Dec
|
| 2019 |
Jan
(4) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(2) |
Dec
(9) |
| 2020 |
Jan
|
Feb
(5) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2021 |
Jan
|
Feb
(1) |
Mar
(1) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Gerwin K. <ge...@do...> - 2021-03-01 09:40:04
|
> On 27 Feb 2021, at 10:02, Régis Décamps <re...@de...> wrote: > > Hello, > > I stumbled upon this visualisation and it's cute https://www.visualsource.net/repo/github.com/jflex-de/jflex Very nice, I like it! :-) Cheers, Gerwin |
|
From: Régis D. <re...@de...> - 2021-02-26 23:03:09
|
Hello, I stumbled upon this visualisation and it's cute https://www.visualsource.net/repo/github.com/jflex-de/jflex -- Régis Décamps http://regis.decamps.info/ |
|
From: Gerwin K. <ge...@do...> - 2020-02-27 05:37:08
|
> To fix this, we could deploy the cup jar, adding sources, which would add a bit of noise to the repo, but, while looking around, I found that someone else has written a cup maven plugin, which actually looks quite nice: > > https://github.com/vbmacher/cup-maven-plugin After playing a bit with it, it is not quite as nice as I had thought. Many things that work by default with out plugin have to be manually added and it doesn’t seem to be able to deal with empty package names, which the examples use. What does look feasible and relatively easy though, is using the packaged com.github.vbmacher java_cup and javap_cup_runtime jars on maven central. That at leat would remove the need to do this part ourselves. If there are no objections, I’ll try that. Cheers, Gerwin |
|
From: Gerwin K. <ge...@do...> - 2020-02-26 10:40:52
|
So the 1.8.0 release is out on github and maven central, but there is a problem which became apparent just after everything was tagged and released. As always ;-) The problem is that our cup-maven-plugin depends on the cup jar, which we don’t deploy, and which we can’t deploy to maven central as it is, because it doesn’t contain sources. This means, things build fine only in precisely the context of our repo, but not, for instance, in the release when the cup jar is not already installed locally (which it was on my machine, so it didn’t appear in my tests). It also won’t build on Travis if the dependency version for the cup-maven-plugin is not precisely the snapshot version. To fix this, we could deploy the cup jar, adding sources, which would add a bit of noise to the repo, but, while looking around, I found that someone else has written a cup maven plugin, which actually looks quite nice: https://github.com/vbmacher/cup-maven-plugin Should we just use that one? Also has a java-cup-runtime package that we could use. This would mean a little less maintenance in our own repo. Any concerns for that one? If none, I’ll just make a very small 1.8.1 release that only changes these dependencies and announce that one instead of 1.8.0. (1.8.0 does work fine, it just doesn’t build from source from the release zip file) Cheers, Gerwin |
|
From: Gerwin K. <ge...@do...> - 2020-02-05 09:52:24
|
> On 5 Feb 2020, at 04:24, Régis Décamps <re...@de...> wrote: > > Hey Gerwin, > > I think releasing now is the right thing to do. The draft changelog <https://github.com/jflex-de/jflex/releases/tag/untagged-53a53c530d78f791cf4c> already contains many valuable things (and doesn't list your recent changes) and a recent build would avoid issues caused by an old build such as issue/712 <https://github.com/jflex-de/jflex/issues/712> I agree, it’ll be good to have something more current out. > I'm sorry the release process is still very manual which is causing an overhead on you. No worries, I’m used to it ;-) > On my side, I don't plan to work much on JFlex in the short/medium term. I hope to do a few small things on JFlex in the next few months, then life will probably get busier again. Cheers, Gerwin |
|
From: Régis D. <re...@de...> - 2020-02-04 20:25:42
|
Le lun. 3 févr. 2020 à 10:03, Gerwin Klein <ge...@do...> a écrit : > Hi Régis, Steve, > > it looks like we’re in a reasonably good state to push out the JFlex 1.8.0 > release. > > There are a few things I still wanted to do, but they can also just be > included in the next release. > > I should have a look at the change log, but otherwise I think it’s pretty > much ready to go. > > Anything else from your side that you’d still want to include in 1.8.0, or > should I start looking at the release process? > > Cheers, > Gerwin > Hey Gerwin, I think releasing now is the right thing to do. The draft changelog <https://github.com/jflex-de/jflex/releases/tag/untagged-53a53c530d78f791cf4c> already contains many valuable things (and doesn't list your recent changes) and a recent build would avoid issues caused by an old build such as issue/712 <https://github.com/jflex-de/jflex/issues/712> I'm sorry the release process is still very manual which is causing an overhead on you. On my side, I don't plan to work much on JFlex in the short/medium term. -- Régis http://regis.decamps.info/ |
|
From: Gerwin K. <ge...@do...> - 2020-02-03 09:03:14
|
Hi Régis, Steve, it looks like we’re in a reasonably good state to push out the JFlex 1.8.0 release. There are a few things I still wanted to do, but they can also just be included in the next release. I should have a look at the change log, but otherwise I think it’s pretty much ready to go. Anything else from your side that you’d still want to include in 1.8.0, or should I start looking at the release process? Cheers, Gerwin |
|
From: Régis D. <re...@de...> - 2019-12-06 12:59:11
|
They have a page describing in relatively clear terms what can be done Third Party Usage Guidelines for Oracle® Trademarks <https://www.oracle.com/legal/trademarks.html> Le jeu. 5 déc. 2019 à 23:54, Gerwin Klein <ge...@do...> a écrit : > > > > On 6 Dec 2019, at 07:25, Régis Décamps <reg...@gm...> wrote: > > > > Sure, throw some sketches! > > Will do! > > > > And I can understand why a brand needs to protect itself. I guess > writing "for Java TM" is legitimate use. > > Yes, the “for" Java makes it clear that it's referring to their product, > not claiming their name for another. > > Cheers, > Gerwin > > -- Régis Décamps http://regis.decamps.info/ |
|
From: Gerwin K. <ge...@do...> - 2019-12-06 09:53:21
|
Alright, below some things I was playing around with. Added the last one for more colour ;-) All of them have a bit much texture for a traditional logo, but we’ll be using it for the manual and the website only, i.e. they don’t need to look good in tiny size print on business cards or letterheads or similar. It’s easy to change background colour on any of them. Anything in there you like? Cheers, Gerwin |
|
From: Gerwin K. <ge...@do...> - 2019-12-05 22:54:22
|
> On 6 Dec 2019, at 07:25, Régis Décamps <reg...@gm...> wrote: > > Sure, throw some sketches! Will do! > And I can understand why a brand needs to protect itself. I guess writing "for Java TM" is legitimate use. Yes, the “for" Java makes it clear that it's referring to their product, not claiming their name for another. Cheers, Gerwin |
|
From: Régis D. <reg...@gm...> - 2019-12-05 20:56:16
|
Sure, throw some sketches! And I can understand why a brand needs to protect itself. I guess writing "for Java TM" is legitimate use. Gerwin Klein <ge...@do...> schrieb am Do., 5. Dez. 2019, 12:11: > Right, sorry for not replying back then, it was one of those times with > just too much going on. > > The current logo is clean ; but minimalist and a bit sad with the grey >> colour. >> > > Minimalist is a good thing :-), at least that is what I was going for. I > will concede that it is a bit grey/dark. > > From the new suggestions, I’m happy to experiment with a bit more colour. > > There is one issue with most of them, though: I have strongly avoided the > use of the word Java in the name and logo of JFlex. I don’t know if Oracle > is as aggressive as Sun was, but JLex used to be called JavaLex for a short > time and had to rename under threat of trademark litigation. JLex was by > far not the only project that was affected. To be fair, trademarks have to > be defended, otherwise you lose them, so I don’t know how much leeway Sun > really had there. > > In any case, I’d still like to avoid it int the logo, esp since it can be > read as part of the name (which would be trademark relevant) as opposed to > referring to the language in a normal sentence (which is why the tag line > should be fine). > > Thinking of new logo ideas, I recently played around with a more Japanese > brush-stroke like thing. I’ll send it tomorrow if I can find it. It might > still be too monochrome for your taste, but I wanted to at least throw it > into the discussion. > > Cheers, > Gerwin > > On 5 Dec 2019, at 10:21, Régis Décamps <re...@de...> wrote: > > Bump before an upcoming 1.8 > > Le ven. 5 oct. 2018 à 20:21, Régis Décamps <re...@de...> a écrit : > >> Hello Gerwin, hello all, >> >> The current logo is clean ; but minimalist and a bit sad with the grey >> colour. >> >> Please find a few explorations for a new logo >> <https://docs.google.com/presentation/d/1vu7irmVJgQTd5yldR7cRQdRrsmnSOOIdlYRpcR05tbA> >> ; let me know what you think! >> >> >> -- >> Régis >> >> <JFlex logo ideas (5).png> >> <JFlex logo ideas (4).png> >> <JFlex logo ideas (3).png> >> <JFlex logo ideas (2).png> >> <JFlex logo ideas (1).png> >> <JFlex logo ideas.png> >> > > > -- > Régis Décamps > > http://regis.decamps.info/ > _______________________________________________ > Jflex-devel mailing list > Jfl...@li... > https://lists.sourceforge.net/lists/listinfo/jflex-devel > > > _______________________________________________ > Jflex-devel mailing list > Jfl...@li... > https://lists.sourceforge.net/lists/listinfo/jflex-devel > |
|
From: Gerwin K. <ge...@do...> - 2019-12-05 11:11:23
|
Right, sorry for not replying back then, it was one of those times with just too much going on. > The current logo is clean ; but minimalist and a bit sad with the grey colour. Minimalist is a good thing :-), at least that is what I was going for. I will concede that it is a bit grey/dark. From the new suggestions, I’m happy to experiment with a bit more colour. There is one issue with most of them, though: I have strongly avoided the use of the word Java in the name and logo of JFlex. I don’t know if Oracle is as aggressive as Sun was, but JLex used to be called JavaLex for a short time and had to rename under threat of trademark litigation. JLex was by far not the only project that was affected. To be fair, trademarks have to be defended, otherwise you lose them, so I don’t know how much leeway Sun really had there. In any case, I’d still like to avoid it int the logo, esp since it can be read as part of the name (which would be trademark relevant) as opposed to referring to the language in a normal sentence (which is why the tag line should be fine). Thinking of new logo ideas, I recently played around with a more Japanese brush-stroke like thing. I’ll send it tomorrow if I can find it. It might still be too monochrome for your taste, but I wanted to at least throw it into the discussion. Cheers, Gerwin > On 5 Dec 2019, at 10:21, Régis Décamps <re...@de...> wrote: > > Bump before an upcoming 1.8 > > Le ven. 5 oct. 2018 à 20:21, Régis Décamps <re...@de... <mailto:re...@de...>> a écrit : > Hello Gerwin, hello all, > > The current logo is clean ; but minimalist and a bit sad with the grey colour. > > Please find a few explorations for a new logo <https://docs.google.com/presentation/d/1vu7irmVJgQTd5yldR7cRQdRrsmnSOOIdlYRpcR05tbA> ; let me know what you think! > > > -- > Régis > > <JFlex logo ideas (5).png> > <JFlex logo ideas (4).png> > <JFlex logo ideas (3).png> > <JFlex logo ideas (2).png> > <JFlex logo ideas (1).png> > <JFlex logo ideas.png> > > > -- > Régis Décamps > > http://regis.decamps.info/ <http://regis.decamps.info/>_______________________________________________ > Jflex-devel mailing list > Jfl...@li... > https://lists.sourceforge.net/lists/listinfo/jflex-devel |
|
From: Régis D. <re...@de...> - 2019-12-04 23:52:40
|
Bump before an upcoming 1.8 Le ven. 5 oct. 2018 à 20:21, Régis Décamps <re...@de...> a écrit : > Hello Gerwin, hello all, > > The current logo is clean ; but minimalist and a bit sad with the grey > colour. > > Please find a few explorations for a new logo > <https://docs.google.com/presentation/d/1vu7irmVJgQTd5yldR7cRQdRrsmnSOOIdlYRpcR05tbA> > ; let me know what you think! > > > -- > Régis > > > > > > > > -- Régis Décamps http://regis.decamps.info/ |
|
From: Gerwin K. <ge...@do...> - 2019-12-02 09:04:14
|
> On 1 Dec 2019, at 23:46, Régis Décamps <re...@de...> wrote:
> but I haven’t figured out yet for instance how to get a list of all available test targets (or how to run them all).
>
> Usually I just run them all [... is recursive]
> bazel test //...
>
> Or just the integration tests [and you can pick the directory of your choice]
> bazel test //javatests/jflex/testcase/...
Thanks, that is what I was really looking for. Has already made life much easier. I should probably actually read the documentation ;-)
>
> There is also a query syntax which may be useful to understand the dependencies, and can be used to answer your first question (list all tests)
> bazel query 'kind(".*test rule", //...)'
>
> Speaking about the tests, I'm also migrating the test suite to bazel. After moving a few by hand, I made a tool to automate the process.
>
> In the process, I also make some cleanup, such as updating the sourceforge bug to a github bug number.
Very nice. The old testing framework has been around for quite a while, it’s good to move that forward a bit.
> Also, generally, I think the regression tests should be based on expected behavior rather than the content of System.out. For instance, the eofclose test can check whether the reader throws an exception rather than printing the exception and asserting that System.out contains this message.
Yes, I agree.
> I also wrote some small utility code. For instance, maybe we could offer the ScannerFactory in the main distribution. If offers utility methods to create a scanner from different inputs (kind of rolls back #195 Remove InputStream-param constructor in a more elegant way)
The question is how to distribute it without requiring a jflex runtime or the jflex jar at runtime. Every time I use CUP, I’m happy that we don’t do that. I guess we could just include it in the distribution and people can either copy it from there (it’s small enough) or decide to include it directly if they want to.
Cheers,
Gerwin
|
|
From: Régis D. <re...@de...> - 2019-12-01 13:17:37
|
Le dim. 1 déc. 2019 à 06:09, Gerwin Klein <ge...@do...> a écrit : > So, I’ve finally managed to take a closer look at Bazel and I really like > its responsiveness. > > Will probably need to spend a bit more time with it for it to feel really > familiar. I’ve managed to build and run jflex and the example through bazel > Cool. Just want to point out that I wrote a custom bazel rule to run JFlex. The rule itself is defined in bazel_rules <https://github.com/jflex-de/bazel_rules> > but I haven’t figured out yet for instance how to get a list of all > available test targets (or how to run them all). > Usually I just run them all [... is recursive] bazel test //... Or just the integration tests [and you can pick the directory of your choice] bazel test //javatests/jflex/testcase/... There is also a query syntax <https://docs.bazel.build/versions/master/query-how-to.html> which may be useful to understand the dependencies, and can be used to answer your first question (list all tests) bazel query 'kind(".*test rule", //...)' Speaking about the tests, I'm also migrating the test suite <https://github.com/jflex-de/jflex/wiki/Migration-to-Bazel#migrate-testsuite> to bazel. After moving a few by hand, I made a tool to automate the process <https://github.com/jflex-de/jflex/tree/master/java/jflex/migration>. In the process, I also make some cleanup, such as updating the sourceforge bug to a github bug number. Also, generally, I think the regression tests should be based on expected *behavior* rather than the content of System.out. For instance, the eofclose test can check whether the reader throws an exception <https://github.com/jflex-de/jflex/pull/642/files#r352343386> rather than printing the exception <https://github.com/jflex-de/jflex/blob/master/testsuite/testcases/src/test/cases/eofclose/eofclose.flex#L45> and asserting that System.out contains this message <https://github.com/jflex-de/jflex/blob/master/testsuite/testcases/src/test/cases/eofclose/eofclose-0.output> . I also wrote some small utility code. For instance, maybe we could offer the ScannerFactory <https://github.com/jflex-de/jflex/blob/master/java/jflex/util/scanner/ScannerFactory.java> in the main distribution. If offers utility methods to create a scanner from different inputs (kind of rolls back #195 Remove InputStream-param constructor <https://github.com/jflex-de/jflex/issues/195> in a more elegant way) Régis > > On 27 Nov 2019, at 09:42, Régis Décamps <re...@de...> wrote: > > Hey! > > I think Bazel really works well for JFlex. > > The build on Cirrus usually takes less than a minute. > > And the manual can be produced with the only dep of having python > installed (and that's a bug in the rule, I'd say). > > The first time will be slow, though (well, Maven was also slow when it was > fetching all deps) > > I tried to document things on the home page README and other directories. > Let me know if you need help. > > Cheers, > > -- > Régis Décamps > > http://regis.decamps.info/ > > > -- Régis Décamps http://regis.decamps.info/ |
|
From: Gerwin K. <ge...@do...> - 2019-12-01 05:09:37
|
So, I’ve finally managed to take a closer look at Bazel and I really like its responsiveness. Will probably need to spend a bit more time with it for it to feel really familiar. I’ve managed to build and run jflex and the example through bazel, but I haven’t figured out yet for instance how to get a list of all available test targets (or how to run them all). In any case, it’s looking pretty good. Cheers, Gerwin > On 27 Nov 2019, at 09:42, Régis Décamps <re...@de...> wrote: > > Hey! > > I think Bazel really works well for JFlex. > > The build on Cirrus usually takes less than a minute. > > And the manual can be produced with the only dep of having python installed (and that's a bug in the rule, I'd say). > > The first time will be slow, though (well, Maven was also slow when it was fetching all deps) > > I tried to document things on the home page README and other directories. Let me know if you need help. > > Cheers, > > -- > Régis Décamps > > http://regis.decamps.info/ <http://regis.decamps.info/> |
|
From: Gerwin K. <ge...@do...> - 2019-11-26 23:29:00
|
Sounds cool, I’ll give it a shot! (It’s a busy work week, so will probably take a few days, potentially weekend) Cheers, Gerwin > On 27 Nov 2019, at 09:42, Régis Décamps <re...@de...> wrote: > > Hey! > > I think Bazel really works well for JFlex. > > The build on Cirrus usually takes less than a minute. > > And the manual can be produced with the only dep of having python installed (and that's a bug in the rule, I'd say). > > The first time will be slow, though (well, Maven was also slow when it was fetching all deps) > > I tried to document things on the home page README and other directories. Let me know if you need help. > > Cheers, > > -- > Régis Décamps > > http://regis.decamps.info/ <http://regis.decamps.info/> |
|
From: Régis D. <re...@de...> - 2019-11-26 23:12:50
|
Hey! I think Bazel really works well for JFlex. The build on Cirrus usually takes less than a minute. And the manual can be produced with the only dep of having python installed (and that's a bug in the rule, I'd say). The first time will be slow, though (well, Maven was also slow when it was fetching all deps) I tried to document things on the home page README and other directories. Let me know if you need help. Cheers, -- Régis Décamps http://regis.decamps.info/ |
|
From: Gerwin K. <ge...@do...> - 2019-01-25 21:47:41
|
Yes, I can do that. Cheers, Gerwin > On 26.01.2019, at 04:22, Steve Rowe <sa...@gm...> wrote: > > Thanks Gerwin, > > I've merged the Unicode 10.0 support PR to master. > > Do you plan on changing JFlex versions on master to 1.8.0? > > Steve > >> On Jan 24, 2019, at 7:55 PM, Gerwin Klein <ge...@do...> wrote: >> >> Hi Steve, >> >> making a branch for 1.7.1 is a good idea, I think. At this point it seems more likely that we’ll do a 1.8.0 release directly, but if we discover a major bug in the meantime and the rest isn’t finished yet, it’d be nice to still have the ability to put out a faster 1.7.1 release. >> >> I’ll add that branch on github, so you can merge your PR. >> >> Cheers, >> Gerwin >> >>> On 18.01.2019, at 06:04, Steve Rowe <sa...@gm...> wrote: >>> >>> Hi Gerwin and Régis, >>> >>> I'd like to merge PR #540 (Unicode 10.0 support) to master, but can't until we've either released 1.7.1 or decided to skip it in favor of 1.8.0. (Because the Add_Unicode-10.0 branch has many fixes related to recent code reorganization in addition to the Unicode 10.0 support, it would be awkward to move forward with Unicode 11.0 support until after I've merged.) >>> >>> Another alternative: make a new branch for 1.7.1 (starting at the current master). This would allow me to merge 1.8.0-targetted stuff without being blocked by the 1.7.1 release. We could also delay branching for now if we decide that a 1.7.1 release is not warranted at this point, and then create the branch later if we change our minds. >>> >>> Thoughts? >>> >>> Steve >>> >>> >>> >>> _______________________________________________ >>> Jflex-devel mailing list >>> Jfl...@li... >>> https://lists.sourceforge.net/lists/listinfo/jflex-devel >> >> >> >> _______________________________________________ >> Jflex-devel mailing list >> Jfl...@li... >> https://lists.sourceforge.net/lists/listinfo/jflex-devel > > > > _______________________________________________ > Jflex-devel mailing list > Jfl...@li... > https://lists.sourceforge.net/lists/listinfo/jflex-devel |
|
From: Steve R. <sa...@gm...> - 2019-01-25 17:22:14
|
Thanks Gerwin, I've merged the Unicode 10.0 support PR to master. Do you plan on changing JFlex versions on master to 1.8.0? Steve > On Jan 24, 2019, at 7:55 PM, Gerwin Klein <ge...@do...> wrote: > > Hi Steve, > > making a branch for 1.7.1 is a good idea, I think. At this point it seems more likely that we’ll do a 1.8.0 release directly, but if we discover a major bug in the meantime and the rest isn’t finished yet, it’d be nice to still have the ability to put out a faster 1.7.1 release. > > I’ll add that branch on github, so you can merge your PR. > > Cheers, > Gerwin > >> On 18.01.2019, at 06:04, Steve Rowe <sa...@gm...> wrote: >> >> Hi Gerwin and Régis, >> >> I'd like to merge PR #540 (Unicode 10.0 support) to master, but can't until we've either released 1.7.1 or decided to skip it in favor of 1.8.0. (Because the Add_Unicode-10.0 branch has many fixes related to recent code reorganization in addition to the Unicode 10.0 support, it would be awkward to move forward with Unicode 11.0 support until after I've merged.) >> >> Another alternative: make a new branch for 1.7.1 (starting at the current master). This would allow me to merge 1.8.0-targetted stuff without being blocked by the 1.7.1 release. We could also delay branching for now if we decide that a 1.7.1 release is not warranted at this point, and then create the branch later if we change our minds. >> >> Thoughts? >> >> Steve >> >> >> >> _______________________________________________ >> Jflex-devel mailing list >> Jfl...@li... >> https://lists.sourceforge.net/lists/listinfo/jflex-devel > > > > _______________________________________________ > Jflex-devel mailing list > Jfl...@li... > https://lists.sourceforge.net/lists/listinfo/jflex-devel |
|
From: Gerwin K. <ge...@do...> - 2019-01-25 01:11:36
|
Hi Steve, making a branch for 1.7.1 is a good idea, I think. At this point it seems more likely that we’ll do a 1.8.0 release directly, but if we discover a major bug in the meantime and the rest isn’t finished yet, it’d be nice to still have the ability to put out a faster 1.7.1 release. I’ll add that branch on github, so you can merge your PR. Cheers, Gerwin > On 18.01.2019, at 06:04, Steve Rowe <sa...@gm...> wrote: > > Hi Gerwin and Régis, > > I'd like to merge PR #540 (Unicode 10.0 support) to master, but can't until we've either released 1.7.1 or decided to skip it in favor of 1.8.0. (Because the Add_Unicode-10.0 branch has many fixes related to recent code reorganization in addition to the Unicode 10.0 support, it would be awkward to move forward with Unicode 11.0 support until after I've merged.) > > Another alternative: make a new branch for 1.7.1 (starting at the current master). This would allow me to merge 1.8.0-targetted stuff without being blocked by the 1.7.1 release. We could also delay branching for now if we decide that a 1.7.1 release is not warranted at this point, and then create the branch later if we change our minds. > > Thoughts? > > Steve > > > > _______________________________________________ > Jflex-devel mailing list > Jfl...@li... > https://lists.sourceforge.net/lists/listinfo/jflex-devel |
|
From: Steve R. <sa...@gm...> - 2019-01-17 19:04:12
|
Hi Gerwin and Régis, I'd like to merge PR #540 (Unicode 10.0 support) to master, but can't until we've either released 1.7.1 or decided to skip it in favor of 1.8.0. (Because the Add_Unicode-10.0 branch has many fixes related to recent code reorganization in addition to the Unicode 10.0 support, it would be awkward to move forward with Unicode 11.0 support until after I've merged.) Another alternative: make a new branch for 1.7.1 (starting at the current master). This would allow me to merge 1.8.0-targetted stuff without being blocked by the 1.7.1 release. We could also delay branching for now if we decide that a 1.7.1 release is not warranted at this point, and then create the branch later if we change our minds. Thoughts? Steve |
|
From: Régis D. <re...@go...> - 2018-10-26 14:11:31
|
Le mar. 23 oct. 2018 à 00:28, Gerwin Klein <ge...@do...> a écrit : > > * revamp syntax: would also benefit from AST. We’d have to keep support > for the old syntax to not break all lexer specs out there, but it would be > nice to have something much cleaner. Come to think of it, I did have a > front-end tool for jflex and cup, plus AST generator many years ago > (1999ish) with much cleaner syntax, somewhat inspired by ANTLR, but > realised differently (sample file attached). It basically generated jflex > and cup files and a bunch of classes to represent syntax trees. Could be a > starting point for that project. > Thanks for sharing. This looks like Yaml. So I gave it a try and there are some thigs to work around but a JFlex spec in Yaml could look like this: https://gist.github.com/regisd/8fe843800f96177909b190b678ca8637 Have a good weekend > > Cheers, > Gerwin > > > > > On 19.10.2018, at 07:15, Régis Décamps via Jflex-devel < > jfl...@li...> wrote: > > > > Hello Gerwin, > > > > How do you feel about making a proposal for a summer of code project > (hence for next summer, but applications will be until Jan 2019 I assume). > > > > The idea of summer of code (g.co/gsoc) is to offer students an > opportunity to contribute to an open-source project for 3 months and even > get paid by Google in return. > > > > I think we could offer a very nice project, for instance: > > • refactor the code to have an AST. Stretch: produce code from > this AST, rather than with println() > > • support antlr > > • have our own parser generator > > • revamp the syntax of the lexer specification. > > Any other idea? For instance, those were the proposals for gRPC or > proposal for a compiler in open-chemistry > > > > What do you think? > > > > -- > > Régis > > Google Lens > > > > _______________________________________________ > > Jflex-devel mailing list > > Jfl...@li... > > https://lists.sourceforge.net/lists/listinfo/jflex-devel > > -- Régis Google Lens |
|
From: Gerwin K. <ge...@do...> - 2018-10-22 22:28:36
|
Hi Régis, work has got me pretty busy again, am a bit slow on email and reviews atm, sorry. I think gsoc is an excellent idea for JFlex. Main problem would be that I won’t have time to mentor over the European summer next year. Would you be eligible as a gsoc mentor for JFlex? In terms of projects: * I like the AST project. It would still only exist at the front end, though. The back end is an NFA, there are no regular expressions or syntax there any more. The stretch goal could be to have a better programmatic front end for JFlex with it, which could make direct use of the AST. * antlr frontend sounds good (could also benefit from the AST, i.e. front ends could all be just AST transformers) * own parser generator: probably too big for a summer, there’s a lot of deep technical stuff to solve to write a good parser generator. * revamp syntax: would also benefit from AST. We’d have to keep support for the old syntax to not break all lexer specs out there, but it would be nice to have something much cleaner. Come to think of it, I did have a front-end tool for jflex and cup, plus AST generator many years ago (1999ish) with much cleaner syntax, somewhat inspired by ANTLR, but realised differently (sample file attached). It basically generated jflex and cup files and a bunch of classes to represent syntax trees. Could be a starting point for that project. Cheers, Gerwin |
|
From: Gerwin K. <ge...@do...> - 2018-10-22 22:07:32
|
That looks like a major outage! Seems like I missed of it over here. Cheers, Gerwin > On 23.10.2018, at 04:28, Régis Décamps <re...@de...> wrote: > > I think I have my answer on https://status.github.com/messages <https://status.github.com/messages> > > > > > October 22, 2018 > > 18:51 Central European Summer TimeWe have resumed Pages builds and will continue to monitor as we process a delayed backlog of events. > 18:45 Central European Summer TimeWe have resumed delivery of webhooks and will continue to monitor as we process a delayed backlog of events. > 18:24 Central European Summer TimeWe've completed validation of data consistency and have enabled some background jobs. We're continuing to monitor as the system recovers and expect to resume delivering webhooks at 16:45UTC. > 17:09 Central European Summer TimeBackground jobs remain paused as we near completion of validation of data consistency. > 15:18 Central European Summer TimeWe are validating the consistency of information across all data stores. Webhooks and Pages builds remain paused. > 13:56 Central European Summer TimeThe majority of restore processes have completed. We anticipate all data stores will be fully consistent within the next hour. > 11:47 Central European Summer TimeWe continue to monitor restores which are taking longer than anticipated. We estimate they will be caught up in an hour and a half. > 10:19 Central European Summer TimeOur restore operations are still on track to serve consistent data within the hour. We've posted an update at https://blog.github.com/2018-10-21-october21-incident-report/ <https://blog.github.com/2018-10-21-october21-incident-report/>. > 09:35 Central European Summer TimeOur restore operations are proceeding as expected, on track for serving fully consistent data within the next 1.5 hours. > 08:51 Central European Summer TimeWe are currently in the later stages of a restore operation, with the aim of serving fully consistent data within the next 2 hours. > 08:18 Central European Summer TimeWe continue work to repair a data storage system for GitHub.com. You may see inconsistent results during this process. > 07:05 Central European Summer TimeWe continue working to repair a data storage system for GitHub.com. You may see inconsistent results during this process. > 06:12 Central European Summer TimeWe are continuing work to repair a data storage system for GitHub.com. You may see inconsistent results during this process. > 05:28 Central European Summer TimeWe continue working to repair a data storage system for GitHub.com. You may see inconsistent results during this process. > 05:00 Central European Summer TimeWe are continuing to repair a data storage system for GitHub.com. You may see inconsistent results during this process. > 04:42 Central European Summer TimeWe continue to repair a data storage system for GitHub.com. You may see inconsistent results during this process. > 04:23 Central European Summer TimeWe are continuing to repair a data storage system for GitHub.com. You may see inconsistent results during this process. > 04:01 Central European Summer TimeWe continue work to repair a data storage system for GitHub.com. You may see inconsistent results during this process. > 03:41 Central European Summer TimeWe are continuing to work to migrate a data storage system in order to restore access to GitHub.com. > 03:22 Central European Summer TimeWe continue to work to migrate a data storage system in order to restore access to GitHub.com. > 03:02 Central European Summer TimeWe continue to migrate a data storage system in order to restore full access to GitHub.com. > 02:43 Central European Summer TimeWe continue to work on migrating a data storage system in order to restore access to GitHub.com. > 02:23 Central European Summer TimeWe're continuing to work on migrating a data storage system in order to restore access to GitHub.com. > 02:05 Central European Summer TimeWe're failing over a data storage system in order to restore access to GitHub.com. > 01:43 Central European Summer TimeWe're investigating problems accessing GitHub.com. > 01:13 Central European Summer TimeWe are investigating reports of service unavailability. > 01:09 Central European Summer TimeWe are investigating reports of elevated error rates. > > > 2018-10-22 19:25 GMT+02:00 Régis Décamps <re...@de... <mailto:re...@de...>>: > Gerwin, > > Have-you changed something in the GitHub integration/webhooks? Nothing is triggering (no travis, no cirrus, no lgtm). If it's not you, then it's an outage aat GitHub > > -- > Régis Décamps > > http://regis.decamps.info/ <http://regis.decamps.info/> > > > -- > Régis Décamps > > http://regis.decamps.info/ <http://regis.decamps.info/>_______________________________________________ > Jflex-devel mailing list > Jfl...@li... > https://lists.sourceforge.net/lists/listinfo/jflex-devel |
