Rainer Joswig wrote:
> http://www.is-research.de/info/vmlanguages/lisp.html
>
> cough
>
This is a well-done and very extensive list. I didn't know there
were so many Lisp implementations on the Java Virtual Machine. Of
course, he's including a broad
range of languages in the Lisp/Scheme family, but
that's fine. His descriptions, in cases where
I know the language, are good.
Pascal Costanza <··@p-cos.net> writes:
> JVM technology has come up with pretty impressive dynamic compilation
> techniques and very advanced garbage collectors, to name just two
> examples. It can be interesting to reuse such technology.
Also, a higher level VM makes it easier for multiple languages to
cooperate properly. Does anyone really enjoy writing CFFI wrappers for
C libraries? It's even less pleasant if the library you want to use is
in, say Python.
It's not as if one would actually need a lot of translation layers and
whatnot if Python and Lisp semantics could share a common substrate: the
semantics of various numbers and functions and so on are pretty similar.
(There's a mismatch over whether strings are mutable, for example, but
that's not a really big deal.) But because Python uses a completely
different runtime system from Lisp implementations, one needs to mess
about at the C level[1] to get them talking, even after you've squashed
them into the same address space together.
[1] You can use CFFI in Lisp and `ctypes' in Python to avoid actually
writing any real C, but that doesn't mean that you can avoid having
to work at that level.
-- [mdw]
On Tue, 20 Jan 2009 23:12:59 +0000, Mark Wooding wrote:
> Pascal Costanza <··@p-cos.net> writes:
>
>> JVM technology has come up with pretty impressive dynamic compilation
>> techniques and very advanced garbage collectors, to name just two
>> examples. It can be interesting to reuse such technology.
>
> Also, a higher level VM makes it easier for multiple languages to
> cooperate properly.
Who said I want to cooperate ? I'm all for language apartheid and
reimplementing everything from scratch.
> Does anyone really enjoy writing CFFI wrappers for
> C libraries?
No, better rewrite it in lisp.
On 2009-01-21, alien_guy <·@l.org> wrote:
> On Tue, 20 Jan 2009 23:12:59 +0000, Mark Wooding wrote:
>
>> Pascal Costanza <··@p-cos.net> writes:
>>
>>> JVM technology has come up with pretty impressive dynamic compilation
>>> techniques and very advanced garbage collectors, to name just two
>>> examples. It can be interesting to reuse such technology.
>>
>> Also, a higher level VM makes it easier for multiple languages to
>> cooperate properly.
>
> Who said I want to cooperate ? I'm all for language apartheid and
> reimplementing everything from scratch.
If you're for language apartheid, you clearly belong in the Java project.
Robert Dodier <·············@gmail.com> writes:
> Well, let me take this opportunity to toot ABCL's horn here.
> After a long period of inactivity, ABCL (with new maintainers) is
> getting pretty close to a full implementation of the CL spec,
This is excellent news. I've not used ABCL very much, but it worked
well enough (just about) a while ago for me to be very grateful.
(I wanted to bash together a simple GUI thing that would work on
Windows, without me having to actually touch a Windows machine for more
than about five minutes. I messed with Mono for a bit before deciding
that System.Windows.Forms was just too awful; Python and (say) wxWindows
required too much installing weird stuff at the far end. I gave up and
used Swing, but actually writing Java was far too much like pulling my
own fingernails out with rusty pliers. ABCL came to my rescue!
If anyone cares, I have some fancy functions for doing Java method and
constructor overload resolution at run-time based on the dynamic
argument types.)
-- [mdw]
From: Mark Evenson
Subject: Fancy functions for the ABCL (was Re: Lisp on the JVM)
Date:
Message-ID: <gl9k3m$kb1$1@reader1.panix.com>
Mark Wooding wrote:
[�]
> If anyone cares, I have some fancy functions for doing Java method and
> constructor overload resolution at run-time based on the dynamic
> argument types.)
As an ABCL maintainer, I would be interested in posting such a set a
functions to the armedbear mailing list for posterity/wider
distribution. Over time, all sorts of people seem to follow ABCL for a
bit, using the mailing list archives to "come-up-to-speed" on what
happened before. Currently, the Java constructor lookup is pretty
verbose, so I would welcome code to help bridge this more intelligently.
Personally, I find great utility in [Alan Ruttenberg's
invoke.lisp][1], but it actually uses the JScheme implementation under
the hood to find the constructor requiring addtional JARs on the JVM
classpath, so I would be interested in comparing it to a pure CL
implementation.
The armedbear mailing list is still the old armedbear-j-devel list
hosted on SourceForge. Unfortunately, the list accepts posts from
members only. If you want to send the code to me, I can make sure it
makes it to the list.
Eventually, we want to make the Java/Lisp interfaces as easy as
possible, but we are currently concentrating on getting ABCL to behave
more like a better CL before going for such extensions.
[1]: http://svn.mumble.net:8080/svn/lsw/trunk/jss/invoke.lisp
Sincerely,
Mark <·······@panix.com>
--
"A screaming comes across the sky. It has happened before, but there is
nothing to compare to it now."
On Tue, 20 Jan 2009 19:32:39 +0000 (UTC)
Kaz Kylheku <········@gmail.com> wrote:
> The JVM is obsolete, because real machine virtualization has become
> commonplace.
Virtualization does not help at all when you are trying to use foreign
language libraries like it is possible and common in Scala or Clojure
for example.
And virtualization doesn't help you when you have native code for MIPS
and want to run it on ARM. You'd need to emulate and not to virtualize
and that's way to slow to be usable.
regards,
Marek
Kaz Kylheku wrote:
> Why would I run some poor quality fake virtual machine when I can virtualize an
> entire operating system, that has MMU based memory management, its own TCP/IP
> stack, its own accurate process and thread scheduler, etc.
What has one got to do with the other?
Want to run a separate OS for every process?
How about portability to different architectures (the "write once, run
everywhere" [yes, I know...])?
On 21 Jan., 17:48, Matthias Buelow <····@incubus.de> wrote:
> Kaz Kylheku wrote:
> > Why would I run some poor quality fake virtual machine when I can virtualize an
> > entire operating system, that has MMU based memory management, its own TCP/IP
> > stack, its own accurate process and thread scheduler, etc.
>
> What has one got to do with the other?
>
> Want to run a separate OS for every process?
>
> How about portability to different architectures (the "write once, run
> everywhere" [yes, I know...])?
Not every process. But if you look at some companies, they are running
each app in a different virtualized OS on blade servers.
On Wed, 21 Jan 2009 08:56:34 -0800 (PST)
·······@corporate-world.lisp.de" <······@corporate-world.lisp.de> wrote:
> Not every process. But if you look at some companies, they are running
> each app in a different virtualized OS on blade servers.
Though it still does not make VMs like what Java and many other
languages use unneccessary, because that's just different things.
regards,
Marek
Marek Kubica <·····@xivilization.net> writes:
> On Wed, 21 Jan 2009 08:56:34 -0800 (PST)
> ·······@corporate-world.lisp.de" <······@corporate-world.lisp.de> wrote:
>
>> Not every process. But if you look at some companies, they are running
>> each app in a different virtualized OS on blade servers.
>
> Though it still does not make VMs like what Java and many other
> languages use unneccessary, because that's just different things.
The VM are still needed in the presence of virtualized OS because most
modern processors are not micro-codable anymore.
If the microcode could be changed for the user processes, instead of
implementing the instruction set in a virtual machine, we could
directly implement it in the processor "firmware", and then you would
have virtualized OS implementing directly the VM you need. You would
have native Java Machines, native Lisp Machines, native Prolog
Machines, etc running "directly" on the metal.
--
__Pascal Bourguignon__
Matthias Buelow <···@incubus.de> wrote:
+---------------
| Kaz Kylheku wrote:
| > Why would I run some poor quality fake virtual machine when I can
| > virtualize an entire operating system, that has MMU based memory
| > management, its own TCP/IP stack, its own accurate process and
| > thread scheduler, etc.
|
| What has one got to do with the other?
| Want to run a separate OS for every process?
+---------------
Heh. VM/CMS did *exactly* that! When you logged into a VM/CMS
session, you actually "booted" a fresh copy of the CMS operating
system within a new VM/370 virtual machine.
Sutherland's "Wheel of Reincarnation" strikes again! ;-}
-Rob
-----
Rob Warnock <····@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607
On Jan 22, 4:41 am, ····@rpw3.org (Rob Warnock) wrote:
> Matthias Buelow <····@incubus.de> wrote:
> +---------------| Kaz Kylheku wrote:
>
> | > Why would I run some poor quality fake virtual machine when I can
> | > virtualize an entire operating system, that has MMU based memory
> | > management, its own TCP/IP stack, its own accurate process and
> | > thread scheduler, etc.
> |
> | What has one got to do with the other?
> | Want to run a separate OS for every process?
> +---------------
>
> Heh. VM/CMS did *exactly* that! When you logged into a VM/CMS
> session, you actually "booted" a fresh copy of the CMS operating
> system within a new VM/370 virtual machine.
>
> Sutherland's "Wheel of Reincarnation" strikes again! ;-}
>
> -Rob
>
> -----
> Rob Warnock <····@rpw3.org>
> 627 26th Avenue <URL:http://rpw3.org/>
> San Mateo, CA 94403 (650)572-2607
Aren't the people who gave us VmWare (where I run Movitz :) )
coming from VM/CMS?
Cheers
--
Marco
http://www.european-lisp-symposium.org
Rob Warnock wrote:
> Heh. VM/CMS did *exactly* that! When you logged into a VM/CMS
> session, you actually "booted" a fresh copy of the CMS operating
> system within a new VM/370 virtual machine.
Yeah but I guess that's different from having n installations of Lignux
or Windows around, each of which boot up with unnecessary baggage (for a
1-service system) and each of which has to be operated and maintained
separately.
I mean, Ok, if you have a database system that you'd probably also run
on a separate machine, then that's ok to run in a virtualized machine on
a more powerful server instead. But that concept is orthogonal to the
Java-style VM.