harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Etienne Gagnon <egag...@sablevm.org>
Subject Re: [sablevm] SIGSEGV signal received from Cygwin
Date Sat, 08 Apr 2006 02:44:48 GMT
Enrico Migliore wrote:
> Yet, I remember, that in JCHEVM I had to remove the POPT_AUTOHELP string
> in a struct in order not to receive that signal,
> therefore, I'm pretty much sure that somewhere in the Pthread library
> there's an access to an area used to initialize constants:
> something that maybe GCC likes but Windows doesn't.
> That's just a guess.

I have to look more carfully to the port library, and see what thread
supports it provides.  I've had lots of professorish things to do over
the last days, so I didn't get enough time to look deeply.  I'll get
back to you about it.

> The documentation included in SableVM trunk is more than good.
> Therefore, I would like to try do this job. I'm not sure I'll succeed
> but I want to
> As far as the port is concerned, there are 3 things to talk about:
> build system in MSVC
> -----------------------
> to my knowledge, MSVC doesn't have a build system like UNIX (autotool +
> configure) therefore, I think that the "config.h" file will have to be
> built manually.

This shouldn't be too much of a problem.  SableVM has no intrinsict
dependence on auto* tools.  It does, however, require m4.  This could be
eliminated if we decided to allow for a Java dependency for building
(i.e. ant & sablecc-based code generator).

Yet, on shorter term, some simpler make file is feasible.  All you
actually need to build is libsablevm.dll.  There's no need for the
sablevm launcher; we already know that the harmony one works, and it is
much more complete...

> how to modify the source files?
> ------------------------------
> Let's say that removing a POSIX dependancy in a SableVM file means:
> replacing some lines of codes and replacing some include files. How am I
> suppost to deal with this kind of thing? Should I modify the trunk or my
> sandbox?

Ideally, initial work should happen in your sandbox.  This way you can
use it to do backups of your code, even when it doesn't compile, without
disturbing anybody.

I am playing with the idea of making a copy of current trunk in
sablevm/branches/last-stable, and simply allowing for a broken trunk
during the Harmony transition (not as broken as a typical sandbox;
should at least compile).

We have a strict policy on using the "svn merge" operation.  We can
discuss it the day you need it.

> how to track source modifications
> ----------------------------------
> Let's say that one source file gets modified by one of SableVM
> developers, and another is added to the trunk. Should I rely on SVN to
> know where the modifications were done?

Not sure I understand the question...  Developers may only checkin code
they wrote themselves.  This way, svn keeps a clear history of who wrote

I think this discussion should probably continue on sablevm-devel@, as
not to add too much noise into harmony-dev@.  We could, there, discuss
of work distribution among you, hadrien and me, as well as any other
interested contributor, to get a working sablevm+harmony duo as soon and
as cleanly as possible.

We should come back to this list for any topic related to the class-lib
and port library side of things.


Etienne M. Gagnon, Ph.D.            http://www.info2.uqam.ca/~egagnon/
SableVM:                                       http://www.sablevm.org/
SableCC:                                       http://www.sablecc.org/

View raw message