Kevin Ryde <[EMAIL PROTECTED]> writes:
> Rob Browning <[EMAIL PROTECTED]> writes:
>>
>> I believe a while back I wondered if we might have trouble with
>> pthreads and fork unless we were very careful, and I'm beginning to
>> wonder again.
>
> Ahh, that sounds likely. If mutexes are unusable once
Neil Jerram <[EMAIL PROTECTED]> writes:
>> Guile wants you to integrate your objects with its mark/sweep
>> approach, by providing appropriate smob marking functions, for
>> example.
>
> If I've understood correctly, this isn't possible in Gregory's
> scenario.
>
> (See
> http://lists.gnu.org/arch
[EMAIL PROTECTED] (Han-Wen Nienhuys) writes:
> In article <[EMAIL PROTECTED]>,
> Neil Jerram <[EMAIL PROTECTED]> wrote:
>
>>[...]
>>It seems to me, though, that the same kind of situation, leading to
>>wanting to call scm_gc_unprotect_object during GC, is likely to arise
>>in any sufficiently com
Kevin Ryde <[EMAIL PROTECTED]> writes:
> Marius Vollmer <[EMAIL PROTECTED]> writes:
>>
>> It should clearly be possible to use equal? with all kinds of arrays.
>> If this isn't the case, we would need to fix.
>
> Eg, picking out a diagonal with a shar
"Bill Schottstaedt" <[EMAIL PROTECTED]> writes:
> If SCM_DEBUG_PAIR_ACCESSES is 1, throw.c line 739 triggers an error
> about accessing a non-pair. Perhaps it should be:
>
>!scm_is_pair (SCM_CAR (wind_goal)) || !scm_is_eq (SCM_CDAR (wind_goal),
> jmpbuf);
Yes, correct!
The wind list used t
Kevin Ryde <[EMAIL PROTECTED]> writes:
> scm_make_port_type returns scm_t_bits, but the various setting
> functions like scm_set_port_mark take a long. Should they be
> scm_t_bits too?
Yes. Good catch.
If you are motivated, you might think about cleaning up and
documenting the ports API... but
Kevin Ryde <[EMAIL PROTECTED]> writes:
>> Should we still support GCC 2.95?
>
> It's still in current debian unstable, so it's not totally dead.
I had the impression it is only there for compiling old Linux
kernels...
> Using it guards against some c99-isms (local variables in the middle
> of fu
milar issue in scm_ithrow, if I remember correctly, but
we removed the workaround in 2003. Should we still support GCC 2.95?
2003-05-04 Marius Vollmer <[EMAIL PROTECTED]>
* throw.c (scm_ithrow): Remove "asm volatile" hack. It used to
work around a bug in GCC 2.
Kevin Ryde <[EMAIL PROTECTED]> writes:
> The configure test for S_ISLNK is merely a "#ifdef", is there any
> reason not to simply do that in filesys.c itself? I think I might
> make that change, to have less in configure.
Hmm, it's fine with me either way.
--
GPG: D5D4E405 - 2F9B BCCC 8527 692
Andy Wingo <[EMAIL PROTECTED]> writes:
> Speaking of which, a -g compile on PPC uses quite a lot of stack -- I
> had to up the default limit in order to get anything to work (for
> example, compiling psyntax). That would be another issue though...
Yeah, it's a "known issue" also on x86. The defa
Andy Wingo <[EMAIL PROTECTED]> writes:
> Hi,
>
> On Mon, 2006-05-08 at 00:29 +0300, Marius Vollmer wrote:
> > 137c137
> > < #define CELL_P(x) (SCM_ITAG3 (x) == scm_tc3_cons)
> > ---
> > > #define CELL_P(x) ((SCM_UNPACK(x) & (sizeof(scm_t_cell
Miroslav Lichvar <[EMAIL PROTECTED]> writes:
> On Fri, May 05, 2006 at 04:05:34PM +0200, Miroslav Lichvar wrote:
> > The scm_mark_locations function in gc-mark.c calls scm_gc_mark on
> > everything located in one of the allocated segments. Shouldn't there
> > be a check if the address is at least
Marius Vollmer <[EMAIL PROTECTED]> writes:
> I will include the test program into configure.in and only use
> __libc_stack_end (or gc_os_dep) when it is really needed.
Done. Steven, please test: either from the "branch_release_1-8"
branch in CVS or a nightly snapshot
Kevin Ryde <[EMAIL PROTECTED]> writes:
> The manual describes SCM_SIMPLE_VECTOR_SET_X but vectors.h has it as
> just SCM_SIMPLE_VECTOR_SET, ie. without the "_X". Which is it meant
> to be?
Since 1.8 has been released, we should stick with
SCM_SIMPLE_VECTOR_SET, I'd say.
--
GPG: D5D4E405 - 2F9B
Neil Jerram <[EMAIL PROTECTED]> writes:
> Just a heads-up: until I get to any work that isn't appropriate for
> the 1.8 branch, I'm planning to make all my commits to the 1.8 branch
> only, on the assumption that we will do something later to copy those
> changes to CVS head.
Yes, that's how it i
Neil Jerram <[EMAIL PROTECTED]> writes:
> (And interestingly, this program says that __libc_stack_end isn't
> needed on my Debian GNU/Linux, despite the comment in threads.c
> suggesting that it _is_ needed on Linux.)
Ahh. Maybe I just had a buggy version of LinuxThreads at the time. I
just tri
Neil Jerram <[EMAIL PROTECTED]> writes:
> [...] I wonder why the change was made to remove the gc_os_dep.c
> fallback option; I can't see anything obvious in the ChangeLog.
> (gc_os_dep.c and the necessary scm_get_stack_base() definitions are
> still there in 1.8, they're just not used.)
I guess
"John Sullivan via RT" <[EMAIL PROTECTED]> writes:
> Can you please let us know whether Guile would still like to be
> listed on the consolidated help wanted page, [...]
Please remove Guile from that page.
Thanks!
--
GPG: D5D4E405 - 2F9B BCCC 8527 692A 04E3 331E FAF8 226A D5D4 E405
__
"John Sullivan via RT" <[EMAIL PROTECTED]> writes:
> Can you please let us know whether Guile would still like to be
> listed on the consolidated help wanted page, [...]
Please remove Guile from that page.
Thanks!
--
GPG: D5D4E405 - 2F9B BCCC 8527 692A 04E3 331E FAF8 226A D5D4 E405
Kevin Ryde <[EMAIL PROTECTED]> writes:
> I'm inclined to remove the short-circuit
>
> if (size <= old_size)
> return where;
>
> from scm_must_realloc, ie. if you ask to decrease a block then
> actually do it, which is what 1.8 has now.
Sounds good to me.
--
GPG: D5D4E405 - 2F9B
Kevin Ryde <[EMAIL PROTECTED]> writes:
> Actually, I see off_t is exposed through the ptob port descriptor
> funcs, so implicitly changing to off64_t would break applications.
I think we need to redo the public port API anyway, for Unicode and to
clean it up. At that time, we can also get large
Kevin Ryde <[EMAIL PROTECTED]> writes:
> What can be said in the manual about `equal?' on arrays these days?
> Can vectors and 1-dim arrays be compared with equal now? Is it still
> the case that all shared arrays have to be compared with
> `array-equal?' ?
It should clearly be possible to use e
Kevin Ryde <[EMAIL PROTECTED]> writes:
> I don't understand all that stuff, but I got some joy from this
> change. Can someone (Marius?) confirm or deny?
>
> * unif.c (bitvector_set): Should be h->writable_elements not
> h->elements, the latter results in a segv in array-set! on a
We are pleased to announce the release of Guile 1.8.0. It can be
found here:
ftp://ftp.gnu.org/gnu/guile/guile-1.8.0.tar.gz
Its SHA1 checksum is
22462680feeda1e5400195c01dee666162503d66 guile-1.8.0.tar.gz
We already know about some issues with 1.8.0, please check the mailing
lists:
Michael Tuexen <[EMAIL PROTECTED]> writes:
> the check for socklen_t fails incorrectly because socklen_t is
> defined in /sys/socket.h on Mac OS X, and on BSD systems in general.
Let's figure this out in HEAD first and then put it into 1.8.1.
--
GPG: D5D4E405 - 2F9B BCCC 8527 692A 04E3 331E FA
[EMAIL PROTECTED] (Ludovic Courtès) writes:
> I think it'd be nice to export `scm_i_mem2number ()'. My initial plan
> was to just rename it `scm_c_string_to_number ()' and document it.
>
> However, due to the eventual support for various encodings, we'd rather
> need to have something like `scm_c
Michael Tuexen <[EMAIL PROTECTED]> writes:
> the check for socklen_t fails incorrectly because socklen_t is
> defined in /sys/socket.h on Mac OS X, and on BSD systems in general.
What happens after the check fails? Will Guile compile correctly
anyway?
(I tried 1.7.90 on a friends Powerbook. It
[EMAIL PROTECTED] (Han-Wen Nienhuys) writes:
> what is your plan for maintaining the branches?
The release-1-6 branch remains stable of course, and the release-1-8
branch will be stable after 1.8.0 has been released, and is now in
feature freeze. "Stable" should mean "we try very hard to not
reg
[EMAIL PROTECTED] (Ludovic Courtès) writes:
>> Well, they get to choose both texts that have a MD5 collision.
>> Looking at the PostScript source reveals that the texts have been
>> rigged, which should be enough if this goes to court. In our case, an
>> attacker would need to find a second meani
[EMAIL PROTECTED] (Ludovic Courtès) writes:
> BTW, I'd strongly recommend using SHA1 sums (e.g., via `sha1sum', part
> of GNU Coreutils) rather than MD5.
Yeah, that's probably best.
> See the example at http://www.cits.rub.de/MD5Collisions/ if in
> doubt. ;-)
Well, they get to choose both text
We are pleased to announce the release of Guile 1.7.91. This is a
release candidate for Guile 1.8. It can be found here:
ftp://alpha.gnu.org/gnu/guile/guile-1.7.91.tar.gz
Its MD5 checksum is
b2106c1b574e22ec67c4c2178074b5ec guile-1.7.91.tar.gz
The plan is to release version 1.8.0 nex
[EMAIL PROTECTED] (Han-Wen Nienhuys) writes:
> The function scm_dynwind_pthread_mutex_lock is defined only if
> SCM_USE_PTHREAD_THREADS is enabled, but it is called regardless in eval.c.
>
> Bug?
Yup. Fixed in 1.7.91. Thanks!
2006-02-13 Marius Vollmer <[EMAIL PROTECTED]>
Hi,
I just uploaded guile-1.7.90.tar.gz to alpha.gnu.org. Please check it
out. I'll now go watch some movie and when I'm back I'll announce it
properly.
--
GPG: D5D4E405 - 2F9B BCCC 8527 692A 04E3 331E FAF8 226A D5D4 E405
___
Guile-devel mailing l
Kevin Ryde <[EMAIL PROTECTED]> writes:
> [EMAIL PROTECTED] (Ludovic Courtès) writes:
>>
>> $ ./pre-inst-guile # i.e., 1.7
>> guile> (define a (make-uniform-array #\nul 10))
>> ERROR: Wrong type (expecting exact integer): #\nul
>> ABORT: (wrong-type-arg)
>
> That's a bug. In 1.6 you could
Neil Jerram <[EMAIL PROTECTED]> writes:
> I'd personally like to have this in 1.8. Any objections?
Hmm, I'm inclined not to put this into 1.8, at least not in 1.8.0. I
can't really put my finger on it, as I see nothing fundamental wrong
with the patch, but I also don't see the immediate need fo
[EMAIL PROTECTED] (Ludovic Courtès) writes:
> Hi,
>
> Rob Browning <[EMAIL PROTECTED]> writes:
>
>> Also if we don't want to have people hold off on 1.9 only bits in the
>> trunk, then I'd say that now qualifies as "as late as possible" ;>
>
> There has been no 1.7.3, the CVS repository has been r
Hi,
as promised, I have branched the guile-core module for the 1.8
release. The branch tag is named branch_release-1-8 and it is rooted
at the tag branch-root_release-1-8.
Please check it out!
Daily snapshots of 1.8 should appear in
ftp://ftp.dt.e-technik.uni-dortmund.de/pub/guile/snapshot
Kevin Ryde <[EMAIL PROTECTED]> writes:
> Marius Vollmer <[EMAIL PROTECTED]> writes:
>>
>> I just put scm_is_pair into inline.h, using our existing inlining
>> machinery that should be portable enough.
>
> Maybe scm_is_eq too (picking up scm_is_true and scm_i
Rob Browning <[EMAIL PROTECTED]> writes:
> Kevin Ryde <[EMAIL PROTECTED]> writes:
>
>>> (What we have in the 1.8 branch is not immediately the 1.8.0 release,
>>> but should be very close.)
>>
>> Do you really want to branch at all?
>
> For what it's worth, I'd say there a benefit to branching as l
Mikael Djurfeldt <[EMAIL PROTECTED]> writes:
> For now, I will not work further on that code. To the Guile
> developers I suggest that you do what you want. Fix it, or back out
> the future feature entirely.
Hmm. Semantically, 'begin-thread' and 'thread-join' should be
(nearly?) identical to '
Neil Jerram <[EMAIL PROTECTED]> writes:
> How about renaming the internal scm_frame functions instead, since
> AFAIK they haven't been released yet?
Yep, I'll do that.
> Perhaps scm_context_..., or scm_dynwind_..., or scm_dc_...?
I'm going with scm_dynwind_ since the functions are directly rela
[EMAIL PROTECTED] (Ludovic Courtès) writes:
> The following patch makes `scm_is_pair ()' an inline [...]
I just put scm_is_pair into inline.h, using our existing inlining
machinery that should be portable enough. Ok?
> I'm not sure that's the only reason, but I'm now unable to compile Guile
> w
Hi,
I need to kick myself to get going with the 1.8 release, and want to
do it by just branching for 1.8 soon and thus get out of the way of
the devlopment happening on the trunk.
I want to branch next weekend, on Sunday, 5. Feb. Before that, the
following things should be settled in trunk, I'd
>> Hmm, what I'm trying to say here that "lazy" is not some standard,
>> established terminology, and if we come up with something better, we
>> should feel free to change terminology.
>
> Yes, that makes good sense. I can't think of anything better than
> "pre-unwind", so I'll use that in all new
Hi,
guile> (define m43 (1- (expt 2 30402457)))
guile> (integer-length m43)
30402457
guile> (remainder m43 8352716958173659)
2698619340888656
guile> (number->string m43 16)
"f."
guile> m43
Segmentation fault
So we can handle numbers like that, but we can
Neil Jerram <[EMAIL PROTECTED]> writes:
> The main part of this patch is appended below, and I would appreciate
> any comments that anyone may have
Looks very good to me. Please go ahead. Thanks!
One (minor?) point I have is the term "lazy". I am not sure if it is
the right term to use. It
Andy Wingo <[EMAIL PROTECTED]> writes:
> 1) functions that take C types normally are named scm_c_*. There are a
> few exceptions though:
The rule is that scm_c_foo is mostly the same as scm_foo, only with a
different calling convention that is easier for C. For example, we
have scm_vector_length
Neil Jerram <[EMAIL PROTECTED]> writes:
> (Sudden confusion: Are fluids part of R5RS? If so, why do we need the
> parameters SRFI? I guess I need to go and reread it.)
No no no, fluids are not part of R5RS. I think we should implement
the parameter SRFI in the core and start using it for thing
Kevin Ryde <[EMAIL PROTECTED]> writes:
> Was some of the change to scm_is_whatever meant to keep the
> representation of an SCM value out of application binaries?
No, it was about having a clean distinction between functions that
return SCM booleans (scm_whatever_p) and those that return C boolea
[EMAIL PROTECTED] (Ludovic Courtès) writes:
> I believe it *really* makes sense to turn `scm_is_pair ()' into a macro.
Yep. But what about an inline function? There is some machinery in
inline.h for this and we already use it for scm_cell, for example.
> +#define scm_is_pair(__obj) (SCM_I_CON
Neil Jerram <[EMAIL PROTECTED]> writes:
> read_without_guile_data *data = (read_without_guile_data *)data;
>
> ... the second "data" should be "raw_data".
Aaarg! :-/ (This wouldn't happen with 'let'...)
Thanks for finding this.
--
GPG: D5D4E405 - 2F9B BCCC 8527 692A 04E3 331E FAF8 226
[EMAIL PROTECTED] (Ludovic Courtès) writes:
> Marius Vollmer <[EMAIL PROTECTED]> writes:
>
>> C code can observe the GC doing its thing (via the smob free
>> functions). In order not to overconstrain the implementation of the
>> GC (which is pretty constraine
[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
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.
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
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
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
[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
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
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'
[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
[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
>> 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
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
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,
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
___
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
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
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
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
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
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
[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
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
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
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:
> 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?
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
[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
_
[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.
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:
> 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
[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:
> 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
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?
>
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
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:
> 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:
> 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
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)
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
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
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
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-
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
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:
>> 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:
> 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:
> 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
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
1 - 100 of 152 matches
Mail list logo
