Hi,
SRFI-14 doesn't take into account the current locale, mostly because
`scm_init_srfi_14 ()' gets invoked before the user has had any chance to
run code like `(setlocale ...)'. Thus, for instance, `char-set:letter'
is always initialized with the English set of letters.
Since SRFI-13 is
Hi Neil,
Neil Jerram [EMAIL PROTECTED] writes:
Interesting piece of work.
It seems to me, though, that there are 3 things going on here.
1. Memoization of global variable references that yield one of a
particular subset of common procedures. (I call this part
memoization because it
Hi,
Rob Browning [EMAIL PROTECTED] writes:
In addition, I have some comments:
- Just as a general concern, I would personally lean toward only
adopting changes to the interpreter that affect language semantics
(especially if they change things to be non-RnRS) if the changes
Hi,
Kevin Ryde [EMAIL PROTECTED] writes:
The setlocale call would be a good way. Maybe the charset tables
could be reinitialized in scm_setlocale (when setting LC_ALL or
LC_CTYPE). I suppose that'd be moderately helpful, and would make
char-alphabetic? etc match how 1.6 worked.
In fact,
Hi,
Kevin Ryde [EMAIL PROTECTED] writes:
[EMAIL PROTECTED] (Ludovic Courtès) writes:
In fact, I'm afraid we have a problem, because the `is' functions from
ctype.h are fully locale-dependent. Thus, they don't only depend on
the charset being used but also on the language settings,
I'd
Hi,
Neil Jerram [EMAIL PROTECTED] writes:
[EMAIL PROTECTED] (Ludovic Courtès) writes:
According to SRFI-14, a Latin-1 implementation should contain _both_ `ñ'
and `ê' in `char-set:letter', regardless of the current language
settings, hence the difficulty we might have building `char
Hi,
Kevin Ryde [EMAIL PROTECTED] writes:
[EMAIL PROTECTED] (Ludovic Courtès) writes:
An example to illustrate what
I was trying to say: Both French and Castellano can be written using
Latin-1; however, letter `ñ' (`n' with tilde) is not a French letter
(thus, `isalpha ()' would return
Hi,
Neil Jerram [EMAIL PROTECTED] writes:
In practice, I can think of two ways to determine the set of _letters_
available in the current encoding (which is what `char-set:letter'
expects).
1. Since SRFI-14 lists all the characters that have to be added to the
ASCII `char-set:letter' to
Hi,
Kevin Ryde [EMAIL PROTECTED] writes:
[EMAIL PROTECTED] (Ludovic Courtès) writes:
+#ifdef HAVE_CONFIG_H
+# include config.h
+#endif
No need to conditionalize that, just the #include is enough. And it
normally should be the first thing in the file, if it isn't already.
I left
Hi Neil,
Neil Jerram [EMAIL PROTECTED] writes:
[EMAIL PROTECTED] (Ludovic Courtès) writes:
I'm not sure whether Mikael Djurfeldt is actually following this list so
perhaps somebody else would like to give their opinion about these
documentation bits?
Thanks,
Ludovic.
[0] http
Hi,
Neil Jerram [EMAIL PROTECTED] writes:
[EMAIL PROTECTED] (Ludovic Courtès) writes:
I committed the patch into HEAD, along with the following doc bits
(under ``Standard Character Sets''):
Currently, the contents of these character sets are recomputed upon a
successful @code
Hi,
Bruce Korb [EMAIL PROTECTED] writes:
GCC on Solaris. I agree that it is just a documentation name and serves
no other purpose, but there it is. I do like -Wshadow, but it is not so
useful
if cluttered up with these spurious messages.
So _all_ these messages were with `-Wshadow'?
Hi,
Stanislav Ievlev [EMAIL PROTECTED] writes:
unnamed port: In expression (vector-length syntmp-x-1008):
unnamed port: Stack overflow
Did you compile with `-O0'? If so, make sure you compile at least with
`-O1'.
Hope this helps,
Ludovic.
___
Hi,
Stanislav Ievlev [EMAIL PROTECTED] writes:
As I understand, this is one of security features from RedHat gcc branch.
http://www.redhat.com/magazine/006apr05/features/security/
I see. I found a more technical post on this matter:
http://lkml.org/lkml/2005/5/25/46
This looks like a
Hi,
Han-Wen Nienhuys [EMAIL PROTECTED] writes:
Ludovic Courtès schreef:
$ tla register-archive http://www.laas.fr/~lcourtes/software/arch-2005/
$ tla get [EMAIL PROTECTED]/guile-core--boehm-gc--1.9
gcc -DHAVE_CONFIG_H -I. -I. -I.. -I.. -I.. -g -O2 -Wall
-Wmissing-prototypes -Werror
Hi,
Rob Browning [EMAIL PROTECTED] writes:
[EMAIL PROTECTED] (Ludovic Courtès) writes:
While I agree that this practically precludes use of those functions
by C programmers (as is the case for those SRFIs that are
implemented in C)
Actually, if I understand you correctly, this isn't
Hi,
Rob Browning [EMAIL PROTECTED] writes:
(BTW, does documentation snarfing work right for C functions in
libraries outside libguile? If not, then that's just a bug.)
No, it doesn't work. In the latest `guile-reader', I have a couple of
modules that do (part of) what the Awk script in
Hi,
Neil Jerram [EMAIL PROTECTED] writes:
[EMAIL PROTECTED] (Ludovic Courtès) writes:
@c Local Variables:
@c TeX-master: guile.texi
[EMAIL PROTECTED] ispell-local-dictionary: american
Hmmm :-) (I'm British.) I guess Guile is an FSF project, and the FSF
is US, though, so OK
Hi,
Neil Jerram [EMAIL PROTECTED] writes:
I agree with both separate module and separate library. If having a
separate library throws up problems, this can motivate us to address
them.
In particular, if we keep it this way for `(ice-9 i18n)', do you think
we should document both the
Hi,
Neil Jerram [EMAIL PROTECTED] writes:
[EMAIL PROTECTED] (Ludovic Courtès) writes:
If `guile' is HEAD, then the memory consumption of that process (as
shown by `top') continuously increases and at a pretty high rate (!).
If `guile' is 1.8, then that does not happen.
Interesting
Hi,
Neil Jerram [EMAIL PROTECTED] writes:
[EMAIL PROTECTED] (Ludovic Courtès) writes:
Just to share my frustration: one of the things preventing me from
writing an application currently is this:
(use-modules (oop goops))
(let loop ((o class))
(gc)
(loop (shallow-clone o
Hi,
If nobody disagrees, I would like to merge `(ice-9 i18n)' in HEAD and
1.8 within a few days as is (that is, using a separate shared library
and without documenting the C functions, as discussed earlier).
Thanks,
Ludovic.
___
Guile-devel mailing
Hi,
Rob Browning [EMAIL PROTECTED] writes:
[EMAIL PROTECTED] (Ludovic Courtès) writes:
If nobody disagrees, I would like to merge `(ice-9 i18n)' in HEAD
and 1.8 within a few days as is (that is, using a separate shared
library and without documenting the C functions, as discussed
earlier
Hi,
Neil Jerram [EMAIL PROTECTED] writes:
I think we probably have taken a wrong turn, because I don't think the
1.8.x that we are on the verge of producing can be described any more
as a stable series. Surely the common connotations of stable are
that the API is as unchanging as possible,
Neil Jerram [EMAIL PROTECTED] writes:
[EMAIL PROTECTED] (Ludovic Courtès) writes:
I'm planning to merge it in 1.8 some time soon.
I'm not sure that's a good idea, as will be apparent from another
thread. Can I suggest holding off until that other thread reaches a
consensus?
Sure
Hi,
I'm finally getting back to this (sorry for the delay!).
Han-Wen Nienhuys [EMAIL PROTECTED] writes:
I've patched it a bit to use GC_typed alloc for tagged data. It
probably doesn't make much of a difference, since 90% of the data is
regular cells, but see
Hi,
[EMAIL PROTECTED] (Ludovic Courtès) writes:
Adding new C code (as is the case with the text collation bug) might
^^^
Oh, I really meant module here, really! :-)
Cheers,
Ludovic
Hi,
Neil Jerram [EMAIL PROTECTED] writes:
To summarize, and to get back to my stable release question, what I'd
like to know is - for all active developers - is there some plan for
getting future stuff out (by a combination of (a) experimental HEAD
releases and (b) how we decide when to
Hi,
Kevin Ryde [EMAIL PROTECTED] writes:
There's really no need to remove globals for their own sake, only one
gc ever runs of course ...
The point in removing them is to clarify the flow of information, that
is, how GC stats are updated and used. Believe me, it _was_ hard to
follow with
Hi,
Kevin Ryde [EMAIL PROTECTED] writes:
I would worry that r6rs may address these things too, leaving
guile-specifics as, well, a dead-end. Though I can see this stuff is
of use now.
Don't worry, R5.91RS doesn't deal with locales and text collation [0],
and if it did, we'd just have to
Hi,
Neil Jerram [EMAIL PROTECTED] writes:
Well we have always had a strict stable policy until very recently, so
there should already be evidence one way or the other. I don't have
any numbers, but I am pretty sure (anecdotally) that we have had most
users sticking to the stable releases,
Hi,
Kevin Ryde [EMAIL PROTECTED] writes:
I think the existing strftime is enough, it's just nobody has got
around to using it. The only extra would be the decimal point for ~f.
I suspect that this would be suboptimal. SRFI-19 has its own template
format for `date-string', and internally it
Hi,
Kevin Ryde [EMAIL PROTECTED] writes:
Sven Hartrumpf on guile-user a while ago reported on a run of
guile --use-srfi=1
leaves the REPL with the core `iota', not the srfi-1 one. What's the
theory behind this bit of top-repl (in boot-9.scm),
;; so that builtin bindings will
Hi,
Kevin Ryde [EMAIL PROTECTED] writes:
Though the change I propose is:
--- boot-9.scm.~1.356.2.4.~ 2006-11-29 05:55:55.0 +1100
+++ boot-9.scm2006-12-05 14:14:31.0 +1100
@@ -3397,9 +3397,7 @@
'(ice-9 debugger) '(debug)))
Hi,
Kevin Ryde [EMAIL PROTECTED] writes:
Perhaps cond-expand could be extended. Maybe `guile-foo' feature to
mean one of guile's features list.
I'd be tempted to think that having a different construct is clearer.
Especially since it makes it unnecessary to add a magic `guile-' prefix
to
Hi,
Rob Browning [EMAIL PROTECTED] writes:
Though I haven't thought about them carefully in this context yet, I
wondered to what extent (if any) the following might be relevant:
- SRFI-7
http://srfi.schemers.org/srfi-7/srfi-7.html
I didn't know this one. That seems really relevant
Hi,
[EMAIL PROTECTED] (Ludovic Courtès) writes:
Rob Browning [EMAIL PROTECTED] writes:
Though I haven't thought about them carefully in this context yet, I
wondered to what extent (if any) the following might be relevant:
- SRFI-7
http://srfi.schemers.org/srfi-7/srfi-7.html
Hi,
Kevin Ryde [EMAIL PROTECTED] writes:
[EMAIL PROTECTED] (Ludovic Courtès) writes:
In order to be consistent with the rest of `(ice-9 i18n)',
`language-information' accepts an optional argument which should be a
locale object. Consequently, `language-information' has to perform
Kevin Ryde [EMAIL PROTECTED] writes:
[EMAIL PROTECTED] (Ludovic Courtès) writes:
+/* Throw an exception corresponding to error ERR. */
+static void inline
+scm_locale_error (const char *func_name, int err)
+{
+ SCM s_err;
+
+ s_err = scm_from_int (err);
+ scm_error
Hi,
Kevin Ryde [EMAIL PROTECTED] writes:
One thing to consider is that the features now are basically build
options or system features of the runtime, so hypothetical compiled
code is quite likely to want to adapt at runtime too. Perhaps when
there's two compiled guiles it'll be of interest
Hi,
Han-Wen Nienhuys [EMAIL PROTECTED] writes:
Han-Wen Nienhuys escreveu:
I'd like to run a coverage check on the lilypond source.
How do I do this in GUILE?
Since noone responded, I decided to take a look myself.
[...]
+int scm_do_profiling;
Are you interested in just profiling or
Hi,
[EMAIL PROTECTED] (Ludovic Courtès) writes:
guile (define x (* 123123123123123123 100))
guile x
12312312312312312300
guile (set! x (+ x 12))
guile x
12312312312312312312
guile (set! x (/ x 100))
guile x
3078078078078078078/25 ;; this is wrong!
The fraction here
Hi,
Han-Wen Nienhuys [EMAIL PROTECTED] writes:
[EMAIL PROTECTED] info]$ guile
guile (trap-enable 'enter-frame-handler)
throw from within critical section.
Abortado
Same here with HEAD and 1.8.0. Here's what happens:
#0 0x0fc13f6c in raise () from /lib/tls/libc.so.6
#1 0x0fc15a0c in
Hi,
Han-Wen Nienhuys [EMAIL PROTECTED] writes:
Unfortunately, this is way too slow.
**
[EMAIL PROTECTED] lilypond]$ time lilypond input/example-1
GNU LilyPond 2.11.10
Hangup
real0m2.534s
user0m2.456s
sys 0m0.063s
[EMAIL PROTECTED] lilypond]$ time lilypond -dcoverage
Hi,
Han-Wen Nienhuys [EMAIL PROTECTED] writes:
See attached patch. This still has rough edges. For some reason, I
don't catch the memoization of display to #proc: display.
Overall, as Kevin suggested, I'd be more in favor of using the existing
trap mechanism (possibly extending it if it
Hi,
Han-Wen Nienhuys [EMAIL PROTECTED] writes:
I have doubts whether this can ever be good enough. For effective
coverage analysis, you have a to run an entire test-suite with
coverage enabled. Eg. for lilypond, the entire test-suite takes 5
minutes on a 1.6ghz Core duo (single thread),
Hi,
Han-Wen Nienhuys [EMAIL PROTECTED] writes:
this order is awkward when a new trap option has to be added.
The problematic thing is that this is exported to GUILE users, through
#define SCM_ENTER_FRAME_P scm_evaluator_trap_table[1].val
in eval.h
I would like to change this
Hi,
Han-Wen Nienhuys [EMAIL PROTECTED] writes:
This is now in CVS, along with a couple of other changes.
Thanks!
Just a minor note: Could you make sure you follow the GNU style for,
e.g., comments [0]?
One could argue it's poor man's coverage test since, unlike with `gcov',
one cannot know
Hi,
Han-Wen Nienhuys [EMAIL PROTECTED] writes:
can you be more specific? According to the URL that you posted, all GUILE
multiline comments are non-GNU conformant, wrt. the opening * on each line.
Yes, the `*' opening on each line (many comments in Guile have it, not
all), the empty first
Hi Kevin,
I basically agree with most of your remarks. Here are some I don't
quite agree with or that deserve discussion.
Kevin Ryde [EMAIL PROTECTED] writes:
+* i18n Introduction:: Introduction to Guile's i18n support.
i18n is a horrible geek-ish abbreviation, much better
Hi,
I finally went ahead and merged the new i18n module into HEAD for you to
test. Hopefully nothing will break and the i18n API won't need to
changed (much). ;-)
A few more notes...
Kevin Ryde [EMAIL PROTECTED] writes:
Call the node just Internationalization and then call the sub nodes
Hi,
FWIW, I started an implementation of R6RS' bytevector API. It is
available in my Arch archive [0], in the branch named
`guile-r6rs-libs--devo--0'.
Just letting you know so that we avoid duplicating this (tedious) work.
;-)
Thanks,
Ludovic.
[0]
Hi,
Kevin Ryde [EMAIL PROTECTED] writes:
I know the values struct is doing exactly this, but I suspect it's
abusing the vtable system. I suspect that what scm_init_stacks() in
stacks.c is doing is normal (if there's such a thing as normal).
I'm not sure the indirection in `scm_init_stacks
Hi,
Kevin Ryde [EMAIL PROTECTED] writes:
[EMAIL PROTECTED] (Ludovic Courtès) writes:
I'm not sure the indirection in `scm_init_stacks ()' is needed since it
uses STACK_LAYOUT for both VTABLE and SCM_STACK_TYPE,
Not sure what you mean there.
We have:
VTABLE - SCM_STACK_TYPE - stack
Hi!
Kevin Ryde [EMAIL PROTECTED] writes:
Thus, VTABLE is redundant.
Well, except for the creation (and continued existance) of
scm_stack_type.
Right. But the layout that's used for VTABLE is unneeded: VTABLE only
needs REQUIRED_VTABLE_FIELDS.
Yes, as long as you don't want any extra
Hi,
The patch below (against HEAD) is a proposal to improve the module
system in several ways:
1. Remove inconsistencies in how it behaves.
2. Get better documentation and test coverage.
3. Improve performance.
(1) has to do mainly with `module-use!' vs. `module-use-interfaces!' (as
was
Hi,
Kevin Ryde [EMAIL PROTECTED] writes:
Neil Jerram [EMAIL PROTECTED] writes:
That's a fair point, but IMO Kevin's doc layout allows for it by
putting the vtable-vtable stuff last.
It's last because it's the most brain twisting :).
I think it's the right term. ;-)
I agree with putting
Hi,
Kevin Ryde [EMAIL PROTECTED] writes:
[EMAIL PROTECTED] (Ludovic Courtès) writes:
(1) has to do mainly with `module-use!' vs. `module-use-interfaces!' (as
was discussed recently). Namely the fact that duplicate processing is
not always performed, depending on whether one uses `module
Hi,
Kevin Ryde [EMAIL PROTECTED] writes:
[EMAIL PROTECTED] (Ludovic Courtès) writes:
Actually, `process-duplicates' is O(N*USES) _for each module used_. So
the overall duplicate processing is really O(N*USES^2). With the
patched version, the whole process is O(N*USES). That can make
Hi,
Neil Jerram [EMAIL PROTECTED] writes:
-subdirs_with_ltlibs=srfi guile-readline # maintain me
+subdirs_with_ltlibs=srfi guile-readline libguile # maintain me
Strangely, I had noticed that `(use-modules (ice-9 i18n))' would work
with `pre-inst-guile', even before
Hi,
Kevin Ryde [EMAIL PROTECTED] writes:
[EMAIL PROTECTED] (Ludovic Courtès) writes:
The measurements in the `module-duplicates.scm' file I posted choose
USES = 1 by default, which is arguably unrealistic.
Was that 1 imported modules? That's well outside the realm of
reason
Hi,
I have a patch that further despaghettifies the evaluator, as Han-Wen
would say. ;-) It adds two files, `eval-memoize.i.c' and
`eval-unmemoize.i.c', and moves memoizers in the former and unmemoizers
in the latter. Thus, the functions that end up in these files are:
* `eval-memoize.i.c'
[EMAIL PROTECTED] (Ludovic Courtès) writes:
Neil Jerram [EMAIL PROTECTED] writes:
Do these need to be .i.c - i.e. implying that they need to be
#included? Can't they be normal .c files?
No, because some of them are `static' (all the `unmemoize_' functions
for instance) and should remain
Hi,
Kevin Ryde [EMAIL PROTECTED] writes:
I'm looking at this to allow non-zero tail array only when the layout
provides for it. I think all the internal uses of structs have no
tail array (and a zero size) so that should all be ok. Dunno if
anyone else might have used the tail size to get
Hi,
Kevin Ryde [EMAIL PROTECTED] writes:
[EMAIL PROTECTED] (Ludovic Courtès) writes:
#define SCM_SOCK_FD_TO_PORT(fd) \
scm_fdes_to_port (fd, r, sym_socket)
That's an incompatible change, I think, since it can leave unflushed
data where previously it went straight out.
Right
Hi,
Kevin Ryde [EMAIL PROTECTED] writes:
If that's true you'll have to start from the beginning again,
everyone's eyes glaze over at 1000 modules.
Quoting the original message in this thread:
An application of mine [1], although it modifies `the-scm-module' at
run-time, requiring 40
Hi,
Kevin Ryde [EMAIL PROTECTED] writes:
It's rather unfair to the data structure to say it's no good when
there's likely to be an easy speedup between perhaps 2x and 5x.
Can you be more specific?
In principle all core primitives should be implemented in C;
Developers are the compiler.
Hi,
Neil Jerram [EMAIL PROTECTED] writes:
I have no technical objection to your patch, but I'm afraid you must
be missing something, or else there is something special about the
environment that you were measuring in. I have played with a few
TCP-based Guile applications (including the
Hi,
Kevin Ryde [EMAIL PROTECTED] writes:
[EMAIL PROTECTED] (Ludovic Courtès) writes:
Right. That's an incompatible change if the _output_ is buffered.
Input can be buffered, though, without this being visible by users.
Alas, that too is in an incompatible change, because recv! ignores
Hi,
Kevin Ryde [EMAIL PROTECTED] writes:
[EMAIL PROTECTED] (Ludovic Courtès) writes:
(uniform-vector-read! vec port)))
Slackness in the implementation of that function. It knows a size to
read and should come out as a read() system call of that size. Yet it
always goes
Hi,
Attached is an updated patch. Ok to apply?
Kevin Ryde [EMAIL PROTECTED] writes:
Besides, how about applying the change I originally proposed to HEAD?
No, principally because unbuffered is an advertised feature.
Hey, it's only advertised as long as we advertise it! ;-)
I mean, if we
Hi!
I am pleased to announce version 0.0 of `guile-r6rs-libs' for Guile 1.8:
Regarding this, my intent is to eventually integrate (parts of) it into
Guile core, when we deem it appropriate (perhaps once the final standard
is released).
Note that Unicode-related libraries are not implementable
Hi,
There are a couple of bug reports (see below) by SZAVAI Gyula
(Nov. 2006, on `bug-guile') that I have not fixed. I'm not very
familiar with this area and after re-looking at it, I still feel unable
to make an accurate evaluation of the issue and solution.
In particular:
1. I don't
Hi,
Kevin Ryde [EMAIL PROTECTED] writes:
I'm looking at the code below for my new `make-vtable'. I'm still not
completely convinced it's a great idea, but it does at least find a
use in stacks.c, so it can't be all bad!
I find it nice and useful, so I'm all in favor of adding it, along with
Hi,
Kevin Ryde [EMAIL PROTECTED] writes:
Speaking of scm_getc ... I've wondered for a while if some of the low
level reading funcs ought to be looking directly into the read buffer
instead of making a call to scm_getc for every char. My experience
has usually been that a function call per
Hi,
Just in case you haven't seen it, there's an interesting discussion
going on about the (im)possibility of writing interpreters for R6RS:
http://lists.r6rs.org/pipermail/r6rs-discuss/2007-February/001696.html
http://lists.r6rs.org/pipermail/r6rs-discuss/2007-March/001795.html
Thanks,
Hi,
Kevin Ryde [EMAIL PROTECTED] writes:
What is struct-vtable-tag meant to be for? Or what can be said about
it in the manual?
No idea. A quick grep through the code shows that it's not used from C
nor from Scheme. That said, it could be used as a unique identifier,
just like
Hi,
Steven Wu [EMAIL PROTECTED] writes:
It seems like the on MacOS X 10.4, the configure decided guile need
locale.h, but certain definitions are missing. I got the following
errors:
i18n.c: In function 'scm_nl_langinfo':
i18n.c:1449: error: 'GROUPING' undeclared (first use in this
Hi,
The case is hygienic test case in `syntax.test' looks suspicious to
me. Why would the fact that `else' is bound influence the syntax of
`case'?
For `cond', whether `else' and `=' are bound does have an impact,
though. Perhaps those bits were copied from `cond'?
The relevant changes date
Hi,
Kevin Ryde [EMAIL PROTECTED] writes:
One possibility for duplicates would be lazy checking, only check for
a clash when actually using a symbol. That's sort of the prolog
theory: don't worry now about what might never come up. I suspect the
total work would end up greater though.
[EMAIL PROTECTED] (Ludovic Courtès) writes:
The case is hygienic test case in `syntax.test' looks suspicious to
me. Why would the fact that `else' is bound influence the syntax of
`case'?
Ok, this is because of the definition of `case' in terms of
`syntax-rules' in R5RS (I remember
Hi,
Han-Wen: The replacement `cexp ()' you added recently in `numbers.c'
seems to be somehow broken. Here, on a system where `HAVE_CEXP' was
undefined (I had forgotten to re-run `configure', etc.), it led to the
failure of the 4 tests around `numbers.test':249.
I don't know how to fix it,
Han-Wen,
The new value for `GUILE_FOR_BUILD' you installed in `configure.in' was
broken, because it prepended `$(top_abs_builddir)', which is already
done in `am/pre-inst-guile'. I fixed it (patch below).
Thanks,
Ludovic.
___
Guile-devel mailing
[EMAIL PROTECTED] (Ludovic Courtès) writes:
The new value for `GUILE_FOR_BUILD' you installed in `configure.in' was
broken, because it prepended `$(top_abs_builddir)', which is already
done in `am/pre-inst-guile'. I fixed it (patch below).
Ooop, patch really below this time.
Ludo'.
* local
Hi,
[EMAIL PROTECTED] (Ludovic Courtès) writes:
Attached is a patch that implements lazy duplicate checking.
`process-duplicates' is gone and `module-variable' plays its role when
an imported variable is looked up for the first time. Subsequent
lookups for the same variable result
Hi,
[EMAIL PROTECTED] (Ludovic Courtès) writes:
Folks, I'm willing to install this patch in HEAD one of these days since
it provides an appreciable performance improvement. Please let me know
if you are strongly opposed to this.
I just committed this lazy duplicate binding handling thing
Hi Andy!
Andy Wingo [EMAIL PROTECTED] writes:
On Fri, 2007-05-25 at 20:12 +0200, Ludovic Courtès wrote:
Alas, it breaks the following test in `syntax.test':
I'm not sure what it is in this case; I assume you mean the fix to
module-make-local-var!.
It means the reordering of `eval_car
Hi,
[EMAIL PROTECTED] (Ludovic Courtès) writes:
Actually, no: the test does a `define' _within_ the body of `begin', so
I *think* this qualifies as an internal define, and internal defines are
equivalent to `letrec' (Section 5.2.2).
I was wrong: `define' within `begin' does not qualify
Hi,
Andy, our chief profiler ;-), reported that a fair amount of time was
spent in `pthread_getspecific ()' (in a thread-enabled build). Indeed,
the current-thread object and more importantly freelists are accessed
this way. Thus we thought that using thread-local storage (TLS) would
be
Hi,
In a program of mine, large mathematical sexps are evaluated as follows:
(define %pure-math-module
;; A confined math module where only math procedures are available.
(let ((m (make-module)))
(module-define! m '+ +)
(module-define! m '- -)
(module-define! m '* *)
Hi,
Kjetil S. Matheussen [EMAIL PROTECTED] writes:
Yes, but for some kinds of software, like programs with custom gui's,
sound processing programs, interactive graphical programs,
interactivety is exclusively more important than those two. I consider
the freeze that the guile's built-in gc
Hi,
Kjetil S. Matheussen [EMAIL PROTECTED] writes:
libgc (v6.8) was compiled with the --enable-threads=posix only.
So `THREAD_LOCAL_ALLOC' was defined in your libgc build, right?
Running the benchmark program directly in guile gives no
difference. Both spent about 50 seconds running the
Hi,
Kjetil S. Matheussen [EMAIL PROTECTED] writes:
and for guile I think you use -rpath? :
Yes.
No. But I have ran a series of benchmarks now:
Thanks for doing this!
To sum up, BGC is always slower but usually more memory-efficient than
GGC.
In Guile + libgc, you could try adding:
Hi,
FYI, I committed the patch below to both branches. It fixes a bus error
(unaligned access) on SPARC in the `AF_INET' case.
Thanks,
Ludovic.
--- orig/libguile/ChangeLog
+++ mod/libguile/ChangeLog
@@ -1,3 +1,9 @@
+2007-06-12 Ludovic Courtès [EMAIL PROTECTED]
+
+ * socket.c
Hi,
[EMAIL PROTECTED] (Ludovic Courtès) writes:
For 1.8, I'm pretty much inclined to commit a similar patch, i.e., where
`module-make-local-var!' and `scm_m_define' are copied from HEAD. This
would break code that does things like:
(define foo (begin (set! foo 1) (+ foo 1)))
but I
Hi,
I think we should release 1.8.2 soon. A number of compile-time and
run-time bugs have been fixed in the 1.8 branch, most of which
(hopefully) appear in the `NEWS' file.
Last time I asked him, Rob told me he was not able to handle it for the
moment, but maybe this has changed since then.
Hi,
I updated the web pages so that they use the GNU CSS (using the attached
script). This adds a bit of eye candy, which is always a good thing.
;-)
I may also update the project list one of these days.
Thanks,
Ludovic.
#!/bin/sh
# CSSify Guile web pages.
for page in $@
do
ed $page EOF
Hi,
In the process of preparing 1.8.2, I added into `guile-core' files that
were initially in `workbook/build/dist-files' and removed `BUGS' from
the distribution files (this bug report mechanism had been essentially
unused since 2003). While I was at it, I removed from `autogen.sh' code
that
to [EMAIL PROTECTED]'.
Ludovic Courtès, on behalf of the Guile team.
___
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel
Hi,
Stephen Compall [EMAIL PROTECTED] writes:
Here are tests for SRFI-61's cond clause.
2007-07-14 Stephen Compall [EMAIL PROTECTED]
* tests/syntax.test: Add SRFI-61 `cond' tests.
Applied (should propagate in a moment).
Thanks!
Ludovic.
101 - 200 of 2428 matches
Mail list logo
