Re: Guile news for the GNU Status Report

2011-01-17 Thread Ludovic Courtès
Hi Neil,

Thanks for your feedback.

Neil Jerram n...@ossau.uklinux.net writes:

 Guile 2.0 is a breakthrough in Guile's history.  First and foremost, it
 is based on a compiler and a virtual machine.  The compiler compiles
 Scheme code to bytecode, applying well-known optimizations.  As a
 result, Scheme code runs noticeably faster with Guile 2.0.  Compilation
 can occur transparently: when the compiled form of a module is not found
 in cache, it is automatically compiled before being run.

 People might assume that this means Guile is now less supporting of
 interactive programming than in previous releases.  I think it would be
 worth adding a sentence to clarify that this is not the case.  Perhaps
 Note that Guile still supports interactive programming, i.e. modifying
 code in running programs, just as extensively as it has in previous
 releases.

In the meantime I had changed this paragraph to mention the REPL and
debugger:

  Guile 2.0 is a breakthrough in Guile's history.  First and foremost,
  it is based on a compiler and a virtual machine, and comes with a
  powerful read-eval-print loop (REPL) and debugger.  The compiler
  compiles Scheme code to bytecode, blah blah blah

How does this address your concern?

Normally the status report should have been published by now, but it
hasn’t, so I may/might still be able to change it.

Thanks,
Ludo’.



Re: rfi: hash set

2011-01-17 Thread Ludovic Courtès
Hi Noah!

Noah Lavine noah.b.lav...@gmail.com writes:

 I started looking into implementing this, and I ran into something
 strange that I'd like clarification on. Am I correct in saying that
 currently, hash tables can only shrink by one size index when they are
 rehashed?

Yes, your analysis looks correct to me.  Would you like to look into
fixing this?  :-)

I suppose the trick would be to regularly recompile ‘min_size_index’
based on the current ‘SCM_HASHTABLE_N_ITEMS’, iterating on
HASHTABLE_SIZE, starting from the current ‘min_size_index’.

Thanks,
Ludo’.




Re: PEG Parser

2011-01-17 Thread Ludovic Courtès
Hi!

Thanks for looking into this!  Perhaps Andy has some insight to share,
too?

Noah Lavine noah.b.lav...@gmail.com writes:

 First of all, it passes its test suite. This is pretty good, because
 its test suite includes a grammar for itself, a grammar for basic
 mathematical equations, and a grammar for parsing /etc/passwd files.
 These all seem like good examples of things you'd want to parse.

While these are nice, small unit tests targeting specific parts of PEG
would seem useful to me, as in the rest of Guile.  This may not be
blocking, though.

[...]

 The only thing that seemed really weird is the macro safe-bind, which
 basically reimplements hygienic macros. It's used all over the place
 in the function-generating code. I also saw a couple of lines that
 were too long, but not many, and the whole thing could be split into a
 few modules, but it's not that long the way it is, so neither of those
 seem like big issues. It could also stand to have a bigger test suite
 (as the test suite itself says).

“./check-guile --coverage peg.test” can be used to measure code
coverage, normally.

I agree that PEG could be useful.

Thanks,
Ludo’.




Re: Sputnik test result (was Re: ECMAScript support broken?)

2011-01-17 Thread Ludovic Courtès
Hi,

Thanks for looking into this!

Noah Lavine noah.b.lav...@gmail.com writes:

 The attached patch should add support for ECMAScript unicode literals.

I applied this one, along with corresponding test cases.

Can you please resubmit the remaining patches with test case(s) for
each, and each in a thread of its own?

Thanks,
Ludo’.