Re: i18n broken on mingw cross compile
Hi, Han-Wen Nienhuys <[EMAIL PROTECTED]> writes: > Could you publish your changes through savannah as well? Like where? I could attach it to a bug report but there's none, which is reasonable since it affects the development branch. I usually find it convenient to grab the attachment and apply it with `patch'. Thanks, Ludo'.
Re: [PATCH] Revise GC asserts.
Hi, Han-Wen Nienhuys <[EMAIL PROTECTED]> writes: > * libguile/gc.c (scm_i_gc): Change assert into deprecation warning. Why? It's not a deprecation but really an invariant, right? > * libguile/private-gc.h (nil): introduce scm_i_last_marked_cell_count, > as a private mechanism for maintaining cell counts. Previous > versions incremented scm_cells_allocated in an inlined function, so > loading dynamic objects of older GUILEs would break invariants. OTOH, if we are to change the way `scm_cells_allocated' is used and don't want older code to interfere with that, it's safe the break the ABI here (we're on `master' after all). Thus I would vote in favor of making `scm_cells_allocated' internal (which requires that no public macro or inline function refer to it) or renaming it, e.g., to `scm_i_cells_allocated'. BTW, can you add a one-line summary to the log, as is done on `master', `vm', etc.? Thanks! Ludo'.
Re: GUILE_MAX_HEAP_SIZE
Han-Wen Nienhuys <[EMAIL PROTECTED]> writes: > commit 53f4876abcebf3f05d2a88bba3a898ddcda25a74 > Merge: 69f2317... 242ebea... > Author: Ludovic Courtès <[EMAIL PROTECTED]> > Date: Tue Sep 9 22:03:42 2008 +0200 > > Merge branch 'master' into strftime-gnulib > > Conflicts: > libguile/ChangeLog > srfi/ChangeLog > test-suite/ChangeLog > > > I thought we were supposed to keep the history linear; did I > miss something? No, *I* did. Strange, I didn't notice it in "git whatchanged", and I don't get why there were conflicts in the first place since said files were left untouched... Thanks, Ludo'.
Re: Cleanup mark-during-GC debug checks.
Hi, Han-Wen Nienhuys <[EMAIL PROTECTED]> writes: > Ludovic Courtès escreveu: >> 1. I don't want to use a web interface to review code. Most free >> software projects use email in one form or another, which I find >> convenient. Having patches in-lined is optimal IMO. > > My experience is that a web interface (which tracks different versions of > the same patch) is a lot easier when it is a major change with lots of > revisions. It's really a matter of taste. I prefer email and/or topic branch in Git. >> * I'd name the macro `SCM_DEBUG_MARK_PHASE' rather, as it sounds mot >> idiomatic (but I'm not a native speaker). > > It's rather the reverse: ensuring that the non-mark phase is correct (in > not having mark calls), but I couldn't think of a good name. My comment was about "marking phase" vs. "mark phase". >> * Use "static const char msg[] = ...". > > done. OK, feel free to push! Hope we'll keep compiling with `SCM_DEBUG_MARK_PHASE == 1'! :-) Thanks, Ludo'.
Re: vm branch now uses vm repl by default
Hi, On Wed 10 Sep 2008 00:43, "Neil Jerram" <[EMAIL PROTECTED]> writes: > I guess source information is of interest for debugging Of course :) > you've observed previously elsewhere that the VM doesn't yet have much > debugging support - by which I presume you mean something like the > traps that the evaluator has. Oh it has some. Here are the hooks: vm-next-hook vm-apply-hook vm-boot-hook vm-return-hook vm-break-hook vm-exit-hook vm-halt-hook vm-enter-hook They sound sufficient, but perhaps more could be added. Unless I misunderstand what the traps do (which is likely). > So I was just wondering if we actually _need_ any debugging support in > the VM. Certainly we do for debugging the VM itself. But besides that, if the VM will be the way that people will want to run their programs, they need good backtraces at the very least. Which implies at least source information. I think the only thing that is missing at this point is procedure names (which I haven't spent enough time figuring out how to push them down the compilation pipeline, but the support is there), and spaghetti stacks, which are also needed to support call/cc. > Then another question is whether we can assume that the VM behaves > equivalently to the evaluator. I think that this is a precondition for merging vm to master. > code that doesn't have side effects? If you believe that, I've got a type system in Scotland I'd like to sell you ;-) Peace, Andy -- http://wingolog.org/
Re: Cleanup mark-during-GC debug checks.
On Wed 10 Sep 2008 03:13, Han-Wen Nienhuys <[EMAIL PROTECTED]> writes: > My experience is that a web interface (which tracks different versions of > the same patch) is a lot easier when it is a major change with lots of > revisions. I can definitely see the value in this. But to take discussions away from the list probably isn't the way to go ;) > In general, I find cutting & pasting patches into emails clumsy and error > prone. In general, git is much better suited for sending patches around. Yep, to make a git-request-pull message is easier, can just pipe to a mailer. Seriously, git needs bundle buggy! http://bundlebuggy.aaronbentley.com/ Piling on a bikeshed, Andy -- http://wingolog.org/
Re: vm branch now uses vm repl by default
Howdy, On Tue 09 Sep 2008 23:01, [EMAIL PROTECTED] (Ludovic Courtès) writes: >> On Tue 09 Sep 2008 10:41, [EMAIL PROTECTED] (Ludovic Courtès) writes: > >>> It'd be nice if we could find a way to "do something" with the >>> `current-reader' fluid at compilation time, like detecting top-level >>> `(fluid-set! current-reader ...)' statements and use that to switch the >>> compiler's reader (hacky...). > > A use case is the following: > > (define-module (foo)) > > (fluid-set! current-reader %my-favorite-reader) > > ;; use non-standard syntax extensions from now on This doesn't map very well to the current semantics of "guile-vm" -- I was going to say "the compiler", but the compiler's fine with whatever, it's more "the expected model of compilation" or something. Currently when compiling an entire file, the entire file is read in and compiled to bytecode as if it were all wrapped in a `begin'. The whole file is compiled at once, because it was all read in at once. But that means we have no semantic meaning to extract from the code at read-time. What to do? I would suggest going down a common-lispy route, and introducing read macros. This is pretty firmly extension land anyway. Or, you could write a custom compiler for skribilo -- probably four hours' work or so. > Anyway, if we are to handle this at all, we're probably going to have to > pattern-match this in `translate.scm' and switch readers when we > encounter it. Ew. You are a bad person ;) Cheers, Andy -- http://wingolog.org/
Re: [PATCH] Avoid `SCM_VALIDATE_LIST ()'
2008/9/9 Ludovic Courtès <[EMAIL PROTECTED]>: > Hi Neil, > > "Neil Jerram" <[EMAIL PROTECTED]> writes: > >> Snapshots as of now are up at >> http://www.ossau.uklinux.net/guile/snapshots, and I hope they will >> keep automagically appearing there. > > Looks good! I think you can already update the web page since the > current link is broken anyway. I've done that now. Neil
Re: Guile automated builds available
Hi Ludo, sorry that this is so late...! 2008/8/12 Ludovic Courtès <[EMAIL PROTECTED]>: > Hello, > > I've installed a daily build process on some of the GCC Compile Farm > Project's machines [0], currently covering 3 architectures (sparc64, > alphaev56 and x86-64), all under GNU/Linux, with different versions of > GCC. From now on, the build should run at around 3pm UTC every day. > Build logs are sent by mail to Simon Josefsson's Autobuild service [1] > and can be seen here: > > http://autobuild.josefsson.org/guile/ This looks really useful! > I use a simple script (attached) that invokes Autobuild's m4 macro [2]. > I'm wondering whether it would be a good idea to include it in releases, > and tell people they can run > "./configure && make check | mail [EMAIL PROTECTED]" so that > we get more build results. > > Thoughts? I think that's an excellent idea. Just to check that I'm understanding correctly: I believe you mean just adding AB_INIT to configure.in, and the source for AB_INIT to acinclude.m4; is that right? Regards, Neil
Re: vm branch now uses vm repl by default
2008/9/10 Andy Wingo <[EMAIL PROTECTED]>: > > Oh it has some. Here are the hooks: > >vm-next-hook vm-apply-hook vm-boot-hook vm-return-hook >vm-break-hook vm-exit-hook vm-halt-hook vm-enter-hook > > They sound sufficient, but perhaps more could be added. Unless I > misunderstand what the traps do (which is likely). No, I agree that those sound sufficient. > Certainly we do for debugging the VM itself. But besides that, if the VM > will be the way that people will want to run their programs, they need > good backtraces at the very least. Yes, of course, silly me. (I was thinking too much about breakpoints and single-stepping, forgot about the basic error case.) Regards, Neil
Re: boot-9 compiling in guile-vm
2008/9/8 Andy Wingo <[EMAIL PROTECTED]>:
> Hi,
>
> I finally pushed some patches I had that enable compilation of
> boot-9.scm in guile-vm. Give it a pull. NB, you'll have to rebuild all
> your .go files -- make clean before making.
I just pulled and built: got this error...
vm-engine.c: In function 'vm_run':
vm-engine.c:199: error: unable to find a register to spill in class 'SIREG'
vm-engine.c:199: error: this is the insn:
(insn:HI 3845 3844 3846 406 vm.c:83 (parallel [
(set (reg:SI 2 cx [1190])
(const_int 0 [0x0]))
(set (reg/f:SI 5 di [orig:1188 .stack_base ] [1188])
(plus:SI (ashift:SI (reg:SI 2 cx [1190])
(const_int 2 [0x2]))
(reg/f:SI 5 di [orig:1188 .stack_base ] [1188])))
(set (reg:SI 1 dx [1189])
(plus:SI (ashift:SI (reg:SI 2 cx [1190])
(const_int 2 [0x2]))
(reg:SI 1 dx [1189])))
(set (mem:BLK (reg/f:SI 5 di [orig:1188
.stack_base ] [1188]) [0 A8])
(mem:BLK (reg:SI 1 dx [1189]) [0 A8]))
(use (reg:SI 2 cx [1190]))
(use (reg:SI 19 dirflag))
]) 704 {*rep_movsi} (insn_list:REG_DEP_TRUE 3843
(insn_list:REG_DEP_TRUE 3844 (nil)))
(expr_list:REG_UNUSED (reg:SI 1 dx [1189])
(expr_list:REG_UNUSED (reg/f:SI 5 di [orig:1188
.stack_base ] [1188])
(expr_list:REG_UNUSED (reg:SI 2 cx [1190])
(expr_list:REG_DEAD (reg:SI 19 dirflag)
(expr_list:REG_UNUSED (reg:SI 1 dx [1189])
(expr_list:REG_UNUSED (reg/f:SI 5 di
[orig:1188 .stack_base ] [1188])
(expr_list:REG_UNUSED (reg:SI 2 cx [1190])
(nil)
vm-engine.c:199: confused by earlier errors, bailing out
... which seems fantastic, because I've never seen GCC decide to dump
so much detailed bytecode information before, or to admit that it is
confused :-). Does GCC know that we're trying to build another kind
of bytecode engine here?
Anyway, any suggestions? I guess my GCC could be too old, but it
doesn't look it:
[EMAIL PROTECTED]:~/guile$ gcc -v
Using built-in specs.
Target: i486-linux-gnu
Configured with: ../src/configure -v
--enable-languages=c,c++,fortran,objc,obj-c++,treelang --prefix=/usr
--enable-shared --with-system-zlib --libexecdir=/usr/lib
--without-included-gettext --enable-threads=posix --enable-nls
--program-suffix=-4.1 --enable-__cxa_atexit --enable-clocale=gnu
--enable-libstdcxx-debug --enable-mpfr --with-tune=i686
--enable-checking=release i486-linux-gnu
Thread model: posix
gcc version 4.1.2 20061115 (prerelease) (Debian 4.1.1-21)
Regards,
Neil
Re: [PATCH] Revise GC asserts.
Ludovic Courtès escreveu: >> * libguile/gc.c (scm_i_gc): Change assert into deprecation warning. > > Why? It's not a deprecation but really an invariant, right? Yes, but it probably does not warrant crashing the program; memory allocation sizes will just be a bit off as a result. > Thus I would vote in favor of making `scm_cells_allocated' internal > (which requires that no public macro or inline function refer to it) or > renaming it, e.g., to `scm_i_cells_allocated'. Let's just remove the variable, since scm_i_last_marked_cell_count is a more exact name. > BTW, can you add a one-line summary to the log, as is done on `master', > `vm', etc.? The custom is (see git-format-patch) that the subject line is the summary. -- Han-Wen Nienhuys - [EMAIL PROTECTED] - http://www.xs4all.nl/~hanwen
