You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@lucene.apache.org by Andi Vajda <an...@osafoundation.org> on 2004/10/02 22:10:33 UTC
Re: IndexInput & GCJ
Do you intend to ultimately support Java Lucene with GCJ ?
This would be great as there are several problems with GCJ and Java Lucene
that I have been maintaining patches for in the PyLucene project
(http://pylucene.osafoundation.org).
I'm in the process of upgrading PyLucene to using the just-released Lucene
1.4.2 and noticed that if I started from the lucene 1.4.2 jar file instead of
from the lucene 1.4.2 sources many of these patches are no longer necessary.
As a matter of fact, I'm down to 3 patches:
- GCJH cannot generate a header file from QueryParser.class because there
are one static field and one static method which have the same name (down
from two in Lucene 1.4.1)
- The delete(int) and delete(Term) methods on IndexReader clash with the
'delete' c++ keyword. GCJ will generate them as 'delete$' which is a neat
workaround; the problem, however, is that the dynamic linker, at least on
Mac OS X, doesn't then properly link to these symbols and fails to load
the resulting shared library.
So I defined two synonym methods deleteDocument(int) and
deleteDocuments(Term) in a patch to IndexReader.
- Because of GCJ bug 15411,
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15411,
Searcher.java needs to be patched to define the missing method
definitions
None of these patches are specific for PyLucene, would you consider
incorporating them into the Lucene sources ?
The actual patches are included in the attached patches.lucene file.
Andi..
On Thu, 16 Sep 2004, Doug Cutting wrote:
> I replaced InputStream with IndexInput and BufferedIndexInput, so buffering
> is now optional. InputStream is now deprecated and one can also now subclass
> FSDirectory.
>
> Still to do:
>
> 1. Replace OutputStream with IndexOutput and BufferedIndexOutput. This is
> not critical and mostly for consistency, as mmap makes more sense for
> read-only data.
> 2. Update RAMDirectory and FSDirectory to no longer use deprecated classes.
> This is done last, to make sure that the earlier steps to not break
> back-compatibility for existing Directory implementations.
>
> Also, I've implemented an mmap-based subclass of FSDirectory in C++ using
> GCJ. Any objections to checking this in under src/gcj? It's not yet much
> faster than the pure Java implementation, but perhaps it can be made faster,
> and it also provides an example of how to extend Lucene with C++ in GCJ,
> which might eventually lead to some big speedups.
>
> Doug
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: lucene-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: lucene-dev-help@jakarta.apache.org
>
>
Re: IndexInput & GCJ
Posted by Andi Vajda <an...@osafoundation.org>.
> Are you willing to submit a bug report to JavaCC?
I just filed an enhancement request with JavaCC:
https://javacc.dev.java.net/issues/show_bug.cgi?id=53
Andi..
---------------------------------------------------------------------
To unsubscribe, e-mail: lucene-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: lucene-dev-help@jakarta.apache.org
Re: IndexInput & GCJ
Posted by Doug Cutting <cu...@apache.org>.
Andi Vajda wrote:
>> This code is generated by JavaCC. I think the best way to fix this
>> would be to fixup the code automatically whenever it is regenerated.
>> So, instead of patching QueryParser.java, patch build.xml. In the
>> javacc-QueryParser task, add a <replace> task which replaces
>> 'jj_la1_0()' with 'jj_la1_0_method()'.
>
> That is a brittle kludge as the code that needs to be changed may vary
> everytime the parser is re-generated. There used to be two such methods
> in 1.4.1 for instance. The proper way to workaround this issue is to fix
> javacc to not generate such java code in the first place.
It is indeed a brittle kludge.
Are you willing to submit a bug report to JavaCC?
https://javacc.dev.java.net/servlets/ProjectIssues
Or even a patch?
https://javacc.dev.java.net/source/browse/javacc/
Doug
---------------------------------------------------------------------
To unsubscribe, e-mail: lucene-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: lucene-dev-help@jakarta.apache.org
Re: IndexInput & GCJ
Posted by Andi Vajda <an...@osafoundation.org>.
> This code is generated by JavaCC. I think the best way to fix this would be
> to fixup the code automatically whenever it is regenerated. So, instead of
> patching QueryParser.java, patch build.xml. In the javacc-QueryParser task,
> add a <replace> task which replaces 'jj_la1_0()' with 'jj_la1_0_method()'.
That is a brittle kludge as the code that needs to be changed may vary
everytime the parser is re-generated. There used to be two such methods in
1.4.1 for instance. The proper way to workaround this issue is to fix javacc
to not generate such java code in the first place.
> Is there a GCJ bug number assigned to this issue? If not, could you please
> file one and note the bug number in a comment? That way, if/when GCJ more
> elegantly resolves this we can remove the hack.
I don't know that there is a such a bug or that it even is one. I'll go look.
>> - The delete(int) and delete(Term) methods on IndexReader clash with the
>> 'delete' c++ keyword. GCJ will generate them as 'delete$' which is a
>> neat
>> workaround; the problem, however, is that the dynamic linker, at least
>> on
>> Mac OS X, doesn't then properly link to these symbols and fails to load
>> the resulting shared library.
>> So I defined two synonym methods deleteDocument(int) and
>> deleteDocuments(Term) in a patch to IndexReader.
>
> In your patch, please add javadocs and deprecate the old delete() methods.
> Again, GCJ and/or OS X bug numbers in a comment would be good to have.
I just filed http://issues.apache.org/bugzilla/show_bug.cgi?id=31708
with such a patch attached. As for filing a bug with Apple, they don't
currently ship gcj so I don't think they'd care very much.
>> - Because of GCJ bug 15411,
>> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15411,
>> Searcher.java needs to be patched to define the missing method
>> definitions
>
> Please add this bug reference in a comment to the patched code.
I just filed http://issues.apache.org/bugzilla/show_bug.cgi?id=31706 with a
patch attached.
Andi..
---------------------------------------------------------------------
To unsubscribe, e-mail: lucene-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: lucene-dev-help@jakarta.apache.org
Re: IndexInput & GCJ
Posted by Doug Cutting <cu...@apache.org>.
Andi Vajda wrote:
> Do you intend to ultimately support Java Lucene with GCJ ?
As far as possible...
> I'm down to 3 patches:
Can you please file a Lucene bug report and attach these patches? I'm
not guaranteeing that they'll all be committed right away, but rather
that that's a better place to keep track of them. And they may get
comitted! Thanks.
I've also suggested a few changes to your patches below.
> - GCJH cannot generate a header file from QueryParser.class because there
> are one static field and one static method which have the same name
> (down
> from two in Lucene 1.4.1)
This code is generated by JavaCC. I think the best way to fix this
would be to fixup the code automatically whenever it is regenerated.
So, instead of patching QueryParser.java, patch build.xml. In the
javacc-QueryParser task, add a <replace> task which replaces
'jj_la1_0()' with 'jj_la1_0_method()'.
Is there a GCJ bug number assigned to this issue? If not, could you
please file one and note the bug number in a comment? That way, if/when
GCJ more elegantly resolves this we can remove the hack.
> - The delete(int) and delete(Term) methods on IndexReader clash with the
> 'delete' c++ keyword. GCJ will generate them as 'delete$' which is a
> neat
> workaround; the problem, however, is that the dynamic linker, at
> least on
> Mac OS X, doesn't then properly link to these symbols and fails to load
> the resulting shared library.
> So I defined two synonym methods deleteDocument(int) and
> deleteDocuments(Term) in a patch to IndexReader.
In your patch, please add javadocs and deprecate the old delete()
methods. Again, GCJ and/or OS X bug numbers in a comment would be good
to have.
> - Because of GCJ bug 15411,
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15411,
> Searcher.java needs to be patched to define the missing method
> definitions
Please add this bug reference in a comment to the patched code.
Doug
---------------------------------------------------------------------
To unsubscribe, e-mail: lucene-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: lucene-dev-help@jakarta.apache.org