jburg-users Mailing List for JBurg
Brought to you by:
tharwood
You can subscribe to this list here.
2003 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(2) |
Oct
|
Nov
|
Dec
|
---|---|---|---|---|---|---|---|---|---|---|---|---|
2004 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(1) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2013 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(1) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2014 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(8) |
Aug
|
Sep
|
Oct
|
Nov
(2) |
Dec
|
From: Tom H. <tho...@gm...> - 2014-11-18 23:50:35
|
Hello Steve, Thanks for your interest in JBurg, and for the interesting idea. It gave me a chuckle; my original experience with BURS technology came while I was porting LCC in the 1990s. As you note, JBurg is considerably evolved from the simple mechanisms in lburg. More powerful is an interesting question; any two BURMs that can process the same tree with the same actions are theoretically as powerful as one another. JBurg was specifically built to process whole method bodies, where iburg and lburg are built specifically to process expression trees. So, on one axis, JBurg is considerably more powerful, but on another axis these tools are all equivalent. It would, by and large, be a mechanical process to port .md files to JBurg format; as I recall, a .md file contains rules of the form: nonterminal: tree "code skeleton" cost and lburg has logic to fill in holes in the templates with subtrees and/or register numbers, etc. This would straightforwardly translate to JBurg syntax: nonterminal = tree { return translate("code skeleton", other data...); } where "other data" would be the subtrees (which presumably would be strings), register allocation information, etc. The big problem I forsee is an implementation language mismatch. lcc's codebase was, and appears to still be, written in C, and JBurg doesn't have a C code emitter. So that would be a necessary first step, and it would be in general accord with your stated goal, I think it's probably not what you're looking to do. If you're interested specifically in experimenting with JBurg -- which I suppose it goes without saying I think a worthy goal -- you might have a look at the tutorial on the wiki. I started writing a small compiler targeting SPIM, the MIPS simulator; coding the calling conventions for MIPS is involved and I got busy before I completed the third tutorial, using procedure calls. A back end that could correctly compile, e.g., the recursive solution to factorial(n) would show you both the interesting and tedious parts of compiler back end construction :) If you decide to do this, and contribute it, I would be most pleased to list you in the AUTHORS credits. If that is of any interest to you, let me know and I'll forward a link to the wiki when Sourceforge is back online. In any case, good luck and let me know if I can be of assistance. Best regards, Tom Harwood On Tue, Nov 18, 2014 at 5:52 AM, Steve Jones <st...@ho...> wrote: > Hi, > > The LCC compiler project has back-ends for several processors (alpha, > mips, sparc, x86 and x866linux). > > I'm trying to find my way into back-end code generation techniques in > general and I figured it would be a useful excise to port the LCC > back-ends across to JBurg. > > I can see that the LBurg back-end definitions (*.md files) used by LCC > are significantly different to the JBurg grammar. Would a > straightforward "mechanical port" of these definitions make any sense? > > The JBurg grammar appears to be a lot more comprehensive. Am I correct > in thinking that a JBurg definition has the potential to emit better > code than LBurg? > > Any pointers or advice would be very much appreciated. > > Thanks in advance. > > Steve > > > > ------------------------------------------------------------------------------ > Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server > from Actuate! Instantly Supercharge Your Business Reports and Dashboards > with Interactivity, Sharing, Native Excel Exports, App Integration & more > Get technology previously reserved for billion-dollar corporations, FREE > > http://pubads.g.doubleclick.net/gampad/clk?id=157005751&iu=/4140/ostg.clktrk > _______________________________________________ > Jburg-users mailing list > Jbu...@li... > https://lists.sourceforge.net/lists/listinfo/jburg-users > |
From: Steve J. <st...@ho...> - 2014-11-18 11:07:35
|
Hi, The LCC compiler project has back-ends for several processors (alpha, mips, sparc, x86 and x866linux). I'm trying to find my way into back-end code generation techniques in general and I figured it would be a useful excise to port the LCC back-ends across to JBurg. I can see that the LBurg back-end definitions (*.md files) used by LCC are significantly different to the JBurg grammar. Would a straightforward "mechanical port" of these definitions make any sense? The JBurg grammar appears to be a lot more comprehensive. Am I correct in thinking that a JBurg definition has the potential to emit better code than LBurg? Any pointers or advice would be very much appreciated. Thanks in advance. Steve |
From: Tom H. <tho...@gm...> - 2014-07-28 01:16:17
|
The INodeAdapter was an early attempt to isolate the tree rewrite phase from changes in the AST (and vice versa). It was not as successful as we had hoped -- as you're discovering, Chris, it causes at least as many maintenance issues as it solves. A simpler method would definitely be preferable; the simplest would be to refactor the AST nodes so they conform to the "naive" JBurg interface. As best I recall, most of the problems were in child elements that weren't dense arrays, or n-ary elements that weren't at the end of the child node list. (For algorithmic reasons JBurg only accepts variadic arguments as the last element of a rule's subtrees.) On Sun, Jul 27, 2014 at 4:36 PM, Christofer Dutz <chr...@c-...> wrote: > I keept on thinking about the order of compilation problem I am having. > > The InodeAdapter seems to be used for defining what method calls should be > generated for the different types of Adapters. So wouldn’t it be enough to > have static resources such as property- or xml-files defining this? This > wouldn’t have any effect on the rest of Jburg but would get rid of the > dependency on custom compiled code. > > > > Chris > > > > > > > > > > *Von:* Christofer Dutz > *Gesendet:* Sonntag, 27. Juli 2014 13:15 > *An:* Christofer Dutz; jbu...@li... > > *Betreff:* AW: [Jburg-users] Antlr4 support? > > > > Hi again J > > > > I just wanted to tell you that I successfully migrated a copy of JBurg I > have to Stringtemplate 4 and was now able to generate part of Falcon with > JBurg 2 in conjunction with my maven plugin. > > If you want, I can zip up the directory and send it to you … thanks to HG > you will be able to see what I added and what I changed. > > > > There is one problem I am having though that is currently preventing me > from completely updating Falcon: > > In Falcon we have a custom InodeAdapter and this should be used. The > problem is that Maven usually has strict phases and code-generation comes > before compilation. Unfortunately JBurg can’t load the NodeAdapter > implementation because it has not been compiled at the time of the code > generation. Do you think there could be a way around this problem? The > usage of the node adapter is very limited in JBurgs generation, is there > eventually a way to use the source instead of the class file? > > > > Chris > > > > *Von:* Christofer Dutz [mailto:chr...@c-... > <chr...@c-...>] > *Gesendet:* Freitag, 25. Juli 2014 11:52 > *An:* jbu...@li... > *Betreff:* Re: [Jburg-users] Antlr4 support? > > > > Ok ... I do have another change that I would need. > > > > in JBurgEmitterFactory line 46 you have: > > > > EmitLang el = > (EmitLang)ClassLoader.getSystemClassLoader().loadClass(cl.getName()).newInstance(); > > > > This needs to be changed to something like this: > > EmitLang el = (EmitLang) JBurgEmitterFactory.*class*.getClassLoader().loadClass(cl.getName()).newInstance(); > > Because as I mentioned in another post. A Maven plugin has it's own classloader that can contain jars the root classloader doesn't have. So I got errors, because JBurg wasn't able to load the classes using the system loader. By changing that line to my version you use the classloader that was used to load the JBurgEmitterFactory which will deffinitely be the one also containing the Emitter implementations. > > A second fix would be to add the following lines to JBurgMain: > > *if*(!outputPath.getParentFile().exists()) { > *if*(!outputPath.getParentFile().mkdirs()) { > > log.error(*"Error creating output directory:" *+ outputPath.getAbsolutePath()); > } > } > > between Line 87 and 88: > > generator.semanticAnalysis(); > *if*(!outputPath.getParentFile().exists()) { > > *if*(!outputPath.getParentFile().mkdirs()) { > log.error(*"Error creating output directory:" *+ outputPath.getAbsolutePath()); > > } > } > generator.emit(className, *new *PrintStream(*new *FileOutputStream(outputPath))); > > > With these changes I was able to successfully generate the Falcon CSS Burm :-) > > > > Chris > > > > > > > > > > > ------------------------------ > > *Von:* Christofer Dutz <chr...@c-...> > *Gesendet:* Freitag, 25. Juli 2014 09:21 > *An:* jbu...@li... > *Betreff:* Re: [Jburg-users] Antlr4 support? > > > > Hi Tom, > > > > good news :-) > > > > As I wrote in my last mail, I was wrong with the two parts so forget that > ;-) > > I think I managed to get everything running without you having to modify > anything at all. > > > > I created a jburg-maven-plugin that wrapps the calls to JBurg. The cool > thing is that each maven plugin has its own classloader. Therefore the > Jburg plugin can use whatever Antlr version it likes and it seems to work > niceley. > > > > There is one thing that would need changing, but it's a no-brainer ;-): > > In the build script at line 150 you add a classpath entry to the manifest > of the jburg.jar. This was causing major classloading issues in maven. > After commenting out/removing that line my plugin seemes to work niceley. > > > > I will experiment a little with the plugin and as soon as I think it's > ready to be used, I would like to donate that to your project ... > unfortunateley I don't quite know how to do that. If you could send me what > I have to do, I'd gladly do it. > > > > Chris > > > > > ------------------------------ > > *Von:* Christofer Dutz > *Gesendet:* Donnerstag, 24. Juli 2014 16:00 > *An:* Tom Harwood > *Betreff:* AW: [Jburg-users] Antlr4 support? > > > > Hi tom, > > > > after your post, I double checked the Exceptions I was recieving and could > see that you were correct about the "no depenency" thing. > > I am having some strange classloading problems with my plugin though ... > will try to sort them out. > > > > Chris > ------------------------------ > > *Von:* Tom Harwood <tho...@gm...> > *Gesendet:* Donnerstag, 24. Juli 2014 14:36 > *An:* Christofer Dutz > *Betreff:* Re: [Jburg-users] Antlr4 support? > > > > Hello Christofer, > > > > My apologies for not responding sooner; I intended to do so last night but > got distracted. > > > > I will look into moving to ANTLR 4 and using the separate StringTemplate > libraries; my time to work on JBurg is quite limited at present, but that > doesn't seem like a very big task. I'll also update the INSTALL documents. > > > > I (as the originator and present sole maintainer of the project) would be > quite grateful for a maven plugin, and also any advice on getting a JBurg > build up somewhere where a maven-ized Falcon build could use it. I tried > to do that in response to a request from a Falcon developer last year, but > my knowledge of Maven is so limited I couldn't quite understand the > procedure to follow. > > > > I do ask that the copyright of contributed code be assigned to me -- I > have had some trouble tracking down a copyright holder in some of the > existing code, which means I cannot switch to a more modern license until I > can find him or I rewrite that code. I would still gratefully accept a > contribution, but you would potentially make my life a little easier by > also assigning copyright. > > > > JBurg doesn't have a runtime; the entire rewrite engine is contained in > the generated .java file. The situation is a little different for C++, but > I don't imagine Falcon's being rewritten in C++ :) So I'm not sure what > you want to split into separate jar files. > > > > Finally, you should be aware that JBurg development is focused on JBurg > 2.0. Like Ter, I reserve the major version number for a breaking change. > In this case, I'm rationalizing the syntax of the various directives and > grammar elements, along with some deeper changes that will generate a much > more efficient state machine. So the tip of the tree will not process > Falcon. There is a JBURG_1 tag in the codebase to get the last JBurg 1.x > tree; there is also a conversion script, convertV1ToV2.sh in the extras > directory, to convert to the version 2 syntax. If Falcon wants to convert > to version 2 syntax I would be happy to pull the latest Falcon code and run > the conversion script. > > > > Best regards, > > - Tom Harwood > > > > On Thu, Jul 24, 2014 at 5:57 AM, Christofer Dutz < > chr...@c-...> wrote: > > Ok ... so I had another look. > > > > Guess we wouldn't have to change anything major with the Antlr version > here. > > > > I whipped up a small maven plugin to do the code generation. I would be > happy to donate that to your project. > > > > Now the plugin can continue to reference Antlr3 and we can use Antlr4 in > Falcon. > > > > There is however one thing preventing me from proceding here. Antlr3 seems > to have contained a template engine "Stringtemplate" that was probably > moved to a top level project some time later www.stringtemplate.org > > Would it be possible to utilize this instead of antlr.stringtemplate > classes? This is currently preventing me from continuing :-( > > > > The next thing is that it seems that JBurg consists of a Generator and a > Runtim part. Would it be possible to split this up into two jars? Then the > runtime part could be completely independent of Antlr. I would reference > the Generator in my Maven plugin and the Runtime would be used in the > application contiainng only the classes needed by the generated code. I > would also be hapy to contribute here. > > > > Chris > > > > > > > ------------------------------ > > *Von:* Christofer Dutz <chr...@c-...> > *Gesendet:* Mittwoch, 23. Juli 2014 14:22 > *An:* jbu...@li... > *Betreff:* [Jburg-users] Antlr4 support? > > > > Hi, > > > > I am currently working on optimizing Apache Falcon. One of the things I > have started working on is cleaning up the CSS and AS parsing code as it > currently uses a mixture of Antlr2, Antlr3 and JFlex and I am woking on > migrating all to Antlr4. I don't want to change anything in the JBurg > usage, but am having the problem, that JBurg currently relys on Antlr3 and > Antlr2 and is incompatable to with Antlr4. Are there any efforts in adding > Antlr4 support in JBurg? Or is there a way I can use JBurg without having > any trouble? > > > > Chris > > > > PS: I did have quite some trouble in building JBurg as you didn't provide > the versions of which libraries I needed ... So it's antlr3 ... how about > adding some auto-download targets to the build script ... would make things > easier. > > > > ------------------------------------------------------------------------------ > Want fast and easy access to all the code in your enterprise? Index and > search up to 200,000 lines of code with a free copy of Black Duck > Code Sight - the same software that powers the world's largest code > search on Ohloh, the Black Duck Open Hub! Try it now. > http://p.sf.net/sfu/bds > _______________________________________________ > Jburg-users mailing list > Jbu...@li... > https://lists.sourceforge.net/lists/listinfo/jburg-users > > > > > ------------------------------------------------------------------------------ > Want fast and easy access to all the code in your enterprise? Index and > search up to 200,000 lines of code with a free copy of Black Duck > Code Sight - the same software that powers the world's largest code > search on Ohloh, the Black Duck Open Hub! Try it now. > http://p.sf.net/sfu/bds > _______________________________________________ > Jburg-users mailing list > Jbu...@li... > https://lists.sourceforge.net/lists/listinfo/jburg-users > > |
From: Christofer D. <chr...@c-...> - 2014-07-27 20:36:48
|
I keept on thinking about the order of compilation problem I am having. The InodeAdapter seems to be used for defining what method calls should be generated for the different types of Adapters. So wouldn’t it be enough to have static resources such as property- or xml-files defining this? This wouldn’t have any effect on the rest of Jburg but would get rid of the dependency on custom compiled code. Chris Von: Christofer Dutz Gesendet: Sonntag, 27. Juli 2014 13:15 An: Christofer Dutz; jbu...@li... Betreff: AW: [Jburg-users] Antlr4 support? Hi again ☺ I just wanted to tell you that I successfully migrated a copy of JBurg I have to Stringtemplate 4 and was now able to generate part of Falcon with JBurg 2 in conjunction with my maven plugin. If you want, I can zip up the directory and send it to you … thanks to HG you will be able to see what I added and what I changed. There is one problem I am having though that is currently preventing me from completely updating Falcon: In Falcon we have a custom InodeAdapter and this should be used. The problem is that Maven usually has strict phases and code-generation comes before compilation. Unfortunately JBurg can’t load the NodeAdapter implementation because it has not been compiled at the time of the code generation. Do you think there could be a way around this problem? The usage of the node adapter is very limited in JBurgs generation, is there eventually a way to use the source instead of the class file? Chris Von: Christofer Dutz [mailto:chr...@c-...] Gesendet: Freitag, 25. Juli 2014 11:52 An: jbu...@li...<mailto:jbu...@li...> Betreff: Re: [Jburg-users] Antlr4 support? Ok ... I do have another change that I would need. in JBurgEmitterFactory line 46 you have: EmitLang el = (EmitLang)ClassLoader.getSystemClassLoader().loadClass(cl.getName()).newInstance(); This needs to be changed to something like this: EmitLang el = (EmitLang) JBurgEmitterFactory.class.getClassLoader().loadClass(cl.getName()).newInstance(); Because as I mentioned in another post. A Maven plugin has it's own classloader that can contain jars the root classloader doesn't have. So I got errors, because JBurg wasn't able to load the classes using the system loader. By changing that line to my version you use the classloader that was used to load the JBurgEmitterFactory which will deffinitely be the one also containing the Emitter implementations. A second fix would be to add the following lines to JBurgMain: if(!outputPath.getParentFile().exists()) { if(!outputPath.getParentFile().mkdirs()) { log.error("Error creating output directory:" + outputPath.getAbsolutePath()); } } between Line 87 and 88: generator.semanticAnalysis(); if(!outputPath.getParentFile().exists()) { if(!outputPath.getParentFile().mkdirs()) { log.error("Error creating output directory:" + outputPath.getAbsolutePath()); } } generator.emit(className, new PrintStream(new FileOutputStream(outputPath))); With these changes I was able to successfully generate the Falcon CSS Burm :-) Chris ________________________________ Von: Christofer Dutz <chr...@c-...<mailto:chr...@c-...>> Gesendet: Freitag, 25. Juli 2014 09:21 An: jbu...@li...<mailto:jbu...@li...> Betreff: Re: [Jburg-users] Antlr4 support? Hi Tom, good news :-) As I wrote in my last mail, I was wrong with the two parts so forget that ;-) I think I managed to get everything running without you having to modify anything at all. I created a jburg-maven-plugin that wrapps the calls to JBurg. The cool thing is that each maven plugin has its own classloader. Therefore the Jburg plugin can use whatever Antlr version it likes and it seems to work niceley. There is one thing that would need changing, but it's a no-brainer ;-): In the build script at line 150 you add a classpath entry to the manifest of the jburg.jar. This was causing major classloading issues in maven. After commenting out/removing that line my plugin seemes to work niceley. I will experiment a little with the plugin and as soon as I think it's ready to be used, I would like to donate that to your project ... unfortunateley I don't quite know how to do that. If you could send me what I have to do, I'd gladly do it. Chris ________________________________ Von: Christofer Dutz Gesendet: Donnerstag, 24. Juli 2014 16:00 An: Tom Harwood Betreff: AW: [Jburg-users] Antlr4 support? Hi tom, after your post, I double checked the Exceptions I was recieving and could see that you were correct about the "no depenency" thing. I am having some strange classloading problems with my plugin though ... will try to sort them out. Chris ________________________________ Von: Tom Harwood <tho...@gm...<mailto:tho...@gm...>> Gesendet: Donnerstag, 24. Juli 2014 14:36 An: Christofer Dutz Betreff: Re: [Jburg-users] Antlr4 support? Hello Christofer, My apologies for not responding sooner; I intended to do so last night but got distracted. I will look into moving to ANTLR 4 and using the separate StringTemplate libraries; my time to work on JBurg is quite limited at present, but that doesn't seem like a very big task. I'll also update the INSTALL documents. I (as the originator and present sole maintainer of the project) would be quite grateful for a maven plugin, and also any advice on getting a JBurg build up somewhere where a maven-ized Falcon build could use it. I tried to do that in response to a request from a Falcon developer last year, but my knowledge of Maven is so limited I couldn't quite understand the procedure to follow. I do ask that the copyright of contributed code be assigned to me -- I have had some trouble tracking down a copyright holder in some of the existing code, which means I cannot switch to a more modern license until I can find him or I rewrite that code. I would still gratefully accept a contribution, but you would potentially make my life a little easier by also assigning copyright. JBurg doesn't have a runtime; the entire rewrite engine is contained in the generated .java file. The situation is a little different for C++, but I don't imagine Falcon's being rewritten in C++ :) So I'm not sure what you want to split into separate jar files. Finally, you should be aware that JBurg development is focused on JBurg 2.0. Like Ter, I reserve the major version number for a breaking change. In this case, I'm rationalizing the syntax of the various directives and grammar elements, along with some deeper changes that will generate a much more efficient state machine. So the tip of the tree will not process Falcon. There is a JBURG_1 tag in the codebase to get the last JBurg 1.x tree; there is also a conversion script, convertV1ToV2.sh in the extras directory, to convert to the version 2 syntax. If Falcon wants to convert to version 2 syntax I would be happy to pull the latest Falcon code and run the conversion script. Best regards, - Tom Harwood On Thu, Jul 24, 2014 at 5:57 AM, Christofer Dutz <chr...@c-...<mailto:chr...@c-...>> wrote: Ok ... so I had another look. Guess we wouldn't have to change anything major with the Antlr version here. I whipped up a small maven plugin to do the code generation. I would be happy to donate that to your project. Now the plugin can continue to reference Antlr3 and we can use Antlr4 in Falcon. There is however one thing preventing me from proceding here. Antlr3 seems to have contained a template engine "Stringtemplate" that was probably moved to a top level project some time later www.stringtemplate.org<http://www.stringtemplate.org> Would it be possible to utilize this instead of antlr.stringtemplate classes? This is currently preventing me from continuing :-( The next thing is that it seems that JBurg consists of a Generator and a Runtim part. Would it be possible to split this up into two jars? Then the runtime part could be completely independent of Antlr. I would reference the Generator in my Maven plugin and the Runtime would be used in the application contiainng only the classes needed by the generated code. I would also be hapy to contribute here. Chris ________________________________ Von: Christofer Dutz <chr...@c-...<mailto:chr...@c-...>> Gesendet: Mittwoch, 23. Juli 2014 14:22 An: jbu...@li...<mailto:jbu...@li...> Betreff: [Jburg-users] Antlr4 support? Hi, I am currently working on optimizing Apache Falcon. One of the things I have started working on is cleaning up the CSS and AS parsing code as it currently uses a mixture of Antlr2, Antlr3 and JFlex and I am woking on migrating all to Antlr4. I don't want to change anything in the JBurg usage, but am having the problem, that JBurg currently relys on Antlr3 and Antlr2 and is incompatable to with Antlr4. Are there any efforts in adding Antlr4 support in JBurg? Or is there a way I can use JBurg without having any trouble? Chris PS: I did have quite some trouble in building JBurg as you didn't provide the versions of which libraries I needed ... So it's antlr3 ... how about adding some auto-download targets to the build script ... would make things easier. ------------------------------------------------------------------------------ Want fast and easy access to all the code in your enterprise? Index and search up to 200,000 lines of code with a free copy of Black Duck Code Sight - the same software that powers the world's largest code search on Ohloh, the Black Duck Open Hub! Try it now. http://p.sf.net/sfu/bds _______________________________________________ Jburg-users mailing list Jbu...@li...<mailto:Jbu...@li...> https://lists.sourceforge.net/lists/listinfo/jburg-users |
From: Christofer D. <chr...@c-...> - 2014-07-27 11:15:35
|
Hi again ☺ I just wanted to tell you that I successfully migrated a copy of JBurg I have to Stringtemplate 4 and was now able to generate part of Falcon with JBurg 2 in conjunction with my maven plugin. If you want, I can zip up the directory and send it to you … thanks to HG you will be able to see what I added and what I changed. There is one problem I am having though that is currently preventing me from completely updating Falcon: In Falcon we have a custom InodeAdapter and this should be used. The problem is that Maven usually has strict phases and code-generation comes before compilation. Unfortunately JBurg can’t load the NodeAdapter implementation because it has not been compiled at the time of the code generation. Do you think there could be a way around this problem? The usage of the node adapter is very limited in JBurgs generation, is there eventually a way to use the source instead of the class file? Chris Von: Christofer Dutz [mailto:chr...@c-...] Gesendet: Freitag, 25. Juli 2014 11:52 An: jbu...@li... Betreff: Re: [Jburg-users] Antlr4 support? Ok ... I do have another change that I would need. in JBurgEmitterFactory line 46 you have: EmitLang el = (EmitLang)ClassLoader.getSystemClassLoader().loadClass(cl.getName()).newInstance(); This needs to be changed to something like this: EmitLang el = (EmitLang) JBurgEmitterFactory.class.getClassLoader().loadClass(cl.getName()).newInstance(); Because as I mentioned in another post. A Maven plugin has it's own classloader that can contain jars the root classloader doesn't have. So I got errors, because JBurg wasn't able to load the classes using the system loader. By changing that line to my version you use the classloader that was used to load the JBurgEmitterFactory which will deffinitely be the one also containing the Emitter implementations. A second fix would be to add the following lines to JBurgMain: if(!outputPath.getParentFile().exists()) { if(!outputPath.getParentFile().mkdirs()) { log.error("Error creating output directory:" + outputPath.getAbsolutePath()); } } between Line 87 and 88: generator.semanticAnalysis(); if(!outputPath.getParentFile().exists()) { if(!outputPath.getParentFile().mkdirs()) { log.error("Error creating output directory:" + outputPath.getAbsolutePath()); } } generator.emit(className, new PrintStream(new FileOutputStream(outputPath))); With these changes I was able to successfully generate the Falcon CSS Burm :-) Chris ________________________________ Von: Christofer Dutz <chr...@c-...> Gesendet: Freitag, 25. Juli 2014 09:21 An: jbu...@li... Betreff: Re: [Jburg-users] Antlr4 support? Hi Tom, good news :-) As I wrote in my last mail, I was wrong with the two parts so forget that ;-) I think I managed to get everything running without you having to modify anything at all. I created a jburg-maven-plugin that wrapps the calls to JBurg. The cool thing is that each maven plugin has its own classloader. Therefore the Jburg plugin can use whatever Antlr version it likes and it seems to work niceley. There is one thing that would need changing, but it's a no-brainer ;-): In the build script at line 150 you add a classpath entry to the manifest of the jburg.jar. This was causing major classloading issues in maven. After commenting out/removing that line my plugin seemes to work niceley. I will experiment a little with the plugin and as soon as I think it's ready to be used, I would like to donate that to your project ... unfortunateley I don't quite know how to do that. If you could send me what I have to do, I'd gladly do it. Chris ________________________________ Von: Christofer Dutz Gesendet: Donnerstag, 24. Juli 2014 16:00 An: Tom Harwood Betreff: AW: [Jburg-users] Antlr4 support? Hi tom, after your post, I double checked the Exceptions I was recieving and could see that you were correct about the "no depenency" thing. I am having some strange classloading problems with my plugin though ... will try to sort them out. Chris ________________________________ Von: Tom Harwood <tho...@gm...> Gesendet: Donnerstag, 24. Juli 2014 14:36 An: Christofer Dutz Betreff: Re: [Jburg-users] Antlr4 support? Hello Christofer, My apologies for not responding sooner; I intended to do so last night but got distracted. I will look into moving to ANTLR 4 and using the separate StringTemplate libraries; my time to work on JBurg is quite limited at present, but that doesn't seem like a very big task. I'll also update the INSTALL documents. I (as the originator and present sole maintainer of the project) would be quite grateful for a maven plugin, and also any advice on getting a JBurg build up somewhere where a maven-ized Falcon build could use it. I tried to do that in response to a request from a Falcon developer last year, but my knowledge of Maven is so limited I couldn't quite understand the procedure to follow. I do ask that the copyright of contributed code be assigned to me -- I have had some trouble tracking down a copyright holder in some of the existing code, which means I cannot switch to a more modern license until I can find him or I rewrite that code. I would still gratefully accept a contribution, but you would potentially make my life a little easier by also assigning copyright. JBurg doesn't have a runtime; the entire rewrite engine is contained in the generated .java file. The situation is a little different for C++, but I don't imagine Falcon's being rewritten in C++ :) So I'm not sure what you want to split into separate jar files. Finally, you should be aware that JBurg development is focused on JBurg 2.0. Like Ter, I reserve the major version number for a breaking change. In this case, I'm rationalizing the syntax of the various directives and grammar elements, along with some deeper changes that will generate a much more efficient state machine. So the tip of the tree will not process Falcon. There is a JBURG_1 tag in the codebase to get the last JBurg 1.x tree; there is also a conversion script, convertV1ToV2.sh in the extras directory, to convert to the version 2 syntax. If Falcon wants to convert to version 2 syntax I would be happy to pull the latest Falcon code and run the conversion script. Best regards, - Tom Harwood On Thu, Jul 24, 2014 at 5:57 AM, Christofer Dutz <chr...@c-...<mailto:chr...@c-...>> wrote: Ok ... so I had another look. Guess we wouldn't have to change anything major with the Antlr version here. I whipped up a small maven plugin to do the code generation. I would be happy to donate that to your project. Now the plugin can continue to reference Antlr3 and we can use Antlr4 in Falcon. There is however one thing preventing me from proceding here. Antlr3 seems to have contained a template engine "Stringtemplate" that was probably moved to a top level project some time later www.stringtemplate.org<http://www.stringtemplate.org> Would it be possible to utilize this instead of antlr.stringtemplate classes? This is currently preventing me from continuing :-( The next thing is that it seems that JBurg consists of a Generator and a Runtim part. Would it be possible to split this up into two jars? Then the runtime part could be completely independent of Antlr. I would reference the Generator in my Maven plugin and the Runtime would be used in the application contiainng only the classes needed by the generated code. I would also be hapy to contribute here. Chris ________________________________ Von: Christofer Dutz <chr...@c-...<mailto:chr...@c-...>> Gesendet: Mittwoch, 23. Juli 2014 14:22 An: jbu...@li...<mailto:jbu...@li...> Betreff: [Jburg-users] Antlr4 support? Hi, I am currently working on optimizing Apache Falcon. One of the things I have started working on is cleaning up the CSS and AS parsing code as it currently uses a mixture of Antlr2, Antlr3 and JFlex and I am woking on migrating all to Antlr4. I don't want to change anything in the JBurg usage, but am having the problem, that JBurg currently relys on Antlr3 and Antlr2 and is incompatable to with Antlr4. Are there any efforts in adding Antlr4 support in JBurg? Or is there a way I can use JBurg without having any trouble? Chris PS: I did have quite some trouble in building JBurg as you didn't provide the versions of which libraries I needed ... So it's antlr3 ... how about adding some auto-download targets to the build script ... would make things easier. ------------------------------------------------------------------------------ Want fast and easy access to all the code in your enterprise? Index and search up to 200,000 lines of code with a free copy of Black Duck Code Sight - the same software that powers the world's largest code search on Ohloh, the Black Duck Open Hub! Try it now. http://p.sf.net/sfu/bds _______________________________________________ Jburg-users mailing list Jbu...@li...<mailto:Jbu...@li...> https://lists.sourceforge.net/lists/listinfo/jburg-users |
From: Christofer D. <chr...@c-...> - 2014-07-25 09:52:22
|
Ok ... I do have another change that I would need. in JBurgEmitterFactory line 46 you have: EmitLang el = (EmitLang)ClassLoader.getSystemClassLoader().loadClass(cl.getName()).newInstance(); This needs to be changed to something like this: EmitLang el = (EmitLang) JBurgEmitterFactory.class.getClassLoader().loadClass(cl.getName()).newInstance(); Because as I mentioned in another post. A Maven plugin has it's own classloader that can contain jars the root classloader doesn't have. So I got errors, because JBurg wasn't able to load the classes using the system loader. By changing that line to my version you use the classloader that was used to load the JBurgEmitterFactory which will deffinitely be the one also containing the Emitter implementations. A second fix would be to add the following lines to JBurgMain: if(!outputPath.getParentFile().exists()) { if(!outputPath.getParentFile().mkdirs()) { log.error("Error creating output directory:" + outputPath.getAbsolutePath()); } } between Line 87 and 88: generator.semanticAnalysis(); if(!outputPath.getParentFile().exists()) { if(!outputPath.getParentFile().mkdirs()) { log.error("Error creating output directory:" + outputPath.getAbsolutePath()); } } generator.emit(className, new PrintStream(new FileOutputStream(outputPath))); With these changes I was able to successfully generate the Falcon CSS Burm :-) Chris ________________________________ Von: Christofer Dutz <chr...@c-...> Gesendet: Freitag, 25. Juli 2014 09:21 An: jbu...@li... Betreff: Re: [Jburg-users] Antlr4 support? Hi Tom, good news :-) As I wrote in my last mail, I was wrong with the two parts so forget that ;-) I think I managed to get everything running without you having to modify anything at all. I created a jburg-maven-plugin that wrapps the calls to JBurg. The cool thing is that each maven plugin has its own classloader. Therefore the Jburg plugin can use whatever Antlr version it likes and it seems to work niceley. There is one thing that would need changing, but it's a no-brainer ;-): In the build script at line 150 you add a classpath entry to the manifest of the jburg.jar. This was causing major classloading issues in maven. After commenting out/removing that line my plugin seemes to work niceley. I will experiment a little with the plugin and as soon as I think it's ready to be used, I would like to donate that to your project ... unfortunateley I don't quite know how to do that. If you could send me what I have to do, I'd gladly do it. Chris ________________________________ Von: Christofer Dutz Gesendet: Donnerstag, 24. Juli 2014 16:00 An: Tom Harwood Betreff: AW: [Jburg-users] Antlr4 support? Hi tom, after your post, I double checked the Exceptions I was recieving and could see that you were correct about the "no depenency" thing. I am having some strange classloading problems with my plugin though ... will try to sort them out. Chris ________________________________ Von: Tom Harwood <tho...@gm...> Gesendet: Donnerstag, 24. Juli 2014 14:36 An: Christofer Dutz Betreff: Re: [Jburg-users] Antlr4 support? Hello Christofer, My apologies for not responding sooner; I intended to do so last night but got distracted. I will look into moving to ANTLR 4 and using the separate StringTemplate libraries; my time to work on JBurg is quite limited at present, but that doesn't seem like a very big task. I'll also update the INSTALL documents. I (as the originator and present sole maintainer of the project) would be quite grateful for a maven plugin, and also any advice on getting a JBurg build up somewhere where a maven-ized Falcon build could use it. I tried to do that in response to a request from a Falcon developer last year, but my knowledge of Maven is so limited I couldn't quite understand the procedure to follow. I do ask that the copyright of contributed code be assigned to me -- I have had some trouble tracking down a copyright holder in some of the existing code, which means I cannot switch to a more modern license until I can find him or I rewrite that code. I would still gratefully accept a contribution, but you would potentially make my life a little easier by also assigning copyright. JBurg doesn't have a runtime; the entire rewrite engine is contained in the generated .java file. The situation is a little different for C++, but I don't imagine Falcon's being rewritten in C++ :) So I'm not sure what you want to split into separate jar files. Finally, you should be aware that JBurg development is focused on JBurg 2.0. Like Ter, I reserve the major version number for a breaking change. In this case, I'm rationalizing the syntax of the various directives and grammar elements, along with some deeper changes that will generate a much more efficient state machine. So the tip of the tree will not process Falcon. There is a JBURG_1 tag in the codebase to get the last JBurg 1.x tree; there is also a conversion script, convertV1ToV2.sh in the extras directory, to convert to the version 2 syntax. If Falcon wants to convert to version 2 syntax I would be happy to pull the latest Falcon code and run the conversion script. Best regards, - Tom Harwood On Thu, Jul 24, 2014 at 5:57 AM, Christofer Dutz <chr...@c-...<mailto:chr...@c-...>> wrote: Ok ... so I had another look. Guess we wouldn't have to change anything major with the Antlr version here. I whipped up a small maven plugin to do the code generation. I would be happy to donate that to your project. Now the plugin can continue to reference Antlr3 and we can use Antlr4 in Falcon. There is however one thing preventing me from proceding here. Antlr3 seems to have contained a template engine "Stringtemplate" that was probably moved to a top level project some time later www.stringtemplate.org<http://www.stringtemplate.org> Would it be possible to utilize this instead of antlr.stringtemplate classes? This is currently preventing me from continuing :-( The next thing is that it seems that JBurg consists of a Generator and a Runtim part. Would it be possible to split this up into two jars? Then the runtime part could be completely independent of Antlr. I would reference the Generator in my Maven plugin and the Runtime would be used in the application contiainng only the classes needed by the generated code. I would also be hapy to contribute here. Chris ________________________________ Von: Christofer Dutz <chr...@c-...<mailto:chr...@c-...>> Gesendet: Mittwoch, 23. Juli 2014 14:22 An: jbu...@li...<mailto:jbu...@li...> Betreff: [Jburg-users] Antlr4 support? Hi, I am currently working on optimizing Apache Falcon. One of the things I have started working on is cleaning up the CSS and AS parsing code as it currently uses a mixture of Antlr2, Antlr3 and JFlex and I am woking on migrating all to Antlr4. I don't want to change anything in the JBurg usage, but am having the problem, that JBurg currently relys on Antlr3 and Antlr2 and is incompatable to with Antlr4. Are there any efforts in adding Antlr4 support in JBurg? Or is there a way I can use JBurg without having any trouble? Chris PS: I did have quite some trouble in building JBurg as you didn't provide the versions of which libraries I needed ... So it's antlr3 ... how about adding some auto-download targets to the build script ... would make things easier. ------------------------------------------------------------------------------ Want fast and easy access to all the code in your enterprise? Index and search up to 200,000 lines of code with a free copy of Black Duck Code Sight - the same software that powers the world's largest code search on Ohloh, the Black Duck Open Hub! Try it now. http://p.sf.net/sfu/bds _______________________________________________ Jburg-users mailing list Jbu...@li...<mailto:Jbu...@li...> https://lists.sourceforge.net/lists/listinfo/jburg-users |
From: Christofer D. <chr...@c-...> - 2014-07-25 07:21:30
|
Hi Tom, good news :-) As I wrote in my last mail, I was wrong with the two parts so forget that ;-) I think I managed to get everything running without you having to modify anything at all. I created a jburg-maven-plugin that wrapps the calls to JBurg. The cool thing is that each maven plugin has its own classloader. Therefore the Jburg plugin can use whatever Antlr version it likes and it seems to work niceley. There is one thing that would need changing, but it's a no-brainer ;-): In the build script at line 150 you add a classpath entry to the manifest of the jburg.jar. This was causing major classloading issues in maven. After commenting out/removing that line my plugin seemes to work niceley. I will experiment a little with the plugin and as soon as I think it's ready to be used, I would like to donate that to your project ... unfortunateley I don't quite know how to do that. If you could send me what I have to do, I'd gladly do it. Chris ________________________________ Von: Christofer Dutz Gesendet: Donnerstag, 24. Juli 2014 16:00 An: Tom Harwood Betreff: AW: [Jburg-users] Antlr4 support? Hi tom, after your post, I double checked the Exceptions I was recieving and could see that you were correct about the "no depenency" thing. I am having some strange classloading problems with my plugin though ... will try to sort them out. Chris ________________________________ Von: Tom Harwood <tho...@gm...> Gesendet: Donnerstag, 24. Juli 2014 14:36 An: Christofer Dutz Betreff: Re: [Jburg-users] Antlr4 support? Hello Christofer, My apologies for not responding sooner; I intended to do so last night but got distracted. I will look into moving to ANTLR 4 and using the separate StringTemplate libraries; my time to work on JBurg is quite limited at present, but that doesn't seem like a very big task. I'll also update the INSTALL documents. I (as the originator and present sole maintainer of the project) would be quite grateful for a maven plugin, and also any advice on getting a JBurg build up somewhere where a maven-ized Falcon build could use it. I tried to do that in response to a request from a Falcon developer last year, but my knowledge of Maven is so limited I couldn't quite understand the procedure to follow. I do ask that the copyright of contributed code be assigned to me -- I have had some trouble tracking down a copyright holder in some of the existing code, which means I cannot switch to a more modern license until I can find him or I rewrite that code. I would still gratefully accept a contribution, but you would potentially make my life a little easier by also assigning copyright. JBurg doesn't have a runtime; the entire rewrite engine is contained in the generated .java file. The situation is a little different for C++, but I don't imagine Falcon's being rewritten in C++ :) So I'm not sure what you want to split into separate jar files. Finally, you should be aware that JBurg development is focused on JBurg 2.0. Like Ter, I reserve the major version number for a breaking change. In this case, I'm rationalizing the syntax of the various directives and grammar elements, along with some deeper changes that will generate a much more efficient state machine. So the tip of the tree will not process Falcon. There is a JBURG_1 tag in the codebase to get the last JBurg 1.x tree; there is also a conversion script, convertV1ToV2.sh in the extras directory, to convert to the version 2 syntax. If Falcon wants to convert to version 2 syntax I would be happy to pull the latest Falcon code and run the conversion script. Best regards, - Tom Harwood On Thu, Jul 24, 2014 at 5:57 AM, Christofer Dutz <chr...@c-...<mailto:chr...@c-...>> wrote: Ok ... so I had another look. Guess we wouldn't have to change anything major with the Antlr version here. I whipped up a small maven plugin to do the code generation. I would be happy to donate that to your project. Now the plugin can continue to reference Antlr3 and we can use Antlr4 in Falcon. There is however one thing preventing me from proceding here. Antlr3 seems to have contained a template engine "Stringtemplate" that was probably moved to a top level project some time later www.stringtemplate.org<http://www.stringtemplate.org> Would it be possible to utilize this instead of antlr.stringtemplate classes? This is currently preventing me from continuing :-( The next thing is that it seems that JBurg consists of a Generator and a Runtim part. Would it be possible to split this up into two jars? Then the runtime part could be completely independent of Antlr. I would reference the Generator in my Maven plugin and the Runtime would be used in the application contiainng only the classes needed by the generated code. I would also be hapy to contribute here. Chris ________________________________ Von: Christofer Dutz <chr...@c-...<mailto:chr...@c-...>> Gesendet: Mittwoch, 23. Juli 2014 14:22 An: jbu...@li...<mailto:jbu...@li...> Betreff: [Jburg-users] Antlr4 support? Hi, I am currently working on optimizing Apache Falcon. One of the things I have started working on is cleaning up the CSS and AS parsing code as it currently uses a mixture of Antlr2, Antlr3 and JFlex and I am woking on migrating all to Antlr4. I don't want to change anything in the JBurg usage, but am having the problem, that JBurg currently relys on Antlr3 and Antlr2 and is incompatable to with Antlr4. Are there any efforts in adding Antlr4 support in JBurg? Or is there a way I can use JBurg without having any trouble? Chris PS: I did have quite some trouble in building JBurg as you didn't provide the versions of which libraries I needed ... So it's antlr3 ... how about adding some auto-download targets to the build script ... would make things easier. ------------------------------------------------------------------------------ Want fast and easy access to all the code in your enterprise? Index and search up to 200,000 lines of code with a free copy of Black Duck Code Sight - the same software that powers the world's largest code search on Ohloh, the Black Duck Open Hub! Try it now. http://p.sf.net/sfu/bds _______________________________________________ Jburg-users mailing list Jbu...@li...<mailto:Jbu...@li...> https://lists.sourceforge.net/lists/listinfo/jburg-users |
From: Christofer D. <chr...@c-...> - 2014-07-24 13:00:28
|
Hi Tom, well the Maven plugin is finished and seems to work. Unfortunateley the code can't compile because I need a dependency to some jburg internals and they again pull in the wrong antlr version. I also have no problems of granting you whatever right you want to the sourcecode. After all I want to make my life with flacon easier ;-) If you could do the upgrade to Antlr4 and Stringtemplate, that would be awesome. If you like I could convert the whole thing to a Maven build for you. Shouldn't take too long. But doing all of that on my own would be a hard task, I guess. Well there is code in JBurg, which I call to generate the code from the jbg-files and there are classes the generated sources reference some JBurg classes: jburg.burg.emitlangs.EmitCpp and jburg.burg.emitlangs.EmitJava for example. That's why I was talking about two parts ... I doubt I need the JBurgMain is needed at runtime and the EmitJava is needed at runtime. So even if it doesn't need a runtime, there seems to be some classes that are needed at runtime. So eventually me calling it "runtime" was wrong, but I simply mean something needed at generation-time and some things needed at runtime. Chris ________________________________ Von: Tom Harwood <tho...@gm...> Gesendet: Donnerstag, 24. Juli 2014 14:36 An: Christofer Dutz Betreff: Re: [Jburg-users] Antlr4 support? Hello Christofer, My apologies for not responding sooner; I intended to do so last night but got distracted. I will look into moving to ANTLR 4 and using the separate StringTemplate libraries; my time to work on JBurg is quite limited at present, but that doesn't seem like a very big task. I'll also update the INSTALL documents. I (as the originator and present sole maintainer of the project) would be quite grateful for a maven plugin, and also any advice on getting a JBurg build up somewhere where a maven-ized Falcon build could use it. I tried to do that in response to a request from a Falcon developer last year, but my knowledge of Maven is so limited I couldn't quite understand the procedure to follow. I do ask that the copyright of contributed code be assigned to me -- I have had some trouble tracking down a copyright holder in some of the existing code, which means I cannot switch to a more modern license until I can find him or I rewrite that code. I would still gratefully accept a contribution, but you would potentially make my life a little easier by also assigning copyright. JBurg doesn't have a runtime; the entire rewrite engine is contained in the generated .java file. The situation is a little different for C++, but I don't imagine Falcon's being rewritten in C++ :) So I'm not sure what you want to split into separate jar files. Finally, you should be aware that JBurg development is focused on JBurg 2.0. Like Ter, I reserve the major version number for a breaking change. In this case, I'm rationalizing the syntax of the various directives and grammar elements, along with some deeper changes that will generate a much more efficient state machine. So the tip of the tree will not process Falcon. There is a JBURG_1 tag in the codebase to get the last JBurg 1.x tree; there is also a conversion script, convertV1ToV2.sh in the extras directory, to convert to the version 2 syntax. If Falcon wants to convert to version 2 syntax I would be happy to pull the latest Falcon code and run the conversion script. Best regards, - Tom Harwood On Thu, Jul 24, 2014 at 5:57 AM, Christofer Dutz <chr...@c-...<mailto:chr...@c-...>> wrote: Ok ... so I had another look. Guess we wouldn't have to change anything major with the Antlr version here. I whipped up a small maven plugin to do the code generation. I would be happy to donate that to your project. Now the plugin can continue to reference Antlr3 and we can use Antlr4 in Falcon. There is however one thing preventing me from proceding here. Antlr3 seems to have contained a template engine "Stringtemplate" that was probably moved to a top level project some time later www.stringtemplate.org<http://www.stringtemplate.org> Would it be possible to utilize this instead of antlr.stringtemplate classes? This is currently preventing me from continuing :-( The next thing is that it seems that JBurg consists of a Generator and a Runtim part. Would it be possible to split this up into two jars? Then the runtime part could be completely independent of Antlr. I would reference the Generator in my Maven plugin and the Runtime would be used in the application contiainng only the classes needed by the generated code. I would also be hapy to contribute here. Chris ________________________________ Von: Christofer Dutz <chr...@c-...<mailto:chr...@c-...>> Gesendet: Mittwoch, 23. Juli 2014 14:22 An: jbu...@li...<mailto:jbu...@li...> Betreff: [Jburg-users] Antlr4 support? Hi, I am currently working on optimizing Apache Falcon. One of the things I have started working on is cleaning up the CSS and AS parsing code as it currently uses a mixture of Antlr2, Antlr3 and JFlex and I am woking on migrating all to Antlr4. I don't want to change anything in the JBurg usage, but am having the problem, that JBurg currently relys on Antlr3 and Antlr2 and is incompatable to with Antlr4. Are there any efforts in adding Antlr4 support in JBurg? Or is there a way I can use JBurg without having any trouble? Chris PS: I did have quite some trouble in building JBurg as you didn't provide the versions of which libraries I needed ... So it's antlr3 ... how about adding some auto-download targets to the build script ... would make things easier. ------------------------------------------------------------------------------ Want fast and easy access to all the code in your enterprise? Index and search up to 200,000 lines of code with a free copy of Black Duck Code Sight - the same software that powers the world's largest code search on Ohloh, the Black Duck Open Hub! Try it now. http://p.sf.net/sfu/bds _______________________________________________ Jburg-users mailing list Jbu...@li...<mailto:Jbu...@li...> https://lists.sourceforge.net/lists/listinfo/jburg-users |
From: Christofer D. <chr...@c-...> - 2014-07-24 09:58:11
|
Ok ... so I had another look. Guess we wouldn't have to change anything major with the Antlr version here. I whipped up a small maven plugin to do the code generation. I would be happy to donate that to your project. Now the plugin can continue to reference Antlr3 and we can use Antlr4 in Falcon. There is however one thing preventing me from proceding here. Antlr3 seems to have contained a template engine "Stringtemplate" that was probably moved to a top level project some time later www.stringtemplate.org<http://www.stringtemplate.org> Would it be possible to utilize this instead of antlr.stringtemplate classes? This is currently preventing me from continuing :-( The next thing is that it seems that JBurg consists of a Generator and a Runtim part. Would it be possible to split this up into two jars? Then the runtime part could be completely independent of Antlr. I would reference the Generator in my Maven plugin and the Runtime would be used in the application contiainng only the classes needed by the generated code. I would also be hapy to contribute here. Chris ________________________________ Von: Christofer Dutz <chr...@c-...> Gesendet: Mittwoch, 23. Juli 2014 14:22 An: jbu...@li... Betreff: [Jburg-users] Antlr4 support? Hi, I am currently working on optimizing Apache Falcon. One of the things I have started working on is cleaning up the CSS and AS parsing code as it currently uses a mixture of Antlr2, Antlr3 and JFlex and I am woking on migrating all to Antlr4. I don't want to change anything in the JBurg usage, but am having the problem, that JBurg currently relys on Antlr3 and Antlr2 and is incompatable to with Antlr4. Are there any efforts in adding Antlr4 support in JBurg? Or is there a way I can use JBurg without having any trouble? Chris PS: I did have quite some trouble in building JBurg as you didn't provide the versions of which libraries I needed ... So it's antlr3 ... how about adding some auto-download targets to the build script ... would make things easier. |
From: Christofer D. <chr...@c-...> - 2014-07-23 12:38:12
|
Hi, I am currently working on optimizing Apache Falcon. One of the things I have started working on is cleaning up the CSS and AS parsing code as it currently uses a mixture of Antlr2, Antlr3 and JFlex and I am woking on migrating all to Antlr4. I don't want to change anything in the JBurg usage, but am having the problem, that JBurg currently relys on Antlr3 and Antlr2 and is incompatable to with Antlr4. Are there any efforts in adding Antlr4 support in JBurg? Or is there a way I can use JBurg without having any trouble? Chris PS: I did have quite some trouble in building JBurg as you didn't provide the versions of which libraries I needed ... So it's antlr3 ... how about adding some auto-download targets to the build script ... would make things easier. |
From: Carlos R. <car...@ap...> - 2013-05-13 21:10:39
|
Hi, I'd like to ask is there's a JBurg Maven artifact. I'm trying to mavenize a project that depends on JBurg and I'm blocked due to not find a repository with this particular library. If there's no artifact, could be plans of provide a maven artifact in the future Thanks in advance Carlos Rovira |
From: <ben...@id...> - 2004-05-25 07:45:52
|
Dear Open Source developer I am doing a research project on "Fun and Software Development" in which I kindly invite you to participate. You will find the online survey under http://fasd.ethz.ch/qsf/. The questionnaire consists of 53 questions and you will need about 15 minutes to complete it. With the FASD project (Fun and Software Development) we want to define the motivational significance of fun when software developers decide to engage in Open Source projects. What is special about our research project is that a similar survey is planned with software developers in commercial firms. This procedure allows the immediate comparison between the involved individuals and the conditions of production of these two development models. Thus we hope to obtain substantial new insights to the phenomenon of Open Source Development. With many thanks for your participation, Benno Luthiger PS: The results of the survey will be published under http://www.isu.unizh.ch/fuehrung/blprojects/FASD/. We have set up the mailing list fa...@we... for this study. Please see http://fasd.ethz.ch/qsf/mailinglist_en.html for registration to this mailing list. _______________________________________________________________________ Benno Luthiger Swiss Federal Institute of Technology Zurich 8092 Zurich Mail: benno.luthiger(at)id.ethz.ch _______________________________________________________________________ |
From: Tom H. <tharwood@TheWorld.com> - 2003-09-24 12:00:08
|
Hello Cristian, My apologies for this late response; I just discovered that I was not = subscribed to jburg-users. What you are doing is called "common subexpression elimination." I = remember having an interesting discussion with Edwin Smith at Macromedia = about using a BURM to do common subexpression elimination, and deciding = that it was probably easiest to do this in a separate compiler pass, = since there is a good deal of prior art in common subexpression = elimination at the intermediate-code level and because, as you noticed, = information about common subexpressions is not hierarchically organized = but scattered throughout the tree, which makes it difficult to use a = dynamic programming engine to find it. For your immediate needs, a Google search on "Common subexpression = elimination" should give you many resources. As a more general and = theoretical point, it might be interesting to investigate integrating = aspect-oriented descriptions of program transformations (such as CSE) = into higher-level compiler tools. Some happy day when I can work on = compilers again, I'll look into it :) Hope this helps, and best regards, - Tom Harwood |
From: Cristian A. <cri...@am...> - 2003-09-02 09:44:30
|
Hello, I would like to know if there is any easy way to optimize arithemtic=20 computations like in the example below. From: x =3D (a + b) + (c + d); y =3D (a + b) + c; z =3D (b + a) + c; To: r1 =3D a + b; y =3D r1 + c; z =3D y; x =3D y + d; If you want I can send you some 'expr.g', 'expr.jburg' and 'Main.java' I'= ve=20 started to play with. One way I was thinking about was to use some cost functions, yet the only= =20 parameter it gets is the input tree, nothing about the context of the cur= rent=20 cost evaluation... For example: expr =3D PLUS(expr e1, expr e2) : 1 { String e =3D Main.getRegister(); Main.emit(e + " =3D " + e1 + " + " + e2); Main.newExpr(e, "" + e1 + "+" + e2); // add to some hash Main.newExpr(e, "" + e2 + "+" + e1); // ready for commutativity return e; } expr =3D PLUS(expr e1, expr e2) : plusCost1() { =09return (Main.getExpr("" + e1 + "+" + e2)); } // and here I would like to get the e1/e2, not the actual input via p... plusCost1() { // it doesn't work this way.. return (Main.getExpr("" + e1 + "+" + e2) !=3D null ? 0 : 1000); } Looking in the generated source, I was thinking about passing 'node' inst= ead=20 of 'node.m_node' to the cost function... Yet, I've just started to look i= nto=20 the theory of operation, so if this doesn't make sense please correct me. Thank you, Cristian |