Leo Simons wrote:
Whoohooh! An actual vi-vs-emacs discussion! Now we are *really* getting
started!
ed is the one true editor.
cheers,
dalibor topic,
patiently awaiting the first ruby on rails vs. java discussion on this
list :)
I know I'm quite late this week, I'm sorry (Counter-Strike and lots
of beer got in the way ;-). Now here's what happend last week on the
harmony development mailing list. And, just because this paragraph is
off topic anyway: Happy Helloween!
In the thread Some questions about the architecture
+1, enthusiastically
As I was passing through Toronto recently I noticed a large Harmony logo
from these guys:
http://www.harmonyairways.com/index.shtml
...have to bear that in mind as the preferred airlne for the first
Harmony user conference ;-)
Regards,
Tim
Leo Simons wrote:
Hi
Jean-Frederic,
Hmmm I used this construction instead of `basename $(PWD)`
so that Unix implementations that do not have basename(1) or
dirname(1) do not have to mess with writing one for sake of
compatibility.
In the two intevening days here, have you been able to find out
what the problem
Thanks for the correction!
Dan Lydick
-Original Message-
From: Jean-frederic Clere [EMAIL PROTECTED]
Sent: Oct 30, 2005 11:33 AM
To: harmony-dev@incubator.apache.org
Subject: Re: [BootJVM] configure
Jean-frederic Clere wrote:
[EMAIL PROTECTED] wrote:
Jean-Frederic,
The _first_
Jean-Frederic,
I personally would rather see the Makefile pick up
the $(JAVA_HOME) environment variable instead
of the configuration shell script. By doing it this
way, you don't have to run the configuration again
when or if JAVA_HOME changes, lest the result
be a mixture of two JDK versions.
[EMAIL PROTECTED] wrote:
Jean-Frederic,
I personally would rather see the Makefile pick up
the $(JAVA_HOME) environment variable instead
of the configuration shell script. By doing it this
way, you don't have to run the configuration again
when or if JAVA_HOME changes, lest the result
be a
Tim Ellison wrote:
Off tanget, but IMHO this is not strictly true: it depends on whether
VM native code relies on finalize() to free up its (non-heap) memory.
Here's an exmaple of this:
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4797189
That problem doesn't occur with GNU Classpath
[EMAIL PROTECTED] wrote:
We're all in this together.
Amen
--
Stefano.
Archie Cobbs wrote:
Tim Ellison wrote:
Off tanget, but IMHO this is not strictly true: it depends on whether
VM native code relies on finalize() to free up its (non-heap) memory.
Here's an exmaple of this:
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4797189
That problem doesn't
AFAIK IKVM, sablevm and jamvm all run on portable devices.
Developing a j2me jvm is not as easier as it seens, first, the
footprint and execution performance must be really optimized, so
expect a LOT of assembly coding.
After that, a jvm that runs in no device is pretty much useless, then
we
Hi,
I would like to propose the following patch:
+++
[EMAIL PROTECTED]:~/harmony/enhanced/trunk/sandbox/contribs/bootjvm/bootJVM
svn diff jvm/src/opcode.c
Index: jvm/src/opcode.c
===
--- jvm/src/opcode.c(revision 329310)
+++
Do you really mean J2ME for a specific purpose?
What we want to do here is a modular system to which you can easily
replace parts as appropriate for your usage, either to port to a new
platform or usage/performance profile
I think that you'll be fairly satisfied with what we come up
Thanks! Keep it coming!
geir
On Oct 28, 2005, at 5:17 PM, Jean-frederic Clere wrote:
Geir Magnusson Jr. wrote:
If you wish to contribute this, could you post it to a JIRA?
Until I get commit rights ;-)
It is now: http://issues.apache.org/jira/browse/HARMONY-10
Now I go for the
Robin - can you post this to a JIRA please?
geir
On Oct 29, 2005, at 1:57 AM, Robin Garner wrote:
In the garbage collectors I've worked with, the essential design is:
- 'new' allocates space on the heap.
- The header of each object contains a pointer (or equiv) to a
per-class
data
On Oct 29, 2005, at 9:22 AM, Mark Wielaard wrote:
Hi Geir,
On Wed, 2005-10-12 at 10:11 -0400, Geir Magnusson Jr. wrote:
For example, create a new subclass of Exception that doesn't look
like ...
public class FooException extends Exception {
public FooException() {
}
public
Any chance of a JIRA so that doesn't fall through the cracks? :)
geir
On Oct 30, 2005, at 12:33 PM, Jean-frederic Clere wrote:
Jean-frederic Clere wrote:
[EMAIL PROTECTED] wrote:
Jean-Frederic,
The _first_ thin to do is:
$ svn update
$ rm -rf ./config
$ ./config.sh
You will notice
So what does that interface look like? Have any suggestions?
geir
On Oct 30, 2005, at 8:51 PM, Steve Shih-wei Liao wrote:
Sure. (I had been out of country until last weekend.)
Since there is a reason to support both JITs and interpreters, we
should
keep the option open to have
Jean-Frederic,
This is the area of the code I am working on
fast and furious. I have used this macro as
a place holder to say, Stop the world! It
doesn't work yet! I am hoping to get all
of these STUB instances removed in the next
week or so when I get all the code done that
it stubs out.
Jean-Frederic,
I see. I can agree with your question
here, but notice that all this is doing is
setting a shell variable whose contents
are to be places into an included Makefile
further down. With this syntax, that Makefile
is dependent on a specific JAVA_HOME
in the environment, yet another
Done. This is issue #11.
cheers
Geir Magnusson Jr. wrote:
Robin - can you post this to a JIRA please?
geir
On Oct 29, 2005, at 1:57 AM, Robin Garner wrote:
In the garbage collectors I've worked with, the essential design is:
- 'new' allocates space on the heap.
- The header of each
Rodrigo Kumpera wrote:
AFAIK IKVM, sablevm and jamvm all run on portable devices.
Developing a j2me jvm is not as easier as it seens, first, the
footprint and execution performance must be really optimized, so
expect a LOT of assembly coding.
Back to the language wars again :) This does
22 matches
Mail list logo
