[PATCH 1/5] Fix "occurrances" typos in getopt-long code and test

* module/ice-9/getopt-long.scm (process-options, getopt-long): Change to "occurrences". * test-suite/tests/getopt-long.test ("multiple occurrences"): Same again. --- module/ice-9/getopt-long.scm |4 ++-- test-suite/tests/getopt-long.test |2 +- 2 files changed, 3 insertions(+), 3

[PATCH 4/5] Implement #:stop-at-first-non-option option for getopt-long

(For use by guile-tools) * module/ice-9/getopt-long.scm: Use (ice-9 optargs) so we can use define*. (process-options): Add stop-at-first-non-option parameter. When this is true, stop processing when we hit a non-option (so long as that non-option isn't something that resulted from the un

[PATCH 5/5] Reveal guile-tools's inner simplicity...

...by not using its own-rolled getopt, and moving the `list' function to a separate script * meta/guile-tools.in: Use (ice-9 getopt-long). (directory-files, strip-extensions, unique, find-submodules, list-scripts): Deleted (and moved to new `list' file). (getopt): Deleted. (main): Use g

[PATCH 2/5] Simplify getopt-long handling of option values, esp with multiple occurrences

Basically, accumulate values in the `process-options' loop variables, instead of using set-option-spec-value! * module/ice-9/getopt-long.scm (option-spec): Delete the `value' slot. (process-options): Delete `val!loop' and just use `loop' everywhere instead. When adding an option spec to `fou

[PATCH 3/5] Handle short option unclumping progressively, instead of all upfront

This is needed as a prerequisite for the following don't know how far through the command line we should go with unclumping. * module/ice-9/getopt-long.scm (expand-clumped-singles): Delete. (process-options): Add a loop variable to indicate how many elements at the start of `argument-ls' are

[PATCH] Simplifying guile-tools

Hi there! While we were discussing the name of guile-tools, back in March, I wrote: > I think I might find guile-tools (as is) less bothering if its > built-in commands (help, version and list) were rewritten as scripts > themselves. Then it would be clearer that the remaining code in > guile-to

Re: possible hash deadlock with recent changes

"Ludovic Courtès" wrote: > Hi, > > writes: > > > Recent changes to stable-2.0 seem to cause a deadlock in scwm. Here is the > > last 10 frames of a backtrace. > > I’m not sure if this is related but there’s this new error that has > started happening from time to time: > [ removed ]

Re: Some guile-unify activities

Hi Stefan, Thanks for this mail, it's interesting. On Fri 06 May 2011 23:18, Stefan Israelsson Tampe writes: > It would be good if there was a standard way to enter type information > in guile and if that information could be hooked into the tree-il > representation. But until then I will just

Re: Some guile-unify activities

Hey, Nice stuff! Stefan Israelsson Tampe writes: > 3. For the type-checking examples I've been working with the assumptions of > having fixed declarations for > lambdas and deduce types for variables and their passage through the system. > The thought is that in the end > one need to allow lamb

pull and recompile for speed

Hi, The VM and compiler got a little help this weekend. Pull and recompile your .go files and things should be faster. Pro tip: just touch module/ice-9/eval.scm and then things are moderately fast without having had to make clean. Andy -- http://wingolog.org/

Re: ‘map’ and ‘for-each’ written in Scheme

On Sun 08 May 2011 17:05, l...@gnu.org (Ludovic Courtès) writes: > Could you add benchmarks so we can see how the Scheme and C > implementations compare? Done. Current Guile: $ ./benchmark-guile srfi-1.bm Benchmarking /home/wingo/src/guile/meta/guile ... srfi-1.bm with GUILE_LOAD_PATH=/hom

‘map’ and ‘for-each’ written in Scheme

Hello! Could you add benchmarks so we can see how the Scheme and C implementations compare? For the record, the results for ‘fold’: . Thanks, Ludo’.

Re: possible hash deadlock with recent changes

Hi, writes: > Recent changes to stable-2.0 seem to cause a deadlock in scwm. Here is the > last 10 frames of a backtrace. I’m not sure if this is related but there’s this new error that has started happening from time to time: --8<---cut here---start->8---

Re: [Guile-commits] GNU Guile branch, stable-2.0, updated. v2.0.1-40-g2252321

Hi Andreas, Thanks for taking care of this, and thanks for the great doc too! "Andreas Rottmann" writes: > commit 2252321bb77fe83d98d5bcc9db1c76b914e9dd6a > Author: Andreas Rottmann > Date: Sat May 7 23:40:14 2011 +0200 > > Make the R6RS simple I/O library use conditions > > * m