using libltdl from 2.2.x requires libtool 2.2.x to link against
Per Ralf Wildenhues from libtool team. It seems that libtool generated from autogen.sh is incorrect for both 1.8.4 and 1.9.0 if using 2.2.x libltdl. The result will be a linking error "symbol _lt__PROGRAM__LTX_preloaded_symbols not found." Even copy 2.2.x libtool, it is still wrong, since the _PROGRAM_ should be "guile" steve
Re: git clone guile 1.9 build problem on MacOS X 10.5.2
looks like the problems are in the configure file, where I found the following: PACKAGE_VERSION='-n 1.9.0 ' PACKAGE_STRING='guile-readline -n 1.9.0 ' If I changed them by hand, the problem went away. steve
Re: git clone guile 1.9 build problem on MacOS X 10.5.2
silly me, here we go:
configure:2881: gccconftest.c >&5
conftest.c:5: error: missing terminating " character
conftest.c:7: error: missing terminating " character
configure:2884: $? = 1
configure:2922: result:
configure: failed program was:
| /* confdefs.h. */
| #define PACKAGE_NAME "guile-readline"
| #define PACKAGE_TARNAME "guile-readline"
| #define PACKAGE_VERSION "-n 1.9.0
| "
| #define PACKAGE_STRING "guile-readline -n 1.9.0
| "
| #define PACKAGE_BUGREPORT ""
| /* end confdefs.h. */
|
| int
| main ()
| {
|
| ;
| return 0;
| }
configure:2929: error: C compiler cannot create executables
See `config.log' for more details.
The problem is the newline before closing quote.
steve
Re: fixes to goops + light structs + 'u' slots
2008/4/14, Andy Wingo <[EMAIL PROTECTED]>: > Is this designed to work? It seems that all is still not right, > @slot-ref (only used in accessors, not in slot-ref) accesses the slot as > a SCM Right, the special form is @slot-ref, not @assert-bound-ref as I stated previously.
Re: fixes to goops + light structs + 'u' slots
2008/4/14, Andy Wingo <[EMAIL PROTECTED]>:
I> have shied away from GOOPS internals in the past, but every time I have
> a brush with them I learn something interesting.
You're very kind. It's in large parts not easily readable code.
> What is your perspective regarding ? I wrote a bit about
> what I did recently in Guile-Gnome here:
>
>http://wingolog.org/archives/2008/04/11/allocate-memory-part-of-n
Sorry for not having time right now to look into this.
> I define a class with a foreign slot like this:
>
> guile> (use-modules (oop goops))
> guile> (define-class () (bar #:class ))
> guile> (define x (make ))
> guile> (slot-set! x 'bar 45)
> guile> (slot-set! x 'bar 45000)
>
> Backtrace:
> In current input:
>6: 0* [slot-set! #< b7dbaa60> bar {45000}]
>
> :6:1: In procedure slot-set! in expression (slot-set! x (quote
> bar) ...):
> :6:1: Value out of range 0 to 4294967295: 45000
> ABORT: (out-of-range)
>
> Is this designed to work? It seems that all is still not right,
> @slot-ref (only used in accessors, not in slot-ref) accesses the slot as
> a SCM regardless of whether is is a 'u' slot or a 'p' slot. I suppose
> that part of the dispatch/compilation needs to be made more
> sophisticated.
Right. That part of the implementation is not finished. The
compilation of accessors is in goops.scm.
Another part, which is also not finished (or wasn't when I left) is
parts of the metaobject protocol. I had some specific ideas how the
MOP part should be completed, which I hope I left somewhere in the
workbook repository.
> > Also, SMOB-based accessors would
> > be more heavyweight with regard to class creation and memory
> > consumption than the current solution.
>
> Regarding memory consumption. Currently, structs are double-cells: one
> word for the vtable, one for the data, one empty, and one for the
> "STRUCT_GC_CHAIN", used (please correct me) during GC to ensure that
> structs are freed before their vtables.
>
> This seems to be to be a waste of memory in instances, in that they
> occupy 4 words when they only need 2. Is it not possible to avoid this?
> I have puzzled over this for a number of hours, but have not really come
> up with anything that seems workable, given our lazy incremental
> sweeping. I suppose another bitvector for structs in the cards would
> work; you could run through it at the end of marking, and mark all
> structs' vtables.
I wash my hands. :-) When I left, structs where two words. Not that
I don't appreciate the new garbage collector.
> > In any case, *please* always benchmark changes like this against previous
> code.
>
> Will work on some benchmarking, I am very interested to see how some of
> the method dispatch and compilation code works.
Thanks!
> ps. I'm happy to see you around!
Ahh, I'm sorry that I'm actually only a ghost. Have to focus on other
stuff right now, but I'm still a Guile user!
Re: fixes to goops + light structs + 'u' slots
Hi Mikael!
On Sun 13 Apr 2008 21:09, "Mikael Djurfeldt" <[EMAIL PROTECTED]> writes:
>> > I have heard that in a well-done CLOS implementation, accessors are are
>> > generally faster than slot-ref
>>
> Note that the current implementation *does*
> compile in the slot position into this form and indeed *has* the
> property which Andy mentions above.
I did not realize this. Thanks for mentioning it. I have shied away from
GOOPS internals in the past, but every time I have a brush with them I
learn something interesting.
What is your perspective regarding ? I wrote a bit about
what I did recently in Guile-Gnome here:
http://wingolog.org/archives/2008/04/11/allocate-memory-part-of-n
I define a class with a foreign slot like this:
guile> (use-modules (oop goops))
guile> (define-class () (bar #:class ))
guile> (define x (make ))
guile> (slot-set! x 'bar 45)
guile> (slot-set! x 'bar 45000)
Backtrace:
In current input:
6: 0* [slot-set! #< b7dbaa60> bar {45000}]
:6:1: In procedure slot-set! in expression (slot-set! x (quote
bar) ...):
:6:1: Value out of range 0 to 4294967295: 45000
ABORT: (out-of-range)
Is this designed to work? It seems that all is still not right,
@slot-ref (only used in accessors, not in slot-ref) accesses the slot as
a SCM regardless of whether is is a 'u' slot or a 'p' slot. I suppose
that part of the dispatch/compilation needs to be made more
sophisticated.
> Also, SMOB-based accessors would
> be more heavyweight with regard to class creation and memory
> consumption than the current solution.
Regarding memory consumption. Currently, structs are double-cells: one
word for the vtable, one for the data, one empty, and one for the
"STRUCT_GC_CHAIN", used (please correct me) during GC to ensure that
structs are freed before their vtables.
This seems to be to be a waste of memory in instances, in that they
occupy 4 words when they only need 2. Is it not possible to avoid this?
I have puzzled over this for a number of hours, but have not really come
up with anything that seems workable, given our lazy incremental
sweeping. I suppose another bitvector for structs in the cards would
work; you could run through it at the end of marking, and mark all
structs' vtables.
> In any case, *please* always benchmark changes like this against previous
> code.
Will work on some benchmarking, I am very interested to see how some of
the method dispatch and compilation code works.
Andy
ps. I'm happy to see you around!
--
http://wingolog.org/
Inlining `scm_getc ()' and friends
Hello,
Small I/O functions like `scm_getc ()' deserve to be inlined. For
instance, Andy measured it some time ago:
http://thread.gmane.org/gmane.lisp.guile.devel/6639
I'm planning to apply the attached patch to both `master' and 1.8.
To get an idea of its benefit, I run the attached "benchmark" (inspired
from that in Guile-Reader) that does a lot of `read'. On my 1.2 GHz
Intel Centrino, the inlining yields a 15% run-time improvement for that
test.
OK to apply?
Thanks,
Ludovic.
>From 4eeedb81429859b683277eee3af38532ee02733f Mon Sep 17 00:00:00 2001
From: =?utf-8?q?Ludovic=20Court=C3=A8s?= <[EMAIL PROTECTED]>
Date: Mon, 14 Apr 2008 18:09:49 +0200
Subject: [PATCH] Inline `scm_getc', `scm_putc' and `scm_puts'.
---
libguile/inline.h | 86 +---
libguile/ports.c | 60 +
libguile/ports.h |5 +--
3 files changed, 83 insertions(+), 68 deletions(-)
diff --git a/libguile/inline.h b/libguile/inline.h
index 8a6635e..8fa9a8c 100644
--- a/libguile/inline.h
+++ b/libguile/inline.h
@@ -25,17 +25,17 @@
"inline.c".
*/
-#include "libguile/__scm.h"
-
-#if (SCM_DEBUG_CELL_ACCESSES == 1)
#include
-#endif
+#include
+
+#include "libguile/__scm.h"
#include "libguile/pairs.h"
#include "libguile/gc.h"
#include "libguile/threads.h"
#include "libguile/unif.h"
-#include "libguile/pairs.h"
+#include "libguile/ports.h"
+#include "libguile/error.h"
#ifndef SCM_INLINE_C_INCLUDING_INLINE_H
@@ -85,6 +85,10 @@ SCM_API void scm_array_handle_set (scm_t_array_handle *h, ssize_t pos, SCM val);
SCM_API int scm_is_pair (SCM x);
+SCM_API int scm_getc (SCM port);
+SCM_API void scm_putc (char c, SCM port);
+SCM_API void scm_puts (const char *str_data, SCM port);
+
#endif
@@ -285,5 +289,77 @@ scm_is_pair (SCM x)
return SCM_I_CONSP (x);
}
+
+/* Port I/O. */
+
+#ifndef SCM_INLINE_C_INCLUDING_INLINE_H
+SCM_C_EXTERN_INLINE
+#endif
+int
+scm_getc (SCM port)
+{
+ int c;
+ scm_t_port *pt = SCM_PTAB_ENTRY (port);
+
+ if (pt->rw_active == SCM_PORT_WRITE)
+/* may be marginally faster than calling scm_flush. */
+scm_ptobs[SCM_PTOBNUM (port)].flush (port);
+
+ if (pt->rw_random)
+pt->rw_active = SCM_PORT_READ;
+
+ if (pt->read_pos >= pt->read_end)
+{
+ if (scm_fill_input (port) == EOF)
+ return EOF;
+}
+
+ c = *(pt->read_pos++);
+
+ switch (c)
+{
+ case '\a':
+break;
+ case '\b':
+SCM_DECCOL (port);
+break;
+ case '\n':
+SCM_INCLINE (port);
+break;
+ case '\r':
+SCM_ZEROCOL (port);
+break;
+ case '\t':
+SCM_TABCOL (port);
+break;
+ default:
+SCM_INCCOL (port);
+break;
+}
+
+ return c;
+}
+
+#ifndef SCM_INLINE_C_INCLUDING_INLINE_H
+SCM_C_EXTERN_INLINE
+#endif
+void
+scm_putc (char c, SCM port)
+{
+ SCM_ASSERT_TYPE (SCM_OPOUTPORTP (port), port, 0, NULL, "output port");
+ scm_lfwrite (&c, 1, port);
+}
+
+#ifndef SCM_INLINE_C_INCLUDING_INLINE_H
+SCM_C_EXTERN_INLINE
+#endif
+void
+scm_puts (const char *s, SCM port)
+{
+ SCM_ASSERT_TYPE (SCM_OPOUTPORTP (port), port, 0, NULL, "output port");
+ scm_lfwrite (s, strlen (s), port);
+}
+
+
#endif
#endif
diff --git a/libguile/ports.c b/libguile/ports.c
index c4ccca3..b25a7d0 100644
--- a/libguile/ports.c
+++ b/libguile/ports.c
@@ -1,4 +1,4 @@
-/* Copyright (C) 1995,1996,1997,1998,1999,2000,2001, 2003, 2004, 2006, 2007 Free Software Foundation, Inc.
+/* Copyright (C) 1995,1996,1997,1998,1999,2000,2001, 2003, 2004, 2006, 2007, 2008 Free Software Foundation, Inc.
*
* This library is free software; you can redistribute it and/or
* modify it under the terms of the GNU Lesser General Public
@@ -960,64 +960,6 @@ scm_fill_input (SCM port)
return scm_ptobs[SCM_PTOBNUM (port)].fill_input (port);
}
-int
-scm_getc (SCM port)
-{
- int c;
- scm_t_port *pt = SCM_PTAB_ENTRY (port);
-
- if (pt->rw_active == SCM_PORT_WRITE)
-/* may be marginally faster than calling scm_flush. */
-scm_ptobs[SCM_PTOBNUM (port)].flush (port);
-
- if (pt->rw_random)
-pt->rw_active = SCM_PORT_READ;
-
- if (pt->read_pos >= pt->read_end)
-{
- if (scm_fill_input (port) == EOF)
- return EOF;
-}
-
- c = *(pt->read_pos++);
-
- switch (c)
-{
- case '\a':
-break;
- case '\b':
-SCM_DECCOL (port);
-break;
- case '\n':
-SCM_INCLINE (port);
-break;
- case '\r':
-SCM_ZEROCOL (port);
-break;
- case '\t':
-SCM_TABCOL (port);
-break;
- default:
-SCM_INCCOL (port);
-break;
-}
-
- return c;
-}
-
-void
-scm_putc (char c, SCM port)
-{
- SCM_ASSERT_TYPE (SCM_OPOUTPORTP (port), port, 0, NULL, "output port");
- scm_lfwrite (&c, 1, port);
-}
-
-void
-scm_puts (const char *s, SCM port)
-{
- SCM_ASSERT_TYPE (SCM_OPOUTPORTP (port), port, 0, NULL, "output port");
- scm_lfwrite (s, strlen (s), port);
-}
/* s
Re: Terrific Dead Lock
Hi, Neil Jerram <[EMAIL PROTECTED]> writes: > Basically yes, but two thoughts: > > - Can I just take a couple more days to review the srcprops changes in > detail? It's important for my debugging work, and I recall having > some concern when Han-Wen implemented this... Looking at the diffs > quickly again now, I can't see any reason for that concern, but I'd > like to be sure. > > - Although I agree in principle that all those macros shouldn't be in > srcprop.h, do we really need to make that change now? I think we can > just apply Han-Wen's changes to the macros in srcprop.h, without > moving them to srcprop.c. Are you OK to apply the patch? Thanks, Ludovic.
Re: git clone guile 1.9 build problem on MacOS X 10.5.2
Hi Steven, By "relevant part of `config.log'", I meant the few lines around "checking for C compiler default output file name..." in `guile-readline/config.log'. It should show the test file that `configure' tried to compile, the command line it used, and the compilation error it got. Thanks, Ludovic.
