Bruno Haible <[EMAIL PROTECTED]> writes:
> Then there are no working libtool releases that work for guile:
> - libtool 1.4.x create no libltdl/ directory,
> - libtool 1.5.x breaks 'aclocal', see
> http://sources.redhat.com/ml/automake/2003-04/msg00222.html
I think this bug does not affect Gu
Marius Vollmer <[EMAIL PROTECTED]> writes:
> I have added a call to autopoint after autoreconf.
I didn't do this, after all. Using autopoint seems to require a
AM_GNU_GETTEXT_VERSION statement or something in configure.in and I
don't know which version to specify. I will
Bruce Korb <[EMAIL PROTECTED]> writes:
> Below is an error message that Matt Kraai gets while trying to
> start my autogen program. Would anyone have a guess about
> what the cause might be? Attached is the script being run
> when this failure occurs.
Can you give more information about how to
Kevin Ryde <[EMAIL PROTECTED]> writes:
> Mikael Djurfeldt <[EMAIL PROTECTED]> writes:
>>
>> Well, to me that specific meaning---a function that can operate on any
>> of a set of types---is just another example of what we have here: a
>> vector that can be any of a set of types, so my view is that
Kevin Ryde <[EMAIL PROTECTED]> writes:
> Speaking of check fails, primitive-fork has stopped working for me,
> making popen.test (and any actual use of popen) hang. Eg.
>
> guile -c '(pk (primitive-fork)) (force-output) (sleep 10)'
>
> It should print 0 in the child and some pid in the pare
Bruce Korb <[EMAIL PROTECTED]> writes:
> Known issue? 1.6.6 sources:
No. What platform is this on? Do you have a fix?
--
GPG: D5D4E405 - 2F9B BCCC 8527 692A 04E3 331E FAF8 226A D5D4 E405
___
Guile-devel mailing list
Guile-devel@gnu.org
http://l
"Neil Jerram" <[EMAIL PROTECTED]> writes:
> I've put the docs for some debugging enhancements that I've been
> working on up at
> http://www.ossau.uklinux.net/guile-debugging/index.html, and would be
> most interested in any comments.
Excellent! I don't really have time right now to read this ca
Kevin Ryde <[EMAIL PROTECTED]> writes:
> Expanded words about make-shared-array, trying to clarify what linear
> means, and adding lots of example usages.
Nice, thanks!
> [...] and perhaps enclose-array too (if anyone can explain what it
> actually does :-).
Yeah, strange critters, those enclos
Mikael Djurfeldt <[EMAIL PROTECTED]> writes:
> I propose we wait for a while. If no-one has objected, we'll remove it
> in a week or two.
Ok.
--
GPG: D5D4E405 - 2F9B BCCC 8527 692A 04E3 331E FAF8 226A D5D4 E405
___
Guile-devel mailing list
Guile-de
Kevin Ryde <[EMAIL PROTECTED]> writes:
> This is some words about tail calls, with I don't think are otherwise
> described.
There is a short section about this in the node "Control Flow". Maybe
you could cross-ref from there to your docs.
--
GPG: D5D4E405 - 2F9B BCCC 8527 692A 04E3 331E FAF8
Mikael Djurfeldt <[EMAIL PROTECTED]> writes:
> The part after the first sentence indicates that I don't have to call
> scm_array_handle_release before throwing the error. Is that so?
It is so. Also, you can use scm_c_array_rank to get the array rank as
a size_t. (I forgot to document this funct
Kevin Ryde <[EMAIL PROTECTED]> writes:
> But I don't know if the read side bits of this change are right. Is
> it supposed to update read_pos, read_end and read_buf_size to be the
> end of the string, or something?
I don't know. Could you try to figure this out yourself?
--
GPG: D5D4E405 - 2F
Kevin Ryde <[EMAIL PROTECTED]> writes:
> Looks like the polar parsing code doesn't cope with #f coming back for
> the angle part. Does this change sound right? It seems to do the
> trick.
Yes, looks right to me!
--
GPG: D5D4E405 - 2F9B BCCC 8527 692A 04E3 331E FAF8 226A D5D4 E405
_
Marius Vollmer <[EMAIL PROTECTED]> writes:
> I do the work on the 'branch_mvo-thread-cleanup' branch.
Ok, I have merged this branch now back into HEAD, which probably
causes a lot of instability.
I will say more about this here, once I am satisfied with updating
NEWS and manu
Hi,
I am not completely happy about having removed the low level thread
API.
I do think that it is not the job of Guile to provide such a thing and
I also found its presence to be confusing, when compared with the
'regular' thread API.
On the other hand, Guile itself both works on systems that
Kevin Ryde <[EMAIL PROTECTED]> writes:
> Marius Vollmer <[EMAIL PROTECTED]> writes:
>>
>> Ok, I have merged this branch now back into HEAD, which probably
>> causes a lot of instability.
>
> With glibc 2.3.2, in eval.c I had to #define _GNU_SOURCE to get
&
Hi,
as far as I am concerned, the last larger thing holding up a Guile 1.8
release is a code review with the aim of making libguile thread safe.
I have replaced all SCM_DEFER_INTS, SCM_ALLOW_INTS calls with
SCM_CRITICAL_SECTION_START/END. We need to check all occurences
whether they are really u
Kevin Ryde <[EMAIL PROTECTED]> writes:
> Marius Vollmer <[EMAIL PROTECTED]> writes:
>>
>> If there might be non-local exits, scm_frame_critical_section can be
>> used instead.
>
> If an error occurs and a lazy-catch executes, is the mutex unlocked
> fo
Hi,
we currently distribute a copy of libltdl as part of guile-core and
install it when libltdl is not already found in the system.
I think this is wrong since libltdl belongs to libtool and should be
installed by libtool and not by any number of programs that use it.
We do not distribute libgmp
Greg Troxel <[EMAIL PROTECTED]> writes:
> A big question is the ease of installation for those using OS package
> systems vs those doing things by hand. My view is that the really big
> issue is making things
> a) easy to package
> and
> b) easy to use once packaged
Those two things would benefi
Kevin Ryde <[EMAIL PROTECTED]> writes:
> Marius Vollmer <[EMAIL PROTECTED]> writes:
>>
>> Does it still fail for you?
>
> Yes. I'm not sure if it's something I've done. I had trouble getting
> gdb to show anything.
I remember seeing strang
Bruce Korb <[EMAIL PROTECTED]> writes:
> My opinion: the more impediments to installation that there are
> results in more folks deciding that it isn't worth the bother.
> I really hate downloading a package only to find that there's
> a bunch of other stuff to find, download and install first.
Bruce Korb <[EMAIL PROTECTED]> writes:
> Since you are not proposing to fail the configure and leave no clues,
Yes, good documentation is of course needed. Right now, Guile fails with
configure: error: libltdl not found. See README.
And the README says:
Required External Packages ===
Hi,
what is the difference between
(join-thread (begin-thread (foo)))
and
(future-ref (future (foo)))
I am thinking about implementing futures as just
(define-macro (future exp) `(begin-thread ,exp))
(define future-ref join-thread)
Would that make sense?
___
Ken Raeburn <[EMAIL PROTECTED]> writes:
> If at all possible, this code should be switched to use get*by*_r, or
> in the gethostby* cases, perhaps getaddrinfo and getnameinfo.
Yes, definitely. Could you help with that?
___
Guile-devel mailing list
Gu
Rob Browning <[EMAIL PROTECTED]> writes:
> Alhough I agree that it would be good to have a clear configure
> error message when libltdl is not detected.
Of course.
___
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/
[EMAIL PROTECTED] writes:
> Can't guile distribute libltdl but only use
> it iff there's no local version found (or if the user states her
> intention by configure magic)?
That is how it works right now. I am not happy about the fact that
Guile does this silently and that it is a configure decis
Rob Browning <[EMAIL PROTECTED]> writes:
> Though is a terminated thread very "heavy"? i.e. is it much heavier
> than a cons pair?
Yes. It is a scm_i_thread struct, but the OS thread has been
deallocated already.
___
Guile-devel mailing list
Guile-d
Mikael Djurfeldt <[EMAIL PROTECTED]> writes:
>> Would that make sense?
>
> I don't think so for obvious reasons. It would not make sense to
> spawn new pthreads for the kind of usage patterns for which futures
> are intended. In my opinion it's better to scrap futures entirely than
> to provide t
Marius Vollmer <[EMAIL PROTECTED]> writes:
> (I will also try to benchmark them, but there is a bug right now that
> prevents me from using a huge number of threads... (that bug is not
> related to futures))
Okaaay, after fixing a couple of nice bugs (gdb is really good
wit
We are pleased to announce the release of Guile 1.7.2. This is a
'technology preview' for the upcoming Guile 1.8. It can be found
here:
ftp://alpha.gnu.org/gnu/guile/guile-1.7.2.tar.gz
Its MD5 checksum is
7fabb64198993e971f65a27846202388 guile-1.7.2.tar.gz
This version is guaranteed
Neil Jerram <[EMAIL PROTECTED]> writes:
> Thanks. So this is now just:
>SCM_RETURN_NEWSMOB (scm_tc16_memoized, scm_cons (exp, env));
>
> which is a completely mechanical change except that one
> SCM_UNPACK(...) has become ((scm_t_bits) ...) - is the definition of
> SCM_NEWSMOB correct in usin
Kevin Ryde <[EMAIL PROTECTED]> writes:
> The cvs seems to have a bug in making a shared array from what's
> already a shared array,
Should be fixed now, please check.
2005-05-22 Marius Vollmer <[EMAIL PROTECTED]>
* unif.c (scm_make_shared_array): Add old
Neil Jerram <[EMAIL PROTECTED]> writes:
> Marius Vollmer wrote:
>> We are pleased to announce the release of Guile 1.7.2.
>
> Have you considered CCing such announcements to [EMAIL PROTECTED] (and
> perhaps any other appropriate places)? Would the extra coverage be
&
Alexey Voinov <[EMAIL PROTECTED]> writes:
> There's a bug in guile srfi-13 implementation.
Thanks! I applied it.
> I haven't checked if this bug is still present in cvs HEAD.
It should be fixed in CVS HEAD already.
--
GPG: D5D4E405 - 2F9B BCCC 8527 692A 04E3 331E FAF8 226A D5D4 E405
Kevin Ryde <[EMAIL PROTECTED]> writes:
> I propose to do 1+ and 1- in C so they're as fast as plain + and -.
Yes, why not. Maybe it would even be worth it to special case
fixnums.
--
GPG: D5D4E405 - 2F9B BCCC 8527 692A 04E3 331E FAF8 226A D5D4 E405
__
Kevin Ryde <[EMAIL PROTECTED]> writes:
> Aubrey Jaffer noticed guile doesn't have r5rs numerator and
> denominator and proposes the definitions below. The head has them
> already with the exact fractions now, but I think I'll add these to
> the 1.6 branch.
Yep, thanks.
--
GPG: D5D4E405 - 2F9B
Kevin Ryde <[EMAIL PROTECTED]> writes:
> Is the Rx regexp library supported in the guile core any more? I
> can't see it, and I think the docs for that stuff in the manual should
> be removed to stop anyone getting confused between those functions and
> the posix regex functions.
Ok.
--
GPG: D
Kevin Ryde <[EMAIL PROTECTED]> writes:
> What happened to substring-fill! ? Has it been lost from the cvs?
Yep, looks like I accidentally left it behind when integrating the
SRFI-13 procedures into the core. I have re-added it to boot-9.scm.
--
GPG: D5D4E405 - 2F9B BCCC 8527 692A 04E3 331E F
Kevin Ryde <[EMAIL PROTECTED]> writes:
> I think I'll try to change it back to accept no sources,
Yes, good plan.
--
GPG: D5D4E405 - 2F9B BCCC 8527 692A 04E3 331E FAF8 226A D5D4 E405
___
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu
Bruce Korb <[EMAIL PROTECTED]> writes:
> snarf-check-and-output-texi hangs forever:
Does 1.6.7 work?
What happens when you do the following:
$ cd .../guile-1.6.6/libguile/
$ ./guile
--
GPG: D5D4E405 - 2F9B BCCC 8527 692A 04E3 331E FAF8 226A D5D4 E405
___
Kevin Ryde <[EMAIL PROTECTED]> writes:
> Looks like list doesn't produce a new list when called through apply,
>
> (define x '(1 2 3))
> (define y (apply list x))
> (eq? x y)
> => #t
Is it required to make a copy in this situation? I thought that
(define (list . args)
Jan Nieuwenhuizen <[EMAIL PROTECTED]> writes:
> Ok, better version below.
Thanks, I applied it with a few changes to strftime.c. Please check.
--
GPG: D5D4E405 - 2F9B BCCC 8527 692A 04E3 331E FAF8 226A D5D4 E405
___
Guile-devel mailing list
Guile-
Neil Jerram <[EMAIL PROTECTED]> writes:
> Is this a good fix for r5rs_pitfall 1.1?
scm_copy_tree is too much, since it makes the following code fail:
(let ((a '(1 2 3))) (letrec ((x a) (y a)) (eq? x y)))
We should not copy the values themselves, just the storage cells;
thus, scm_list_copy is
Kevin Ryde <[EMAIL PROTECTED]> writes:
> Marius Vollmer <[EMAIL PROTECTED]> writes:
>>
>> (define (list . args) args)
>>
>> is an acceptable definition of list. Is it not?
>
> Yep, because args is of course a fresh list when calling a lambda, b
Kevin Ryde <[EMAIL PROTECTED]> writes:
> More apparent array dodginess in the head,
>
> (let ((a (make-array #f '(425 425
> (array-in-bounds? a 0))
> => #t
Should be fixed now.
2005-06-06 Marius Vollmer <[EMAIL PROTECTED]>
* un
[EMAIL PROTECTED] (Ludovic Courtès) writes:
> Hi,
>
> I'd like to know whether one can reliably allocate a cell on its own,
> without using `scm_cell ()'.
No.
> So my question is: Is there a way to allocate cells, cheaper than
> `scm_cell ()', that could be used?
If there is a cheaper way (very
tly
> added in scm_eval_options_interface.
Yep:
2005-06-06 Marius Vollmer <[EMAIL PROTECTED]>
* eval.c (scm_eval_options_interface): Use
scm_frame_critical_section instead of SCM_CRITICAL_SECTION_START
and SCM_CRITICAL_SECTION_END.
--
GPG: D5D4E
Kevin Ryde <[EMAIL PROTECTED]> writes:
> Marius Vollmer <[EMAIL PROTECTED]> writes:
>>
>> Thanks! I applied it.
>
> I already made a fix (from the head by Han-Wen) in chars.h which
> covers this, by stopping signed values getting into the value field of
>
Neil Jerram <[EMAIL PROTECTED]> writes:
> I propose that the SCM_NECONSP fix is good enough in practice, and
> would like to release it into 1.6.x. Any objections?
Not from me!
--
GPG: D5D4E405 - 2F9B BCCC 8527 692A 04E3 331E FAF8 226A D5D4 E405
__
Kevin Ryde <[EMAIL PROTECTED]> writes:
> In scm_take_locale_stringn, how about using realloc to add a null
> terminator to the block being acquired? That should usually be better
> than the current code doing malloc+copy+free.
>
> Something like the following,
Yes, very good.
--
GPG: D5D4E405
Neil Jerram <[EMAIL PROTECTED]> writes:
> Cunning, isn't it? It passes the test because a continuation captured
> during an ecache_evalx call will preserve the values on the stack, and
> because the values on the stack are not affected by set!s on the letrec
> environment.
Yep, I was thinkning i
Andreas Rottmann <[EMAIL PROTECTED]> writes:
> Hi!
>
> I've developed the following patch, which fixes R5RS-compatibility for
> printing symbols starting/ending with ':'.
Good!
[...]
> However, when the keywords reader option is set, the old behaviour is
> re-established, to allow writing out
Han-Wen Nienhuys <[EMAIL PROTECTED]> writes:
> Since noone has complained, I've taken the liberty of adding this to
> CVS guile 1.6 as well.
Humph. I can see that my slowness is to blame here, but usually
things like this should not happen... Let's hope your fix is
brilliant :-)
> Marius could
Han-Wen Nienhuys <[EMAIL PROTECTED]> writes:
> Hi,
>
> I've found a memory leak in GUILE.
>
> The contents of modules are not garbage collected.
>
> This seems to be related with two errors:
>
> - scm_stand_in_procs is a hashtable. I believe it should be weak_key
> hashtable, just like the scm_o
Han-Wen Nienhuys <[EMAIL PROTECTED]> writes:
>> I think the right fix is to change the weak hashtable marking
>> algorithm to properly cope with circular references like this. I will
>> try this and then come back to you.
>
> Interesting. How would you go about doing that?
The marking would wo
Han-Wen Nienhuys <[EMAIL PROTECTED]> writes:
> what happens if the weak (c[ad]r ITEM) is marked through a postponed
> weak vector that you haven't processed yet? Then P is removed
> erroneously, or am I missing something?
Hmm, you are right. I first have thought about this behavior as a
feature
Han-Wen Nienhuys <[EMAIL PROTECTED]> writes:
> isn't it possible to store the 'module property in a doubly weak hash
> table?
That would work, but the 'module property would then be a special
case. If we can, we should solve the general problem, I'd say.
The general problem being that cycles
Hi,
I am afraid I have to come back to guardians once more.
I stumpled over our peculiar guardians while trying to improve the
weak hash table marking algorithm so that it will properly deal with
references from the non-weak part to the weak part. (For example,
referencing a weak key from a non-
Hi,
Guile's guardians currently make the guarantee that "it is impossible
for a guardian to return a 'contained' object before its 'containing'
object."
I am considering removing this guarantee since it makes it impossible
for guardians to deal with cycles among guarded objects, and because
it is
Neil Jerram <[EMAIL PROTECTED]> writes:
>> If you do, you would need to take care of the ordering yourself, which
>> is quite easy by keeping objects alive in a global data structure
>> until they are no longer needed.
>
> Not sure what you mean by this, though. How would this generate an
> order
Marius Vollmer <[EMAIL PROTECTED]> writes:
> (I am a bit worried right now that the 'obvious' approach of putting
> FOO and BAR into a weak key hashtable with FOO as the key and BAR as
> the value does conflict a bit with my original goal of breaking up
> cycles fro
Han-Wen Nienhuys <[EMAIL PROTECTED]> writes:
> I've found a memory leak in GUILE.
>
> The contents of modules are not garbage collected.
I believe this is fixed in CVS HEAD now in the 'proper' way:
guile> (define g (make-guardian))
guile> (g (make-module))
guile> (gc)
guile> (g)
Han-Wen Nienhuys <[EMAIL PROTECTED]> writes:
> Well, almost. The scm_stand_in_scm_procs need to be weak too.
It is; this change will remain in 1.6. Sorry that I wasn't clear
about that. With "too large" I was only referring to the changed
semantics of weak hash tables and guardians.
--
GPG: D
Kevin Ryde <[EMAIL PROTECTED]> writes:
> The head built with debian i386 gcc 4 bombs with a stack overflow on
> startup. Under gdb it looks like it really has used up its 80kbytes,
> but I can't tell where or why. The same built with gcc 3.3 is ok, so
> something evil has happened.
I have seen
Han-Wen Nienhuys <[EMAIL PROTECTED]> writes:
> Yes, I've already done that. Any idea of when we will see this in a
> release?
As soon as Rob gets around to do it! :-)
--
GPG: D5D4E405 - 2F9B BCCC 8527 692A 04E3 331E FAF8 226A D5D4 E405
___
Guile-d
Kevin Ryde <[EMAIL PROTECTED]> writes:
> I think I'll do this in the 1.6 branch too.
Yes, sounds good.
--
GPG: D5D4E405 - 2F9B BCCC 8527 692A 04E3 331E FAF8 226A D5D4 E405
___
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailma
Rob Browning <[EMAIL PROTECTED]> writes:
> Marius Vollmer <[EMAIL PROTECTED]> writes:
>
>> Han-Wen Nienhuys <[EMAIL PROTECTED]> writes:
>>
>>> Yes, I've already done that. Any idea of when we will see this in a
>>> release?
>
[EMAIL PROTECTED] (Ludovic Courtès) writes:
> Are there any concrete plans for wide-character support in Guile? (I
> only found mentions of it in the list archive that dated back to several
> years)
Well, my current plans are to get us Unicode support by having three
kinds of strings, with three
[EMAIL PROTECTED] (Ludovic Courtès) writes:
> Marius Vollmer <[EMAIL PROTECTED]> writes:
>
>> Well, my current plans are to get us Unicode support by having three
>> kinds of strings, with three widths (8, 16 and 32 bits, of course).
>> But they are not very conc
[EMAIL PROTECTED] (Ludovic Courtès) writes:
> Right. And is it something you would like to have for 1.8 or is it a
> longer-term goal?
Unicode should come immediately after 1.8 is released.
--
GPG: D5D4E405 - 2F9B BCCC 8527 692A 04E3 331E FAF8 226A D5D4 E405
Andreas Rottmann <[EMAIL PROTECTED]> writes:
>> Shouldn't we make a new printer option for this so that reading and
>> writing can be controlled separately? The printer option could have a
>> setting that says "be compatible with the reader option", which would
>> be the default.
>>
>> Ok?
>>
> S
[EMAIL PROTECTED] (Ludovic Courtès) writes:
> Kevin Ryde <[EMAIL PROTECTED]> writes:
>
>> If the generated file is checked into the cvs and the dates are right
>> then you won't need flex for a maintainer build, unless you actually
>> change the source.
>
> Actually I needed it, hence this thread.
[EMAIL PROTECTED] (Ludovic Courtès) writes:
> Comments?
Your patch has the problem that it breaks things like
(+ 2 2 #! 2 !#)
We can still support the #! read-hash extension, of course, which I
think is a good idea.
--
GPG: D5D4E405 - 2F9B BCCC 8527 692A 04E3 331E FAF8 226A D5D4 E405
_
Rob Browning <[EMAIL PROTECTED]> writes:
> [EMAIL PROTECTED] (Ludovic Courtès) writes:
>
>> Still, I don't understand the rationale behind this and I consider this
>> a limitation. In fact, it's misleading compared to block comments in
>> other languages or in SRFI-30.
>
> Unless there's a strong
Michael Tuexen <[EMAIL PROTECTED]> writes:
> I'm trying to compile guile-1.7.2 on Mac OS X 10.3.9. The compilation
> breaks because scm_mutex_lock and scm_mutex_unlock are used in
> libguile/arbiters.c but the compiler and I can not find a definition
> of those functions. Where are they defined?
TEX_RECURSIVE is defined on my system.
Ok.
>> I will make this change and let you know when it is done.
I have committed it, please try.
2005-10-23 Marius Vollmer <[EMAIL PROTECTED]>
PTHREAD_RECURSIVE_MUTEX_INITIALIZER_NP is not portable enough.
Michael Tuexen <[EMAIL PROTECTED]> writes:
> eval.c:2658: error: `PTHREAD_RECURSIVE_MUTEX_INITIALIZER_NP'
> undeclared here (not in a function)
>
> Any idea, how to fix that? I'm trying to compile it on Mac OS X 10.3.9.
Hmm. PTHREAD_RECURSIVE_MUTEX_INITIALIZER_NP seems not to be portable
enough
Michael Tuexen <[EMAIL PROTECTED]> writes:
> I tried the old version with --without-threads and it worked.
Ok!
> How can I try the new version? the guile-core-unstable.tar.gz
> is still the old version...
You can wait for the snapshots to catch up (should happen in a day or
so), or you can chec
[EMAIL PROTECTED] (Ludovic Courtès) writes:
> The problem stems from the fact that
> `scm_i_mark_weak_vector_non_weaks ()' would not mark a value
> attached to a weak key if that weak key is unmarked. Therefore,
> both the weak key and its associated value become unmarked during
> the very same m
Kevin Ryde <[EMAIL PROTECTED]> writes:
> [EMAIL PROTECTED] (Ludovic Courtès) writes:
>>
>> For instance, while
>> testing weakly-key alist vectors "by hand" in a REPL, it occurred to
>> me that the weak-key pair would reliably die, *unless* the hash
>> table was written (I mean usi
Rob Browning <[EMAIL PROTECTED]> writes:
> Indeed. If I felt relatively certain that just calling
>
> (load-from-slib "guile.init")
>
> would do the right thing with the current SLIB version, then I'd be
> inclined to consider that as a solution, even in 1.6.8, whenever we
> detect a "newer
Rob Browning <[EMAIL PROTECTED]> writes:
> A minor difference regards output-port-width. The version in slib.scm
> returns 80 where the version in guile.init returns 79.
>
> A more significant question regards evaluation. In slib.scm we have:
> [...]
> where guile.init has:
> [...]
I'd say that
Neil Jerram <[EMAIL PROTECTED]> writes:
> To be completely concrete about what I mean, here is a version of
> your patch which I prefer (untested except by make check).
Hmm. Your approach make 'load' configurable so that it can use
different 'read' procedures. Wouldn't it be more natural to mak
Kevin Ryde <[EMAIL PROTECTED]> writes:
> Marius Vollmer <[EMAIL PROTECTED]> writes:
>>
>> If there might be non-local exits, scm_frame_critical_section can be
>> used instead.
>
> If an error occurs and a lazy-catch executes, is the mutex unlocked
> for t
Ken Raeburn <[EMAIL PROTECTED]> writes:
> Somebody please check me on this, I'm not sure if scm_leave_guile can
> be relied upon to work.
I believe everything you say is correct, unfortunately.
I will make the change you propose to scm_without_guile and remove
scm_leave_guile and scm_enter_guile
Stephen Compall <[EMAIL PROTECTED]> writes:
> Attached is a version with the suggested doc move and no more
> srfi-61.scm. Thanks for your recommendations.
Applied, thanks!
Do you have any test cases for this?
--
GPG: D5D4E405 - 2F9B BCCC 8527 692A 04E3 331E FAF8 226A D5D4 E405
___
Han-Wen Nienhuys <[EMAIL PROTECTED]> writes:
> Hi,
>
> what's the proper way to use read-string!/partial ?
>
> If I read a file with fewer bytes than the arg of read-string!/partial,
> I get problems down the line [with scm_to_locale_stringn]
Do you pass the right length to scm_to_locale_stringn,
Andy Wingo <[EMAIL PROTECTED]> writes:
> Just updated an ancient checkout of guile 1.7. The attached patch fixes
> a bug caught by my compiler.
Applied, thanks!
--
GPG: D5D4E405 - 2F9B BCCC 8527 692A 04E3 331E FAF8 226A D5D4 E405
___
Guile-devel ma
>> The `(oop goops util)' module currently exports its own version of `any' and
>> `every', which is unnecessary and causes warnings to be issued when
>> `(srfi srfi-1)' is being used.
>
> When using (oop goops) ? I'm not sure (oop goops util) is meant to be
> used outside the goops implementation
[EMAIL PROTECTED] (Ludovic Courtès) writes:
> * srfi/srfi-34.scm: Don't export `raise', replace it instead
> (because `raise' otherwise overrides a code binding).
These two 'raise' funtions are very different: one raises a Unix
signal, the other raises an exception. So I'd say the
[EMAIL PROTECTED] (Ludovic Courtès) writes:
> IOW, property values are to be "collected" _after_ the Scheme value to
> which they are attached has been collected.
The manual talks from the perspective of a Scheme program here. For a
Scheme program, the important information is that some object i
Neil Jerram <[EMAIL PROTECTED]> writes:
>> However, making the read procedure used by 'load' configurable can't
>> hurt, I think.
>
> OK, thanks. I'll just wait a few days in case you or anyone else have
> further comments. If not I'll commit the patch as proposed.
Yes, please do. I still don'
Kevin Ryde <[EMAIL PROTECTED]> writes:
> Bruce Korb <[EMAIL PROTECTED]> writes:
>>
>> ERROR: Wrong type argument in position 1: #
>
> Ah, I see 1.7 now throws an error for a non-number argument to
> inexact?, where 1.6 would accept anything.
>
> Looks l
[EMAIL PROTECTED] (Ludovic Courtès) writes:
> Any news regarding this patch?
I made the following changes. OK?
Index: api-modules.texi
===
RCS file: /cvsroot/guile/guile/guile-core/doc/ref/api-modules.texi,v
retrieving revision 1.1
Bruce Korb <[EMAIL PROTECTED]> writes:
> Anyway, *real bugs* in Guile 1.7.2 are:
>
> 1. When an error is thrown, "exit" should be called with
> EXIT_FAILURE, not 0.
I agree. In 1.7.2, Guile no longer exits the whole program when an
uncaught error happens; it only exits the current thread w
ught throws
unless there is some ither bug in Guile. scm_with_guile, which is now
the main function for initializing Guile, establishes a catch all (via
scm_with_continuation_barrier). However, that catch all does not exit
with pthread_exit, it simply makes scm_with_guile return NULL. Bad.
2005-1
Rob Browning <[EMAIL PROTECTED]> writes:
> Marius Vollmer <[EMAIL PROTECTED]> writes:
>
>> Is there a way to return an exit code with pthread_exit()?
>
> Doesn't pthread allow that directly?
>
> Function: void pthread_exit (void *RETVAL)
>
> Of cou
Bruce Korb <[EMAIL PROTECTED]> writes:
> It turns out that in all places where I was using scm_makstr(), I
> was also using SCM_CHARS to access the string memory and then fill
> it in. It *must* be safe to do because I don't call any scheme
> functions before I am done scribbling in the memory.
[EMAIL PROTECTED] (Ludovic Courtès) writes:
> See also:
> http://lists.gnu.org/archive/html/guile-devel/2005-10/msg00101.html .
>
>> If you don't want to warning, you can define your own way of handling
>> duplicates. See the NEWS file for docs about the options.
>
> Precisely, you said you were
1 - 100 of 152 matches
Mail list logo
