I have two applications where I think java would now fit. I have never
been a fan of java, but I find that now these applications would/should
be good in java. The features I'm looking at are some sort of byte-code
interpreter that is platform independent and handles pointers and
memory allocation. The reason I want platform independence(?) is so
that I can write this code/app on unix/linux and have it run on
windows without me touching windows myself. A purely subjective reason,
but valid none the less. :)
The first app is something that looks like a browser, but if it can't
render html and I code the layout by hand, that's fine. It must be
able to accept inputs from text fields, text areas, selection lists, etc.,
and there must be some way to open socket connections. Also, there
must be some way that I can cause the printing of reports.
The second app also requires socket connections to a server, and
some way to plot graphs (strip chart, like an o-scope) of data
over time.
Both apps are graphical and I'd much prefer to write it in lisp
than java. I could do the first in emacs, but then I'd need to teach
the users all the meta keys. :(
I forgot, I also need to include SSL in some variety into the
socket connections. I will authenticate the actual user on the
server, but the data transmissions must be encrypted.
Ideas?
Mike
·····@mikee.myip.org (mikee) writes:
> I have two applications where I think java would now fit. I have never
> been a fan of java, but I find that now these applications would/should
> be good in java. The features I'm looking at are some sort of byte-code
> interpreter that is platform independent and handles pointers and
> memory allocation. The reason I want platform independence(?) is so
> that I can write this code/app on unix/linux and have it run on
> windows without me touching windows myself. A purely subjective reason,
> but valid none the less. :)
Sorry to use the S-word here, but have you looked at Kawa? It's
Scheme compiled to Java bytecode. Works very well from what I can
see, and lets you call out to classes written in Java (including all
the UI stuff, sockets/SSL, etc).
If it's gotta be Lisp rather than Scheme, I don't know of anything
even close.
-Doug
On 15 Jan 2002, Doug McNaught wrote:
> ·····@mikee.myip.org (mikee) writes:
[snip]
> Sorry to use the S-word here, but have you looked at Kawa? It's
> Scheme compiled to Java bytecode. Works very well from what I can
> see, and lets you call out to classes written in Java (including all
> the UI stuff, sockets/SSL, etc).
And has is uses to support JEmacs, a java port of Emacs.
> If it's gotta be Lisp rather than Scheme, I don't know of anything
> even close.
Actually, Kawa again. There's some beginnings of Common Lisp support (both
as extentions to Scheme and in it's own right). Funding and assitence
might push it beyond the very rudimentory faster :)
Cheers,
Bijan Parsia.
Bijan Parsia <·······@email.unc.edu> writes:
> On 15 Jan 2002, Doug McNaught wrote:
>
>> ·····@mikee.myip.org (mikee) writes:
> [snip]
>> Sorry to use the S-word here, but have you looked at Kawa? It's
>> Scheme compiled to Java bytecode. Works very well from what I can
>> see, and lets you call out to classes written in Java (including all
>> the UI stuff, sockets/SSL, etc).
>
> And has is uses to support JEmacs, a java port of Emacs.
>
>> If it's gotta be Lisp rather than Scheme, I don't know of anything
>> even close.
>
> Actually, Kawa again. There's some beginnings of Common Lisp support (both
> as extentions to Scheme and in it's own right). Funding and assitence
> might push it beyond the very rudimentory faster :)
>
Would people then have the oppurtunity to use JCL? :)
> Cheers,
> Bijan Parsia.
>
--
BPT <···@tunes.org> /"\ ASCII Ribbon Campaign
backronym for Linux: \ / No HTML or RTF in mail
Linux Is Not Unix X No MS-Word in mail
Meme plague ;) ---------> / \ Respect Open Standards
> I have two applications where I think java would now fit. I have never
> been a fan of java, but I find that now these applications would/should
> be good in java. The features I'm looking at are some sort of byte-code
> interpreter that is platform independent and handles pointers and
> memory allocation. The reason I want platform independence(?) is so
> that I can write this code/app on unix/linux and have it run on
> windows without me touching windows myself. A purely subjective reason,
> but valid none the less. :)
>
> The first app is something that looks like a browser, but if it can't
> render html and I code the layout by hand, that's fine. It must be
> able to accept inputs from text fields, text areas, selection lists, etc.,
> and there must be some way to open socket connections. Also, there
> must be some way that I can cause the printing of reports.
>
> The second app also requires socket connections to a server, and
> some way to plot graphs (strip chart, like an o-scope) of data
> over time.
>
> Both apps are graphical and I'd much prefer to write it in lisp
> than java. I could do the first in emacs, but then I'd need to teach
> the users all the meta keys. :(
>
> I forgot, I also need to include SSL in some variety into the
> socket connections. I will authenticate the actual user on the
> server, but the data transmissions must be encrypted.
I believe Clisp supports a substantial amount of what you're asking
for. Gnuplot might be a slightly easier way to generate the graphs.
Clisp on Doze seems to behave well though a little slow, however I've
not used it extensively there. It works quite well on Linux &
elsewhere.
I seem to remember someone setting up SSL FFI defintions which <might>
be available in Clisp. It might be easier to use ssh for your
communications; if you redirect a port via ssh, you get authentication
& crypto but using native socket calls. It's not quite a seamless as
you might like, but can be reduced to one step pretty well. We've
used this technique for secure CVS and it works fine. Under Windows,
you'll find Cygwin goes a long way to setting up a useful environment.
As far as reports are concerned, you could always use one of the
myriad html generation packages available in Lisp and display it via
some local web browser.
If your data collection only needs a primitive interface, then doing
it via web browser might be sufficient. If so, CL-HTTP would be a
nice way of generating the interface, accepting the input and doing
something with it. I found CL-HTTP to be remarkably easy to work with
once I started to grok how it goes together.
Gregm
On Wed, 16 Jan 2002 02:58:50 -0000, ·····@mikee.myip.org (mikee) wrote:
> I have two applications where I think java would now fit. I have never
[...]
> Both apps are graphical and I'd much prefer to write it in lisp
> than java. I could do the first in emacs, but then I'd need to teach
Allegro Common Lisp by Franz, Inc. provides good integration with Java.
Check their Web site for more information:
http://www.franz.com
Paolo
--
EncyCMUCLopedia * Extensive collection of CMU Common Lisp documentation
http://web.mclink.it/amoroso/ency/README
[http://cvs2.cons.org:8000/cmucl/doc/EncyCMUCLopedia/]
·····@mikee.myip.org (mikee) writes:
> I have two applications where I think java would now fit. I have never
> been a fan of java, but I find that now these applications would/should
> be good in java. The features I'm looking at are some sort of byte-code
> interpreter that is platform independent and handles pointers and
> memory allocation. The reason I want platform independence(?) is so
> that I can write this code/app on unix/linux and have it run on
> windows without me touching windows myself. A purely subjective reason,
> but valid none the less. :)
Wanting to develop on Unix and deploy on Windows is a reasonable
desire. Wanting to do it without touching Windows is not. I wouldn't
even trust Java to do that, without testing (which involves touching
windows)
> The first app is something that looks like a browser, but if it can't
> render html and I code the layout by hand, that's fine. It must be
> able to accept inputs from text fields, text areas, selection lists, etc.,
> and there must be some way to open socket connections. Also, there
> must be some way that I can cause the printing of reports.
>
> The second app also requires socket connections to a server, and
> some way to plot graphs (strip chart, like an o-scope) of data
> over time.
>
> Both apps are graphical and I'd much prefer to write it in lisp
> than java. I could do the first in emacs, but then I'd need to teach
> the users all the meta keys. :(
Actually, you could do both in Emacs (with a connection to gnuplot for
the second). There's no need to make your key bindings or menus
Emacs-like just becaue you're using Emacs. You can dump an emacs that
launches straight into your app, which you gave a perfectly normal
menu setup and key bindings to. Emacs will give you about the same
level of portability as Java -- you can develop it wherever you want,
but you really should test it in an environment like where it will be
deployed.
Emacs is a weird Lisp environment heavily biased towards writing
editor-like applications. It also ships with several editors written
in it. There's nothing forcing you to use the pre-written editors,
though, any more than you're forced to make your CMUCL applications
include Hemlock. This isn't just theoretical, either. I've written
an application in emacs that didn't include much of Emacs at all in
the final product. Didn't look too much like Emacs, either (kinda,
but not too much :)
> I forgot, I also need to include SSL in some variety into the
> socket connections. I will authenticate the actual user on the
> server, but the data transmissions must be encrypted.
You can tunnel Emacs' socket connections through ssltunnel (see the W3
web browser, for example). You'll definitely want to debug it on
Windows, though. If you're willing to touch Windows for a pretty
small portion of your development process, Emacs has got you.
And of course, others have mentioned CLISP and the commercial Lisps.
--
/|_ .-----------------------.
,' .\ / | No to Imperialist war |
,--' _,' | Wage class war! |
/ / `-----------------------'
( -. |
| ) |
(`-. '--.)
`. )----'