I was looking at Apple's page announcing version 2.2 of their Java
runtime software. Its appalling bulk makes CL look positively
svelte by comparison.
[from http://developer.apple.com/java/text/download.html]
Minimum System Requirements for MRJ 2.2
Macintosh computer with a PowerPC processor
Mac OS 8.1 or later
Memory requirements will vary depending on how you are using
Java. The minimum requirement for running simple applets is 40
megabytes (MB) of RAM, with virtual memory on and set to at least
44 MB. To run complex applets and applications, 64 MB of RAM is
highly recommended. Increasing RAM to 64 MB or more will also
improve performance.
At least 13 MB of free disk space
Using Java applets over the Internet requires an active Internet
connection.
I'm running CL-HTTP in MCL 4.3 in a 20MB memory partition on a
Powerbook, with close to 6MB of room left. And I need 40MB of memory
to run a simple Java applet?
-matt
R Matthew Emerson wrote:
>
> I was looking at Apple's page announcing version 2.2 of their Java
> runtime software. Its appalling bulk makes CL look positively
> svelte by comparison.
>
> [from http://developer.apple.com/java/text/download.html]
>
> Minimum System Requirements for MRJ 2.2
>
> Macintosh computer with a PowerPC processor
>
> Mac OS 8.1 or later
>
> Memory requirements will vary depending on how you are using
> Java. The minimum requirement for running simple applets is 40
> megabytes (MB) of RAM, with virtual memory on and set to at least
> 44 MB. To run complex applets and applications, 64 MB of RAM is
> highly recommended. Increasing RAM to 64 MB or more will also
> improve performance.
>
> At least 13 MB of free disk space
>
> Using Java applets over the Internet requires an active Internet
> connection.
I would assume that Apple's Java system has tons of GUI objects that allow
fairly easy high quality GUI development. Those take a lot of space in any
language. CL doesn't have them in the common package, if you add those you
are going to gain alot. CL should be compared to an embedded Java
implementation that does not include GUI support.
Muddy
>
> I'm running CL-HTTP in MCL 4.3 in a 20MB memory partition on a
> Powerbook, with close to 6MB of room left. And I need 40MB of memory
> to run a simple Java applet?
>
> -matt
In article <·················@raytheon.com>,
Robert (\"Bevo\") Posey <·····@raytheon.com> wrote:
>I would assume that Apple's Java system has tons of GUI objects that allow
>fairly easy high quality GUI development. Those take a lot of space in any
>language. CL doesn't have them in the common package, if you add those you
>are going to gain alot. CL should be compared to an embedded Java
>implementation that does not include GUI support.
But Macintosh Common Lisp *does* include lots of GUI stuff. Although I
guess most of it is just wrappers around foreign function calls to the
built-in Macintosh toolboxes.
--
Barry Margolin, ······@bbnplanet.com
GTE Internetworking, Powered by BBN, Burlington, MA
*** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
Please DON'T copy followups to me -- I'll assume it wasn't posted to the group.
In article <················@burlma1-snr2>, Barry Margolin
<······@bbnplanet.com> wrote:
> In article <·················@raytheon.com>,
> Robert (\"Bevo\") Posey <·····@raytheon.com> wrote:
> >I would assume that Apple's Java system has tons of GUI objects that allow
> >fairly easy high quality GUI development. Those take a lot of space in any
> >language. CL doesn't have them in the common package, if you add those you
> >are going to gain alot. CL should be compared to an embedded Java
> >implementation that does not include GUI support.
>
> But Macintosh Common Lisp *does* include lots of GUI stuff. Although I
> guess most of it is just wrappers around foreign function calls to the
> built-in Macintosh toolboxes.
Not really. MCL has a CLOSified UIMS,
includes an editor written in Common Lisp and *several*
other tools.
Rainer Joswig, ISION Internet AG, Harburger Schlossstra�e 1,
21079 Hamburg, Germany, Tel: +49 40 77175 226
Email: ·············@ision.de , WWW: http://www.ision.de/
Rainer Joswig <·············@ision.de> writes:
> In article <················@burlma1-snr2>, Barry Margolin
> <······@bbnplanet.com> wrote:
>
> > In article <·················@raytheon.com>,
> > Robert (\"Bevo\") Posey <·····@raytheon.com> wrote:
> > >I would assume that Apple's Java system has tons of GUI objects that allow
> > >fairly easy high quality GUI development. Those take a lot of space in any
> > >language. CL doesn't have them in the common package, if you add those you
> > >are going to gain alot. CL should be compared to an embedded Java
> > >implementation that does not include GUI support.
> >
> > But Macintosh Common Lisp *does* include lots of GUI stuff. Although I
> > guess most of it is just wrappers around foreign function calls to the
> > built-in Macintosh toolboxes.
>
> Not really. MCL has a CLOSified UIMS,
> includes an editor written in Common Lisp and *several*
> other tools.
Which I bet is the same setup of the Mac Java system (i.e. wrappers
plus what you get in MCL). Hence, CL is tiny :)
Cheers
Marco
--
Marco Antoniotti ===========================================
PARADES, Via San Pantaleo 66, I-00186 Rome, ITALY
tel. +39 - 06 68 10 03 17, fax. +39 - 06 68 80 79 26
http://www.parades.rm.cnr.it/~marcoxa
In article <··············@parades.rm.cnr.it>, Marco Antoniotti
<·······@parades.rm.cnr.it> wrote:
>> Not really. MCL has a CLOSified UIMS,
>> includes an editor written in Common Lisp and *several*
>> other tools.
>
>Which I bet is the same setup of the Mac Java system (i.e. wrappers
>plus what you get in MCL). Hence, CL is tiny :)
No, actually, Java does GUI either by the AWT, which is Sun's first stab
at a cross platform UIMS, or Swing, the more recent, more bloated, and
still not really native feeling attempt. Neither of these can be
described as "wrappers," since they're full blown OO frameworks for GUI
work.
You can, of course use JNI (or JDirect as it is known on the Mac) to
call MacOS routines from Java, but this is not how real GUI work is
done. The overhead of setting up each native call actually makes this
slower than using the AWT peers.
So, CL and Java both have extensive, OO frameworks for UI work on the
Mac. MCL's is just better, that's all ;^)
--
Raffael Cavallaro, Ph.D.
·······@mediaone.net
Raffael Cavallaro <·······@mediaone.net> writes:
> In article <··············@parades.rm.cnr.it>, Marco Antoniotti
> <·······@parades.rm.cnr.it> wrote:
>
> >> Not really. MCL has a CLOSified UIMS,
> >> includes an editor written in Common Lisp and *several*
> >> other tools.
> >
> >Which I bet is the same setup of the Mac Java system (i.e. wrappers
> >plus what you get in MCL). Hence, CL is tiny :)
>
> No, actually, Java does GUI either by the AWT, which is Sun's first stab
> at a cross platform UIMS, or Swing, the more recent, more bloated, and
> still not really native feeling attempt. Neither of these can be
> described as "wrappers," since they're full blown OO frameworks for GUI
> work.
Well, yes.....
> You can, of course use JNI (or JDirect as it is known on the Mac) to
> call MacOS routines from Java, but this is not how real GUI work is
> done. The overhead of setting up each native call actually makes this
> slower than using the AWT peers.
I don't quit efollow this. Eventually an AWT Peer calls the
Toolkit.createWhatever() method (i.e. AWT Peers are more or less akin
to "Factories" in Pattern Speak). This method eventually calls (on a
Sun and I assume on a Mac as well) the sun.motif.Whatever.* method
(which is available thanks to Property's magic). I.e. eventually the
native (read: platform available) call is actually invoked. This is
what I call a "wrapper". This is what you do in MCL when calling the
UI functionalities.
I am saying this to clarify my viewpoint and, maybe, to converge on
terminology and understanding.
> So, CL and Java both have extensive, OO frameworks for UI work on the
> Mac. MCL's is just better, that's all ;^)
I have little doubts about it. After all I still remember my first
Lisp Machine: a Mac Plus with 4 Meg of RAM and MCL :)
Cheers
--
Marco Antoniotti ===========================================
PARADES, Via San Pantaleo 66, I-00186 Rome, ITALY
tel. +39 - 06 68 10 03 17, fax. +39 - 06 68 80 79 26
http://www.parades.rm.cnr.it/~marcoxa
"Robert (\"Bevo\") Posey" <·····@raytheon.com> writes:
> I would assume that Apple's Java system has tons of GUI objects that allow
> fairly easy high quality GUI development. Those take a lot of space in any
> language. CL doesn't have them in the common package, if you add those you
> are going to gain alot. CL should be compared to an embedded Java
> implementation that does not include GUI support.
But MCL *does* come with "tons of GUI objects" and can be run in a
memory partition of eight megabytes.
Carl Shapiro <·······@panix.com> writes:
> But MCL *does* come with "tons of GUI objects" and can be run in a
> memory partition of eight megabytes.
CL runtime systems should be renamed to 'nanoservlets', maybe that
could sell them? ;-)
--
(espen)
In article <·················@raytheon.com>, "Robert (\"Bevo\") Posey"
<·····@raytheon.com> wrote:
> I would assume that Apple's Java system has tons of GUI objects that allow
> fairly easy high quality GUI development. Those take a lot of space in any
> language.
No, not in any language. On Apple's Newton (sigh) GUI stuff
was/is really tiny.
- applications have the size of small compiled Lisp files
- objects inherit from prototypes. Only the changes are allocated.
That means you can ROMify prototype objects and delegate
to them.
Rainer Joswig, ISION Internet AG, Harburger Schlossstrasse 1,
21079 Hamburg, Germany, Tel: +49 40 77175 226
Email: ·············@ision.de , WWW: http://www.ision.de/
In article <···············@agrias.lerc.nasa.gov>:
> Minimum System Requirements for MRJ 2.2
>
> Macintosh computer with a PowerPC processor
>
> Mac OS 8.1 or later
>
> Memory requirements will vary depending on how you are using
> Java. The minimum requirement for running simple applets is 40
> megabytes (MB) of RAM, with virtual memory on and set to at least
> 44 MB. To run complex applets and applications, 64 MB of RAM is
> highly recommended. Increasing RAM to 64 MB or more will also
> improve performance.
I believe above requirement includes the memory requirement for
MacOS itself. Not that MRJ2.2 itself needs extra 40-64 MB.
> I'm running CL-HTTP in MCL 4.3 in a 20MB memory partition on a
> Powerbook, with close to 6MB of room left.
That translates to 40-70 mb = 20mb (MCL) + 20?-50mb (OS). So MCL
and MRJ is almost equivalent in memory requirement here, although
I have no idea how much memory MRJ would need if you run a 'complex
application' like CL-http in it...
regards,
abe
In article <·····················@tc-1-150.osaka.gol.ne.jp>,
····@gol.com (Keke Abe) wrote:
> > Memory requirements will vary depending on how you are using
> > Java. The minimum requirement for running simple applets is 40
> > megabytes (MB) of RAM, with virtual memory on and set to at least
> > 44 MB. To run complex applets and applications, 64 MB of RAM is
> > highly recommended. Increasing RAM to 64 MB or more will also
> > improve performance.
>
> I believe above requirement includes the memory requirement for
> MacOS itself. Not that MRJ2.2 itself needs extra 40-64 MB.
That's right. Just try the "Apple Applet Runner" application.
For a simple applet the OS' RAM size was increasing by 2 MB and
the application allocated 8MB.
Rainer Joswig, ISION Internet AG, Harburger Schlossstra�e 1,
21079 Hamburg, Germany, Tel: +49 40 77175 226
Email: ·············@ision.de , WWW: http://www.ision.de/
····@gol.com (Keke Abe) writes:
> > I'm running CL-HTTP in MCL 4.3 in a 20MB memory partition on a
> > Powerbook, with close to 6MB of room left.
>
> That translates to 40-70 mb = 20mb (MCL) + 20?-50mb (OS). So MCL
> and MRJ is almost equivalent in memory requirement here, although
> I have no idea how much memory MRJ would need if you run a 'complex
> application' like CL-http in it...
I've seen those java 'servlets' grow to 500MB resident memory size...
For simple applications, MCL is very happy with only 8MB of memory.
I just inspected a fairly complex TCP server I've written in ACL
for Solaris 2.6 (which is a *memory hog* compared to MCL!). The
server process has been running uninterrupted since Dec 22 (6 weeks),
serving up to 30 simultanous threads and hundreds of thousands of
requests each day, and is still requiring only 13MB resident memory
(20MB total).
--
(espen)
Espen Vestre wrote:
>
> ····@gol.com (Keke Abe) writes:
>
> > > I'm running CL-HTTP in MCL 4.3 in a 20MB memory partition on a
> > > Powerbook, with close to 6MB of room left.
> >
> > That translates to 40-70 mb = 20mb (MCL) + 20?-50mb (OS). So MCL
> > and MRJ is almost equivalent in memory requirement here, although
> > I have no idea how much memory MRJ would need if you run a 'complex
> > application' like CL-http in it...
>
> I've seen those java 'servlets' grow to 500MB resident memory size...
This is unfair, because memory leaks in this magnitude are caused by bad
coding...
> For simple applications, MCL is very happy with only 8MB of memory.
In Java (and many other Languages) there is a rather clear difference
between the IDE and the application you're writing (edit, compile, run,
edit, ...). In MCL that's a little bit different. You can use and change
fred, but can you make a tiny application without any GUI at all (a only
Common-LISP image + your code)?
So one should compare IDE's for Java and CL against each other and
applications for Java and CL against each other, buit not mix these.
> I just inspected a fairly complex TCP server I've written in ACL
> for Solaris 2.6 (which is a *memory hog* compared to MCL!). The
> server process has been running uninterrupted since Dec 22 (6 weeks),
> serving up to 30 simultanous threads and hundreds of thousands of
> requests each day, and is still requiring only 13MB resident memory
> (20MB total).
This sounds interesting. If you are in position to publish (some of)
your code, it would be an interesting piece of software to study and
learn from. It doesnt not really matter what service or content you're
server provides, but a general "CL-TCP-Server-Library" of the quality
which you describe and on which you can do your own service seems to be
good thing to have (for the community, does anybody agree with me?).
Remember Paul Meurer and his SQL-ODBC-Library, which does a nice job for
many people, no matter for what purposes he had developped it in the
first place. Had something to with dictionaries and natural speech
recognition.
Bye,
Joe
--
Johannes Beck ····@informatik.uni-wuerzburg.de
* Johannes Beck wrote:
> So one should compare IDE's for Java and CL against each other and
> applications for Java and CL against each other, buit not mix these.
OK, I'll bite. How small *are* Java applications (when you include
the runtime support they need that isn't shared with all the other
applications on the machine the same way everyone does for Lisp
systems)
--tim
I take Espens answer into this,. so I dont have to replay twice.
Tim Bradshaw wrote:
>
> * Johannes Beck wrote:
>
> > So one should compare IDE's for Java and CL against each other and
> > applications for Java and CL against each other, buit not mix these.
>
> OK, I'll bite. How small *are* Java applications (when you include
> the runtime support they need that isn't shared with all the other
> applications on the machine the same way everyone does for Lisp
> systems)
Espen Vestre wrote:
> I don't get your point. MCL *including* compiler & FRED & co has,
> AFAIK, a smaller memory footprint than HelloWorld.class.
I'm a lousy Java-Programmer. My HelloWorld looks like this:
class HelloWorld {
public static void main(String args[]) {
while (1==1)
{
System.out.println("Hello World!");
}
}
};
> java HelloWorld > /dev/null &
> top
PID USER PRI NI SIZE RSS SHARE STAT LIB %CPU %MEM TIME COMMAND
2171 root 11 0 3700 3700 988 R 0 97.4 5.8 0:36 java
The virtual machine running it has a footprint of 3.7MB (IBM-JDJ1.1.7 on
linux, I dont have a Mac and MCL at hand). When I was doing LISP on MCL
(about 3 years ago) a vanilla MCL had something about 8MBs. And MacOS
7.5.X was quite lousy on memory management (virtual memory, sharing), so
I cant admit that it shared memory with other applications. I heard this
has become better.
Back to the point. The point was...
The argument is weak, because one shouldnt compare IDEs against runtimes
and draw general conclusions which environment will use more resource.
Lets look what a JAVA IDE uses and what a LISP IDE uses (and which is
nicer to work with, has more features, better connectivity to other
applications, whatever is important to your project...) and what the
runtimes need (here the point is more on speed and memory, or the GUI it
can provide).
Java IDEs are huge resource eating things. They are much larger than any
LISP IDE. LISP runtimes and Java runtimes (both without any GUI) can be
relatively small and of the similar sizes. A Java runtime without GUI is
smaller than a LISP IDE with a GUI.
Java does a better job on separating between runtime and IDE. Sometimes
you want this. Sometimes it's nicer to have runtimes with features from
the IDE (e.g. using FRED).
I'm a LISP programmer and used to arguing on the "why LISP it better
than the rest" thing. But you have to sort your arguments because
religious faith alone won't work against the disbelievers. And foul or
weak arguments (like the comparison between IDEs and runtimes) wont help
too.
Bye
Joe
--
Johannes Beck ····@informatik.uni-wuerzburg.de
http://www-info6.informatik.uni-wuerzburg.de/~beck/
PGP Public Key available by
·············@www-info6.informatik.uni-wuerzburg.de
Johannes Beck <····@informatik.uni-wuerzburg.de> writes:
> PID USER PRI NI SIZE RSS SHARE STAT LIB %CPU %MEM TIME COMMAND
> 2171 root 11 0 3700 3700 988 R 0 97.4 5.8 0:36 java
>
> The virtual machine running it has a footprint of 3.7MB (IBM-JDJ1.1.7 on
> linux, I dont have a Mac and MCL at hand). When I was doing LISP on MCL
> (about 3 years ago) a vanilla MCL had something about 8MBs. And MacOS
> 7.5.X was quite lousy on memory management (virtual memory, sharing), so
> I cant admit that it shared memory with other applications. I heard this
> has become better.
I don't have java on a mac at hand, but HelloWorld will use 6MBs on
a SPARC, which is probably closer to the mac value (You're running
it on a CISC, the mac and the sun are RISCs). You can do much more
than Hello World inside a 6MB MCL image. In fact, back in macintosh
68k days, admittedly before CLOS, I could compile and run fairly advanced
computational linguistics programs inside 2.5MB.
> The argument is weak, because one shouldnt compare IDEs against runtimes
> and draw general conclusions which environment will use more resource.
And your point is? I am showing you that the mcl IDE WITH THE RUNTIME
SYSTEM AND A NATIVE COMPILER (I usually don't write in capitals, but
this upsets me) uses less resources than only the fragment of the java
runtime system needed to run a hello world program, what more proof do
you need?
> relatively small and of the similar sizes. A Java runtime without GUI is
> smaller than a LISP IDE with a GUI.
I just showed you for the second time that you are completely wrong,
so I really hope you'll try to understand me this time.
--
(espen)
Espen Vestre <·····@*do-not-spam-me*.vestre.net> writes:
> I just showed you for the second time that you are completely wrong,
> so I really hope you'll try to understand me this time.
Now, go away or I will have to taunt you a third time ;)
--
(Rmz)
Bj\o rn Remseth !Institutt for Informatikk !Net: ···@ifi.uio.no
Phone:+47 91341332!Universitetet i Oslo, Norway !ICBM: N595625E104337
Hello,
Espen Vestre wrote:
>
> Johannes Beck <····@informatik.uni-wuerzburg.de> writes:
>
> ...
>
> > The argument is weak, because one shouldnt compare IDEs against runtimes
> > and draw general conclusions which environment will use more resource.
>
> And your point is? I am showing you that the mcl IDE WITH THE RUNTIME
> SYSTEM AND A NATIVE COMPILER (I usually don't write in capitals, but
> this upsets me) uses less resources than only the fragment of the java
> runtime system needed to run a hello world program, what more proof do
> you need?
> I just showed you for the second time that you are completely wrong,
> so I really hope you'll try to understand me this time.
> --
> (espen)
STOP SLAPPING ME. I BELIEVE YOU! AND STOP SHOUTING:-)
My memory is weak. I cant remember that you could have a 2.5MB MCL but I
will and do believe you. I had a figure in mind which was about 4-5
times more. Since I am wrong, I must admit that you are right.
And I will not go away. This NG is too good.
--
Johannes Beck beck @ informatik.uni-wuerzburg.de
Johannes Beck <····@informatik.uni-wuerzburg.de> writes:
> In Java (and many other Languages) there is a rather clear difference
> between the IDE and the application you're writing (edit, compile, run,
> edit, ...). In MCL that's a little bit different. You can use and change
> fred, but can you make a tiny application without any GUI at all (a only
> Common-LISP image + your code)?
>
> So one should compare IDE's for Java and CL against each other and
> applications for Java and CL against each other, buit not mix these.
I don't get your point. MCL *including* compiler & FRED & co has,
AFAIK, a smaller memory footprint than HelloWorld.class.
--
(espen)
On Sat, 05 Feb 2000 15:53:51 +0100, Johannes Beck
<····@informatik.uni-wuerzburg.de> wrote:
>Remember Paul Meurer and his SQL-ODBC-Library, which does a nice job for
>many people, no matter for what purposes he had developped it in the
>first place. Had something to with dictionaries and natural speech
>recognition.
>
To straighten that out: It had (has) to do with (natural language)
dictionaries and terminological databases. (No speach though.)
- Paul
____________________________________________
Paul Meurer at HIT UiB no
Humanities Information Technologies Centre,
University of Bergen
All�gaten 27, 5007 Bergen
Norway