The following diff seemed to help build a nice native binary in my
fedora. The first modification makes using the new core archive file
name and the second avoids a problematic class . . .
[EMAIL PROTECTED] lucene-trunk]$ svn diff
Index: src/gcj/Makefile
==
Until there is a free java 5 alternative, it would be nice to have a
clean compile in 1.4. We might also consider waiting until gcj does the
1.5 move, since some of us are loving the native binaries, particularly
on x86_64.
How else can you index billions of documents (aside from expensive bi
Robert Engels wrote:
Do you have any hard numbers to support this? The last time I checked, gcj
had minimal improvement over JVM 1.5.
In terms of speed, there is not much difference between native code and
classes (see sample timings). However, the pragmatic availability of
java 5 environ
Andi Vajda wrote:
On Mon, 10 Jul 2006, Doug Cutting wrote:
Andi Vajda wrote:
On Sat, 8 Jul 2006, Doug Cutting wrote:
Since GCJ is effectively available on all platforms, we could say
that we will start accepting 1.5 features when a GCJ release
supports those features. Does that seem reaso
robert engels wrote:
Seems silly to support 1.5 and not do it this way.
Sometimes a little silliness is some serious fun! Just give me a rubber
nose, since I am just clowning around trying to build Andi's kewly
contrib/db using gcj on the slightly stylish db-4.4.20 and je-3.0.12 . . .
O
adasal wrote:
Don't be coy, what's your comapany?
This URL is derivable from the text, with a little search ening help . . .
**
http://www.terracottatech.com/terracotta_spring.shtml
more,
l8r,
v
On 21/09/06, Steve Harris <[EMAIL PROTECTED]> wrote:
Warning, I'm a vendor dude but this isn
J.Zhu wrote:
If I would like to contribute, what should I do? I am not a good Java
developer myself though. Can I work with someone also interested?
In some of my group's usage of lucene over large document collections,
we have split the documents across several machines. This has lead to a
Chuck Williams wrote:
Vic Bancroft wrote on 10/17/2006 02:44 AM:
In some of my group's usage of lucene over large document collections,
we have split the documents across several machines. This has lead to
a concern of whether the inverse document frequency was appropriate,
since the
Simon Willnauer wrote:
I'm actually looking for alternatives and suggestions about this
topic, I know you guys have your own schedule but I would really
appreciate some help with that.
Perhaps the derby would be appropriate,
http://db.apache.org/derby/
It is fairly fast, somewhat scalable