GlkJNI: a new Glk implementation

Visto 2 veces
Saltar al primer mensaje no leído

Edward Mc

no leída,
9 jul 2009, 21:56:069/7/09
a
GlkJNI: a new Glk Implementation

GlkJNI is a C implementation of Glk which uses JNI (Java Native
Interface) to allow C Glk programs to use a Java frontend for I/O.
Right now, the only frontend is JDemoGlk, which is basically a Java
port of CheapGlk.

GlkJni and JDemoGlk live at http://code.google.com/p/glkjni

See the README file in the glkjni subdirectory of the source tarball
for build instructions; GlkJNI builds with GCC on Linux, Windows
(tested on Vista Home Basic with MinGW) and OSX (tested on 10.4 PPC).

A jar file for JDemoGlk can be downloaded from the GlkJNI home page;
the source and JavaDoc are included in the GlkJNI tarball.

I know this would be (possibly) more interesting if I had a more
sophisticated Java frontend; I am working on that. In the meantime,
all comments and questions are welcome.

-- Edward McCardell

Poster

no leída,
10 jul 2009, 0:04:2310/7/09
a
In article
<0d1504ed-2539-4f12...@k19g2000yqn.googlegroups.com>,
Edward Mc <edward.m...@gmail.com> wrote:

Ok, I've read through what GLK does and it's typically obtuse. Mind
breaking it down a bit what this does and where we can go with it?

--
Poster

www.intaligo.com I6 libraries, doom metal, Building
sturmdrangif.wordpress.com Game development blog / IF commentary
Seasons: fall '09 -- One-man projects are prone to delays.

Jesse McGrew

no leída,
10 jul 2009, 0:13:1510/7/09
a
On Jul 9, 9:04 pm, Poster <pos...@nospam.com> wrote:
> In article
> <0d1504ed-2539-4f12-b0a8-b4b9fcb04...@k19g2000yqn.googlegroups.com>,

>  Edward Mc <edward.mccard...@gmail.com> wrote:
>
>
>
> > GlkJNI: a new Glk Implementation
>
> > GlkJNI is a C implementation of Glk which uses JNI (Java Native
> > Interface) to allow C Glk programs to use a Java frontend for I/O.
> > Right now, the only frontend is JDemoGlk, which is basically a Java
> > port of CheapGlk.
>
> > GlkJni and JDemoGlk live athttp://code.google.com/p/glkjni

>
> > See the README file in the glkjni subdirectory of the source tarball
> > for build instructions; GlkJNI builds with GCC on Linux, Windows
> > (tested on Vista Home Basic with MinGW) and OSX (tested on 10.4 PPC).
>
> > A jar file for JDemoGlk can be downloaded from the GlkJNI home page;
> > the source and JavaDoc are included in the GlkJNI tarball.
>
> > I know this would be (possibly) more interesting if I had a more
> > sophisticated Java frontend; I am working on that. In the meantime,
> > all comments and questions are welcome.
>
> > -- Edward McCardell
>
> Ok, I've read through what GLK does and it's typically obtuse. Mind
> breaking it down a bit what this does and where we can go with it?

It sounds like this connects a Glk-enabled interpreter written in C
(like Glulxe or Demona) to a user interface library written in Java
(like the included JDemoGlk).

The next step is to come up with a fully functional Glk library in
Java. The Java Z-code terps like Twisty and Zplet would be a good
place to start. GlkJNI makes it possible to replace Twisty's slow
(interpreted) Java core with a fast native core like Nitfol.

vw

Edward Mc

no leída,
10 jul 2009, 1:55:5510/7/09
a
On Jul 10, 12:04 am, Poster <pos...@nospam.com> wrote:

> Ok, I've read through what GLK does and it's typically obtuse. Mind
> breaking it down a bit what this does and where we can go with it?

Sorry about the terseness; after two weeks poring over all things Glk
I forgot that not everyone would automatically know what I was talking
about.

On Jul 10, 12:13 am, Jesse McGrew <jmcg...@gmail.com> wrote:

> It sounds like this connects a Glk-enabled interpreter written in C
> (like Glulxe or Demona) to a user interface library written in Java
> (like the included JDemoGlk).

Exactly. As such, GlkJNI will be interesting primarily to interpreter
authors. There is not much to appeal to end users, at least not
until...

> The next step is to come up with a fully functional Glk library in
> Java. The Java Z-code terps like Twisty and Zplet would be a good
> place to start. GlkJNI makes it possible to replace Twisty's slow
> (interpreted) Java core with a fast native core like Nitfol.

This will be the major focus of the next stage in GlkJNI's
development.
For anyone interested in beating me to the punch, the jglk package
that
comes with GlkJNI describes the Java interfaces and methods that are
needed to interoperate with the C portion of the library.

I also have plans for a Java client/server frontend that would allow
another program (like Eclipse) to interact with a Java-enabled
interpreter. But that is much further down the road.

--Edward McCardell

Mapache

no leída,
10 jul 2009, 7:21:3410/7/09
a
Hi,

> The next step is to come up with a fully functional Glk library in
> Java. The Java Z-code terps like Twisty and Zplet would be a good
> place to start. GlkJNI makes it possible to replace Twisty's slow
> (interpreted) Java core with a fast native core like Nitfol.
>
> vw

Does it means in the mid/long term an android glk port?

It will be great!

Regards,
Mapache

Maks Verver

no leída,
10 jul 2009, 14:22:5910/7/09
a
Poster wrote:
> Ok, I've read through what GLK does and it's typically obtuse. Mind
> breaking it down a bit what this does and where we can go with it?

Glk is a library used by many interpreters to handle user interaction,
file I/O and a couple of other platform-dependent odds and ends that
aren't part of the typical interpreter.

Glk uses a C API to interface with the interpreter. This library
allows the C API calls to be dispatched to a Java implementation,
thereby allowing one to implement the Glk library in Java (even though
the interpreters themselves are still implemented in a native
language).

As Edward said, this isn't realy interesting to end users until
someone actually writes a Java Glk implementation for it. Why we would
want this, I don't know. In theory, a Java Glk library could be very
portable if it sticks to the standard class library, but C/C++
implementations that use a portable toolkit are in a similar
situation.

- Maks.


Edward Mc

no leída,
10 jul 2009, 22:28:0810/7/09
a

Now that I think about it, an Android port looks very interesting; and
from what I've been able to find out about Android, there don't seem
to be any insurmountable technical barriers. So I'll put that on my
todo list as a mid-term goal.

--Edward

Jesse McGrew

no leída,
11 jul 2009, 13:24:5711/7/09
a

I would recommend getting in touch with the developers of Twisty (the
Android Z-machine interpreter). There's been chatter on the mailing
list lately about making a Glk interface, so you could probably
combine your efforts.

vw

Edward Mc

no leída,
13 jul 2009, 14:31:3513/7/09
a

Thanks for the suggestion--I did get in touch, and it seems like
GlkJNI + Android may be a more promising line of development than
using it as yet another desktop Glk implementation.

--Edward Mc

Ben Collins-Sussman

no leída,
23 jul 2009, 11:00:0923/7/09
a
FYI, Edward got in touch with us Twisty folks, and as of last night
we're now running nitfol as a native C program on Android, using
GLKJNI to map GLK calls to Android's native java UI. It's running
curses.z5!

We have a long way to go still, but it's a huge milestone. It should
be easy to run glulxe eventually as well, or any other GLK program.
Huge thanks to Edward... this is a massive speedup, particularly
necessary for modern I7 games (which were unplayably slow on zplet.)

Responder a todos
Responder al autor
Reenviar
0 mensajes nuevos