This patch implements the region-based matching
methods in java.util.regex. There are still a number
of minor bugs, due to missing features in our regex
implementation, but I'd prefer to keep those fixes
for further patches, as this one already alters things
a great deal and does at least
Hi,
I am playing with gnu.regexp these days and finding more and more
to do before it becomes comparable with Sun's JDK.
Although I will continue to make efforts on gnu.regexp,
I am beginning to try another thing.
I have found oniguruma, the regex library which is used as a
regex engine of
Ito Kazumitsu wrote:
I am playing with gnu.regexp these days and finding more and more
to do before it becomes comparable with Sun's JDK.
Although I will continue to make efforts on gnu.regexp,
I am beginning to try another thing.
I have found oniguruma, the regex library which is used as
Hi there,
Am Dienstag, den 14.02.2006, 15:29 +0100 schrieb Jeroen Frijters:
Ito Kazumitsu wrote:
I am playing with gnu.regexp these days and finding more and more
to do before it becomes comparable with Sun's JDK.
Although I will continue to make efforts on gnu.regexp,
I am beginning
Hi,
From: Roman Kennke [EMAIL PROTECTED]
Date: Tue, 14 Feb 2006 16:15:30 +0100
Am Dienstag, den 14.02.2006, 15:29 +0100 schrieb Jeroen Frijters:
While I'm certainly not against this option, I would like to point out
that for some VMs using a native library isn't really a great solution,
Follow-up Comment #1, bug #12307 (project classpath):
This bug can be closed as it's been fixed in CVS:
2005-05-16 Ziga Mahkovec [EMAIL PROTECTED]
PR libgcj/20504
* gnu/regexp/RE.java: Add support for quoting constructs.
On Sun, 2004-03-07 at 19:00, Mark Wielaard wrote:
Hi all,
I finally imported gnu.regexp and added java.util.regex wrappers for it.
At the moment our gnu.regexp is the same as the original gnu.regexp
version, except for a few files and added copyright notices.
Maybe I should have mentioned
Mark Wielaard wrote:
Hi all,
I finally imported gnu.regexp and added java.util.regex wrappers for it.
At the moment our gnu.regexp is the same as the original gnu.regexp
version, except for a few files and added copyright notices.
If this doesn't break things then I want to ship
Tom Tromey [EMAIL PROTECTED] writes:
For something like java.util.regex I think it would be preferable to
have a single implementation in Classpath itself. So, yeah, in this
case I think assignment would be ideal.
The assignment is ideal also to avoid more license irregularities
Hi,
I read a while ago that support for java.util.regex
was to come into GNU Classpath, so I'm interested to
know what came out of it? I know there are stubs in
the CVS, but I've also read Wes wrote a
java.util.regex wrapper around his gnu.regex package,
so I'm wondering if there was any progress
Dalibor Topic wrote:
Hi,
I read a while ago that support for java.util.regex
was to come into GNU Classpath, so I'm interested to
know what came out of it? I know there are stubs in
the CVS, but I've also read Wes wrote a
java.util.regex wrapper around his gnu.regex package,
so I'm wondering
Wes Biggs [EMAIL PROTECTED] writes:
Dalibor Topic wrote:
Hi,
I read a while ago that support for java.util.regex
was to come into GNU Classpath, so I'm interested to
know what came out of it? I know there are stubs in
the CVS, but I've also read Wes wrote a
java.util.regex wrapper
given that Gtk itself is).
For something like java.util.regex I think it would be preferable to
have a single implementation in Classpath itself. So, yeah, in this
case I think assignment would be ideal.
Tom
___
Classpath mailing list
[EMAIL PROTECTED
to compile Classpath, this sucked in files from rt.jar when
they didn't appear in Classpath, and gave me a clean compile even though
I was expecting failure (because I referenced java.util.regex, which is
not yet in Classpath).
Someone with a little more autoconf knowledge than me should figure out
John Leuner wrote:
they didn't appear in Classpath, and gave me a clean compile even though
I was expecting failure (because I referenced java.util.regex, which is
not yet in Classpath).
How should we build Classpath without regex?
I think the short answer right now is that Classpath doesn't
they didn't appear in Classpath, and gave me a clean compile even though
I was expecting failure (because I referenced java.util.regex, which is
not yet in Classpath).
How should we build Classpath without regex?
I think the short answer right now is that Classpath doesn't support
On Fri, Mar 08, 2002 at 01:43:49PM -0800, Wes Biggs wrote:
How long before this work will be finished? Would it be possible to
create stubs from your code at the moment? If yes, then please send them
to me and I will do it and check them in so the tree at least builds
again.
I'll check
Wes Biggs [EMAIL PROTECTED] writes:
Any thoughts on getting this into classpath, logistics-wise? I would
like to continue to maintain gnu.regexp as a separately releasable
project; I see the java.util.regex.* classes as bridge classes to its
API from Classpath. However, I have
Nic Ferrier wrote:
Is there any reason why Classpath couldn't include your source code
in the CVS?
If you hosted the CVS for gnu regexp on subversions (via the savannah
system) we would be able to create a link from the Classpath CVS to
your source code directories to make it seem as if
Wes Biggs [EMAIL PROTECTED] writes:
With a little gentle prodding by Nic Ferrier, I've implemented the
java.util.regex package as a facade of gnu.regexp.
That's great!
Any thoughts on getting this into classpath, logistics-wise? I would
like to continue to maintain gnu.regexp
20 matches
Mail list logo
