Re: development goals
Hey! "Neil Jerram" <[EMAIL PROTECTED]> writes: > For me, almost all of my time since becoming a maintainer has been > absorbed by working on bug fixes, largely to do with slightly odd > platforms (e.g. Mac) or architectures (e.g. ia64). IMO it was > worthwhile to focus on such bug reports soon after they were reported, > because (i) the reporters are still around and interested enough to be > able to provide more info and test fixes, (ii) I believe that running > on more platforms will be good for the Guile community, and for Guile > applications. Same here. But everyone is welcome to help fix bugs! :-) > Basically, my feeling is that Guile users have been badly burned by > major release incompatibilities in the past, and I really don't want > that to happen again. Therefore my "straw man" plan is that > > - we stay on 1.8.x for a while Which IMO means fixing portability bugs and the likes. > - we treat "master" as a pot of goodies, which we aim incrementally to > merge across and release as part of the 1.8.x series The problem is that some of them might be subtly incompatible, mostly because a lot of internals have been exposed and actually used. I think it's good to have API and possibly ABI-compatibility within a major release, so that "1.8.x" really means something, for any value of `x'; requiring "x >= something" is acceptable IMO (we already have this, e.g., with modules that got added in 1.8), but "a <= x <= b" isn't. > - we don't do a big jump to 1.10.x, by just deciding to do so at some > time (+ a bit of pretesting), because I don't feel confident that we > can properly consider and document all of the 1.8 .. 1.10 > compatibility issues at once. I agree that we should reduce the gap between any two major releases. > But #1 : as I said above, I'm pretty sure Ludovic disagrees with this! It's not all black & white. ;-) > I believe that programmers' natural tendency is to plan for infinite > compatibility. +1. (That is especially true in Guile land where many projects are small and developed only on people's spare time, whom you can't expect to dedicate time switching APIs.) > There you're right. We can and should rip GH out now. Actually that > might make an excellent first example for documenting incompatibility. > (Anyone who really still needs it can take on the burden of > maintaining the GH layer themselves.) IMO, if it doesn't cost anything to keep it (beside `.so' size), let's keep it. Thanks, Ludo'.
Re: development goals
Hi Han-Wen, You're confrontational, indeed. Han-Wen Nienhuys <[EMAIL PROTECTED]> writes: > - Rolling back a patch is preferred over fixing actual problems. What makes you say so? > - Nobody has enough initiative to put a single strategic #ifdef in the > code. To me, it looks like the "strategic #if 0" was a way of admitting that we know our code is broken, we don't know why, and we don't want to investigate that ATM but we might eventually do that if we have time. So no, I didn't feel that happy with this. > - If someone finally does take initiative, it's only ok if it is > perfect. Yeah, that "#if 0" was just per-fect, thank you very much. I have the impression that I'm under attack. ;-) It turns out that I'm working on Guile in my spare time, which is scarce. Surely I could do better work if only I spent more time on Guile, I could take more initiatives because I would be confident that if I do break something I can work something out. > You might construe that I would like to turn Guile development into > LilyPond development. That is not necessarily the case, but I keep > misunderstanding what people expect in this community. I am assuming > that developers in general are interested in a more lively and more > rapid evolution of Guile, but everytime I see habits and policies that > seem contrary to that goal. How many people fix bugs reported to `bug-guile'? Believe me, spending time doing this makes you feel reluctant to large unmotivated changes. > Then again, with all the back & forth porting of changes between 1.8 > and head, it's difficult to tell what is in 1.8 and what is not. Surely you'll enjoy it: we have an old-fashioned tradition of updating `NEWS' when changing something in a branch! :-) Thanks, Ludo'.
Re: [PATCH] Avoid `SCM_VALIDATE_LIST ()'
Hi,
Clinton Ebadi <[EMAIL PROTECTED]> writes:
> Perhaps a macro could be used instead (is it possible to pass entire
> blocks of code to a macro using something like CYCLE_DETECTING({
> code ... }) in C?).
Sure, something like `scm_i_for_each (element, list)' that expands to a
tortoise-and-hare test.
Thanks,
Ludo'.
Re: Race condition in threading code?
Hi Julian, "Julian Graham" <[EMAIL PROTECTED]> writes: > ...And then I just reapplied the fix by hand because it was only one > line. :) A patch against the branch is attached. Let me know if > there are any problems with it. Perfect, thanks! I added a `NEWS' entry as well. Ludo'.
Re: [PATCH] Avoid `SCM_VALIDATE_LIST ()'
Hello! "Neil Jerram" <[EMAIL PROTECTED]> writes: > I'm sorry but I'm still really struggling to see how this change helps us... Yes, I see... ;-) I'm taking it the other way: I can't see how one can argue for unneeded run-time overhead. > 2008/9/1 Ludovic Courtès <[EMAIL PROTECTED]>: >> You're right, but it's always better to traverse the list once rather >> than twice. :-) > > Not necessarily. It depends what happens inside the loop, on each > iteration, and whether the iteration time is significant in comparison > with that. I'd say it's better regardless of what's inside the loop. Sure, one may argue that `memq' is rarely used with million-of-element lists anyway, because other methods would be used in such situations (hash tables, etc.). But that's not necessarily the case with `reverse', `partition', etc. > What overhead? (Quantifiably, I mean.) In terms of profile dumps, a full run of the test suite under Callgrind reveals that `scm_ilength ()' is *not* in the top 10. But hey, one could surely come up with a Real World(TM) application that does a lot of list processing and is measurably impacted by that double traversal. > I don't believe anyone's worked this all out yet, but, for example, if > the arg to scm_reverse() was generated by some other function that is > known only to produce proper lists, then the arg might be represented > as ( . the-actual-list), and obviously then the > SCM_VALIDATE_LIST in scm_reverse() can be completely skipped. If the > validation code is interleaved with the actually-doing-something code, > it becomes more difficult to skip (in some hypothetical future). How would you remove those checks from compiled code like `list.o'? Guile-VM, OTOH, may have clear opportunities to optimize away certain cases at compilation time. > Do we really need to continue this discussion? Maybe not. To be honest, I didn't expect I'd have to argue about this in the first place. I see it as a (maybe small, application-dependent) benefit, while I have the impression that you regard it solely as a "possible breakage" and as "code churning". Probably we disagree because we don't value the same things here. Thanks, Ludo'.
Re: development goals
Ludovic Courtès escreveu: >> You might construe that I would like to turn Guile development into >> LilyPond development. That is not necessarily the case, but I keep >> misunderstanding what people expect in this community. I am assuming >> that developers in general are interested in a more lively and more >> rapid evolution of Guile, but everytime I see habits and policies that >> seem contrary to that goal. > > How many people fix bugs reported to `bug-guile'? Believe me, spending > time doing this makes you feel reluctant to large unmotivated changes. Good point. I've just added myself to that list. >> Then again, with all the back & forth porting of changes between 1.8 >> and head, it's difficult to tell what is in 1.8 and what is not. > > Surely you'll enjoy it: we have an old-fashioned tradition of updating > `NEWS' when changing something in a branch! :-) Well, yes, but we also have many commits that are identified as "Changes from Arch/CVS synchronization" and "merge from 1.8" I tend to look at development history with gitk. I realize these commits are from the CVS era, but it makes me loose track of what is happening where. -- Han-Wen Nienhuys - [EMAIL PROTECTED] - http://www.xs4all.nl/~hanwen
Re: [PATCH] Avoid `SCM_VALIDATE_LIST ()'
2008/9/7 Neil Jerram <[EMAIL PROTECTED]>: > 2008/9/7 Ken Raeburn <[EMAIL PROTECTED]>: >> >> Still keeping it in the back of my mind, but first my attempts to use SVK to >> mirror the Emacs repository broke (naturally, after it had looked solid >> enough that I had switched to it for my Emacs development work), and now >> Guile uses git, which I've never picked up, and some Emacs folks are talking >> about changing to yet another source control system. (BTW, are people aware >> that the www.gnu.org pages for guile list an ftp snapshot site that has in >> fact not been updated since last September? For people not interested in >> downloading, installing, and learning N new source control systems, daily or >> weekly snapshots are handy.) > > Noted, thanks. I'll try to fix that up. Snapshots as of now are up at http://www.ossau.uklinux.net/guile/snapshots, and I hope they will keep automagically appearing there. In case anyone feels like reviewing and commenting on it, I've also uploaded the `make-snap' script that generates these, in the same directory. If all seems well after a few days, I'll update the www.gnu.org pages accordingly. Neil
GC asserts and threads
Hi there, I'm debugging an issue here that cause the GC asserts to trigger, with the values compared being off by one. The problem disappears when I compile --without-threads. The program does not explicitly create threads Is there any code in GUILE that would create a thread (possibly leading to race conditions) when there is no explicit start-thread call in the code? The program (lilypond) does run through the regular GUILE boot procedure. -- Han-Wen Nienhuys - [EMAIL PROTECTED] - http://www.xs4all.nl/~hanwen
vm branch now uses vm repl by default
Hi, I've enabled the VM repl by default on the vm branch. Here's a brief annotated tour: $ ./pre-inst-guile Guile Scheme interpreter 0.5 on Guile 1.9.0 Copyright (C) 2001-2008 Free Software Foundation, Inc. Enter `,help' for help. A very pleasant introduction, no? And totally configurable with a nice programming interface. scheme@(guile-user)> 'foo $1 = foo A normal repl. The `scheme' indicates the current language, and (guile-user) is the current module. The $1 = foo is from the history module. If you don't have this in your ~/.guile, you really really want it: (use-modules (ice-9 readline) (ice-9 history)) (activate-readline) Anyway, moving on: scheme@(guile-user)> (lambda () (pk a #:bar)) $2 = # Entering in expressions actually compiles and executes them. In this case we compiled and loaded a thunk. Compiled procedures are "programs", and print as such. scheme@(guile-user)> (define a '(a . pair)) scheme@(guile-user)> ($2) ;;; ((a . pair) #:bar) $3 = #:bar Procedures resolve toplevel bindings lazily, as in the interpreter, so you get letrec semantics in the repl. scheme@(guile-user)> ,x $2 There is a wealth of meta-commands at the repl, commands that start with `,'. This command, `,x', is an abbreviation for `,disassemble'. Its output is this: Disassembly of #: nargs = 0 nrest = 0 nlocs = 0 nexts = 0 The program has no arguments, no rest arguments, no local variables, and no external (lexically-bound) variables. Bytecode: 0(late-variable-ref 0) 2(late-variable-ref 1) 4(object-ref 2) ;; #:bar 6(tail-call 2) Objects: 0#> 1# 2#:bar Late-variable-ref looks at a cell in the object vector. If it is a symbol, it is resolved relative to the module that was current when the program was made. The object cell is then replaced with the resulting resolved variable. Here we see that objects 0 and 1 were already resolved. Object 2 is just the constant, #:bar. All of the ref instructions push their values on the stack. Call instructions pop off arguments, if any, then call the program on the top of the stack. In this case it is a tail call. Sources: 8#(1 11 #f) Some instructions are annotated with source information. In this case, when the instruction pointer is at 8 (right after the tail-call -- one byte for tail-call and one for the number of arguments, 2), the original source was at line 1 and column 11 in an unnamed port (stdin in this case). scheme@(guile-user)> ,option interp #t scheme@(guile-user)> ,option trace #f interp #t Here we tell the repl that, given the option, we prefer to interpret rather than compile. Of course, if the current language doesn't support compilation, we always interpret. scheme@(guile-user)> (lambda () (pk a #:bar)) $4 = # An interpreted procedure, like in olden times. Happy hacking! Andy -- http://wingolog.org/
