Re: java.util.regex, gnu.regexp, ... How about oniguruma?
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, > > so I really hope this doesn't mean that you discontinue your excellent > > (and *much* appreciated) work on gnu.regexp. > > My opinion. :-) Yes, of course. A pure Java implementaton comes first, and it should be used by default. For now, until some nice alternative appears, that is gnu.regexp. I do not see any nice alternative appearing, so I will continue to make efforts to improve gnu.regexp. JNI implementation will be for those who cannot be satisfied with the dafault. That is the way I am using java.nio.charset. I am not satisfied with the default gnu.java.nio.charset because it cannot handle Japanese charsets, so I use gnu.java.nio.charset.iconv.
RE: java.util.regex, gnu.regexp, ... How about oniguruma?
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 to try another thing. > > > > I have found oniguruma, the regex library which is used as a > > regex engine of Ruby, is pretty good. It already supports > > most part of java.util.regex.Pattern syntax. > > > > http://www.geocities.jp/kosako3/oniguruma/ > > > > I will write a JNI interface to oniguruma, and make it > > switchable with gnu.regexp. Users can select one of the > > supported regexp engines at their choice. > > 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, > so I really hope this doesn't mean that you discontinue your excellent > (and *much* appreciated) work on gnu.regexp. My opinion. :-) /Roman signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
RE: java.util.regex, gnu.regexp, ... How about oniguruma?
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 a > regex engine of Ruby, is pretty good. It already supports > most part of java.util.regex.Pattern syntax. > > http://www.geocities.jp/kosako3/oniguruma/ > > I will write a JNI interface to oniguruma, and make it > switchable with gnu.regexp. Users can select one of the > supported regexp engines at their choice. 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, so I really hope this doesn't mean that you discontinue your excellent (and *much* appreciated) work on gnu.regexp. Thanks, Jeroen
Re: java.util.regex
> It's been a while since I've popped my head in, it's good to see some > familiar names. Congratulations on the latest release! > > With a little gentle prodding by Nic Ferrier, I've implemented the > java.util.regex package as a facade of gnu.regexp. Currently it's only > a Java syntax facade -- the underlying engine assumes Perl-style, not > JDK 1.4-style, regular expressions. But for many (most?) cases it's > drop-in compatible already, and I've tested it with a number of examples. > > My goal is to implement the JDK 1.4 regular expression syntax in > gnu.regexp (gnu.regexp has a concept of predefined RESyntax objects), so > additional changes to the java.util.regex classes will be minimal. Cool! I used gnu.regexp in a proprietary project recently, it's really cool! > 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 no problem relicensing gnu.regexp > with the exception clause if that would make things easier. I like the bridge classes approach. That way we provide the 1.4 API while still being modular and not forcing the bloat on users. If people want to, they can still use gnu.regexp in a restricted environment. John Leuner ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: java.util.regex
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 as a separately releasable > project; I see the java.util.regex.* classes as bridge classes to its > API from Classpath. However, I have no problem relicensing gnu.regexp > with the exception clause if that would make things easier. At least one license of gnu.regexp would need to be the same as Classpath. Copyright assignment of gnu.regexp would be helpful although if you have a number of large contributors that you don't have good records for it might not be possible. The package can be treated as 3rd party, and we can track it in CVS as such or we can do as Nic suggested and perhaps try to include it symbolically. Brian -- Brian Jones <[EMAIL PROTECTED]> ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: java.util.regex
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 Classpath included > your source code (but it would still be maintained separately). That would work. I've been making slow progress on getting set up on Savannah (there's a project created, but I don't yet have CVS access working). > I think to do that you'd need to hand over (c) to the GNU project. As well as getting all past contributors to do so, I would presume, which might take some time. > Alternately Classpath could start to deliver jar files with the > distribution. I personally think we should make Aaron's getopt stuff > available with Classpath. I see gnu.regexp as something analogous to a RPM dependency, so that might be appropriate in the near term. > Embrace and extend. Now where have I heard that before..? :-) Wes P.S. Nic, did you ever find the javax.servlet.jsp.tagext classes? I received confirmation from FSF last week that they have my (c) assignment on file, so you should be able to add them to classpathx. ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: java.util.regex
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 no problem relicensing gnu.regexp > with the exception clause if that would make things easier. Well done for doing this Wes! Brian or Aaron will have some thoughts on how to integrate (if they want to!) but I think it's a pretty good idea.. 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 Classpath included your source code (but it would still be maintained separately). I think to do that you'd need to hand over (c) to the GNU project. Alternately Classpath could start to deliver jar files with the distribution. I personally think we should make Aaron's getopt stuff available with Classpath. Embrace and extend. Nic ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
