Any ideas for binary compatibility for the micro revisions?
I recently discovered that a library compiled against 1.8.3
would core dump when used with an application compiled
against 1.8.5. Operationally, not a big deal, really; I just
recompiled the lib, but emotionally, it did give
Hi Neil!
Neil Jerram [EMAIL PROTECTED] writes:
This all sounds pretty compelling to me. From my point of view, you
and Han-Wen have the most knowledge of this area, and Han-Wen has one
of the most demanding applications - so if you and Han-Wen are happy
to go ahead, I'm happy too.
Great.
Hi Linas,
Linas Vepstas [EMAIL PROTECTED] writes:
Any ideas for binary compatibility for the micro revisions?
I recently discovered that a library compiled against 1.8.3
would core dump when used with an application compiled
against 1.8.5.
Do you remember what caused it?
I don't remember
Hi Linas,
On Tue 11 Nov 2008 04:44, Linas Vepstas [EMAIL PROTECTED] writes:
2008/11/10 Neil Jerram [EMAIL PROTECTED]:
I also think it will help us manage API incompatibilities better. I
think our default position from now on should be to maintain
source-level (API) compatibility, but it is
On Tue 11 Nov 2008 21:11, [EMAIL PROTECTED] (Ludovic Courtès) writes:
I think the best we can do is keep the thing in a separate branch.
Sure.
Does that seem like a reasonable plan?
Some benchmarking would be really nice ;-)
Like these for example:
Hello!
Neil Jerram [EMAIL PROTECTED] writes:
In my view, the most important thing for Guile's near-to-medium-term
future is focus. By that I mean having developers working on, and
users using, as far as possible, a similar level of code. In the
past, we did big jumps - from 1.4.x to 1.6.x,
Hello,
I just pushed the BDW-GC branch to Savannah:
http://git.savannah.gnu.org/gitweb/?p=guile.git;a=shortlog;h=refs/heads/boehm-demers-weiser-gc
The machinery and benchmarks I used are available under the
`gc-benchmarks' directory:
2008/11/11 Andy Wingo [EMAIL PROTECTED]:
Any ideas for binary compatibility for the micro revisions?
I think it needs to be guaranteed.
I recently discovered that a library compiled against 1.8.3
would core dump when used with an application compiled
against 1.8.5.
Ludovic asked:
Do you
Quoth Neil Jerram [EMAIL PROTECTED]:
In my view, when we add in [the community focus] angle, the steady new
feature model is better.
As a non-developer, but committed user, I couldn't agree more.
Sebastian
Hi,
On Tue 11 Nov 2008 22:05, Linas Vepstas [EMAIL PROTECTED] writes:
2008/11/11 Andy Wingo [EMAIL PROTECTED]:
--enable-threads, or vice versa. Probably what happened to you?
Don't think so. The 1.8.3 was from Ubuntu Hardy. I assume
it had threads turned on
Nope, Debian builds
A brief note:
Piqued by the need to document GHIL, I noticed a lack of Replage (noun,
in the state of repl) in the GHIL language. No more!
scheme@(guile-user) ,language ghil
Guile High Intermediate Language (GHIL) interpreter 0.3 on Guile 1.9.0
Copyright (C) 2001-2008 Free Software
Neil Jerram escreveu:
So, what do you think? There have been discussions of release
strategy in the past, which I've seen as 50/50 between the split
stable and development model (which we have now) and the steady new
feature model (described above), but I don't recall them considering
the
12 matches
Mail list logo
