You can subscribe to this list here.
2002 |
Jan
|
Feb
|
Mar
|
Apr
(4) |
May
(7) |
Jun
(1) |
Jul
(4) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
---|---|---|---|---|---|---|---|---|---|---|---|---|
2003 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(6) |
Jul
(8) |
Aug
(4) |
Sep
|
Oct
|
Nov
|
Dec
(1) |
2004 |
Jan
(1) |
Feb
|
Mar
|
Apr
(3) |
May
(1) |
Jun
(1) |
Jul
|
Aug
|
Sep
(2) |
Oct
|
Nov
|
Dec
|
2007 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(1) |
Sep
|
Oct
|
Nov
|
Dec
|
2015 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(1) |
Sep
|
Oct
|
Nov
|
Dec
|
2017 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(2) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
From: Andrew C. <and...@gm...> - 2017-06-28 07:50:51
|
Unfortunately, I broke using org.gnu.readline.ReadlineCompleter with java-readline in my last release. Sorry about that. I've fixed it up for now[1] and added an initial test case for it. Andrew [1]: https://github.com/aclemons/java-readline/releases/tag/v0.8.2 |
From: Andrew C. <and...@gm...> - 2017-06-24 21:15:14
|
With Bernhard's approval, I have taken over maintenance of java-readline. The source code has been migrated from the SourceForge CVS repository to git[1]. This first release[2] includes Bernhard's unreleased changes for supporting getVar/setVar. Additionally, there were various fixes to get the build tidied up, but the main change for this release is unicode support. java-readline should no longer mangle non-ascii characters. I have added a bats test case for this and hope to continue expanding test coverage for future releases. Bug reports and pull reports are most welcome. Andrew [1]: https://github.com/aclemons/java-readline [2]: https://github.com/aclemons/java-readline/releases/tag/v0.8.1 |
From: Bengt M. <bu...@be...> - 2015-08-12 06:24:18
|
Hi, Just wanted to announce that I have "forked" java-readline (version sourceforge CVS) and converted it to used Maven. I also did *some* modifications to the Makefiles for building the shared library, but the "right thing" would probably be to invoke the Gnu autotools. https://github.com/bengtmartensson/java-readline.git This is not a "release", neither do I have any (immediate) plans to create one either. Greetz, Bengt |
From: Bernhard B. <ma...@ba...> - 2004-09-12 09:13:17
|
Thanks Sven, I will update the project as soon as I find time (it will take a few weeks though) Bernhard > Hi, > > on newer linux-distros, termcap has been replaced by ncurses. Even > /usr/include/termcap.h is provided by the ncurses package. Your makefile > (at least version 0.8.0) still links against termcap. I wrote a simple > patch for the make file so that libreadline links against ncurses > instead of termcap. You may introduce some documented variables, so that > the user can decide wether to choose ncurses or termcap. > > The patch is here: > http://bugs.gentoo.org/show_bug.cgi?id=63129 > > It simply replaces "-ltermcap" by "-lncurses" - "make test" still works! > > In addition i noticed, that you didn't specify source- and > target-version for javac. Failure to do so might cause you troubles in > the future, since default source- and target-version of JDK1.5 aren't > that backword-compatible anymore, they are 1.5 by default know (as far > as i know). You should introduce variables for that in your Makefile. > > Thx > Sven > > > > ------------------------------------------------------- > This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170 > Project Admins to receive an Apple iPod Mini FREE for your judgement on > who ports your project to Linux PPC the best. Sponsored by IBM. > Deadline: Sept. 13. Go here: http://sf.net/ppc_contest.php > _______________________________________________ > Java-readline-devel mailing list > Jav...@li... > https://lists.sourceforge.net/lists/listinfo/java-readline-devel |
From: <sko...@up...> - 2004-09-12 02:35:31
|
Hi, on newer linux-distros, termcap has been replaced by ncurses. Even /usr/include/termcap.h is provided by the ncurses package. Your makefile (at least version 0.8.0) still links against termcap. I wrote a simple patch for the make file so that libreadline links against ncurses instead of termcap. You may introduce some documented variables, so that the user can decide wether to choose ncurses or termcap. The patch is here: http://bugs.gentoo.org/show_bug.cgi?id=63129 It simply replaces "-ltermcap" by "-lncurses" - "make test" still works! In addition i noticed, that you didn't specify source- and target-version for javac. Failure to do so might cause you troubles in the future, since default source- and target-version of JDK1.5 aren't that backword-compatible anymore, they are 1.5 by default know (as far as i know). You should introduce variables for that in your Makefile. Thx Sven |
From: Bernhard B. <ma...@ba...> - 2004-06-06 10:55:49
|
Hi David, it seems to be impossible that a non-cygwin win32-binary (in this case java.exe) can load a cygwin-dll. There are numerous threads on this issue on the cygwin mailing-list. I managed to compile, but as soon as it loads, it barfs. If you want to put some work into it: there is a pure Java implementation of readline called jline (I don't have the link right now, but I think it is on Sourceforge). It should probably be only a matter of a wrapper class to use jline as a backing library for JavaReadline. I will certainly don't have any time to work on this issue before automn. The getline.dll was compiled with a native C compiler. You might try to download the MS-compiler (I read that it is freely available, the IDE not included) and try to compile it. Please tell me about any results. Thanks, Bernhard > Bernhard, > > I'm hoping you can point me to in the right direction. I'm very > interested in getting JavaReadline working on win32. However, using > Cygwin to compile JRL 0.8.0 against Readline 4.2 doesn't seem to work. > Actually, I've tried numerous combinations of MinGW's Win32 Readline > Port 4.1 -> 4.2 and your JRL 0.7.2 -> 0.8.0. > > What I'm wondering is there any known combination of JavaReadline > working against any known port of GNU Readline for win32? If so, can > you let me know where to acquire it? If there isn't, then do you know > if anyone has gotten Getline to work with Windows XP? The dll provided > in the contrib dir doesn't work in WinXP and I also was unsuccessful in > getting Getline to compile on Cygwin/WinXP. > > Thanks in advance for your help. I've been using your library on Linux > for the past year. Thanks bringing a great component to the Java > community! ;-) > > Regards, > Dave > > --------------------------------- > David Esmond > Dorado Corporation > desk: 650-227-7413 > mobile: 415-215-5454 > yim/aim: twopisquared |
From: Bernhard B. <ma...@ba...> - 2004-05-16 13:31:17
|
Hi, you seem to be using the getline backing library. It is an open problem that this lib segfaults, but I still have no idea why. Under RedHat, I recommend to use the readline backing-library. Bernhard > [user@host libreadline-java-0.8.0]$ LD_LIBRARY_PATH=`pwd` java -jar \ > libreadline-java.jar > > When I press F1 the program segfaults (also F2 F3 and F4). > > (F1 = ^[OP) > > F5 prints: ~ > F6 prints: ~ > F7 prints: Function key F7 > F8 prints: Function key F8 > F9-F12 prints: ~ > > Redhat Linux 9, jdk 1.4.2 and jdk 1.5.0 > Terminal: xterm (running under Gnome) > > initializing Readline... > ... done > linux> An irrecoverable stack overflow has occurred. > > An unexpected exception has been detected in native code outside the VM. > Unexpected Signal : 11 occurred at PC=0x4CE11793 > Function=_rl_dispatch_subseq+0x3 > Library=/usr/lib/libreadline.so.4 > > Current Java thread: > at org.gnu.readline.Readline.readlineImpl(Native Method) > at org.gnu.readline.Readline.readline(Readline.java:215) > at org.gnu.readline.Readline.readline(Readline.java:191) > at test.ReadlineTest.main(ReadlineTest.java:108) > > The error seems to be triggered in function getline (getline.c) > I don't know enough C to investigate further. > > -- > Trond Aasan > <http://www.aasan.org/> > > In my wee world Bill Gates cheats at cards, steals candy from children and > pees on the toilet seat. |
From: Ben B. <ba...@de...> - 2004-04-14 01:52:45
|
> ps: I included below the results of attempting to compile after changing > #include <editline/readline.h> to #include <editline/editline.h> On further investigation: There is also a libeditline by Simmule Turner and Rich Salz which is AIUI completely different from libedit. It might be that you're using this other libeditline instead (not libedit). Ben. |
From: Ben B. <ba...@de...> - 2004-04-14 01:49:38
|
Hi. The version of the debian packages for libedit is 2.6.cvs.20020109-7. According to the debian copyright file: Upstream Author: NetBSD Foundation It was originally checked out from NetBSD CVS on 2001-08-21. (CVSROOT :pserver:an...@an...:/pub/NetBSD-CVS) The latest checkout seems to have been on 9 Jan 2002. Hope this helps, Ben. |
From: Bernhard B. <ma...@ba...> - 2004-04-13 18:43:31
|
Hi Ben, could you help? Since I don't use Debian, I also never succeded in compiling against libedit. Thanks, Bernhard ---------- ---------- Subject: Java Readline and libedit Date: Montag, 12. April 2004 20:26 From: Rob Wygand <ro...@wy...> To: ma...@ba... Hi Bernhard, I have been attempting to get your Java Readline compiled against editline/libedit 1.11, but there are issues: namely, there is no editline/readline.h. Also, many functions that Java Readline attempts to export to java simply don't exist that version of libedit. I was just curious what version of libedit you did use for compilation / testing. Thanks! rjw ps: I included below the results of attempting to compile after changing #include <editline/readline.h> to #include <editline/editline.h> make[3]: Entering directory `/home/rjw/hcsh/src/libreadline-java-0.8.0/src/native' javah -classpath ../../build -jni org.gnu.readline.Readline touch org_gnu_readline_Readline.h gcc -I /opt/j2sdk_nb/j2sdk1.4.2/include -I /opt/j2sdk_nb/j2sdk1.4.2/include/linux -fPIC -DPOSIX -DJavaEditline \ -c org_gnu_readline_Readline.c org_gnu_readline_Readline.c: In function `Java_org_gnu_readline_Readline_initReadlineImpl': org_gnu_readline_Readline.c:93: `rl_readline_name' undeclared (first use in this function) org_gnu_readline_Readline.c:93: (Each undeclared identifier is reported only once org_gnu_readline_Readline.c:93: for each function it appears in.) org_gnu_readline_Readline.c: In function `Java_org_gnu_readline_Readline_readlineImpl': org_gnu_readline_Readline.c:189: warning: assignment makes pointer from integer without a cast org_gnu_readline_Readline.c: In function `Java_org_gnu_readline_Readline_getHistoryImpl': org_gnu_readline_Readline.c:217: `HIST_ENTRY' undeclared (first use in this function) org_gnu_readline_Readline.c:217: `histSingle' undeclared (first use in this function) org_gnu_readline_Readline.c:236: `history_length' undeclared (first use in this function) org_gnu_readline_Readline.c: In function `Java_org_gnu_readline_Readline_getHistoryLineImpl': org_gnu_readline_Readline.c:264: `HIST_ENTRY' undeclared (first use in this function) org_gnu_readline_Readline.c:264: `hist' undeclared (first use in this function) org_gnu_readline_Readline.c: In function `Java_org_gnu_readline_Readline_getHistorySizeImpl': org_gnu_readline_Readline.c:281: `history_length' undeclared (first use in this function) org_gnu_readline_Readline.c: In function `Java_org_gnu_readline_Readline_setCompleterImpl': org_gnu_readline_Readline.c:472: `rl_completion_entry_function' undeclared (first use in this function) org_gnu_readline_Readline.c:476: `CPFunction' undeclared (first use in this function) org_gnu_readline_Readline.c:476: parse error before ')' token org_gnu_readline_Readline.c: In function `Java_org_gnu_readline_Readline_getLineBufferImpl': org_gnu_readline_Readline.c:496: `rl_line_buffer' undeclared (first use in this function) org_gnu_readline_Readline.c: In function `Java_org_gnu_readline_Readline_getWordBreakCharactersImpl': org_gnu_readline_Readline.c:511: `rl_completer_word_break_characters' undeclared (first use in this function) org_gnu_readline_Readline.c:513: `rl_basic_word_break_characters' undeclared (first use in this function) org_gnu_readline_Readline.c: In function `Java_org_gnu_readline_Readline_setWordBreakCharactersImpl': org_gnu_readline_Readline.c:558: `rl_completer_word_break_characters' undeclared (first use in this function) make[3]: *** [org_gnu_readline_Readline.o] Error 1 make[3]: Leaving directory `/home/rjw/hcsh/src/libreadline-java-0.8.0/src/native' make[2]: *** [JavaEditline] Error 2 make[2]: Leaving directory `/home/rjw/hcsh/src/libreadline-java-0.8.0/src/native' make[1]: *** [native] Error 2 make[1]: Leaving directory `/home/rjw/hcsh/src/libreadline-java-0.8.0/src' make: *** [build-native] Error 2 ------------------------------------------------------- |
From: Bernhard B. <ma...@ba...> - 2004-01-06 16:18:18
|
Hi Alan, I just uploaded the modified makefiles to cvs - you might want to have a try, since I modified them extensively (now there is a var OS_FLAVOR like you suggested: running "make world OS_FLAVOR=MAC" should do it). Please let me know if you find some time to test it. As soon as I fix the remaining problem with Getline, I will prepare a new release. Thanks, Bernhard > Hi, > > The attached tar.gz contains: > > * libreadline-java-0.8.0/Makefile > - Changed PREFIX to /usr/local > - Changed location of Java & JNI header files. > > * libreadline-java-0.8.0/src/native/Makefile. > - Changed location of TERMCAP & GNUReadline headers & libs. > - Changed .so extension to .jnilib (only Apple knows why they name it > this way:-) > - Changed the link flags for Apple. > > i've marked the areas i've fiddled in with '# arp'. > > A few potential gotchas: > - According to Apple's docs, *.jnilib must either live in > /Library/Java/Extensions (available system wide for all users), > ~/Library/Java/Extension (available only for that user) or pointed to > be DYLD_LIBRARY_PATH. i only tested the second option so can't make any > guarantees as to the accuracy of Apple's docs :-( > > - i've only tried this is using GNU readline as the underlying readline > code. > > BTW, it might be worthwhile defining a platform variable in the > makefiles (.e.g. PLATFORM=linux) rather than using various > platform-specific vars (MSC, cygwin, etc.)? |
From: Bernhard B. <ma...@ba...> - 2003-12-07 20:17:30
|
Hi Alan, yes, please send me your contributions. I will try to include them in the official distribution. Thanks, Bernhard > Hi, > > Thanks for java-readline: very useful! i've used GNU readline in C/C++ > programs and was hankering for something similar for Java. > > i recently (yesterday) downloaded & built java-readline on Mac OSX > (10.3). The only modifications i had to do were to two of the Makefiles > (the main one & one in src/native). Initial tests indicate java > readline works when using ReadlineLibrary.GnuReadline and doesn't work > (gobbles up CPU time in Readline.readline()) when using > ReadlineLibrary.EditLine: i haven't tried to find the cause of this > problem yet. > > Would you like my modified Makefiles to review & perhaps incorporate > into your official Makefiles? > > Thanks > alan |
From: Bernhard B. <ma...@ba...> - 2003-08-22 04:22:18
|
Hi, I have commited changes to Makefile, src/native/Makefile and org_gnu_readline_Readline.c to support win32, especially cygwin. Best thing is to checkout a complete set of sources, since there have been a number of changes to the sources recently. To build under NT, type: make build-java build-native WIN32=CYGWIN make test WIN32=CYGWIN or in case you have a MS C-Compiler make build-java build-native WIN32=MSC make test WIN32=MSC Current status is: both JavaReadline and JavaGetline compile, link and load using cygwin, but as soon as a native method is called, java exists without further comments. I will investigate this in the next few days. The MSC-build only works with Getline, and there are no problems. Also JavaGetline compiles, links and loads under Linux, but using it produces a SIGSEGV (rather strange, since the relevant code has not changed recently, and it did already work :-() Bernhard > Great! Meanwhile I got nowhere with the Intel compiler because it > requires not just the MS SDK but bits of the MS compiler as well. > Quite stupid from a commercial point of view, I would say. > > -- O.L. |
From: Bernhard B. <ma...@ba...> - 2003-08-17 17:02:42
|
Hi, the very last lines of org_gnu_readline_Readline.c read: #ifdef WIN32 int WINAPI readline_init(HANDLE h, DWORD reason, void *foo) { return 1; } #endif These define a necessary function for DLLs. This might be the reason why loading of the DLL failes (the log does not show if you defined WIN32). But don't set it to CYGWIN or cygwin, or else the makefiles work different (it seems that cygwin does not need all the stuff anymore in src/native/Makefile). Maybe you could describe your cygwin-environment, because I never got that far and I wan't to reproduce it if possible. Bernhard > Hi again, > > I almost got there but I get the following exception when trying > to run test.ReadlineTest: > > Exception in thread "main" java.lang.UnsatisfiedLinkError: > C:\cygwin\lib\JavaReadline.dll: Invalid access to memory location > at java.lang.ClassLoader$NativeLibrary.load(Native Method) > at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1560) > at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1485) > at java.lang.Runtime.loadLibrary0(Runtime.java:788) > at java.lang.System.loadLibrary(System.java:834) > at org.gnu.readline.Readline.load(Readline.java:133) > at test.ReadlineTest.main(ReadlineTest.java:62) > > It looks like there is something bad with the DLL built by your > Makefile. Do you have any idea what it could be? I have attached > the make log. > > Thanks a lot if you can help, > > Olivier Lefevre |
From: Ben B. <ba...@de...> - 2003-08-16 19:51:09
|
> I have just commited some changes to implement the getVar()/setVar() methods. Wonderful! > Maybe you could have a look at the code and comment on it. If you find the > implementation ok, you should also fill in the editline-stuff (readline only > has 45 internal variables ;-): in the C-code you just have to fill the array > of internal variables, in Readline.java you have to add the > Editline-library-constant to all supported constants. Rightio. I might be a week or so - we just landed in Wisconsin for the informatics olympiad, and I'll be here until August 25 with what might or might not be restricted net access. Ben. :) PS: If you could change my email address to ba...@de... in your address book, that would be great - the acm.org address will probably not last much longer. |
From: Bernhard B. <ma...@ba...> - 2003-08-15 10:21:50
|
Hi Ben, I have just commited some changes to implement the getVar()/setVar() methods. Currently, the methods only support Gnu-Readline. Maybe you could have a look at the code and comment on it. If you find the implementation ok, you should also fill in the editline-stuff (readline only has 45 internal variables ;-): in the C-code you just have to fill the array of internal variables, in Readline.java you have to add the Editline-library-constant to all supported constants. Bernhard |
From: Bernhard B. <ma...@ba...> - 2003-07-23 19:47:13
|
Hi, I just commited some changes to implement the java-side of the getVar() / setVar()-stuff. It is not complete in the sense that all constants are defined (in fact, only one is), but it should give an idea of the design. The native-C side will follow soon. If you have any comments, questions and or suggestions, please let me know. Thanks, Bernhard |
From: Bernhard B. <ma...@ba...> - 2003-07-18 18:01:51
|
> For the time being, I would like to keep them separate, for a couple > reasons: > Ok, let's stick with the adapter. > In any case, I am happy to have JLine (w/ the adapter) also bundled > into the java-readline libraries so people do not have to download two > separate sets of libraries in order to get the functionality. That will be the best solution. > I'm probably going to be too busy with work for the new couple weeks to > do much work on it, so if you want to work on the adaptor, then feel > free to jump right in. Otherwise, I'll let you know when I'm able to > work something out. I imagine it will only take a few hours to get > something working. I'm also busy, but more because of the fine weather ;-) Before starting, I will ask you again to prevent duplication of work. Bernhard |
From: Marc Prud'h. <ma...@ap...> - 2003-07-17 01:35:59
|
Bernhard- > I think jline is very good work. IMHO there are two options: > > - we merge our projects > - we write a java-readline wrapper to jline > > I would prefer the first solution, since the second one is more > cumbersome for > developers and users: they have to download two libraries to compile > and use > java-readline. > > Maybe we could setup jline as a subproject of the merger (name to be > found) so > it could be built and used seperately if necessary. > > Which option do you prefer? For the time being, I would like to keep them separate, for a couple reasons: 1. I want to be able to make quick architectural changes without having to worry about projects that are relying on various libraries to keep them stable, and 2. There is some additional functionality that I need to have for other projects in JLine (like the fairly sophisticated ArgumentCompletor and other completor stuff), and I think that introducing that into java-readline might convolute the API (since there would be features that would only be available for a single implementation). 3. JLine is still a little flaky, and doesn't really work on Windows at all yet. So I think that an adapter for java-readline would be the way to go. It would be nice if java-readline used a "pluggable" system, that maybe uses the java services framework for automatic discovery of java-readline implementations. However, writing a quick little adaptor would probably be quite easy. In any case, I am happy to have JLine (w/ the adapter) also bundled into the java-readline libraries so people do not have to download two separate sets of libraries in order to get the functionality. I'm probably going to be too busy with work for the new couple weeks to do much work on it, so if you want to work on the adaptor, then feel free to jump right in. Otherwise, I'll let you know when I'm able to work something out. I imagine it will only take a few hours to get something working. -Marc On Saturday, July 12, 2003, at 09:23 AM, Bernhard Bablok wrote: > >> Bernhard- >> >>> this sounds great - I thought it could not be possible. I will have a >>> look at >>> it this weekend. >> >> Excellent. Let me know what you think. > > Hi Marc, > > I think jline is very good work. IMHO there are two options: > > - we merge our projects > - we write a java-readline wrapper to jline > > I would prefer the first solution, since the second one is more > cumbersome for > developers and users: they have to download two libraries to compile > and use > java-readline. > > Maybe we could setup jline as a subproject of the merger (name to be > found) so > it could be built and used seperately if necessary. > > Which option do you prefer? > > Bernhard > > > -- Marc Prud'hommeaux ma...@so... SolarMetric Inc. http://www.solarmetric.com |
From: Bernhard B. <ma...@ba...> - 2003-07-12 14:08:34
|
> Bernhard- > > > this sounds great - I thought it could not be possible. I will have a > > look at > > it this weekend. > > Excellent. Let me know what you think. Hi Marc, I think jline is very good work. IMHO there are two options: - we merge our projects - we write a java-readline wrapper to jline I would prefer the first solution, since the second one is more cumbersome for developers and users: they have to download two libraries to compile and use java-readline. Maybe we could setup jline as a subproject of the merger (name to be found) so it could be built and used seperately if necessary. Which option do you prefer? Bernhard |
From: Bernhard B. <ma...@ba...> - 2003-07-12 14:08:31
|
Hello Rune, I think I will add a new public method setLibrary(). Could you contribute y= our=20 code for extracting and loading the native library from the jar file? We=20 could then put getline.so and getline.dll into the jar and extract and use = it=20 as the default fallback solution. Bernhard > Hello, > > I have a request for an enhancement to the java-readline library. > > Readline.iLib is a private variable. The only way to set it, is > through Readline.load, which attempts to load the file through > System.loadLibrary(). > > This does not work if the location of the so file is not known prior > to starting of the java program (in my case, it is a jar file), and > java isn't to happy about honoring a > System.setProperty("java.library.path", path). However, there is also > System.load(), which accepts a filename as argument, thus one could, > after determining os, extract the relevant so file to a temp directory > and load it from there. > > It would therefore be great if you could either add a test to > Readline.load() to check if the library is already loaded (I've been > unable to find out how to do this), or simply add a new public method > setIlib(). > > Regards, > Rune Fr=F8ysa |
From: Marc Prud'h. <ma...@ap...> - 2003-07-10 19:09:47
|
Bernhard- > this sounds great - I thought it could not be possible. I will have a > look at > it this weekend. Excellent. Let me know what you think. Note that it currently has a lot of problems on Windows ... I hope to be able to get it work on that platform in the near future. > If in any way possible, it would be great if we could > integrate it into java-readline (users already have asked for a native > implementation). Sure. It's LGPL, so you are certainly free to do anything you like with it. > > Thanks, Bernhard > >> Bernhard- >> >> I just release a new version of my JLine library at >> http://jline.sf.net. It is a pure-java implementation of GNU readline. >> It works pretty well (it has command history, tab completion, and line >> editing), but it is not as stable/robust as the native libraries, and >> currently works only on UNIX platforms. >> >> Looking at the source code for java-readline, it looks like it might >> be >> possible to write an adaptor to have it act as one of the >> implementations that java-readline can use. This would be a good >> intermediate between not having readline/editline support on the >> platform (either because it is too difficult to build, or if you do >> not >> want your users to have to install extra software) and the pain that >> is >> a pure-java System.in console utility. >> >> FYI, I initially wrote this because I couldn't get the java-readline >> native binaries to build on Mac OS 10.2, and I wanted something that >> would work with another one of my projects (http://sqlline.sf.net). >> >> Let me know if you would be interested in working together on this. >> >> Sincerely, >> >> -Marc > > -- Marc Prud'hommeaux ma...@so... SolarMetric Inc. http://www.solarmetric.com |
From: Bernhard B. <ma...@ba...> - 2003-07-10 18:53:10
|
Hi Marc, this sounds great - I thought it could not be possible. I will have a look at it this weekend. If in any way possible, it would be great if we could integrate it into java-readline (users already have asked for a native implementation). Thanks, Bernhard > Bernhard- > > I just release a new version of my JLine library at > http://jline.sf.net. It is a pure-java implementation of GNU readline. > It works pretty well (it has command history, tab completion, and line > editing), but it is not as stable/robust as the native libraries, and > currently works only on UNIX platforms. > > Looking at the source code for java-readline, it looks like it might be > possible to write an adaptor to have it act as one of the > implementations that java-readline can use. This would be a good > intermediate between not having readline/editline support on the > platform (either because it is too difficult to build, or if you do not > want your users to have to install extra software) and the pain that is > a pure-java System.in console utility. > > FYI, I initially wrote this because I couldn't get the java-readline > native binaries to build on Mac OS 10.2, and I wanted something that > would work with another one of my projects (http://sqlline.sf.net). > > Let me know if you would be interested in working together on this. > > Sincerely, > > -Marc |
From: Robert A. <ra...@pp...> - 2003-07-01 23:19:14
|
I have had problems with using the gnu readline with jython under linux systems. It would work fine except when the window was resized and then everything would hang and I would have to exit with Control-C causing a JavaVM panic in native code type of exit. This is with various linux distributions though all of them were gcc 2.9X based. Because of this problem and the distribution incompatibility of gnu readline with jython, I tried getline. The compile went ok but testing and usage revealed the arrow keys would print out 'A','D',... This was under KDE Konsole terminal. From experimentation and debugging if I made the following changes, modified src/native/Makefile: add unix symbol CFLAGS=-fPIC -DPOSIX -Dunix CC = gcc -g modified src/native/getline.c: add c=='O' option case '\033': /* ansi arrow keys */ c = gl_getc(); if (c == '['||c=='O') { then it worked fine. I am not too familiar with unix terminal i/o. Do these seem like reasonable changes for getline or any hint as to what might be going on? thanks, rob andre |
From: Bernhard B. <ma...@ba...> - 2003-06-27 16:46:40
|
Ok, your points are correct. I was more thinking about the implementation of the native code, which is easier with standard types. There you have to map every constant to a readline/editline variable, which should be quite simple with a lookup-table. The numeric constant (resp. the string constant after a atoi-conversion) would just be an index into an array. Bernhard > > void setVar(int which_variable, int value); > > void setVar(String which_variable, String value); > > int getVar(int which_variable); > > String getVar(String which_variable); > > Using setVar() and getVar() works for me. Using string constants for > variable names does seem a little unclean though, simply because string > comparisons aren't as clean as integer or pointer comparisons. > > The suggestion of IntVar and StrVar was for cleanness and consistency. > If you're using strings then you either compare with String.equalTo() > which is inconsistent with integer comparison, or you compare with == > in which case you're doing pointer comparisons and you might as well not > assign values to the strings at all. > > Using IntVar and StrVar also avoids problems of implicit conversion if > (for instance) we later add character variables or whatever; you can > implicitly convert (char which_variable) to (int which_variable) but not > (CharVar which_variable) to (IntVar which_variable), which means it's a > little safer in the long run. > > The user of course doesn't even need to know that the IntVar and StrVar > classes exist; they simply call getVar(INHIBIT_COMPLETION) or whatever. > > Anyway, it should be relatively straightforward to change from one > implementation to the other, without affecting the use of the library at > all. > > b. |