[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: api differences between 1.4 and 1.6
From: |
Neil Jerram |
Subject: |
Re: api differences between 1.4 and 1.6 |
Date: |
09 Mar 2002 16:33:12 +0000 |
User-agent: |
Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7 |
>>>>> "Dirk" == Dirk Herrmann <address@hidden> writes:
Dirk> On 8 Mar 2002, Neil Jerram wrote:
>> How about using the SCM_API macro as a way of being more specific
>> about what is in the API? In practice, this would initially mean
>> _removing_ SCM_API from a lot of stuff that has it but shouldn't.
Dirk> There's a problem with this idea: You can't use SCM_API for
Dirk> macros, even if they belong to the API.
Yes, good point. This rather messes up my scm_tc16_keyword example,
as well: scm_tc16_keyword must be exported from the Guile library (or
DLL) even if we decide not to consider it as part of the API;
otherwise the SCM_KEYWORDP macro won't compile.
So we cannot use the same marker to mean both `this is part of the
API' and `export from library/DLL'.
Dirk> The reason is, that SCM_API has been introduced only for the
Dirk> sake of windows DLLs, and with respect to that the macro is
Dirk> quite inaccurately named. My opinion is, that this change
Dirk> was a bad idea from the beginning: There are other
Dirk> alternatives to document the information that is necessary
Dirk> for windows DLLs, which don't have an influence on other
Dirk> code. See the mail to guile-devel titled "Re: proposal:
Dirk> scm_string2str() and scm_symbol2str()" from Ken Raeburn,
Dirk> sent on 30 Nov 2001.
I'll take a look when I'm next online. SCM_API is only in 1.7.x, so
we have plenty of time to reconsider it.
Dirk> However, for guile we have already defined a mechanism to
Dirk> distinguish between definitions that belong to the API and
Dirk> definitions that don't: The prefixes SCM_I_... and
Dirk> scm_i_... indicate internal definitions in header files.
Sorry, I forgot that we had agreed this.
Dirk> We have, up to now, not begun to change all the definitions
Dirk> accordingly. From time to time, some definitions are
Dirk> renamed that way. If we did it consequently (like, in a
Dirk> cleanup session), we would even find that in many of the
Dirk> cases it would be sufficient to remove the definitions from
Dirk> the headers and use static definitions in the corresponsing
Dirk> c files instead. The biggest part of the work is to search
Dirk> through all definitions in the header files and decide,
Dirk> which of the definitions should be part of the API and which
Dirk> shouldn't.
Right. I agree that this is the way to go, and I think we could do
this cleanup even during 1.5/1.6, since the things that will change
are, by definition, internal.
Marius - can you OK this?
The patch below begins the process by getting rid of all the C names
in doc/guile-api.alist (stable branch) that begin with something other
than `coop_', `gdb_', `gh_' or `scm_'. Is it OK to commit it?
Neil
Index: doc/guile-api.alist
===================================================================
RCS file: /cvsroot/guile/guile/guile-core/doc/guile-api.alist,v
retrieving revision 1.1.4.2
diff -u -r1.1.4.2 guile-api.alist
--- doc/guile-api.alist 1 Mar 2002 08:45:05 -0000 1.1.4.2
+++ doc/guile-api.alist 9 Mar 2002 16:32:37 -0000
@@ -1543,7 +1543,6 @@
(zero? "#<primitive-procedure zero?>")
) ;; end of scheme
(C
-(collisionp B)
(coop_abort T)
(coop_condition_variable_destroy T)
(coop_condition_variable_init T)
@@ -1588,7 +1587,6 @@
(gdb_print T)
(gdb_read T)
(gdb_result B)
-(gexceptfds B)
(gh_append T)
(gh_append2 T)
(gh_append3 T)
@@ -1700,13 +1698,6 @@
(gh_vector_ref T)
(gh_vector_set_x T)
(gh_write T)
-(gnfds B)
-(greadfds B)
-(gwritefds B)
-(issued_msgs B)
-(rexceptfds B)
-(rreadfds B)
-(rwritefds B)
(scm_2ulong2big T)
(scm_I_am_dead B)
(scm_abs T)
@@ -3302,6 +3293,6 @@
(scm_yield T)
(scm_your_base D)
(scm_zero_p T)
-(terminating B)
+(scm_i_terminating B)
) ;; end of C
) ;; eof
Index: libguile/deprecation.c
===================================================================
RCS file: /cvsroot/guile/guile/guile-core/libguile/deprecation.c,v
retrieving revision 1.9
diff -u -r1.9 deprecation.c
--- libguile/deprecation.c 28 Jun 2001 01:11:58 -0000 1.9
+++ libguile/deprecation.c 9 Mar 2002 16:32:45 -0000
@@ -58,7 +58,7 @@
/* This is either a boolean (when a summary should be printed) or a
hashtab (when detailed warnings shouold be printed).
*/
-SCM issued_msgs;
+static SCM issued_msgs;
void
scm_c_issue_deprecation_warning (const char *msg)
Index: libguile/fports.c
===================================================================
RCS file: /cvsroot/guile/guile/guile-core/libguile/fports.c,v
retrieving revision 1.100.2.2
diff -u -r1.100.2.2 fports.c
--- libguile/fports.c 26 Aug 2001 21:49:32 -0000 1.100.2.2
+++ libguile/fports.c 9 Mar 2002 16:32:53 -0000
@@ -717,7 +717,7 @@
/* becomes 1 when process is exiting: normal exception handling won't
work by this time. */
-extern int terminating;
+extern int scm_i_terminating;
static void
fport_flush (SCM port)
@@ -749,7 +749,7 @@
}
pt->write_pos = pt->write_buf + remaining;
}
- if (terminating)
+ if (scm_i_terminating)
{
const char *msg = "Error: could not flush file-descriptor ";
char buf[11];
Index: libguile/gc.c
===================================================================
RCS file: /cvsroot/guile/guile/guile-core/libguile/gc.c,v
retrieving revision 1.208.2.6
diff -u -r1.208.2.6 gc.c
--- libguile/gc.c 1 Mar 2002 21:12:47 -0000 1.208.2.6
+++ libguile/gc.c 9 Mar 2002 16:33:18 -0000
@@ -2684,7 +2684,7 @@
scm_gc_unregister_root (p);
}
-int terminating;
+int scm_i_terminating;
/* called on process termination. */
#ifdef HAVE_ATEXIT
@@ -2701,7 +2701,7 @@
#endif
#endif
{
- terminating = 1;
+ scm_i_terminating = 1;
scm_flush_all_ports ();
}
Index: libguile/iselect.c
===================================================================
RCS file: /cvsroot/guile/guile/guile-core/libguile/iselect.c,v
retrieving revision 1.28
diff -u -r1.28 iselect.c
--- libguile/iselect.c 12 Apr 2001 01:40:20 -0000 1.28
+++ libguile/iselect.c 9 Mar 2002 16:33:25 -0000
@@ -100,21 +100,21 @@
/* This flag indicates that several threads are waiting on the same
file descriptor. When this is the case, the common fd sets are
updated in a more inefficient way. */
-int collisionp;
+static int collisionp;
/* These are the common fd sets. When new select calls are made,
those sets are merged into these. */
-int gnfds;
-SELECT_TYPE greadfds;
-SELECT_TYPE gwritefds;
-SELECT_TYPE gexceptfds;
+static int gnfds;
+static SELECT_TYPE greadfds;
+static SELECT_TYPE gwritefds;
+static SELECT_TYPE gexceptfds;
/* These are the result sets. They are used when we call OS select.
We couldn't use the common fd sets above, since that would destroy
them. */
-SELECT_TYPE rreadfds;
-SELECT_TYPE rwritefds;
-SELECT_TYPE rexceptfds;
+static SELECT_TYPE rreadfds;
+static SELECT_TYPE rwritefds;
+static SELECT_TYPE rexceptfds;
/* Constant timeval struct representing a zero timeout which we use
when polling. */
Re: api differences between 1.4 and 1.6, Rob Browning, 2002/03/09
Re: api differences between 1.4 and 1.6, Marius Vollmer, 2002/03/09