Kevin Ryde [EMAIL PROTECTED] writes:
Szavai Gyula [EMAIL PROTECTED] writes:
(let ((b (make-shared-array #(1) (lambda (x) '(0)) 2)))
Thanks, though I'm not sure that's supposed to work. I suspect you're
not meant to make parts of the old array appear in more than one place
in the new
Hi,
(just for the record, I am going to fix this myself if nobody beats me
to it.)
guile (make-vector 1 2 3)
ABORT: (wrong-number-of-args)
but
guile (apply make-vector '(1 2 3))
#(2)
This doesn't happen for Scheme functions, probably only for (certain
types of) primitives.
--
Matt Kraai [EMAIL PROTECTED] writes:
When I tried to compile Guile on a QNX 6.3.0 system, it did not find
the libtool and gmp libraries or the gmp header files that I'd built
and installed under /usr/local until I set the CPPFLAGS environment
variable to -I/usr/local/include and the LDFLAGS
Mike Gran [EMAIL PROTECTED] writes:
In libguile/srfi-4.c and libguile/strings.c, the SCM_C_INLINE_KEYWORD
needs to be used instead of SCM_C_INLINE for compilers w/o an inline
keyword.
Thanks, fixed!
--
GPG: D5D4E405 - 2F9B BCCC 8527 692A 04E3 331E FAF8 226A D5D4 E405
Matt Kraai [EMAIL PROTECTED] writes:
So the correct solution is to ensure that the compiler looks in
/usr/local?
Yes.
Do you know why other programs don't require this?
Maybe... :-) What programs are you talking about?
--
GPG: D5D4E405 - 2F9B BCCC 8527 692A 04E3 331E FAF8 226A D5D4
Neil Jerram [EMAIL PROTECTED] writes:
You might like to try making the code for my-hostname safer, like
this:
We should make the example safe as well...
--
GPG: D5D4E405 - 2F9B BCCC 8527 692A 04E3 331E FAF8 226A D5D4 E405
___
Bug-guile mailing
James Bergstra [EMAIL PROTECTED] writes:
I have a program that causes the guile interpreter to segfault when
I output with (simple-format), but runs properly when I replace the
simple-format with what I believe are equivalent calls to (display).
If you can, please show us that program. We
Neil Jerram [EMAIL PROTECTED] writes:
Anyone care to comment or to concoct new tests to explore these?
Everything is possible with out array code. It is too clever for its
own good and needs to be rewritten. Looking at the code makes you
think that something really sophisticated must be going
Neil Jerram [EMAIL PROTECTED] writes:
in lines
872-893, this -
if (s[k].inc 0)
old_max += (s[k].ubnd - s[k].lbnd) * s[k].inc;
else
old_min += (s[k].ubnd - s[k].lbnd) * s[k].inc;
- suggests that (old_min, old_max) will be (inclusive, exclusive),
Kevin Ryde [EMAIL PROTECTED] writes:
Aubrey Jaffer [EMAIL PROTECTED] writes:
Because (= 0.0 -0.0) is #t, (eqv? 0.0 -0.0) must be #t.
Ah dear, thanks. Bit too much creativity with the nans and infs.
Hmm. I think SRFI 77 (Preliminary Proposal for R6RS Arithmetic) would
require (eqv? 0.0
Mikael Djurfeldt [EMAIL PROTECTED] writes:
I've now fixed this in CVS HEAD:
Thanks! I 'ported' your fix to the relase_1-8 branch and it is in
1.8.0.
--
GPG: D5D4E405 - 2F9B BCCC 8527 692A 04E3 331E FAF8 226A D5D4 E405
___
Bug-guile mailing list
Neil Jerram [EMAIL PROTECTED] writes:
Marius Vollmer [EMAIL PROTECTED] writes:
Please also make this change in the branch_release-1-8 branch if
appropriate.
Yes, I've done that.
Thanks!
--
GPG: D5D4E405 - 2F9B BCCC 8527 692A 04E3 331E FAF8 226A D5D4 E405
Neil Jerram [EMAIL PROTECTED] writes:
Thanks for confirming this. I'll make the change in CVS.
Please also make this change in the branch_release-1-8 branch if
appropriate.
(I'll make a note so that I don't forget about it myself in case you
can't find time.)
--
GPG: D5D4E405 - 2F9B BCCC
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
___
Davide Angelocola [EMAIL PROTECTED] writes:
Guile version 1.7.1.
srfi-13.c: In function `scm_string_trim_right':
srfi-13.c:771: warning: passing arg 3 of `scm_i_get_substring_spec'
from incompatible pointer type
I believe this haaas been fixed in 1.7.2. Please try that version.
Thanks!
Bill Schottstaedt [EMAIL PROTECTED] writes:
A less-than-ideal error message (abstracted from a much larger context):
guile (version)
1.7.2
guile (+ pk 1.0) ; pk was a typo in the original code
Backtrace:
In standard input:
5: 0* [+ {#procedure peek stuff} 1.0]
standard input:5:1:
Stephen Caraher [EMAIL PROTECTED] writes:
The front page of the Guile homepage says that the release of Guile
1.7.2 was on 2004-03-09. I think it's meant to say 2005 :)
Yes! Thanks!
___
Bug-guile mailing list
Bug-guile@gnu.org
Issac Trotts [EMAIL PROTECTED] writes:
I propose the following change to the documentation so that newbies
like me can learn to use eval more easily.
Done, thanks!
$ diff eval.c{,.bak}
4155,4156c4155
is reset to its previous value when @var{eval} returns.\n
Neil Jerram [EMAIL PROTECTED] writes:
This change (calculating and storing the offset in
scm_make_continuation) makes sense, but I'd like also to understand
where the bug was in my version (using offset = (SCM_CONTREGS
(stack) - stack) - SCM_BASE (stack);) and why my code worked in 1.6
but
Neil Jerram [EMAIL PROTECTED] writes:
One more thing - are you happy with the proposed new tests for 1.6 and
head?
Yes.
I think one change is needed, namely to save and restore
(debug-options) so that the effect of (debug-enable 'debug) can't
affect other tests.
Sounds good to me, too.
Neil Jerram [EMAIL PROTECTED] writes:
And one more problem ... the same problem exists in CVS head, but a
similar patch doesn't fix it ... still investigating.
I'm looking into this as well, now. The fix you did for 1.6 looks
good, although I don't understand it completely yet. I will try to
Mikael Djurfeldt [EMAIL PROTECTED] writes:
What's needed seems to be to factorize scm_sym2var a little.
Or, we could switch to the environments.c implementation! :-)
I have changed module-make-local-var! a bit:
(define (module-make-local-var! m v)
(or (let ((b (module-obarray-ref
Mikael Djurfeldt [EMAIL PROTECTED] writes:
Marius Vollmer [EMAIL PROTECTED] writes:
Mikael Djurfeldt [EMAIL PROTECTED] writes:
2004-04-22 Dirk Herrmann [EMAIL PROTECTED]
(scm_m_define): Change order to first create binding and
evaluating the expression afterwards.
While
Neil Jerram [EMAIL PROTECTED] writes:
Hmm, I can't find the place where scm_procedure_property calls apply.
Could you give me a hint?
Sorry! Please see the attached stack trace. scm_procedure_property
calls scm_stand_in_proc, which calls scm_assoc, which calls
scm_equal_p, which decides to do
Kevin Ryde [EMAIL PROTECTED] writes:
Pierre [EMAIL PROTECTED] writes:
fail: scm_from_double (nan) == +nan.0
FAIL: test-conversion
See if you can trace through with gdb to see where it fails, ie. if
one of the operands is not a nan, or if the comparison has gone wrong.
Guile and the
[EMAIL PROTECTED] (Paul Jarc) writes:
Building 1.6.5 fails for me:
[...]
Paul, any news on this front? Things like this are very hard to
reproduce on a second system, and everything seems to work fine for me
here...
However, there is one snag that I noticed: try changing the line in
Mikael Djurfeldt [EMAIL PROTECTED] writes:
2004-04-22 Dirk Herrmann [EMAIL PROTECTED]
(scm_m_define): Change order to first create binding and
evaluating the expression afterwards.
While this change works in the R5RS situation without a module system,
the presence of a module
Neil Jerram [EMAIL PROTECTED] writes:
Working on breakpoints for 1.6.x, I just discovered that the
following ENTER_APPLY trap code in eval.c goes into a tight busy loop
if (debug-enable 'trace) and (trap-set! apply-frame-handler non-#f).
if (CHECK_APPLY SCM_TRAPS_P)\
if
Rob Browning [EMAIL PROTECTED] writes:
Mikael Djurfeldt [EMAIL PROTECTED] writes:
Execution of guilw-core/autogen.sh yields:
Makefile.am:24: required directory ./libltdl does not exist
autoreconf: automake failed with exit status: 1
I think Marius may have just removed libguile-ltdl from
Andreas Vögele [EMAIL PROTECTED] writes:
there are still C99isms in strings.c and threads.c.
Fixed, thanks.
--
GPG: D5D4E405 - 2F9B BCCC 8527 692A 04E3 331E FAF8 226A D5D4 E405
___
Bug-guile mailing list
[EMAIL PROTECTED]
Rob Browning [EMAIL PROTECTED] writes:
Marius Vollmer [EMAIL PROTECTED] writes:
Makes me think, maybe we should remove the restriction that #! and
!# comments are only detected at the ery beginning of a line. That
restriction serves no real purpose, imo. Opinions?
I would have thought
Kevin Ryde [EMAIL PROTECTED] writes:
Andreas Vögele [EMAIL PROTECTED] writes:
Here's a patch that replaces the test for the pthread library with the
macro from
http://www.gnu.org/software/ac-archive/htmldoc/acx_pthread.html.
Copyright paperwork will be needed before that can be used.
I
Andreas Vögele [EMAIL PROTECTED] writes:
The problem is that NaN may be negative or positive on these
systems. The function real_eqv in libguile/eq.c, which uses memcmp
to compares doubles, doesn't take this into account.
Hmm. Another stance on this is that real_eqv does in fact take this
Kevin Ryde [EMAIL PROTECTED] writes:
Bill Schottstaedt [EMAIL PROTECTED] writes:
(begin
(display 1)
#!
(display 2)
!#
)
gets:
ERROR: In procedure scm_lreadr:
ERROR: tmp34.scm:6:2: unexpected )
Looks like #! !# doesn't work as the last thing in a list. Maybe that
comment should
Mike Small [EMAIL PROTECTED] writes:
Maybe this could be changed to something like the following:
--
Miscellaneous
`string-replace' is for replacing a portion of a string with another
string and `string-tokenize' splits
Kevin Ryde [EMAIL PROTECTED] writes:
Thanks. I fixed integer-expt to reject an exponent +/-inf.
Hmm, we could only allow exact integers. That would reject +/-inf as
well. Right now, we have
(exact? (integer-expt 2 2.0))
= #t
which seems wrong.
It got there because (integer?
Han-Wen Nienhuys [EMAIL PROTECTED] writes:
Compile GUILE with
#define SCM_DEBUG_CELL_ACCESSES 1
in config.h. Then apply this patch
+ (set-debug-cell-accesses! 5000)
then compilation bombs out with:
I have found the bug. init_heap_seg was using SCM_SET_CELL_TYPE to
initialize
Bill Schottstaedt [EMAIL PROTECTED] writes:
In the CVS guile, if you don't have GUILE_LOAD_PATH set,
you get an immediate segfault:
Yep, thanks. Fixed!
--
Marius Vollmer AG Datentechnik / E-Technik
Tel: +49-231-755-3036 Universität Dortmund
Andreas Vögele [EMAIL PROTECTED] writes:
here's a patch that replaces SCM_FALSEP and SCM_NFALSEP in readline.c
with the new functions scm_is_false and scm_is_true.
Thanks! I think I have fixed this already. It'll be in the next
commit frenzy...
--
GPG: D5D4E405 - 2F9B BCCC 8527 692A 04E3
Dirk Herrmann [EMAIL PROTECTED] writes:
Marius Vollmer wrote:
Kevin Ryde [EMAIL PROTECTED] writes:
Ah, no, I see this is still not right. scm_m_generalized_set_x is
using scm_macroexp, but it's not defined at all under
--disable-deprecated.
Looks like this was a change by Marius
Kevin Ryde [EMAIL PROTECTED] writes:
Ah, no, I see this is still not right. scm_m_generalized_set_x is
using scm_macroexp, but it's not defined at all under
--disable-deprecated.
Looks like this was a change by Marius not so long ago. Dunno if it
should be using scm_macroexp, or something
Han-Wen Nienhuys [EMAIL PROTECTED] writes:
in list.c, many doc strings say
Return a pointer to\n
the mutated list.
Return a pointer to the last pair in @var{lst},
isn't this stupid?
Yes!
Scheme doesn't have pointers. Why not say
Return the last
Han-Wen Nienhuys [EMAIL PROTECTED] writes:
Can you please fix this? I consider this a severe bug.
Done! Thanks.
PS: A workaround is to use 'quote':
(eval `(bar ',q) (current-module))
2004-03-21 Marius Vollmer [EMAIL PROTECTED]
* eval.c (scm_ceval, scm_deval): Explicitely
Bernard Urban [EMAIL PROTECTED] writes:
Debian woody on i386.
$ guile
guile (version)
1.6.4
guile (/ 0)
+#.#
guile (/ 1.0 0)
+#.#
guile (/ 1 0.0)
+#.#
guile(/ 1 0)
standard input:3:1: In procedure / in expression (/ 1 0):
standard input:3:1: Numerical overflow
ABORT:
Bill Schottstaedt [EMAIL PROTECTED] writes:
read.c (line 271 in 1.6.4, 286 in CVS):
in skip_scsh_block_comment (SCM port)
if (history == (('\n' 24) | ('!' 16) | ('#' 8) | '\n'))
gets confused if the text editor uses \r\n rather than \n.
Fixed, thanks!
(This is possible with
Bill Schottstaedt [EMAIL PROTECTED] writes:
define* is a bit confusing in that it simply ignores invalid
arguments:
Yes. Patches welcome! :-)
--
GPG: D5D4E405 - 2F9B BCCC 8527 692A 04E3 331E FAF8 226A D5D4 E405
___
Bug-guile mailing list
[EMAIL
Andreas Rottmann [EMAIL PROTECTED] writes:
libguile/.cvsignore ignores itself, which is useless:
Fixed, thanks.
--
GPG: D5D4E405 - 2F9B BCCC 8527 692A 04E3 331E FAF8 226A D5D4 E405
___
Bug-guile mailing list
[EMAIL PROTECTED]
Bill Schottstaedt [EMAIL PROTECTED] writes:
In Friday's CVS guile there are two redundant declarations.
Fixed, thanks!
--
GPG: D5D4E405 - 2F9B BCCC 8527 692A 04E3 331E FAF8 226A D5D4 E405
___
Bug-guile mailing list
[EMAIL PROTECTED]
Roland Orre [EMAIL PROTECTED] writes:
guile-user (uniform-vector? '(a b c))
#t
Yeahh, and
(uniform-vector? 'foo)
= #t
(uniform-vector? (expt 2 60))
= #t
(uniform-vector? 1.0)
= #t
(uniform-vector? 1+i)
= #t
unif.c is totally botched, I'd say. We need to
tickled by backtrace, but I haven't had time to try to
track it down (it's independent of GOOPS).
Please try again, I think I have fixed it:
2004-01-22 Marius Vollmer [EMAIL PROTECTED]
* eval.c (m_expand_body): Rewrite the expression in place (by
overwriting FORMS) also when
Han-Wen Nienhuys [EMAIL PROTECTED] writes:
It seems to be working. There was a stray variable in eval.c, though.
I fixed that.
Yep, thanks.
BTW, how is GUILE 1.8 progressing?
The two big things that need to be done are: GH replacement (including
docs of course) and finishing the thread
[EMAIL PROTECTED] (Paul Jarc) writes:
This is still not complete, though. There are still problem cases
like #{0.0}#, #{-i}#, etc.
This patch handles those numeric cases. [...]
Applied, thanks! (Good thing I'm so slow, eh? ;-)
--
GPG: D5D4E405 - 2F9B BCCC 8527 692A 04E3 331E FAF8 226A
joop renes [EMAIL PROTECTED] writes:
In vain i tried to install guile-oops on my SuSE9.0 prof box.
response to make attached. what can i do ?
You probably already have GOOPS included in Guile and do not need to
compile guile-goops at all. Guile includes GOOPS since version 1.6.0.
Check with
Robert D. Skeels [EMAIL PROTECTED] writes:
-# ifndef mach_type_known
+# ifdef mach_type_known
-- unknown machine type
# endif
That's not a fix, that's a bug! ;)
When your machine type is unknown, we need to add it to gc_os_dep.c.
An alternative would be to make scm_init_guile fail
[EMAIL PROTECTED] (Paul Jarc) writes:
(OOC, would a patch like this be appropriate for 1.6? What's the
policy there?)
Yes, since it's a pure bug fix, we can apply it to 1.6 also. I will
do this. Thanks!
ISTR someone suggested triggering the garbage collector after so many
open()s; that
[EMAIL PROTECTED] (Paul Jarc) writes:
OTOH, it's also good to explicitly close
descriptors - if close() reports an error, we want to see where it
came from.
Yes, definitely. We might even emit a warning when the GC closes a
port.
--
GPG: D5D4E405 - 2F9B BCCC 8527 692A 04E3 331E FAF8 226A
Bill Schottstaedt [EMAIL PROTECTED] writes:
Another oddity in ice-9/format.scm:
Thanks, I recorded this in our backwater bug database, but I'm afraid
I'll need a patch for fixing this... do you have any?
Perhaps this will do it (line 740):
(if param-value-found (format:error
Thien-Thi Nguyen [EMAIL PROTECTED] writes:
From: Thamer Al-Harbash [EMAIL PROTECTED]
Date: Thu, 28 Aug 2003 10:53:34 -0400 (EDT)
This cgi::make-cookie breaks under guile-1.6 because it's using a
#key and the (bound?) macro which seem to be no longer available
or depreciated.
HF [EMAIL PROTECTED] writes:
GH_DEFER_INTSMacro
GH_ALLOW_INTS Macro
These macros disable and re-enable Scheme's flow control. They
IMHO the text should continue after the trailing They.
Yes, thanks for pointing this out! The DEFER, ALLOW thing needs to be
properly
Mike Gran [EMAIL PROTECTED] writes:
Here is a super-trivial document patch to the reference
manual.
Applied, thanks!
--
GPG: D5D4E405 - 2F9B BCCC 8527 692A 04E3 331E FAF8 226A D5D4 E405
___
Bug-guile mailing list
[EMAIL PROTECTED]
Post, Mark K [EMAIL PROTECTED] writes:
When I went to upgrade to Guile 1.6.3, I discovered that it wouldn't compile
due to the addition of libguile/gc_os_dep.c. I'm attaching a patch to add
support for Linux/390.
Hmm, I think we should just copy the gc_os_dep.c from CVS HEAD over to
the 1.6
Adrian Bunk [EMAIL PROTECTED] writes:
Please apply
Done! Thanks!
--
GPG: D5D4E405 - 2F9B BCCC 8527 692A 04E3 331E FAF8 226A D5D4 E405
___
Bug-guile mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-guile
Andrew Koenig [EMAIL PROTECTED] writes:
Marius Could you try compiling without -O2? Also, if convenient,
could you Marius compile with GCC 2.95.x?
Do I need to do anything beyond deleting -O2 from all the Makefiles?
Just doing
$ make clean
$ make CFLAGS=-g
should be enough. You can
Andrew Koenig [EMAIL PROTECTED] writes:
I was going to suggest a binary-search approach to finding the
problem, but of course that might not work if the optimization problem
shows up in more than one translation unit. But what should work is
to compile everything with -O0, then recompiling
Andrew Koenig [EMAIL PROTECTED] writes:
OK ... what's happening is that the right guile is being run, but
the run is not successful:
[europa] GUILE=/tmp/guile/guile-1.6.3/pre-inst-guile
../scripts/snarf-check-and-output-texi --manual
Segmentation Fault - core dumped
Ok. I have just
Andrew Koenig [EMAIL PROTECTED] writes:
I just tried building up the input file by hand that
snarf-check-and-output-texi expects, and running it through
snarf-check-and-output-texi to see what it does. The output:
$ snarf-check-and-output-texi /tmp/guile-doc
;;; WARNING (no code for
Neil Jerram [EMAIL PROTECTED] writes:
Marius/Rob, should this go into the stable branch as well?
Yes. (The way I understand it, it is a fix for something that didn't
work before at all, right? It doesn't change existing behavior,
right?)
--
GPG: D5D4E405 - 2F9B BCCC 8527 692A 04E3 331E
Neil Jerram [EMAIL PROTECTED] writes:
Marius == Marius Vollmer [EMAIL PROTECTED] writes:
Marius Neil Jerram [EMAIL PROTECTED] writes:
Marius/Rob, should this go into the stable branch as well?
Marius Yes. (The way I understand it, it is a fix for something
Marius
Marko Rauhamaa [EMAIL PROTECTED] writes:
The Guile manual doesn't state that basically all writable memory of
a process participates in GC:
Hmm. More needs to be said to get a accurate picture of how GC works
in Guile.
The Guile GC does only manage objects that are represented as a value
of
Stanislav Brabec [EMAIL PROTECTED] writes:
there is a small typo fix in guile-1.6.0, causing disfunctionality of
some applications, namelly TeXmacs.
Thanks for the report! This has been fixed already in CVS and will be
in Guile 1.6.1, which should be out soonish.
--
GPG: D5D4E405 - 2F9B
Neil Jerram [EMAIL PROTECTED] writes:
Marius == Marius Vollmer [EMAIL PROTECTED] writes:
Marius Note also that (ice-9 format) is not thread safe...
And also -- if it makes any difference -- not async safe.
Yeah, right, I didn't think about this. When format is reimplemented
to nbe
jblazi [EMAIL PROTECTED] writes:
scm_eval_string((scm_unused_struct*)(test_function 4));
You can not just cast a char* to a SCM. Where did you get that idea?
(Maybe there is some misleading stuff in the manual, that's why I
ask.)
You should either use scm_c_eval_string,
jblazi [EMAIL PROTECTED] writes:
test2.cpp: In function `void register_procs()':
test2.cpp:12: invalid conversion from `
scm_unused_struct*(*)(scm_unused_struct*)' to `scm_unused_struct*(*)()'
*/
You need to use an explicit cast in C++:
gh_new_procedure(test_function,(SCM
Bill Schottstaedt [EMAIL PROTECTED] writes:
[ alot of good stuff about Mac OSX. ]
Thanks for the detailed report! Could you condense this into a patch
that we can apply?
--
GPG: D5D4E405 - 2F9B BCCC 8527 692A 04E3 331E FAF8 226A D5D4 E405
___
Bill Schottstaedt [EMAIL PROTECTED] writes:
It appears to be a compiler bug.
Ok. We have seen this already, in a different place. It's good to
know that it is a compiler bug and not some property of ANSI C that we
would need to take into account.
--
GPG: D5D4E405 - 2F9B BCCC 8527 692A 04E3
Eric Hanchrow [EMAIL PROTECTED] writes:
This is guile 1.6.0
$ /usr/local/guile1.6/bin/guile -q -c '(begin (display (expt 0 3)) (newline))'
1
Thanks! It's fixed in CVS (both branches).
--
GPG: D5D4E405 - 2F9B BCCC 8527 692A 04E3 331E FAF8 226A D5D4 E405
Bill Schottstaedt [EMAIL PROTECTED] writes:
in iselect.c the HAVE_UNISTD_H macro is used before
it has any chance to be defined.
Thanks! Fixed in both branches.
--
GPG: D5D4E405 - 2F9B BCCC 8527 692A 04E3 331E FAF8 226A D5D4 E405
___
Bug-guile
Eric Hanchrow [EMAIL PROTECTED] writes:
Invoke the snippet with `guile -s snippet.scm'. Note the total lack
of output.
The process exits before it can produce any output. guile -s exits
as soon as the main thread exits. (The builtin simple-format is
probably fast enough to produce output
Christof Boeckler [EMAIL PROTECTED] writes:
On Solaris 8 I had the following error while executing 'make' (configure
was successful):
It looks like Sun's make does not understand the $ construct, which
I find really strange as the man page of make mentions it
(mysteriously). It might be that
Joost Helberg [EMAIL PROTECTED] writes:
If not, can you fix it? :-)
Not necessary.
Ok, thanks!
Is there a way to extend srfi-19, or to make up a new one?
I hope so. I'm not really familiar with the SRFI process, but it
looks like you need to start a new SRFI to bugfix an existing
Orm Finnendahl [EMAIL PROTECTED] writes:
after compiling and installing guile 1.6.0 I get the following error
on a Debian with 2.4.19 kernel when trying to use libreadline as
specified in guile's info manual:
Please try configuring Guile with the option --enable-ltdl-install.
That will
Michael Vanier [EMAIL PROTECTED] writes:
I'm pretty happy to see guile catching up with other scripting languages.
I'm especially happy with how easy it is to write extensions; I don't know
of any other scripting language that has such a trivially simple extension
mechanism.
I'm very happy
[EMAIL PROTECTED] (I.Sheldon) writes:
With a simple test of starting guile and then typing `(quit)', this
reduced the number of warnings I was getting from 19270 to 19014.
Since this reduction is so small, I'm inclined not to apply your
patch. What do others say?
--
GPG: D5D4E405 - 2F9B
Michael Vanier [EMAIL PROTECTED] writes:
I have put the file into /usr/lib and it still couldn't find it!
This is (another) bug in libltdl. It first tries the .la extenstion
and then should continue with the .so extension. However, it
incorrectly stops when no .la file could be found.
A
Dirk Herrmann [EMAIL PROTECTED] writes:
I'd say introduce scm_defined_p for consistency, but keep the old version
as deprecated for some time. We don't have to get rid of it soon. This
could for example be scheduled for guile 2.0. Then, you have both
consistency and backwards
P Pareit [EMAIL PROTECTED] writes:
In the info file at node Symbol Props:
- Scheme Procedure: set-symbol-property sym prop val
should be:
- Scheme Procedure: set-symbol-property! sym prop val
Fixed. Thanks!
--
GPG: D5D4E405 - 2F9B BCCC 8527 692A 04E3 331E FAF8 226A D5D4 E405
Eric Hanchrow [EMAIL PROTECTED] writes:
Node `Further Reading' says that Teach Yourself Scheme in Fixnum
Days is at
http://www.cs.rice.edu/~dorai/t-y-scheme/t-y-scheme.html,
but in fact it appears to be at
http://www.ccs.neu.edu/home/dorai/t-y-scheme/t-y-scheme.html
Greg Troxel [EMAIL PROTECTED] writes:
There are two apparently spurious CVS directories in the 1.6.0 tarball.
Thanks, I have added code that removes them during make dist.
--
GPG: D5D4E405 - 2F9B BCCC 8527 692A 04E3 331E FAF8 226A D5D4 E405
___
P Pareit [EMAIL PROTECTED] writes:
In the info file for guile at node The Basic Guile Package the
version info is still written for version 1.5.7. At the same page
the sequence of command to install guile is:
Thanks, I fixed this.
--
GPG: D5D4E405 - 2F9B BCCC 8527 692A 04E3 331E FAF8 226A
P Pareit [EMAIL PROTECTED] writes:
In the info node Creating a Procedure there is a typo:
Fixed, thanks!
--
GPG: D5D4E405 - 2F9B BCCC 8527 692A 04E3 331E FAF8 226A D5D4 E405
___
Bug-guile mailing list
[EMAIL PROTECTED]
Rolf-Alois Walter [EMAIL PROTECTED] writes:
When I tried to build Guile 1.6 on AIX 4.3 there occurred
a 'stack overflow':
That seems strange. Can you try to add
(debug-set! stack 0)
to the file guile-1.6.0/scripts/snarf-check-and-output-texi, after the
'define-module' statement? That
Steven G. Johnson [EMAIL PROTECTED] writes:
ftp://alpha.gnu.org/gnu/guile/guile-1.5.6.tar.gz
We don't currently have access to alpha.gnu.org so we can't rebuild it
after it after it has been cracked.
ftp://krusty.e-technik.uni-dortmund.de/pub/guile/snapshots/
Oops, I could've sworn that I
Marius Vollmer [EMAIL PROTECTED] writes:
SRFI-1 list-copy can copy dotted lists. Maybe we can just use it.
But ours can't since it is the core list-copy! Bugger!
___
Bug-guile mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug
Dirk Herrmann [EMAIL PROTECTED] writes:
I assume that the problem is also relevant for the newer branches.
There, we could think of providing a public improper-list-copy in list.c
instead of providing it privately within optargs.scm. Do we want that?
Yes, that looks like the better option
Thien-Thi Nguyen [EMAIL PROTECTED] writes:
Will MacOS X be officially supported in the future?
personally, i don't see the value of official support at this time in
theory or in practice (guile maintainership is pretty losing, IMHO). by
the same token (also personally), i'd like to see
[EMAIL PROTECTED] (Paul Jarc) writes:
I have guile 1.4.1 installed in an unusual place, so PREFIX/lib
isn't in the usual search path for shared libraries. It seems guile
should always search PREFIX/lib, preferably before the systemwide
directories and after those listed in $LD_LIBRARY_PATH.
[EMAIL PROTECTED] (Paul Jarc) writes:
I'm building guile 1.5.6, and I get this error from make check:
Thanks for the report. This has been fixed already in our sources.
___
Bug-guile mailing list
[EMAIL PROTECTED]
[EMAIL PROTECTED] (Thomas Bushnell, BSG) writes:
This bug exists in Guile 1.4.
Thanks, I have recorded this as bug 'eager-funpos-checking'.
___
Bug-guile mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-guile
Richard Y. Kim [EMAIL PROTECTED] writes:
As far as I can tell from reading guile documentation for version
1.5.4., scm_make_gsubr is deprecated. scm_c_define_gsubr seems to be
the new name. However, the guile manual still refers to the old name.
Here is a patch that updates the document to
Neil Jerram [EMAIL PROTECTED] writes:
I copied various followups to [EMAIL PROTECTED], but no firm
conclusion was reached on any (except 6). Can you see them there?
If not, I could send them to you privately.
I see them, thanks! I get back to this case by case.
1 - 100 of 178 matches
Mail list logo
