java-readline-devel — Developer mailing list

[Java-readline-devel] New Version 0.8.2

[Andrew C. <and...@gm...>]

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

[Java-readline-devel] New Version 0.8.1

[Andrew C. <and...@gm...>]

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

[Java-readline-devel] Git/Maven version of java-readline

[Bengt M. <bu...@be...>]

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

Re: [Java-readline-devel] termcap vs. readline

[Bernhard B. <ma...@ba...>]

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

[Java-readline-devel] termcap vs. readline

[<sko...@up...>]

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

[Java-readline-devel] Re: JavaReadline for win32

[Bernhard B. <ma...@ba...>]

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

[Java-readline-devel] Re: Segfault in libreadline-java

[Bernhard B. <ma...@ba...>]

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.

[Java-readline-devel] Re: Fwd: Java Readline and libedit

[Ben B. <ba...@de...>]

> 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.

[Java-readline-devel] Re: Fwd: Java Readline and libedit

[Ben B. <ba...@de...>]

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.

[Java-readline-devel] Fwd: Java Readline and libedit

[Bernhard B. <ma...@ba...>]

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

-------------------------------------------------------

[Java-readline-devel] Re: java-readline & Mac OSX

[Bernhard B. <ma...@ba...>]

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.)?

[Java-readline-devel] Re: java-readline & Mac OSX

[Bernhard B. <ma...@ba...>]

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

[Java-readline-devel] Re: Building Java readline on Cygwin

[Bernhard B. <ma...@ba...>]

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.

[Java-readline-devel] Re: Building Java readline on Cygwin

[Bernhard B. <ma...@ba...>]

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

[Java-readline-devel] Re: Working implementation for getVar() / setVar()

[Ben B. <ba...@de...>]

> 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.

[Java-readline-devel] Working implementation for getVar() / setVar()

[Bernhard B. <ma...@ba...>]

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

[Java-readline-devel] First java-implementation for getVar()/setVar()

[Bernhard B. <ma...@ba...>]

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

[Java-readline-devel] Re: java-readline and jline

[Bernhard B. <ma...@ba...>]

> 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

[Java-readline-devel] Re: java-readline and jline

[Marc Prud'h. <ma...@ap...>]

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

[Java-readline-devel] Re: java-readline and jline

[Bernhard B. <ma...@ba...>]

> 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

[Java-readline-devel] Re: Request: allow write access to Readline.iLib

[Bernhard B. <ma...@ba...>]

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

[Java-readline-devel] Re: java-readline and jline

[Marc Prud'h. <ma...@ap...>]

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

[Java-readline-devel] Re: java-readline and jline

[Bernhard B. <ma...@ba...>]

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

[Java-readline-devel] run on linux -- hung gnu readline, modified getline

[Robert A. <ra...@pp...>]

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

Re: [Java-readline-devel] Java-Readline and tab completion

[Bernhard B. <ma...@ba...>]

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.