Re: Guile release planning
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 me that sinking feeling for a while, of maybe having yet another hard-to-find bug, or a system I cannot fully trust. :-( The first question is if there was a shlib minor version bump. But, if it were the other way around it would be bad. It is not expected in general that you can use older libraries than what you built against. But, building against 1.8.3 and then updating to 1.8.5 should be ok. pgpZks8eh1jNE.pgp Description: PGP signature
Re: Why bother porting Guile to BDW-GC?
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. I hope others view these arguments as compelling, too. Just in case some really hard problem emerges, is it possible to organize the development so that we could retain the option for a while - say, a few months - to switch back? I think the best we can do is keep the thing in a separate branch. It's already too late to have, say, a configure-time option to choose GCs (because I did not plan to do this when I started). It would have been quite hard anyway since the current GC code is quite entangled with the rest of Guile in some places. Does that seem like a reasonable plan? Thanks, Ludo'.
Re: Guile release planning
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 of any ABI change in the 1.8.x series (apart from function additions). The with-threads and without-threads Guiles are not ABI-compatible, though. Thanks, Ludo'.
Re: Guile release planning
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 inevitable that there will be exceptions to this. 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. Ooh, bummer. The 1.8 series is binary-compatible (i.e. 1.8.x is compatible with 1.8.y if x = y), *but* only if compiled in the same way. An example of compiling in different ways is if you build against a guile with --disable-threads, but then rebuild guile with --enable-threads, or vice versa. Probably what happened to you? The linux kernel got rid of the stable/unstable branch idea, and it's worked really really well. (the reasons why are widely documented) I'm for it. The linux kernel doesn't guarantee ABI /or/ API stability -- it's a different kettle of fish. Cheers, Andy -- http://wingolog.org/
Re: Why bother porting Guile to BDW-GC?
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: http://www.ccs.neu.edu/home/will/Twobit/benchmarksAbout.html Andy -- http://wingolog.org/
Re: Guile release planning
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, and from 1.6.x to 1.8.x - which I think left users unable easily to upgrade, or perhaps just unsure of whether to upgrade. From the developer point of view, they increased the support burden (because of some users staying with the old series). Also the big jump model can be frustrating for developers, because it tends to mean that there is a long time between when a shiny new feature is ready, and when it gets released and so into the hands of most users. I fully agree with this, but... Your note doesn't take binary compatibility into account, and I think it's an important thing, too. I think the ideal is to maintain binary compatibility within a major series, as we've done (or tried to do) in the 1.8.x series. This is very convenient for binary distributions like Debian, and for users in general. Thus, introducing ABI incompatibilities should imply increasing the first or second digit of the version number, IMO. Maintaining ABI compatibility doesn't mean we can't add new features, though. In the course of the 1.8.x series, several Scheme modules were added. I think enhancements like the lazy symbol binding in modules could have been in theory added in 1.8.x since it breaks neither the API nor the ABI. Things like `libguile-i18n' could have been added too, but the issue when adding C code is portability: it may be that this module would have caused build issues on some platforms. Now, with more frequent releases, it would be reasonable to hope that such regressions would quickly be fixed. Another thing is actual big jumps. I think the addition of the VM is a big jump. A GC change, or a rewrite of the string/char code with Unicode support would be a big jump, too. Such big jumps surely need a new major release. BTW, we need to consider releasing 1.8.6 one of these days! ;-) Thanks! Ludo'.
Re: Why bother porting Guile to BDW-GC?
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: http://git.savannah.gnu.org/gitweb/?p=guile.git;a=tree;f=gc-benchmarks;hb=refs/heads/boehm-demers-weiser-gc Thanks, Ludo'.
Re: Guile release planning
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 remember what caused it? I didn't bother to investigate; I recomipled and the problem went away. --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; but I wasn't yet using threads at that time, so I don't know. The 1.8.5 was self-built. I did not specify --enable-threads, this seemed to be on automatically. --linas
Re: Guile release planning
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
Re: Guile release planning
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 --without-threads. The 1.8.5 was self-built. I did not specify --enable-threads, this seemed to be on automatically. Voilà. Andy -- http://wingolog.org/
ghil repl
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 Foundation, Inc. Enter `,help' for help. ghil@(guile-user) foo $1 = foo Ooooh! ghil@ means that the input language is GHIL, or rather, the external representation of GHIL in S-expressions. Self-quoting values translate into ghil-quote instances, which, when compiled and executed, evaluate to results: above, foo. ghil@(guile-user) (values 1 2 '(3 4)) $2 = 1 $3 = 2 $4 = (3 4) But self-quoting values are a degenerate case. Besides bare symbols, which translate into ghil-ref instances, the external representation of GHIL is a tagged list, whose interpretation depends on the tag. In this case, `values' corresponds to ghil-values, which ends up returning multiple values. ghil@(guile-user) (values* 1 2 '(3 4)) $5 = 1 $6 = 2 $7 = 3 $8 = 4 Here we see values* -- used by the scheme compiler in the (apply values ...) idiom. ghil@(guile-user) (lambda (x) #f () (call * x x)) $9 = #program #(3 18 #f) (x) The form of the `lambda' GHIL construct is not the same as scheme's lambda, though they are functionally equivalent. Its form goes like this: (lambda ARGS REST? META . BODY) Here the args are (), there are no rest arguments, and no meta-information. The body is a call expression: (call PROC . ARGS) Here we call `*' with x and x. ghil@(guile-user) (call $9 5) $10 = 25 Incidentally, $9 is a ghil-ref instance. ghil@(guile-user) (call (lambda (a b) #f () (inline add a b)) 10 20) $11 = 30 An illustration of procedural values and ghil-inline. The whole range of forms understood as external representations of GHIL will be documented, but for now it may be seen in parse-ghil in module/system/il/ghil.scm. The tags are: quote void lambda begin bind bindrec set! define if and or mv-bind call mv-call inline values values* compile-time-environment quasiquote Happy hacking! Andy -- http://wingolog.org/
Re: Guile release planning
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 overall community focus angle before. In my view, when we add in that angle, the steady new feature model is better. One angle that we could take is time based release planning, like GNOME and Fedora do: plan to do one or two releases per year on a rigid schedule. The LilyPond 2.11 vs. 2.12 jump has been delaying for too long, but I generally do a biweekly release, which is stable enough to reasonably be called 'stable', and it has worked very well so far. The precondition for this is that there is a good test-suite so we can be sure that a release that passes the tests is good. -- Han-Wen Nienhuys - [EMAIL PROTECTED] - http://www.xs4all.nl/~hanwen
