Re: Proposal: Basic OSS Cultural Issue: You guys really should stop being such idiots. (Was: Re: Contribution and question about getting involved in the project.)
Jonathan Revusky
> Yes
> on the build, that is what bother me.
> I need to make JavaCC builder (and not only generated parser) run with
> the Eclipse plugin.
Yes, I use the plugin. I appreciate the work you have done on that.
But really, you should try to better understand what is being discussed
before jumping in and expressing such categorical opinions.
First of all, none of these changes are going into JavaCC. I started
this work and wanted to donate it to the project, but simply could not
deal with this culture of aggressive idiocy. (I said enough about that
elsewhere.)
So I created a separate project called KawaDD which is a fork of the
JavaCC codebase. That is at http://code.google.com/p/kawadd and the
current road map is here
http://code.google.com/p/kawadd/wiki/RoadMap
Now, as a gesture for you, I just translated that page to French. It is
here:
http://code.google.com/p/kawadd/wiki/CarteDeRoute
(In case, you're wondering, I speak French like you do. Maybe better...
;--)) So you can write me any questions in French and I'll answer you in
French, but on the list, we should stick to English.
>
> Please do not use an extra tool.
Okay, look, I don't think that what you're saying is based on much
understanding of what is going on here. First of all, KawaDD is a
separate project. You don't even have to support it if you don't want
to, and since there is no official release yet, we're still talking
hypothetically.
Now, that said, I think you should plan to support it and I also think
that once you really understand what is going on here, you will want to
support it. I also don't think that there will be many technical
obstacles to supporting both JavaCC and KawaDD with your plugin, and if
there are, since I naturally want it to work, I will help you with any
problems that arise.
If you want to check whether there is a problem, just grab the latest
version and see if you have a problem getting it to work with your plugin.
svn co http://kawadd.googlecode.com/svn/trunk/kawadd
ant
Or you can see the instructions for grabbing it as a project in eclipse
that I put up here.
http://code.google.com/p/kawadd/wiki/StartHacking
(Sorry, only in English.)
I do not see offhand why you would have any problem getting this to
work. But if you do, write me on the KawaDD discussion list or in
private (and then it can be in French if you want).
Regards,
Jonathan Revusky
--
KawaDD Parser Generator, http://code.google.com/p/kawadd
lead developer, FreeMarker project, http://freemarker.org/
>
> Remi
>
> Le 15/06/2008 11:35, J.Chris Findlay a écrit :
>> re 2: the dependency is on the build only - the build parser will not
>> have any extra dependency. And that dependency is on a single extra
>> .jar anyway
Jonathan Revusky
> Please Jonathan, try to make short.
> I can't read well English is not my native language.
> And http://www.google.com/ do not give much help reading you.
I think the reason that you don't understand it is mostly because you
lack the context. You would have to read through the earlier messages
and understand what had happened. You can do that if you are interested,
but I there is little reason for me to explain it further.
>
> I understand JavaCC is going to evolve.
Well,.... no, it's not. JavaCC is going to remain exactly the same. (I
don't have a crystal ball, but I think it's a very (very very very) safe
bet. :-))
The project that is going to evolve is called KawaDD.
> Three things worth for me :
> 1) Do not add dependencies on a different Product
Why do you care about this?
Suppose that instead of leveraging an existing library for templating
(FreeMarker) one added all that same functionality as classes under
org.javacc.templating.*. Then that would be okay for you because it
wouldn't be a "different product".
But that whole thing is an ersatz discussion. Technically, there is no
real difference between one thing and the other. The whole concept of a
"different product" is basically meaningless technically. Technically,
they're all just java classes. A given set of java classes being a
separate product or not is really a marketing thing, or has to do with
intellectual property and so on, but has no technical meaning.
The only thing that occurs to me is package names, if some other plugin
uses FreeMarker, a different version.... but don't eclipse plugins all
run in their own ClassLoader? Anyway, if there is a package name
conflict, there are known solutions for this. Ever seen a tool called
Jar Jar Links? Very handy. If freemarker.template.* is conflicting with
something somewhere, just run JarJar on your jars and change
freemarker.template.* to koutcheraway.freemarker.template.* and voilà,
no package name conflicts.
> 2) Keep the lexical states
There is no issue of removing lexical states. What KawaDD does remove is:
a) static parsers
b) reusing (ReIniting) parsers (you have to throw it away and new a new one)
The reason is that, on careful consideration, I have concluded that
static and reusable parsers are.... idiotic. In a language that is
inherently multithreaded like Java.
> 3) Make JJDoc able to parse JJTree files
Interesting. I think this is already achieved. Try it out with KawaDD.
You see, I intend for JJTree to melt away and to just have one program
that generates both parser and tree-builder code, so I alredy tweaked
the KawaDD parser to accept the extra productions in JJTree. (Note that
JJDoc just uses the JavaCC parser.)
>
> Because
> I am trying to make evolve Eclipse plugin
> http://sourceforge.net/projects/eclipse-javacc
> 1) dependencies are hard to handle with multi platform environment.
> Bugs report with a System a Java version an Eclipse version I do not
> have, are a pain to correct.
It's not an issue in this case. Any KawaDD release will be bundled with
its own freemarker.jar that has been tested to work with that specific
release.
> 2) lexical states makes me switch to JavaCC l
> Terence Parr tells how to avoid them, but it means switching between
> different lexers.
> http://www.antlr2.org/doc/lexer.html#Lexical_States
THe lack of lexical states made it pretty much impossible for me to
switch to ANTLR. There is no way I would remove them from KawaDD.
> 3) JJDoc bugs on JJTree options set in the .jjt file
This is trivial. The KawaDD grammar already handles the NodeDescriptor
productions, things like #DefNode(2) or whatever. It does nothing on
them right now, but it parses them. I can't remember offhand whether I
modified it to accept the extra JJTree options, but... basically,
consider it done. :-)
>
> For JJDoc I resort to modify JavaCC and pack it with the plugin
> http://eclipse-javacc.cvs.sourceforge.net/eclipse-javacc/sf.eclipse.javacc/javacc_mod_src.zip?view=log
If you have read http://code.google.com/p/kawadd/wiki/CarteDeRoute you
will see that one near-term goal is simply to unify the three programs
and just treat them as one. Offhand, that may make things simpler for a
tool author like you. In general, I'll be interested in making changes
so that KawaDD is more suitable for tooling than JavaCC has been.
Of course, I admit that it will be easier to maintain your support for
JavaCC. Nothing is going to change out from under you. But that, of
course, is because it's a dead project.
Regards,
Jonathan Revusky
--
KawaDD Parser Generator, http://code.google.com/p/kawadd
lead developer, FreeMarker project, http://freemarker.org/
>
>
> Rémi Koutchérawy
>
> Le 14/06/2008 23:47, Jonathan Revusky a écrit :
>>
>> Jonathan,
>>
>> [...]
> Voilà ce que Goggle traduit :
>
> La stagnation technique et audacieux idiotie de la part de personnes
> impliquées. Il est vrai que la corrélation n'implique pas causalité,
> mais c'est au moins une hypothèse de travail raisonnable: une culture de
> l'agressivité idiotie simplement ne pas produire les résultats techniques.
>
> Je me demande si c'est plus compréhensible pour ceux qui le lisent dans
> leur langue maternelle...
>>
>> Jonathan Revusky
>> --
>> KawaDD Parser Generator http://code.google.com/p/kawadd