Re: entering and leaving guile mode, and GC stack protection
Hello, Andy Wingo writes: > On Thu 06 Aug 2009 18:30, Ken Raeburn writes: > >> On Aug 5, 2009, at 10:06, I wrote: >>> (3) My four-year-old comments on scm_enter/leave_guile, recorded in >>> threads.c around line 300, still stand Those functions really >>> ought to go away. At least they're confined to one file, now. Some >>> of it looks a little messy, but I can probably get rid of some of the >>> uses >> >> I've made a bit of progress on this. > > The patches look good to me; my only wonder is what relation they have > to the BDW-GC branch Ludovic was working on. If BDW will land before > 2.0, then perhaps all this mess can go away (wishful thinking); > otherwise we should apply it now (after the release). Ludovic? :) Exactly. I've been meaning to reply to this thread because of this. These functions don't do much in the BDW-GC branch: http://git.savannah.gnu.org/cgit/guile.git/tree/libguile/threads.c?h=boehm-demers-weiser-gc#n379 Likewise, `scm_without_guile ()' does a `GC_do_blocking ()', but in many cases `scm_without_guile ()' is not needed because BDW-GC doesn't rely on cooperation from all threads to work. And yes, I do hope to have it part of 2.0, but I haven't taken the time to update it lately. Thanks, Ludo'.
Re: Porting GNU Projects - Guile
Neil Jerram wrote: > > bornlibra23 writes: > >> Thanks Mike for the heads up but the problem I think is with the source >> code >> itself. I get the same error on linux though it doesnt die there. I >> preprocessed the code & changed the line like so : >>>From (ch) == ' ' | (ch) == '\t') to (ch) == ' ' || (ch) == '\t') >> (note the or operator) & the problem went away but then I had the >> mentioned >> problem. I will build it again & get back to you. My build log seems to >> be >> dated. > > FWIW this is fixed in Guile's master branch: > > #ifdef HAVE_ISBLANK > # define CSET_BLANK_PRED(c) (isblank (c)) > #else > # define CSET_BLANK_PRED(c) \ >(((c) == ' ') || ((c) == '\t')) > #endif > I guess it was missed for a long time because it is rare to have an OS > that doesn't provide isblank(). > Regards, > Neil > Hello Neil I just patched this in the code butu it still fails. I have yet to try the 1.8.7 version. Thanks bornlibra23 -- View this message in context: http://www.nabble.com/Porting-GNU-Projects---Guile-tp24721426p24969386.html Sent from the Gnu - Guile - Dev mailing list archive at Nabble.com.
Re: Removing memoizers from the 1.8 public API?
l...@gnu.org (Ludovic Courtès) writes: > Hello! > > I'm tempted to apply these two patches to 1.8: > > > http://git.savannah.gnu.org/cgit/guile.git/commit/?id=4d0949ea45c46dd13e767a8a3342d02caef1b483 > > http://git.savannah.gnu.org/cgit/guile.git/commit/?id=b3ce13b667634be30ab2d74b8ccb1de190d7aeeb > > It cleans the name space and potentially makes memoization slightly > faster (because it removes the indirection through the PLT). > > Opinions? Personally I wouldn't apply either of these for 1.8, as the case for them seems weak in comparison with the risk. If the temptation is strong, though, I'd add that - 4d0949 looks safe. It's arguably just a bug that these functions were ever exposed, and I don't think that anyone will actually have found them useful outside libguile. - b3ce13 looks like a non-starter to me. By putting those function in SCM_ENABLE_DEPRECATED we've explicitly acknowledged IMO that there are possible reasonable uses for them; so removing them in the middle of a stable series would be very odd. Regards, Neil
Re: Using a linker version script
l...@gnu.org (Ludovic Courtès) writes:
> It also makes it possible to provide two versions of the same symbol,
> e.g.:
>
> SCM scm_from_string (const char *)--> GUILE_2.0
> SCM scm_from_string (const char *, scm_t_handler) --> GUILE_2.1
>
> Applications that were compiled against libguile 2.0 will keep using the
> GUILE_2.0 version of the function, while those compiled against 2.1 will
> use the GUILE_2.1 version.
>
> Technically, defining multiple versions of a given symbol is achieved
> using the `.symver' GNU as directive:
>
>__asm__ (".symver scm_from_string_v2_0,scm_from_str...@guile_2.0");
>__asm__ (".symver scm_from_string,scm_from_str...@guile_2.1");
That sounds very cool. But given that we try to consider non-GNU
platforms too, will it really give us more options than we have at
present?
Regards,
Neil
Re: Removing memoizers from the 1.8 public API?
Hi Neil, Neil Jerram writes: > If the temptation is strong, though, I'd add that > > - 4d0949 looks safe. It's arguably just a bug that these functions > were ever exposed, and I don't think that anyone will actually have > found them useful outside libguile. Agreed. I'll eventually commit this one if nobody objects. > - b3ce13 looks like a non-starter to me. By putting those function in > SCM_ENABLE_DEPRECATED we've explicitly acknowledged IMO that there > are possible reasonable uses for them; so removing them in the > middle of a stable series would be very odd. Agreed, too (that was the reason for making it a separate patch). Nevertheless, I think the rationale for having the non-deprecated memoizers private holds as well for the deprecated memoizers. Thanks, Ludo'.
Re: Using a linker version script
Neil Jerram writes:
> l...@gnu.org (Ludovic Courtès) writes:
>
>> It also makes it possible to provide two versions of the same symbol,
>> e.g.:
>>
>> SCM scm_from_string (const char *)--> GUILE_2.0
>> SCM scm_from_string (const char *, scm_t_handler) --> GUILE_2.1
>>
>> Applications that were compiled against libguile 2.0 will keep using the
>> GUILE_2.0 version of the function, while those compiled against 2.1 will
>> use the GUILE_2.1 version.
>>
>> Technically, defining multiple versions of a given symbol is achieved
>> using the `.symver' GNU as directive:
>>
>>__asm__ (".symver scm_from_string_v2_0,scm_from_str...@guile_2.0");
>>__asm__ (".symver scm_from_string,scm_from_str...@guile_2.1");
>
> That sounds very cool. But given that we try to consider non-GNU
> platforms too, will it really give us more options than we have at
> present?
It will give us more options on GNU (and possibly Solaris) but not on
the other platforms. So that won't affect our policy of not breaking
the ABI during a stable series.
On GNU and Solaris, we may be able to reduce the number of applications
that have to be recompiled when a new major version comes out by:
- having per-symbol binary compatibility info, as opposed to Libtool's
coarse-grain `-version-info'.
- providing older versions of symbols that have changed.
I see it essentially as an additional "safety net", and something that
GNU/* distribution maintainers will appreciate.
Section 3.3 of [0] contains a discussion of this.
Thanks,
Ludo'.
[0] http://people.redhat.com/drepper/dsohowto.pdf
Re: Problems with and libguile/__scm.h on HP-UX/IA64
Neil Jerram writes:
> Albert Chin writes:
>> But, on HP-UX/IA64, has a conflicting declaration of jmp_buf.
>
> Thanks for the report. This is also a Debian bug [1], and their patch
> is [2].
>
> [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=506684
> [2]
> http://patch-tracking.debian.net/patch/series/view/guile-1.8/1.8.5+1-4.1/dont-redefine-jmp_buf.diff
Here's my proposed fix for this, for 1.8 and master. Please let me
know of any comments.
Neil
>From 26adbdf1ea98e20124f44960a8e0dfa302306991 Mon Sep 17 00:00:00 2001
From: Neil Jerram
Date: Wed, 5 Aug 2009 16:13:28 +0100
Subject: [PATCH] Avoid clash with system setjmp/longjmp on IA64
Problem was that if an application includes both libguile.h and the
system's setjmp.h, and is compiled on IA64, it gets compile errors
because of jmp_buf, setjmp and longjmp being multiply defined.
* libguile/__scm.h (__ia64__): Define scm_i_jmp_buf, SCM_I_SETJMP and
SCM_I_LONGJMP instead of jmp_buf, setjmp and longjmp.
(all other platforms): Map scm_i_jmp_buf, SCM_I_SETJMP and
SCM_I_LONGJMP to jmp_buf, setjmp and longjmp.
* libguile/continuations.c (scm_make_continuation): Use `SCM_I_SETJMP'
instead of `setjmp'.
(copy_stack_and_call): Use `SCM_I_LONJMP' instead of `longjmp'.
(scm_ia64_longjmp): Use type `scm_i_jmp_buf' instead of `jmp_buf'.
* libguile/continuations.h (scm_t_contregs): Use type `scm_i_jmp_buf'
instead of `jmp_buf'.
* libguile/threads.c (suspend): Use `SCM_I_SETJMP' instead of
`setjmp'.
* libguile/threads.h (scm_i_thread): Use type `scm_i_jmp_buf' instead
of `jmp_buf'.
* libguile/throw.c (JBJMPBUF, make_jmpbuf, jmp_buf_and_retval): Use
type `scm_i_jmp_buf' instead of `jmp_buf'.
(scm_c_catch): Use `SCM_I_SETJMP' instead of `setjmp'.
(scm_ithrow): Use `SCM_I_LONGJMP' instead of `longjmp'.
---
libguile/__scm.h | 17 +
libguile/continuations.c |6 +++---
libguile/continuations.h |2 +-
libguile/threads.c |6 +++---
libguile/threads.h |2 +-
libguile/throw.c | 10 +-
6 files changed, 26 insertions(+), 17 deletions(-)
diff --git a/libguile/__scm.h b/libguile/__scm.h
index 29b371d..6782654 100644
--- a/libguile/__scm.h
+++ b/libguile/__scm.h
@@ -423,19 +423,28 @@
typedef struct {
ucontext_t ctx;
int fresh;
-} jmp_buf;
-# define setjmp(JB)\
+} scm_i_jmp_buf;
+# define SCM_I_SETJMP(JB) \
( (JB).fresh = 1,\
getcontext (&((JB).ctx)), \
((JB).fresh ? ((JB).fresh = 0, 0) : 1) )
-# define longjmp(JB,VAL) scm_ia64_longjmp (&(JB), VAL)
-void scm_ia64_longjmp (jmp_buf *, int);
+# define SCM_I_LONGJMP(JB,VAL) scm_ia64_longjmp (&(JB), VAL)
+void scm_ia64_longjmp (scm_i_jmp_buf *, int);
# else /* ndef __ia64__ */
# include
# endif /* ndef __ia64__ */
# endif/* ndef _CRAY1 */
#endif/* ndef vms */
+/* For any platform where SCM_I_SETJMP hasn't been defined in some
+ special way above, map SCM_I_SETJMP, SCM_I_LONGJMP and
+ scm_i_jmp_buf to setjmp, longjmp and jmp_buf. */
+#ifndef SCM_I_SETJMP
+#define scm_i_jmp_buf jmp_buf
+#define SCM_I_SETJMP setjmp
+#define SCM_I_LONGJMP longjmp
+#endif
+
/* James Clark came up with this neat one instruction fix for
* continuations on the SPARC. It flushes the register windows so
* that all the state of the process is contained in the stack.
diff --git a/libguile/continuations.c b/libguile/continuations.c
index f856476..347bd80 100644
--- a/libguile/continuations.c
+++ b/libguile/continuations.c
@@ -131,7 +131,7 @@ scm_make_continuation (int *first)
SCM_NEWSMOB (cont, scm_tc16_continuation, continuation);
- *first = !setjmp (continuation->jmpbuf);
+ *first = !SCM_I_SETJMP (continuation->jmpbuf);
if (*first)
{
#ifdef __ia64__
@@ -229,12 +229,12 @@ copy_stack_and_call (scm_t_contregs *continuation, SCM val,
scm_i_set_last_debug_frame (continuation->dframe);
continuation->throw_value = val;
- longjmp (continuation->jmpbuf, 1);
+ SCM_I_LONGJMP (continuation->jmpbuf, 1);
}
#ifdef __ia64__
void
-scm_ia64_longjmp (jmp_buf *JB, int VAL)
+scm_ia64_longjmp (scm_i_jmp_buf *JB, int VAL)
{
scm_i_thread *t = SCM_I_CURRENT_THREAD;
diff --git a/libguile/continuations.h b/libguile/continuations.h
index 08eec8f..82cf178 100644
--- a/libguile/continuations.h
+++ b/libguile/continuations.h
@@ -44,7 +44,7 @@ SCM_API scm_t_bits scm_tc16_continuation;
typedef struct
{
SCM throw_value;
- jmp_buf jmpbuf;
+ scm_i_jmp_buf jmpbuf;
SCM dynenv;
#ifdef __ia64__
void *backing_store;
diff --git a/libguile/threads.c b/libguile/threads.c
index 9589336..1721e0b 100644
--- a/libguile/threads.c
+++ b/libguile/threads.c
@@ -312,7 +312,7 @@ unblock_from_queue (SCM queue)
var 't'
// save registers.
SCM_FLUSH_REGISTER_WINDOWS; // sparc only
- setjmp (t->regs);// here's most of the magic
+ SCM_I_SETJMP (t->re
Re: trace examples broken in master
Andy Wingo writes:
> On Tue 14 Jul 2009 10:07, Neil Jerram writes:
>
>> but the right thing to do is to fix the scm_set_source_properties_x ()
>> code.
>
> Yes, this would be better.
Here are my proposed changes for that, for master. Please let me know
of any comments.
Unfortunately too late now for 1.9.2, but I'll commit (subject to
comments) after that release.
Neil
>From 4448d1b02ab6724d05a95ba3e15ca662fce43d50 Mon Sep 17 00:00:00 2001
From: Neil Jerram
Date: Tue, 4 Aug 2009 15:40:06 +0100
Subject: [PATCH] Minor improvements to doc on source properties
In particular avoid any suggestion that the API uses the
property list format, i.e. (key1 value1 key2 value2 ...),
as opposed to the alist format that it actually does use.
---
doc/ref/api-debug.texi | 18 +-
1 files changed, 9 insertions(+), 9 deletions(-)
diff --git a/doc/ref/api-debug.texi b/doc/ref/api-debug.texi
index 7886366..dbf3c00 100644
--- a/doc/ref/api-debug.texi
+++ b/doc/ref/api-debug.texi
@@ -283,9 +283,9 @@ runs a script non-interactively.
The following procedures can be used to access and set the source
properties of read expressions.
-...@deffn {Scheme Procedure} set-source-properties! obj plist
-...@deffnx {C Function} scm_set_source_properties_x (obj, plist)
-Install the association list @var{plist} as the source property
+...@deffn {Scheme Procedure} set-source-properties! obj alist
+...@deffnx {C Function} scm_set_source_properties_x (obj, alist)
+Install the association list @var{alist} as the source property
list for @var{obj}.
@end deffn
@@ -302,12 +302,12 @@ Return the source property association list of @var{obj}.
@deffn {Scheme Procedure} source-property obj key
@deffnx {C Function} scm_source_property (obj, key)
-Return the source property specified by @var{key} from
-...@var{obj}'s source property list.
+Return the property specified by @var{key} from @var{obj}'s source
+properties.
@end deffn
In practice there are only two ways that you should use the ability to
-set an expression's source breakpoints.
+set an expression's source properties.
@itemize
@item
@@ -330,9 +330,9 @@ involved in a backtrace or error report.
If you are looking for a way to attach arbitrary information to an
expression other than these properties, you should use
-...@code{make-object-property} instead (@pxref{Object Properties}), because
-that will avoid bloating the source property hash table, which is really
-only intended for the specific purposes described in this section.
+...@code{make-object-property} instead (@pxref{Object Properties}). That
+will avoid bloating the source property hash table, which is really
+only intended for the debugging purposes just described.
@node Decoding Memoized Source Expressions
--
1.5.6.5
>From 2e2fdcdef595bb7c4969783390399ae3ddbe6bab Mon Sep 17 00:00:00 2001
From: Neil Jerram
Date: Tue, 4 Aug 2009 18:54:50 +0100
Subject: [PATCH] In srcprop.c change all occurrences of "plist" to "alist"
As with the previous commit, this is to avoid any suggestion that
the source properties API uses the property list format, i.e.
(key1 value1 key2 value2 ...).
Also remove scm_srcprops_to_plist () from the API. It doesn't have any
external usefulness and has never documented.
---
libguile/srcprop.c | 76 ++-
libguile/srcprop.h |2 -
2 files changed, 39 insertions(+), 39 deletions(-)
diff --git a/libguile/srcprop.c b/libguile/srcprop.c
index efa0b7f..a43f4ce 100644
--- a/libguile/srcprop.c
+++ b/libguile/srcprop.c
@@ -68,7 +68,7 @@ SCM_GLOBAL_SYMBOL (scm_sym_breakpoint, "breakpoint");
* car = tag
* cbr = pos
* ccr = copy
- * cdr = plist
+ * cdr = alist
*/
#define SRCPROPSP(p) (SCM_SMOB_PREDICATE (scm_tc16_srcprops, (p)))
@@ -77,7 +77,7 @@ SCM_GLOBAL_SYMBOL (scm_sym_breakpoint, "breakpoint");
#define SRCPROPLINE(p) (SRCPROPPOS(p) >> 12)
#define SRCPROPCOL(p) (SRCPROPPOS(p) & 0x0fffL)
#define SRCPROPCOPY(p) (SCM_CELL_OBJECT(p,2))
-#define SRCPROPPLIST(p) (SCM_CELL_OBJECT_3(p))
+#define SRCPROPALIST(p) (SCM_CELL_OBJECT_3(p))
#define SETSRCPROPBRK(p) \
(SCM_SET_SMOB_FLAGS ((p), \
SCM_SMOB_FLAGS (p) | SCM_SOURCE_PROPERTY_FLAG_BREAK))
@@ -89,9 +89,11 @@ SCM_GLOBAL_SYMBOL (scm_sym_breakpoint, "breakpoint");
#define SETSRCPROPLINE(p, l) SETSRCPROPPOS (p, l, SRCPROPCOL (p))
#define SETSRCPROPCOL(p, c) SETSRCPROPPOS (p, SRCPROPLINE (p), c)
#define SETSRCPROPCOPY(p, c) (SCM_SET_CELL_WORD(p, 2, c))
-#define SETSRCPROPPLIST(p, l) (SCM_SET_CELL_WORD(p, 3, l))
+#define SETSRCPROPALIST(p, l) (SCM_SET_CELL_WORD(p, 3, l))
+static SCM scm_srcprops_to_alist (SCM obj);
+
scm_t_bits scm_tc16_srcprops;
@@ -99,7 +101,7 @@ static SCM
srcprops_mark (SCM obj)
{
scm_gc_mark (SRCPROPCOPY (obj));
- return SRCPROPPLIST (obj);
+ return SRCPROPALIST (obj);
}
static int
@@ -108,7 +110,7 @@ srcprops_print (SCM obj, SCM port, scm_print_state *pstate)
int writingp = SCM_WRITINGP
Review request for wip-manual branch
The wip-manual branch contains various bits of work on the manual. It's largely driven by the plan to publish the manual as a book, later this year, and the biggest change so far is the merging of the GOOPS manual. Apart from that I'm not following any kind of systematic plan, just reviewing and working on areas as I notice them. One general thing is that I am consciously _not_ trying to make the manual more consistent in style - i.e. closer to my own style, or to a more `neutral' style, or whatever; I actually think it's quite fun that the style and tone change a bit from place to place. So my overall guideline is only to change something when there is a clear benefit from doing so, not just because I'd write it a bit differently. So, please let me know of any comments. Subject to those, I'll merge what's there already after the 1.9.2 release, and then keep working on this as time permits. Regards, Neil
Re: trace examples broken in master
Hey Neil, Thanks for addressing this. Looking forward to trying it out -- it'll be a great help. Regards, Julian On Fri, Aug 14, 2009 at 1:00 PM, Neil Jerram wrote: > Andy Wingo writes: > >> On Tue 14 Jul 2009 10:07, Neil Jerram writes: >> >>> but the right thing to do is to fix the scm_set_source_properties_x () >>> code. >> >> Yes, this would be better. > > Here are my proposed changes for that, for master. Please let me know > of any comments. > > Unfortunately too late now for 1.9.2, but I'll commit (subject to > comments) after that release. > > Neil > >
Re: Problems with and libguile/__scm.h on HP-UX/IA64
Neil Jerram writes: > Neil Jerram writes: > >> Albert Chin writes: > >>> But, on HP-UX/IA64, has a conflicting declaration of jmp_buf. >> >> Thanks for the report. This is also a Debian bug [1], and their patch >> is [2]. >> >> [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=506684 >> [2] >> http://patch-tracking.debian.net/patch/series/view/guile-1.8/1.8.5+1-4.1/dont-redefine-jmp_buf.diff > > Here's my proposed fix for this, for 1.8 and master. Please let me > know of any comments. Looks good to me (you can still commit it for 1.9.2 if you want). Thanks! Ludo'.
guile.m4
Hi- guile.m4's serial number should be bumped for releases if it has changed. Thanks, Mike
Re: Using a linker version script
l...@gnu.org (Ludovic Courtès) writes: > It will give us more options on GNU (and possibly Solaris) but not on > the other platforms. So that won't affect our policy of not breaking > the ABI during a stable series. > > On GNU and Solaris, we may be able to reduce the number of applications > that have to be recompiled when a new major version comes out by: > > - having per-symbol binary compatibility info, as opposed to Libtool's > coarse-grain `-version-info'. > > - providing older versions of symbols that have changed. > > I see it essentially as an additional "safety net", and something that > GNU/* distribution maintainers will appreciate. OK, many thanks for explaining all that. I'm happy that this is useful now. > Section 3.3 of [0] contains a discussion of this. That paper is so verbose that I find it difficult to read! But thanks for the reference anyway; I know where to go now if I want to know every detail of dynamic linking. Regards, Neil
Re: Problems with and libguile/__scm.h on HP-UX/IA64
l...@gnu.org (Ludovic Courtès) writes: > Looks good to me (you can still commit it for 1.9.2 if you want). Thanks, but I think it's OK to wait. Even if we lose out on some testing, and eventually release 2.0 with a bug, it's still only a bug fix needed that we can add later. Neil
Re: Porting GNU Projects - Guile
bornlibra23 writes: > I just patched this in the code butu it still fails. I have yet to try the > 1.8.7 version. In the same way, or differently? Please provide the relevant part of the new build output. Regards, Neil
