public inbox for kawa@sourceware.org
 help / color / mirror / Atom feed
* kawa binary snapshot
@ 2016-06-06 16:04 Per Bothner
  2016-06-06 20:44 ` Jamison Hope
  2016-06-18 16:29 ` kawa binary snapshot with domterm-based console Per Bothner
  0 siblings, 2 replies; 4+ messages in thread
From: Per Bothner @ 2016-06-06 16:04 UTC (permalink / raw)
  To: Kawa mailing list

I'm switching to a new "more complete" style of binary releases for Kawa.
Please check out:
     ftp://ftp.gnu.org/pub/gnu/kawa/kawa-2.1.9-20160605.zip

Later, we could perhaps set up automatically-generated binary snapshots.

This bundles not only the kawa .jar file, but also a shell script
(bin/kawa) or Windows batch file (bin/kawa.bat), along with version 3
of the jline input library.  This should be fairly portable.
The jline input editing doesn't seem to work on Windows (I need to
research how to fix this), but it works fine on Fedora and probably
most GNU/Linux distributions. Reports on how it works on *BSD and MacOS
would be helpful.

Using jline3 has a number of advantages:  In contrast to GNU readline,
it doesn't require compiling a C program, which makes it easier to
distribute binaries.  It supports command completion.   (Well, so does GNU
readline, but it's more complicated to write, especially if we want to
avoid subjecting Kawa to the GPL.)

The multi-line input editing is neat: While writing a continuation line,
you can go back and edit an earlier line in the multi-line command.
A continuation line is when you hit enter when more input is required
(such as inside parenthesis), or if you explicitly type Esc Enter or Ctrl-Q Ctrl-J.
Multi-line commands are stored as a single entry in the history.

More REPL improvements are planned.
-- 
	--Per Bothner
per@bothner.com   http://per.bothner.com/

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: kawa binary snapshot
  2016-06-06 16:04 kawa binary snapshot Per Bothner
@ 2016-06-06 20:44 ` Jamison Hope
  2016-06-18 17:26   ` Per Bothner
  2016-06-18 16:29 ` kawa binary snapshot with domterm-based console Per Bothner
  1 sibling, 1 reply; 4+ messages in thread
From: Jamison Hope @ 2016-06-06 20:44 UTC (permalink / raw)
  To: kawa list

On Jun 6, 2016, at 12:03 PM, Per Bothner <per@bothner.com> wrote:

> I'm switching to a new "more complete" style of binary releases for Kawa.
> Please check out:
>    ftp://ftp.gnu.org/pub/gnu/kawa/kawa-2.1.9-20160605.zip
> 
> Later, we could perhaps set up automatically-generated binary snapshots.
> 
> This bundles not only the kawa .jar file, but also a shell script
> (bin/kawa) or Windows batch file (bin/kawa.bat), along with version 3
> of the jline input library.  This should be fairly portable.
> The jline input editing doesn't seem to work on Windows (I need to
> research how to fix this), but it works fine on Fedora and probably
> most GNU/Linux distributions. Reports on how it works on *BSD and MacOS
> would be helpful.

It seems to work fine on Mac OS X, as long as I run under Java 8.
I get an UnsupportedClassVersionError if I try to use Java 7.

(Also, the path to servlet.jar in the script is not very portable, but
this doesn't affect ordinary non-server usage.)

> Using jline3 has a number of advantages:  In contrast to GNU readline,
> it doesn't require compiling a C program, which makes it easier to
> distribute binaries.  It supports command completion.   (Well, so does GNU
> readline, but it's more complicated to write, especially if we want to
> avoid subjecting Kawa to the GPL.)

I usually just use rlwrap, as in

alias kawa='rlwrap -q\" java kawa.repl'

which avoids the compilation / linking-to-readline issue.

> The multi-line input editing is neat: While writing a continuation line,
> you can go back and edit an earlier line in the multi-line command.
> A continuation line is when you hit enter when more input is required
> (such as inside parenthesis), or if you explicitly type Esc Enter or Ctrl-Q Ctrl-J.
> Multi-line commands are stored as a single entry in the history.

Yeah that is neat, and is something that rlwrap can't match (since it
just dumbly wraps I/O to java without knowing anything of parenthesis
matching).

> More REPL improvements are planned.

Are the prompt colors going to be customizable?  I usually do
white-on-black, so the JLine prompt ends up being white on light green,
which is hard to read.


--
Jamison Hope
The PTR Group
www.theptrgroup.com



^ permalink raw reply	[flat|nested] 4+ messages in thread

* kawa binary snapshot with domterm-based console
  2016-06-06 16:04 kawa binary snapshot Per Bothner
  2016-06-06 20:44 ` Jamison Hope
@ 2016-06-18 16:29 ` Per Bothner
  1 sibling, 0 replies; 4+ messages in thread
From: Per Bothner @ 2016-06-18 16:29 UTC (permalink / raw)
  To: kawa

The latest Kawa snapshot:
   ftp://ftp.gnu.org/pub/gnu/kawa/kawa-2.1.9-20160618.zip
supports a completely new console (REPL) window (as started by -w).

Before, when you created a new REPL window using -w (or no arguments
in an environment with no Console) Kawa would create a Swing-based REPL:
   http://per.bothner.com/blog/2007/ReplPane/
This Swing-based REPL is no longer the default.  Instead, Kawa uses
DomTerm (http://domterm.org/) running in a JavaFX WebView.

One advantage of DomTerm over the Swing console is that it is compatible
with JLine3 (as mentioned in my 06/06 message), so you get Line3's
multi-line editing. history, tab-completion etc.  You can disable JLine3 with
the command-line flag console:use-jline=no, in which case you get DomTerm's
builtin line-editing (based on WebKit's contenteditable support), which
includes basic history support (up/down-arrow but no history search).

The DomTerm+JLine3 combination works out-of-the-box on Windows, using
the binary snapshot.

Another big advantage of DomTerm is you can "print" HTML expressions,
including images and SVG.  See the http://domterm.org for some examples.
For example to print a cat image:

#|kawa:1|# #<img src="http://pics.bothner.com/2013/Cats/06t.jpg"/>

You can also control the appearance of the DomTerm window using a
CSS stylesheet.  The new domterm-load-stylesheet procedure takes a literal
stylesheet (and an optional name, defaulting to "kawa") and loads it.
For example:

#|kawa:2|#  (domterm-load-stylesheet "div.domterm { background-color: yellow }")
   
To load from a stylesheet file use the '&<' load-whole-file syntax:

(domterm-load-stylesheet &<{foo.css})
or:
(domterm-load-stylesheet &<[filename-expression])

The Swing console is still available, if you specific the command-line
flag console:use-domterm=no or if DomTerm fails to load (if JavaFX
or the domterm.jar are missing).

I've also implemented interrupt handing: If you have an infinite loop,
you can interrupt it with ctrl-c (at least on my Fedora Linux system).
(When jline is enabled, asit is by default, there are glitches in
ctrl-c handling that I haven't worked out yet.)

-- 
	--Per Bothner
per@bothner.com   http://per.bothner.com/

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: kawa binary snapshot
  2016-06-06 20:44 ` Jamison Hope
@ 2016-06-18 17:26   ` Per Bothner
  0 siblings, 0 replies; 4+ messages in thread
From: Per Bothner @ 2016-06-18 17:26 UTC (permalink / raw)
  To: kawa

On 06/06/2016 01:44 PM, Jamison Hope wrote:
> It seems to work fine on Mac OS X, as long as I run under Java 8.
> I get an UnsupportedClassVersionError if I try to use Java 7.

Yes, the JLine3 implementation has some Java 8 dependencies.

I re-build (and re-uploaded) kawa-2.1.9-20160618.zip built with
-source 7 -target 7, so Kawa will run under Java 7, though you
won't get the jline (or domterm) support.

> (Also, the path to servlet.jar in the script is not very portable, but
> this doesn't affect ordinary non-server usage.)

I fixed that.

> Yeah that is neat, and is something that rlwrap can't match (since it
> just dumbly wraps I/O to java without knowing anything of parenthesis
> matching).

Also, tab-completion would be difficult with rlwrap (or the old
kawa-frontend).

> Are the prompt colors going to be customizable?  I usually do
> white-on-black, so the JLine prompt ends up being white on light green,
> which is hard to read.

Yes.  I expect I will remove the default prompt coloring when using jline,
though for now I checked it to green foreground, rather than green background.
I do plan to keep some default prompt color when using domterm, but that
is customizable with css:

(domterm-load-stylesheet "span[std='prompt'] {color: blue; background-color: pink }")

(This does not yet work when using jline+domterm, because there isn't
yet a way for jline to pass the correct escape codes to domterm.)
-- 
	--Per Bothner
per@bothner.com   http://per.bothner.com/

^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2016-06-18 17:26 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2016-06-06 16:04 kawa binary snapshot Per Bothner
2016-06-06 20:44 ` Jamison Hope
2016-06-18 17:26   ` Per Bothner
2016-06-18 16:29 ` kawa binary snapshot with domterm-based console Per Bothner

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).