Re: [PATCH 1/1] scm_set_source_properties_x: optimize if only name, line, and/or col
On 1/17/21 2:24 PM, Rob Browning wrote:
* libguile/srcprop.c (scm_set_source_properties_x): When only a subset
of file, line, and column fields are specified, store the data as a
srcprops object (tc16_srcprops) rather than an alist.
---
Proposed for at least 3.x. If we want some additional tests, then
one option might be a public or private predicate to test for a
srcprops object (at least for scheme level testing).
Does this mean I can swap out this code for something better now? I've
disliked this code for years.
static SCM
ag_scm_c_eval_string_from_file_line(
char const * pzExpr, char const * pzFile, int line)
{
SCM port = scm_open_input_string(AG_SCM_FROM_STR(pzExpr));
if (OPT_VALUE_TRACE >= TRACE_EVERYTHING)
fprintf(trace_fp, TRACE_EVAL_STRING, pzFile, line, pzExpr);
{
static SCM file = SCM_UNDEFINED;
static char * pzOldFile = NULL;
if ((pzOldFile == NULL) || (strcmp(pzOldFile, pzFile) != 0)) {
if (pzOldFile != NULL)
AGFREE(pzOldFile);
AGDUPSTR(pzOldFile, pzFile, "scheme source");
file = AG_SCM_FROM_STR(pzFile);
}
{
SCM ln = scm_from_int(line);
scm_set_port_filename_x(port, file);
scm_set_port_line_x(port, ln);
scm_set_port_column_x(port, SCM_INUM0);
}
}
{
SCM ans = SCM_UNSPECIFIED;
/* Read expressions from that port; ignore the values. */
for (;;) {
SCM form = scm_read(port);
if (SCM_EOF_OBJECT_P(form))
break;
ans = scm_primitive_eval_x(form);
}
return ans;
}
}
Re: Why did this compile fail?
On Sat, Jul 28, 2018 at 10:42 AM Bruce Korb wrote: > > gcc -DHAVE_CONFIG_H -I. -I../../agen5 -I.. -I.. -I../.. -I../autoopts > -I../../autoopts -pthread -I/u/ROOT/usr/local/include/guile/3.0 > -I/u/ROOT/usr/local/include -g -O2 -Wno-format-contains-nul > -fno-strict-aliasing -MT autogen-ag.o -MD -MP -MF .deps/autogen-ag.Tpo > -c -o autogen-ag.o `test -f 'ag.c' || echo '../../agen5/'`ag.c > In file included from /u/ROOT/usr/local/include/guile/3.0/libguile.h:52:0, > from ../../agen5/autogen.h:60, > from ag.c:9: > /u/ROOT/usr/local/include/guile/3.0/libguile/extensions.h:26:10: fatal > error: libguile/libpath.h: No such file or directory > #include "libguile/libpath.h" > ^~~~ > compilation terminated. > > > The "-I /u/ROOT/usr/local/include/guile/3.0" was used to find > "libguile/extensions.h", so why would > libguile/libpath.h not be found? Why would it not have been found > after a full build and "make install"? So I just copied it out of the guile source directory into the /usr/local one and I can compile. That hackery should not be required. ;(
Why did this compile fail?
gcc -DHAVE_CONFIG_H -I. -I../../agen5 -I.. -I.. -I../.. -I../autoopts -I../../autoopts -pthread -I/u/ROOT/usr/local/include/guile/3.0 -I/u/ROOT/usr/local/include -g -O2 -Wno-format-contains-nul -fno-strict-aliasing -MT autogen-ag.o -MD -MP -MF .deps/autogen-ag.Tpo -c -o autogen-ag.o `test -f 'ag.c' || echo '../../agen5/'`ag.c In file included from /u/ROOT/usr/local/include/guile/3.0/libguile.h:52:0, from ../../agen5/autogen.h:60, from ag.c:9: /u/ROOT/usr/local/include/guile/3.0/libguile/extensions.h:26:10: fatal error: libguile/libpath.h: No such file or directory #include "libguile/libpath.h" ^~~~ compilation terminated. The "-I /u/ROOT/usr/local/include/guile/3.0" was used to find "libguile/extensions.h", so why would libguile/libpath.h not be found? Why would it not have been found after a full build and "make install"?
Re: Bootstrap is hung
It is the "more user entertainment" thing. I needed 40 minutes with a hefty system. On Thu, Jul 26, 2018 at 5:51 PM Bruce Korb wrote: > > It has been in the pictured state for half an hour. > If it really takes this long on an 8-thread 2.2GHz box, > then more user entertainment is in order. -- - Bruce
Bootstrap is hung
It has been in the pictured state for half an hour. If it really takes this long on an 8-thread 2.2GHz box, then more user entertainment is in order.
Why is Guile unable to find libtool?
$ ./configure . checking for libltdl... no configure: error: GNU libltdl (Libtool) not found, see README. $ type libtool bash: type: libtool: not found $ sudo apt install libtool Reading package lists... Done Building dependency tree Reading state information... Done libtool is already the newest version (2.4.6-2). 0 upgraded, 0 newly installed, 0 to remove and 230 not upgraded. $ sudo apt install libtool-devel Reading package lists... Done Building dependency tree Reading state information... Done E: Unable to locate package libtool-devel $ type libtool bash: type: libtool: not found
Re: There is no returning
On 11/17/13 13:18, Ludovic Courtès wrote: What would you think of sticking to the standard and less problematic ‘_Noreturn’ identifier in Gnulib? (I also agree that it’s better for Guile’s public headers to use ‘__noreturn__’, but using ‘noreturn’ was not completely silly either.) noreturn is a C11 keyword and does not need #define-ing, except as a C11 compatibility thing. When you #include stdnoreturn.h, that token should work as expected. gnulib makes that available.
Re: [PATCH] Fix library search order and don't change LD_LIBRARY_PATH
Thank you so much Mark and Ludovic! Regards, Bruce On Tue, Nov 27, 2012 at 2:54 PM, Mark H Weaver m...@netris.org wrote: Hello all, Apologies for the delay in resolving this issue with LD_LIBRARY_PATH, but we *do* plan to get this fix in 2.0.7. After discussion with Ludovic on IRC, I believe we've reached agreement.
Re: Program received signal SIGSEGV, Segmentation fault.
On 11/16/12 20:22, Mark H Weaver wrote:
Bruce, if you refuse to fix these problems properly, you will end up
Hi Mark,
My program's intent is to read text from two inputs and weave them
together. It has no need to know or understand the encoding in any way,
other than to communicate exception messages to the user.
Read the inputs, transform the text, write the output.
ISO-8859-1 or UTF8 or unsimplified Chinese input, doesn't matter.
It only matters that it be NUL byte delimitable, and all encodings
support that. User messages are not involved here.
with a broken program. Period. Full stop. Most modern distributions
use UTF-8 by default, and if you simply write a bare 0xA9 to the
terminal or output file, that's not going to look right on their
terminal or editor.
It was a data character, not part of my program.
I am trying to get that character to flow through my program
from my inputs to the output file, but I am having trouble with
the Guile functions that transform the data. I want to hand the
Guile library a string, a la
(define my-val (get val-string))
where get is a function that pulls bytes from the input.
Then, later on, insert it into the output with:
(emit my-val)
and have *exactly* what was gotten from the input.
I do not care in the slightest what the current locale is.
I pulled in some arbitrary data with ``(get val-string)''
and now I want those exact bytes to be emitted where I
have the ``(emit my-val)'' invocation.
But if that's really what you want, fine, here's how you do it:
(fluid-set! %default-port-encoding ISO-8859-1)
(set-port-encoding! (current-output-port) ISO-8859-1)
(set-port-encoding! (current-input-port) ISO-8859-1)
(set-port-encoding! (current-error-port) ISO-8859-1)
and make sure to *not* set the locale.
Every time I have a fragment of scheme code, I have a new port.
Doing it this way would require concatenating that text with
the text to invoke. That adds an allocate, two string copies
and a free to every scheme invocation. I'll poke around, but
I am guessing there would have to be some more of this set up
for each scheme sequence, yes?
{
SCM ln = AG_SCM_INT2SCM(line);
scm_set_port_filename_x(port, file);
scm_set_port_line_x(port, ln);
scm_set_port_column_x(port, SCM_INUM0);
}
Re: Program received signal SIGSEGV, Segmentation fault.
Hi Noah, Mark, On 11/16/12 18:19, Noah Lavine wrote: OK, so I tried latin1, too. (replacing scm_from_utf3_string with scm_from_latin1_string). That also does not work. It replaced the 0xA9 character with '?'. I am no expert on character encodings, but we've seen errors like this before where it turned out that Guile was attempting to display the character on a terminal which didn't support it, and then the terminal converted it into '?'. I actually do not use Guile to output anything. I give Guile a string with either the define or set! functions and later pull them out with the verboten function scm_i_string_chars. As far as I can tell, I have to call this procedure myself because all other paths seem to lead through u8_uctomb, which is not helpful for my application. Could there have been some change in how Guile displays strings that caused this error? Did it used to show a \-escape sequence? I have always called some function to obtain the text. I understand the memory is not stable, so I immediately copy the text out and forget the returned address. Much like what scm_to_utf8_stringn() does, but without going through the u8_uctomb_aux transmogrifier. I tend to use memcpy or fwrite. What it all boils down to is that I am looking for string handling functions that will handle the NUL terminated list of bytes and keep its nose out of the contents of the string. Period. Full stop. Could you explain what you're trying to do a little more? Read input text, modify it according to some embedded markups, inserting some auxiliary text gotten from another file, and emitting the result. 95% of it is for computer program text. The remainder is for man pages and texi docs. Sometimes, people like to insert a copyright character in their program text. About a decade ago, someone asked me to do something that would verify that a particular file was pure and proper text and that copyright characters were okay. This meant that the file program was insufficient. I rebuilt my library of old stuff and my current autogen choked and died. So here I am investigating the cause. If you're calling a function that looks at characters on a string object that doesn't contain valid characters, then it will fail. The only invalid character in my tiny little world is the NUL byte. ... So do you intend to make a string object and then never look inside? I look inside for a limited set of reasons: 1. to write it to output 2. to move it someplace else 3. to compare it against another sequence of bytes Or are you going to roll your own string-handling starting from byte sequences? I do not want to do this, but I will if I have to. I really do not want to mess with transforming character sets on my input and output. Just read in, adjust as directed, and write. Thank you for any help on using the Guile interface properly! Regards, Bruce
Program received signal SIGSEGV, Segmentation fault.
This is a clumsy way of saying you don't like the '©' character in strings.
I truly do dislike the fact that that you changed the behavior of strings.
Yes, I know I can figure out how to change my code to use byte arrays
somehow or another, but it is a lot of work. More than just sed
's/string/bytes/'
Anyway, seg faulting is not a good response.
(gdb) printf %s\n, pDE-de_val.dvu_text
This program reads or accepts a list of files and prints the names of the
files that are not plain text. @i{plain text} characters are characters
in the range of 0x20 thru 0x7E (' ' thru '~'), plus backspace,
whitespace characters and the character 0xA9 (© - the circled-C copyright
character).
(gdb) s
Backtrace:
In ice-9/boot-9.scm:
149: 5 [catch #t #catch-closure 9b5860 ...]
157: 4 [#procedure 9510f0 ()]
In unknown file:
?: 3 [catch-closure]
In ice-9/eval.scm:
368: 2 [eval # ()]
368: 1 [eval # ()]
In unknown file:
?: 0 [stack explain]
ERROR: In procedure stack:
ERROR: Throw to key `decoding-error' with args `(scm_from_stringn input
locale conversion error 84 \
#vu8(84 104 105 115 32 112 114 111 103 114 97 109 32 114 101 97 100 115 32 111
114 32 97 99 99 101 112 \
116 115 32 97 32 108 105 115 116 32 111 102 32 102 105 108 101 115 32 97 110
100 32 112 114 105 110 \
116 115 32 116 104 101 32 110 97 109 101 115 32 111 102 32 116 104 101 10 102
105 108 101 115 32 116 \
104 97 116 32 97 114 101 32 110 111 116 32 112 108 97 105 110 32 116 101 120
116 46 32 32 64 105 123 \
112 108 97 105 110 32 116 101 120 116 125 32 99 104 97 114 97 99 116 101 114
115 32 97 114 101 32 99 \
104 97 114 97 99 116 101 114 115 10 105 110 32 116 104 101 32 114 97 110 103
101 32 111 102 32 48 \
120 50 48 32 116 104 114 117 32 48 120 55 69 32 40 39 32 39 32 116 104 114 117
32 39 126 39 41 44 \
32 112 108 117 115 32 98 97 99 107 115 112 97 99 101 44 10 119 104 105 116 101
115 112 97 99 101 32 \
99 104 97 114 97 99 116 101 114 115 32 97 110 100 32 116 104 101 32 99 104 97
114 97 99 116 101 114 \
32 48 120 65 57 32 40 169 32 45 32 116 104 101 32 99 105 114 99 108 101 100 45
67 32 99 111 112 121 \
114 105 103 104 116 10 99 104 97 114 97 99 116 101 114 41 46))'.
Program received signal SIGSEGV, Segmentation fault.
Re: Adding to the end of the load path
On 11/15/12 16:10, Noah Lavine wrote: Given that the module-lookup system is fundamentally complicated, I'm going to suggest that we *don't* try to make it all configurable by environment variables. If people want full control of lookups, they can write a site-wide Guile init file or a personal ~/.guile. The regular load-path would still be part of the system, and that would be configurable by an environment variable, so legacy setups would continue to work. However, I'd be happy saying that if you wanted to access all of the functionality, you need to write Scheme code. Let's start by adding Scheme interfaces to the functionality we want, and maybe not worry about environment variables if they're complicated. What do you think? Yes!! With that, can the LD_LIBRARY_PATH be freed from fiddling?
Re: Program received signal SIGSEGV, Segmentation fault.
On 11/16/12 11:19, Mark H Weaver wrote:
Hi Bruce,
Bruce Korb bruce.k...@gmail.com writes:
This is a clumsy way of saying you don't like the '©' character in
strings.
I'm sorry, but you haven't provided nearly enough information for me to
I'm sorry, I did leave off the backtrace. Here's another GDB session:
460 return AG_SCM_STR02SCM(pE-de_val.dvu_text);
(gdb) printf %s\n, pE-de_val.dvu_text
This program reads or accepts a list of files and prints the names of the
files that are not plain text. @i{plain text} characters are characters
in the range of 0x20 thru 0x7E (' ' thru '~'), plus backspace,
whitespace characters and the character 0xA9 (© - the copyright character).
(gdb) s
Backtrace:
In ice-9/boot-9.scm:
149: 8 [catch #t #catch-closure 9b5860 ...]
157: 7 [#procedure 9510f0 ()]
In unknown file:
?: 6 [catch-closure]
In ice-9/eval.scm:
407: 5 [eval # ()]
442: 4 [eval # #]
368: 3 [eval # #]
368: 2 [eval # #]
368: 1 [eval # #]
In unknown file:
?: 0 [get explain #undefined]
ERROR: In procedure get:
ERROR: Throw to key `decoding-error' with args `(scm_from_stringn input
locale conversion error \
84 #vu8(84 104 105 115 32 112 114 111 103 114 97 109 32 114 101 97 100 115 32
111 114 32 97 99 99 \
101 112 116 115 32 97 32 108 105 115 116 32 111 102 32 102 105 108 101 115 32
97 110 100 32 112 \
114 105 110 116 115 32 116 104 101 32 110 97 109 101 115 32 111 102 32 116 104
101 10 102 105 108 \
101 115 32 116 104 97 116 32 97 114 101 32 110 111 116 32 112 108 97 105 110
32 116 101 120 116 46 \
32 32 64 105 123 112 108 97 105 110 32 116 101 120 116 125 32 99 104 97 114 97
99 116 101 114 115 \
32 97 114 101 32 99 104 97 114 97 99 116 101 114 115 10 105 110 32 116 104 101
32 114 97 110 103 \
101 32 111 102 32 48 120 50 48 32 116 104 114 117 32 48 120 55 69 32 40 39 32
39 32 116 104 114 \
117 32 39 126 39 41 44 32 112 108 117 115 32 98 97 99 107 115 112 97 99 101 44
10 119 104 105 116 \
101 115 112 97 99 101 32 99 104 97 114 97 99 116 101 114 115 32 97 110 100 32
116 104 101 32 99 \
104 97 114 97 99 116 101 114 32 48 120 65 57 32 40 169 32 45 32 116 104 101 32
99 111 112 121 114 \
105 103 104 116 32 99 104 97 114 97 99 116 101 114 41 46))'.
Program received signal SIGSEGV, Segmentation fault.
0x778a389e in scm_frame_procedure () from /usr/lib64/libguile-2.0.so.22
AG_SCM_STR02SCM() is a Guile-version dependent macro:
$ fgrep GUILE_VERSION ../config.h
#define GUILE_VERSION 25
an edited extract from my version dependent wrapper header:
#if (GUILE_VERSION = 20) (GUILE_VERSION = 23)
# error AutoGen does not work with this version of Guile
choke me.
#elif (GUILE_VERSION = 106000)
# error AutoGen does not work with this version of Guile
choke me.
#elif GUILE_VERSION 107000
# define AG_SCM_STR02SCM(_s) scm_makfrom0str(_s)
#elif GUILE_VERSION 20
# define AG_SCM_STR02SCM(_s) scm_from_locale_string(_s)
#elif GUILE_VERSION 201000
# define AG_SCM_STR02SCM(_s) scm_from_utf8_string(_s)
[...]
figure out what caused the SIGSEGV. I don't even know what function you
scm_from_locale_string(). I had a stack trace that disappeared
from the email. (Typo of some sort. Sorry.)
called, or what arguments you passed to it. I guess you called one of
the scm_from_*_string functions with a string, without telling Guile
what string encoding was used.
Telling it? Aside from LC_ALL=C ?? Nope.
Anyway, seg faulting is not a good response.
If you give me more information, perhaps I can help figure out what
caused the SIGSEGV.
I am certain it was the \251 character, because when I remove it, it doesn't
happen.
Re: Program received signal SIGSEGV, Segmentation fault.
AG_SCM_STR02SCM() is a Guile-version dependent macro: $ fgrep GUILE_VERSION ../config.h #define GUILE_VERSION 25 an edited extract from my version dependent wrapper header: #elif GUILE_VERSION 20 # define AG_SCM_STR02SCM(_s) scm_from_locale_string(_s) #elif GUILE_VERSION 201000 # define AG_SCM_STR02SCM(_s) scm_from_utf8_string(_s) [...] figure out what caused the SIGSEGV. I don't even know what function you scm_from_locale_string(). I had a stack trace that disappeared from the email. (Typo of some sort. Sorry.) Actually, it was scm_from_utf8_string, since GUILE_VERSION was 25 -- C Function: SCM scm_from_latin1_string (const char *str) -- C Function: SCM scm_from_utf8_string (const char *str) -- C Function: SCM scm_from_utf32_string (const scm_t_wchar *str) Return a scheme string from the null-terminated C string STR, which is ISO-8859-1-, UTF-8-, or UTF-32-encoded. These functions should be used to convert hard-coded C string constants into Scheme strings.
scm_from_zbyte_string
This is insufficient. There are the to functions
and the string extraction thingys that must be done.
But I really don't like that scm_i_make_string() call.
SCM
scm_from_zbyte_string (const char *str)
{
return scm_from_zbyte_stringn (str, -1);
}
SCM
scm_from_zbyte_stringn (const char *str, size_t len)
{
char *bf;
SCM res;
if (len == (size_t)-1)
len = strlen (str);
res = scm_i_make_string (len, bf, 0);
memcpy (bf, str, len);
return res;
}
Re: Adding to the end of the load path
On 11/11/12 13:51, Mark H Weaver wrote: This is certainly the cleanest solution, but there is a complication: if a user has multiple versions of Guile installed on their system, some of which look for GUILE_LOAD_PATH_SUFFIX and some which do not, there is no way for them to configure their environment variables that will work correctly for all versions. Guile 2.0.5 will be widely deployed until at least 2017, since it is part of Ubuntu 12.04 LTS. We have to cope with that somehow. Declare Guile 2.0.5 to be buggy and recommend Ubuntu/Debian to upgrade with a patch that fixes the LD_LIBRARY_PATH/*_LOAD_PATH stuff? What do you think? Maybe a 2.0.5.1 release that just fixes this bit and fold it into the main branch, too.
Re: Release time!
On 11/05/12 10:11, Ludovic Courtès wrote: Hello! I think time has come for 2.0.7. I suggest scheduling it for Week 48, WDYT? I think it would be Really Nice if it were not fiddling LD_LIBRARY_PATH by the next release. By then, we should essentially squash as many bugs as possible. that bug is quite the nuisance for me
Re: bdwgc
Hi Mark, Thank you. A little while ago I sent an email off to libtool because the actual command name was not set into a variable. The command that failed was: $to_tool_file_cmd $1 and the command trace leading up to it was: lt-func_mode_compile func_to_tool_file alloc.c func_convert_file_msys_to_w32 lt-func_to_tool_file set -x lt-func_to_tool_file case ,$2, in lt-func_to_tool_file alloc.c ./libtool: line 2088: ./alloc.c: Permission denied (where PS4 has been set to: 'lt-$FUNCNAME ') $to_tool_file_cmd should be a shell function that converts alloc.c into a host file name appropriate for the transform tool. In other words, a lot of rigmarole for converting alloc.c into alloc.c.
Re: [PATCH] do not augment environment
Hi Mark, On 09/30/12 19:38, Mark H Weaver wrote: Thanks for the patch, but I think it needs more work before it can be committed. See below for my comments. You're welcome! Just FYI, I've got no ego wrapped up in being the one to type in characters, so fixing things up for preferred style or oversights would be no concern to me at all. * You assume that the directory separator is '/'. Either that, or a wrapper environment fixes it up. If there is a conventional way of dealing with Microsoft-did-it-their-way issues, I don't know what it is. I'm not overly familiar with Guile code. * You should not do the extra search if 'fname' is an absolute pathname, and I'm not sure whether it should be done for relative pathnames containing directory separators. Does anyone else have thoughts on that? It is already an unusual case path. The extra check would save a few cpu cycles when the unusual case was going to fail. This saves one or two cycles in the marginally more common case of the unusual case succeeding. * As a stylistic issue, I don't like your trick of breaking out of the do-while. I'd prefer something closer to this (but with the above problems addressed): I consider it a developed style. :) The deeper the logic nesting, the more complex the code, to my eyes anyway. In this particular case, we're talking about break in the third level instead of two statements. I definitely think the two statements make for microscopically more complex code. That is likely much outweighed by familiarity with the technique. All that notwithstanding, it's your code and what I provided I considered mostly a guideline for what needs to happen to eliminate the LD_LIBRARY_PATH fiddling. Just let me know how to plug in the Microsoft directory separator when needed and I'll resubmit the patch. NOTE: I'll be out of town the 10th through 20th. Thanks - Bruce
Re: [PATCH] do not augment environment
Hi, P.S. On 09/30/12 19:38, Mark H Weaver wrote: In the current code, SCM_LIB_DIR and SCM_EXTENSIONS_DIR are only added to the library search path when GUILE_SYSTEM_EXTENSIONS_PATH is not set. Your patch mishandles this, because it _always_ acts as if SCM_LIB_DIR and SCM_EXTENSIONS_DIR have been added to the search path. Always inserting GUILE_SYSTEM_EXTENSIONS_PATH= into the environment is a better fix than erasing LD_LIBRARY_PATH, but I hadn't read and digested the source. Thanks for the pointer.
Re: [PATCH] do not augment environment
On 10/01/12 09:59, Mark H Weaver wrote: On 10/01/2012 10:39 AM, Bruce Korb wrote: On 09/30/12 19:38, Mark H Weaver wrote: In the current code, SCM_LIB_DIR and SCM_EXTENSIONS_DIR are only added to the library search path when GUILE_SYSTEM_EXTENSIONS_PATH is not set. Your patch mishandles this, because it _always_ acts as if SCM_LIB_DIR and SCM_EXTENSIONS_DIR have been added to the search path. Always inserting GUILE_SYSTEM_EXTENSIONS_PATH= into the environment is a better fix than erasing LD_LIBRARY_PATH, but I hadn't read and digested the source. Thanks for the pointer. Are you deploying this fix in widely-used software, or just within your private environment? If the latter, that's fine, and you can disregard the rest of this message. If the former, then we need to be careful. By setting GUILE_SYSTEM_EXTENSIONS_PATH=, you will break Guile programs that need to load extensions, not just within your own program, but within any subprocesses that might be unrelated to your project. Also, our internal hack of setting GUILE_SYSTEM_EXTENSIONS= during the Guile build is not documented as far as I know, and might change in the future. It's actually a bad hack, for the same reasons given above. For example, if 'gcc' started using Guile, then setting GUILE_SYSTEM_EXTENSIONS= within the Guile build could break gcc. I admit that we created this mess by deploying a bad hack, but let's try to avoid getting ourselves into an even bigger mess by deploying more bad hacks that lock us into preserving our current hacks. Before I spend any more time thinking about this, can you please answer my question above? autogen is used within GCC for constructing the top level Makefile.am's and for cobbling together all the hackery required to fix up broken include files. There are another dozen or so lesser known projects that use it for building out Java Beans infrastructure and similar repetitive tasks. The most common use is likely option processing, but that use would surely never bump into problems with GUILE_SYSTEM_EXTENSIONS_PATH. (NTP and GNU TLS are two well known users of the option stuff.) I control all the associated templates and they do not use any subprograms implemented in Scheme/Guile. In general, I've found my clients to be reluctant users of scheme and it is actually more a barrier to use rather than a facilitator of use. In other words, I suspect, but do not know, that there would be little issue. WRT my problem, I have several choices that I would activate only when the problematical versions of Guile are detected (2.0.1 thru 2.0.?? - what ??): 1. putenv(LD_LIBRARY_PATH=); 2. putenv(GUILE_SYSTEM_EXTENSIONS_PATH=); 3. putenv(GUILE_SYSTEM_EXTENSIONS_PATH=/dev/null); 4. any other suggestions? I think #3 would likely be safest for my environment, but I would certainly like your opinion. Thank you! Regards, Bruce P.S. To be clear: I would not bind you into keeping the null extensions hack. I would stop using it upon detecting a Guile version that does not hack LD_LIBRARY_PATH.
Re: [PATCH] do not augment environment
Thank you for looking into the patch. Could you give me an idea as to when it will be in a release? Thank you so much! Regards, Bruce
[PATCH] do not augment environment
From b7a04164b9de62fe1e80f061f926c9255c84e710 Mon Sep 17 00:00:00 2001
From: Bruce Korb bk...@gnu.org
Date: Fri, 21 Sep 2012 16:33:44 -0700
Subject: [PATCH] do not augment environment
* libguile/dynl.c (augment_env): no longer used. Removed.
(sysdep_dynl_init): remove code that fiddled LD_LIBRARY_PATH
-- aka SHARED_LIBRARY_PATH_VARIABLE
(augment_env): removed. Not used any more.
---
libguile/dynl.c | 67 +--
1 file changed, 25 insertions(+), 42 deletions(-)
diff --git a/libguile/dynl.c b/libguile/dynl.c
index 72305a4..999627a 100644
--- a/libguile/dynl.c
+++ b/libguile/dynl.c
@@ -81,7 +81,25 @@ sysdep_dynl_link (const char *fname, const char *subr)
lt_dlhandle handle;
if (fname != NULL)
-handle = lt_dlopenext (fname);
+{
+ char * buf;
+
+ handle = lt_dlopenext (fname);
+ if (handle == NULL)
+do
+ {
+static char const ext_dir[] = SCM_EXTENSIONS_DIR;
+static char const lib_dir[] = SCM_LIB_DIR;
+buf = alloca (max(sizeof (ext_dir), sizeof (lib_dir))
+ + strlen (fname) + 1); // fault on failure
+sprintf (buf, %s/%s, lib_dir, fname);
+handle = lt_dlopenext (buf);
+if (handle != NULL)
+ break;
+sprintf (buf, %s/%s, ext_dir, fname);
+handle = lt_dlopenext (buf);
+ } while (0);
+}
else
/* Return a handle for the program as a whole. */
handle = lt_dlopen (NULL);
@@ -120,30 +138,6 @@ sysdep_dynl_value (const char *symb, void *handle, const char *subr)
return fptr;
}
-/* Augment environment variable VARIABLE with VALUE, assuming VARIABLE
- is a path kind of variable. */
-static void
-augment_env (const char *variable, const char *value)
-{
- const char *env;
-
- env = getenv (variable);
- if (env != NULL)
-{
- char *new_value;
- static const char path_sep[] = { LT_PATHSEP_CHAR, 0 };
-
- new_value = alloca (strlen (env) + strlen (value) + 2);
- strcpy (new_value, env);
- strcat (new_value, path_sep);
- strcat (new_value, value);
-
- setenv (variable, new_value, 1);
-}
- else
-setenv (variable, value, 1);
-}
-
static void
sysdep_dynl_init ()
{
@@ -152,26 +146,15 @@ sysdep_dynl_init ()
lt_dlinit ();
env = getenv (GUILE_SYSTEM_EXTENSIONS_PATH);
- if (env strcmp (env, ) == 0)
-/* special-case interpret system-ltdl-path== as meaning no system path,
- which is the case during the build */
-;
- else if (env)
+ if (env == NULL)
+return;
+
+ /* special-case interpret system-ltdl-path== as meaning no system path,
+ which is the case during the build */
+ if (*env != '\0')
/* FIXME: should this be a colon-separated path? Or is the only point to
allow the build system to turn off the installed extensions path? */
lt_dladdsearchdir (env);
- else
-{
- /* Add SCM_LIB_DIR and SCM_EXTENSIONS_DIR to the loader's search
- path. `lt_dladdsearchdir' and $LTDL_LIBRARY_PATH can't be used
- for that because they are searched before the system-dependent
- search path, which is the one `libtool --mode=execute -dlopen'
- fiddles with (info (libtool) Libltdl Interface). See
- http://lists.gnu.org/archive/html/guile-devel/2010-11/msg00095.html
- for details. */
- augment_env (SHARED_LIBRARY_PATH_VARIABLE, SCM_LIB_DIR);
- augment_env (SHARED_LIBRARY_PATH_VARIABLE, SCM_EXTENSIONS_DIR);
-}
}
scm_t_bits scm_tc16_dynamic_obj;
--
1.7.10.4
searching variation on sysdep_dynl_link
I confess to not having tested this because I don't have all the
required infrastructure to build.
autoreconf: running: /usr/bin/autoconf --force
configure.ac:58: error: possibly undefined macro: AC_LIBTOOL_WIN32_DLL
If this token and others are legitimate, please use m4_pattern_allow.
See the Autoconf documentation.
configure.ac:77: error: possibly undefined macro: AC_LIBTOOL_DLOPEN
configure.ac:78: error: possibly undefined macro: AC_PROG_LIBTOOL
configure.ac:898: error: possibly undefined macro: AM_GNU_GETTEXT
P.S. Would you please be kind enough to rename your bootstrap script to
bootstrap?
Occasionally, folks ask me for help with their bootstrap scripts because I
maintain
autogen. Thanks.
diff --git a/libguile/dynl.c b/libguile/dynl.c
index 72305a4..ae1f795 100644
--- a/libguile/dynl.c
+++ b/libguile/dynl.c
@@ -81,7 +81,25 @@ sysdep_dynl_link (const char *fname, const char *subr)
lt_dlhandle handle;
if (fname != NULL)
-handle = lt_dlopenext (fname);
+{
+ char * buf;
+
+ handle = lt_dlopenext (fname);
+ if (handle == NULL)
+do
+ {
+static char const ext_dir[] = SCM_EXTENSIONS_DIR;
+static char const lib_dir[] = SCM_LIB_DIR;
+buf = alloca (max(sizeof (ext_dir), sizeof (lib_dir))
+ + strlen (fname) + 1); // fault on failure
+sprintf (buf, %s/%s, lib_dir, fname);
+handle = lt_dlopenext (buf);
+if (handle != NULL)
+ break;
+sprintf (buf, %s/%s, ext_dir, fname);
+handle = lt_dlopenext (buf);
+ } while (0);
+}
else
/* Return a handle for the program as a whole. */
handle = lt_dlopen (NULL);
@@ -152,26 +170,15 @@ sysdep_dynl_init ()
lt_dlinit ();
env = getenv (GUILE_SYSTEM_EXTENSIONS_PATH);
- if (env strcmp (env, ) == 0)
-/* special-case interpret system-ltdl-path== as meaning no system path,
- which is the case during the build */
-;
- else if (env)
+ if (env == NULL)
+return;
+
+ /* special-case interpret system-ltdl-path== as meaning no system path,
+ which is the case during the build */
+ if (*env != '\0')
/* FIXME: should this be a colon-separated path? Or is the only point to
allow the build system to turn off the installed extensions path? */
lt_dladdsearchdir (env);
- else
-{
- /* Add SCM_LIB_DIR and SCM_EXTENSIONS_DIR to the loader's search
-path. `lt_dladdsearchdir' and $LTDL_LIBRARY_PATH can't be used
-for that because they are searched before the system-dependent
-search path, which is the one `libtool --mode=execute -dlopen'
-fiddles with (info (libtool) Libltdl Interface). See
-http://lists.gnu.org/archive/html/guile-devel/2010-11/msg00095.html
-for details. */
- augment_env (SHARED_LIBRARY_PATH_VARIABLE, SCM_LIB_DIR);
- augment_env (SHARED_LIBRARY_PATH_VARIABLE, SCM_EXTENSIONS_DIR);
-}
}
scm_t_bits scm_tc16_dynamic_obj;
Re: Why is Guile now setting LD_LIBRARY_PATH?
On 09/11/12 09:21, Bruce Korb wrote: Do you have any solutions meeting this criteria in mind? Wrap your dlopen's in code that pushes the needed values to the environment I have a better solution that does not require serializing environment variable access: do your own search. Do full path dlopen-s first, using the paths you otherwise would have put into LD_LIBRARY_PATH. If they fail, then fall back to whatever the glibc would otherwise do (maybe even using LD_LIBRARY_PATH -- it hasn't been touched).
Re: Why is Guile now setting LD_LIBRARY_PATH?
Hi Ludo, in main() LD_LIBRARY_PATH='EMPTY' in inner_main() LD_LIBRARY_PATH='/usr/lib64:/usr/lib64/guile/2.0/extensions' The reason provided in ‘sysdep_dynl_init’ is: /* Add SCM_LIB_DIR and ... See http://lists.gnu.org/archive/html/guile-devel/2010-11/msg00095.html for details. */ I am sure you are not arguing that I ought to have known due to a comment in source code and an email from a couple of years ago. My point is that messing with the library search path in an effectively secret manner caused me to spend hours chasing the problem. libguile needs to be linked with -Wl,-rpath -Wl,/usr/lib64/guile/2.0/extensions instead of messing up your client's link/load. (/usr/lib64 should not be needed.) Problem is that (1) -rpath is not always available, and (2) when using GNU ld with --enable-new-dtags, it produces a RUNPATH (not an RPATH), which can be overridden by $LD_LIBRARY_PATH. I agree that using setenv is ugly, but finding an option that’s portable and doesn’t break existing programs seems tricky too. Do you have any solutions meeting this criteria in mind? Wrap your dlopen's in code that pushes the needed values to the environment and then removes them when dlopen is done. You still have multi-thread issues when someone is calling dlopen or exec while a libguile thread is messing with the environment. Perhaps you could document a global lock variable that could single-thread these operations for multi-threaded applications. Either way, fiddling the environment only while using dlopen is far better than breaking people's applications in unexpected ways. At the end: messing with LD_LIBRARY_PATH in a library breaks programs that use the library and make calls to exec or dlopen. Please find a solution that does not do this, or at least minimizes the issues. Thank you. Regards, Bruce C.F. Greg Troxel: I don't follow why you think this is the right fix. It seems that guile (main) and libguile (library) should both not set LD_LIBRARY_PATH at all. To be clear, I do not think this the right fix, but since my application has to cope with un-fixed guile releases, I have to do something. Nuking the variable is the easiest. WRT guile the program and libguile the library, you are correct: neither should set LD_LIBRARY_PATH. It needs to be a user selection to adjust to specific issues in a user's environment.
Why is Guile now setting LD_LIBRARY_PATH?
$ guile --version guile (GNU Guile) 2.0.5 Copyright (C) 2011 Free Software Foundation, Inc. I added a couple of debug printf's after several hours chasing down why my program was crashing: in main() LD_LIBRARY_PATH='EMPTY' in inner_main() LD_LIBRARY_PATH='/usr/lib64:/usr/lib64/guile/2.0/extensions' It was crashing because it was linking against a library in /usr/lib64 instead of /usr/local/lib64. Now I know why. 1. Why was this done? 2. Why no notice? This is *BROKEN*. libguile needs to be linked with -Wl,-rpath -Wl,/usr/lib64/guile/2.0/extensions instead of messing up your client's link/load. (/usr/lib64 should not be needed.) Distribution: openSuSE 12.2 (Just in case they are not following your build procedures and I need to harass them.)
Re: Why is Guile now setting LD_LIBRARY_PATH?
On 09/10/12 16:48, Bruce Korb wrote:
$ guile --version
guile (GNU Guile) 2.0.5
Copyright (C) 2011 Free Software Foundation, Inc.
I added a couple of debug printf's after several hours chasing down
why my program was crashing:
in main() LD_LIBRARY_PATH='EMPTY'
in inner_main() LD_LIBRARY_PATH='/usr/lib64:/usr/lib64/guile/2.0/extensions'
It was crashing because it was linking against a library in /usr/lib64
instead of /usr/local/lib64. Now I know why.
1. Why was this done?
2. Why no notice? This is *BROKEN*.
libguile needs to be linked with -Wl,-rpath
-Wl,/usr/lib64/guile/2.0/extensions
instead of messing up your client's link/load. (/usr/lib64 should not be
needed.)
Distribution: openSuSE 12.2 (Just in case they are not following your
build procedures and I need to harass them.)
P.S. the fix seems to be this, though, naturally, I hate it.
static void
inner_main(void * closure, int argc, char ** argv)
{
atexit(done_check);
initialize(argc, argv);
{
char const * p = getenv(LD_LIBRARY_PATH);
if (p != NULL)
putenv(LD_LIBRARY_PATH=);
}
Re: guile.m4 for autogen
Hi Ludovic, On 08/24/12 06:36, Ludovic Courtès wrote: I'd prefer to use guile.m4, even though it uses guile-config. It insists. Unfortunately, it does not work. For me. configure.ac:140: the top level configure:14130: error: possibly undefined macro: AC_LIB_LINKFLAGS_FROM_LIBS If this token and others are legitimate, please use m4_pattern_allow. See the Autoconf documentation. bootstrap failure: trapped exit signal mk-all: line 197: 5702 Killed As the comment says: dnl AC_LIB_LINKFLAGS_FROM_LIBS is defined in gnulib/m4/lib-link.m4 and needs dnl the file gnulib/build-aux/config.rpath. This means that these two files have to be imported in your project for this to work. I hadn’t noticed that, and I reckon that this is unfortunate. The change dates back to Feb. 2011, by Bruno, so we’d have to check the rationale. Thank you for the explanation. I am a big fan of comprehensible error messages and, as you'd guess, I don't think that possibly undefined macro: AC_LIB_LINKFLAGS_FROM_LIBS qualifies. Adding an AC_REQUIRE() would likely trigger something more meaningful. Having to trace down a comment in an m4 file is not very friendly. However, now that I know the issue, obviously I'll add these files to the list of things I grab from gnulib. Thank you again. Regards, Bruce
Re: guile.m4 for autogen
Hi Harlan,
On 08/18/12 14:41, Harlan Stenn wrote:
Have you tried using pkg-config in autogen's configure to find the guile
CFLAGS and loader stuff?
I'd prefer to use guile.m4, even though it uses guile-config. It insists.
Unfortunately, it does not work. For me.
configure.ac:140: the top level
configure:14130: error: possibly undefined macro: AC_LIB_LINKFLAGS_FROM_LIBS
If this token and others are legitimate, please use m4_pattern_allow.
See the Autoconf documentation.
bootstrap failure: trapped exit signal
mk-all: line 197: 5702 Killed
Here's the configure script fragment with the reference:
{ $as_echo $as_me:${as_lineno-$LINENO}: checking libguile link flags 5
$as_echo_n checking libguile link flags... 6; }
GUILE_LDFLAGS=`$GUILE_CONFIG link`
{ $as_echo $as_me:${as_lineno-$LINENO}: result: $GUILE_LDFLAGS 5
$as_echo $GUILE_LDFLAGS 6; }
AC_LIB_LINKFLAGS_FROM_LIBS(GUILE_LIBS, $GUILE_LDFLAGS, )
GUILE_LIBS=$GUILE_LDFLAGS $GUILE_LIBS
AC_LIB_LINKFLAGS_FROM_LIBS(GUILE_LTLIBS, $GUILE_LDFLAGS, yes)
GUILE_LTLIBS=$GUILE_LDFLAGS $GUILE_LTLIBS
Since this guile.m4 comes from Guile 2.0.4, it is recent enough that any
fully supported AC_* macro should not have been removed from autoconf 2.69.
If I delete the GUILE_FLAGS invocation, then all is fine.
*sigh*.
Re: (ice-9 debug) is deprecated.
Hi Ludovic, On 04/09/12 10:29, Ludovic Courtès wrote: Is this the currently accepted way of setting up an environment where I can trace errors back to their source? Currently uncaught errors lead to Guile printing a backtrace, normally. Doesn’t it work for you? The honest truth? I found I had to go through this rigmarole to get error info and file/line info way back when and haven't looked back. If it is now the default to print out the problem at issue and the file and line for where the problem was discovered, then I can remove it. I _would_ prefer to do that, but otherwise I need to do what I can to get the file/line information. So, can I eliminate this stuff and still get what I need? Thank you!! Regards, Bruce
Re: (ice-9 debug) is deprecated.
On 04/09/12 13:44, Andy Wingo wrote: So, can I eliminate this stuff and still get what I need? On Guile 2.0, I think so, as far as I know. If you are still supporting 1.8, of course, you need #ifdeffery. Thanks, Andy! I still have to support 1.6. 1.8 is not going away any time soon. Cheers - Bruce
Re: (ice-9 debug) is deprecated.
On 04/07/12 14:16, Ludovic Courtès wrote: Hi Bruce, (system vm trace) appeared in Guile 2.0. Hi Ludovic, Then I have a question: Is this the currently accepted way of setting up an environment where I can trace errors back to their source? char fmt[] = (use-modules (%s))\n (read-enable 'positions)\n (add-hook! before-error-hook error-source-line)\n (use-modules (ice-9 stack-catch)); char post_2[] = system vm trace; char pre_2[] = ice-9 debug; asprintf(p, fmt, (guile_ver = 2) ? post_2 : pre_2); ag_scm_eval_string_from_file_line(p, __FILE__, __LINE__);
(ice-9 debug) is deprecated.
``(ice-9 debug) is deprecated. Use (system vm trace) for tracing.'' How far back into Guile history is (system vm trace) valid? Viz. Is it there for 1.6.x? If not, I have to continue using it for a few more years.
ASCII DEL characters are allowed in strings, yes?
Hi, I don't know why this would not have been stumbled over before, but I'd like to confirm that in the Guile string processing code, you only delete or alter characters in the 0x80 to 0xFF range, correct? I can still rely on 0x01 through 0x1F and 0x7F being left alone, yes? Thanks! - Bruce
Re: GNU Guile 2.0.5 released
On 01/30/12 14:02, Ludovic Courtès wrote: We are pleased to announce GNU Guile release 2.0.5. And we users are pleased to have it. Thank you!! Regards, Bruce
Re: unknown location: definition in expression context in subform optname-from of _^
Hi Mark,
On Sat, Jan 28, 2012 at 8:12 PM, Mark H Weaver m...@netris.org wrote:
In short, this single function allows code to do the ideal thing
relatively painlessly. Typical usage might be something like this:
SCM
my_eval (const char *string, const char *file_name,
long line, long column)
{
return scm_eval_string_from_file
(scm_from_locale_string (string), SCM_UNDEFINED,
scm_from_locale_string (file_name), line, column, 0);
}
What do you think?
I think it is what I've wanted for years. Thank you!!
Any of these variations would make me happy.
Cheers - Bruce
Re: unknown location: definition in expression context in subform optname-from of _^
Hi Andy, On Sun, Jan 29, 2012 at 12:28 PM, Andy Wingo wi...@pobox.com wrote: * Bruce's original problem statement says nothing about columns. That's because I, personally, in my application, didn't put forth the effort originally (~15 years ago) and it's too hard to retrofit. * The eval-string introduced in 2.0.1 does add a #:column facility. It also adds #:module, #:lang, and #:compile?. It was only recently I dropped support for Guile 1.4 and I still support 1.6. Translation: I may be dead before 1.8 could be desupported. * All things being equal, writing Guile functionality in Scheme is better than in C. (Note the caveat, please.) Is Guile intended as the be-all and end-all in application languages, or as an extension language. It was initially billed as an extension language, tho, I confess, it's been over a decade since I started using it. As a corrolary, for it to make little difference to C code what language something is implemented in, it needs to be easy to call Scheme from C without creating C bindings. (Note that there is a difference between easy and familiar; Rich Hickey's Simple Made Easy presentation deals with this point at some length.) Amen. The proposed scm_c_eval_string_from_file_line does not allow for #:lang. It also has a trailing boolean argument, which is something of an antipattern. Something of precisely what I, personally, needed, with little to no concern over being applied to variations on a theme. It was presented more as a Here's my problem, here's my hack around it, *please* come up with something better. And you have. Thank you. I look forward to using it and getting that cruft out of my code. Keyword arguments suit this task much better. Indeed. I certainly agree that that is better for supporting so many variations. Our current API encourages sloppiness by making it tedious to do the right thing. We provide a very convenient interface to evaluate a C string without source information, thus encouraging coders to use that even if source information is conveniently available to them. It seems to me that we should provide equally convenient means of doing the right thing. This is true. Amen. vehement agreement here. :) Regards, Bruce
Re: unknown location: definition in expression context in subform optname-from of _^
Hi Mark, On Fri, Jan 27, 2012 at 11:02 PM, Mark H Weaver m...@netris.org wrote: Hi Bruce, In case you didn't see the other thread here on guile-devel: I read some of it. ... with Guile 2.0.4 the error message would have been something like this: /old-home/ROOT/usr/local/share/autogen/aginfo.tpl:171:2: definition in expression context, where definitions are not allowed, in form (define optname-from _^) That's waay too cool !!! :) Thank you. Actually, I think I can, with that, drop my own file/line numbers when complaining about Guile complaints then!! Scheme evaluation error. AutoGen ABEND-ing in template /old-home/ROOT/usr/local/share/autogen/aginfo.tpl on line 163 Bruce Korb bruce.k...@gmail.com writes: I need to be able to locate a guile scheme expression in my ASCII text input and hand it off to Guile, telling it the file name and line number and column number of where I found the string. I agree that we should add a function or two to handle this more conveniently. Let's talk about it after 2.0.4 has been released, and hopefully we can get it into 2.0.5. Maybe less cumbersome than scm_c_eval_string_from_file_line ;) Super! Thank you again! Regards, Bruce
Re: unknown location: definition in expression context in subform optname-from of _^
On 01/26/12 22:19, Mark H Weaver wrote: Then either it ought to have printed the location, or there are new wrinkles in the file/line number stuff that I need to know about. Your code looks good to me, and should allow source locations to be properly reported in error messages. It turns out that this was simply a bug in Guile. That's a relief to me! (I'd still advocate adding it to Guile. :) I have produced a patch to fix these error messages, and will post it as soon as I have thoroughly tested it (within a couple of hours), in the hopes that it may be included in 2.0.4. Excellent. Ideally, you would also call 'scm_set_port_column_x' here. Otherwise, the column numbers of errors on the first line will not be reported properly. All I can do is set the first line column to zero. I don't track the columns. scm_set_port_column_x(port, SCM_INUM0); // yes? Thank you! Regards, Bruce
Re: unknown location: definition in expression context in subform optname-from of _^
On 01/25/12 20:22, Mike Gran wrote: From: Bruce Korbbruce.k...@gmail.com unknown location: definition in expression context in subform optname-from of _^ Scheme evaluation error. AutoGen ABEND-ing in template /old-home/ROOT/usr/local/share/autogen/aginfo.tpl on line 163 Failing Guile command: = = = = = (define opt-name ) (define extra-ct 0) (define extra-text ) (define optname-from A-Z_^) ;;=== is something wrong here? What, exactly? (define optname-to a-z--) (make-tmp-dir) what is the message trying to say? For some reason, it thinks that you're not at the top level, but instead in the middle of some expression. It might be saying that you've missed a close parenthesis on a define somewhere above. The answer, then, is I don't know. The text handed off to the read/process loop is exactly what you see above, modulo I added the comment. Since an entire s-expression is read before processing, there cannot have been a left-open s-expression from another call to ag_scm_eval_expression_from_file_line. I'd have choked there. I tried it twice last night and it failed this way both times. I just retried it and it worked correctly. It is an inexplicable transient error. An irreproducible result. Thank you! Cheers - Bruce
Re: unknown location: definition in expression context in subform optname-from of _^
On 01/26/12 16:10, Mark H Weaver wrote: unknown location: definition in expression context in subform optname-from of _^ The other interesting thing here is that the error message above says _^ instead of the full string A-Z_^. That suggests that the string literal was not properly read. Bruce, are you sure that the following expression was passed directly to 'eval' or 'primitive-eval'? I am completely certain. Unfortunately, though the string now looks like this: (define opt-name ) (define extra-ct 0) (define extra-text ) (define optname-from A-Z_^) (define optname-to a-z--) (make-tmp-dir) (if (exist? preserve-case) (begin (set! optname-from _^) (set! optname-to --) )) Upon careful examination of the entire, not-clipped string, I know at one point those set! used to be define. Then I got bit, went through several fixup cycles and an old version must have been copied into place. Sorry for the bother. PS: As a side note to the Guile developers: the error message here is misleading, because in the call to 'syntax-violation' within the 'define*' cases of 'expand-expr', the bound identifier is passed as the 'subform' and the bound value is passed as the 'form'. Unfortunately, there is no way to fix this without changing the values that 'syntax-type' returns for 'define*' forms. Too bad. I do prefer clue-ful error messages and unknown location just wasn't the helpful clue I needed. Perhaps just use improper location? invalid location? Just not unknown location. It sounds like Guile is out in the weeds and cannot really tell me what's awry.
Re: unknown location: definition in expression context in subform optname-from of _^
On 01/26/12 18:26, Mark H Weaver wrote:
Too bad. I do prefer clue-ful error messages and unknown location
just wasn't the helpful clue I needed. Perhaps just use improper location?
invalid location? Just not unknown location.
That part of the error message (where unknown location was printed)
would normally contain the filename, line number, and column number.
Then either it ought to have printed the location, or there are new
wrinkles in the file/line number stuff that I need to know about.
That is precisely why I hate having this function in my code:
SCM
ag_scm_c_eval_string_from_file_line(
char const * pzExpr, char const * pzFile, int line)
{
SCM port = scm_open_input_string(AG_SCM_STR02SCM(pzExpr));
if (OPT_VALUE_TRACE = TRACE_EVERYTHING)
fprintf(pfTrace, TRACE_EVAL_STRING, pzFile, line, pzExpr);
{
static SCMfile = SCM_UNDEFINED;
static char * pzOldFile = NULL;
if ((pzOldFile == NULL) || (strcmp(pzOldFile, pzFile) != 0)) {
if (pzOldFile != NULL)
AGFREE(pzOldFile);
AGDUPSTR(pzOldFile, pzFile, scheme source);
file = AG_SCM_STR02SCM(pzFile);
}
{
SCM ln = AG_SCM_INT2SCM(line);
scm_set_port_filename_x(port, file);
scm_set_port_line_x(port, ln);
}
}
{
SCM ans = SCM_UNSPECIFIED;
/* Read expressions from that port; ignore the values. */
for (;;) {
SCM form = scm_read(port);
if (SCM_EOF_OBJECT_P(form))
break;
ans = scm_primitive_eval_x(form);
}
return ans;
}
}
Every evaluation comes from here and in this instance, pzFile
pointed to /path/to/aginfo.tpl and line was set to 163.
Therefore, the location should *NOT* have been unknown and
in fact, the displayed line number ought to have been 171.
Why that failed I would very much want to know so that I can
fix this ag_scm_c_eval_string_from_file_line() thingy.
The message definition in expression context accurately conveys the
Yes, it does. I was thrown off by the unknown location stuff.
Thank you for your help!!
Regards, Bruce
Re: unknown location: definition in expression context in subform optname-from of _^
On 01/26/12 18:59, Noah Lavine wrote:
Hello,
/* Read expressions from that port; ignore the values. */
for (;;) {
SCM form = scm_read(port);
if (SCM_EOF_OBJECT_P(form))
break;
ans = scm_primitive_eval_x(form);
}
return ans;
}
}
Every evaluation comes from here and in this instance, pzFile
pointed to /path/to/aginfo.tpl and line was set to 163.
Therefore, the location should *NOT* have been unknown and
in fact, the displayed line number ought to have been 171.
Why that failed I would very much want to know so that I can
fix this ag_scm_c_eval_string_from_file_line() thingy.
I am not an expert, but this is my guess about what's happening: you
get the form from the file with scm_read. scm_read returns a regular
s-expression, not a syntax object. Then you pass this form to
scm_primitive_eval_x. scm_primitive_eval_x has a plain syntax-object
with no way to know where it came from, so it prints unknown
location.
Nope. My code is parsing a text file, keeping track of file and line.
The pzExpr argument is, indeed, an array of UTF-8/ASCII text
from a file and line number known and also passed in.
So, I am getting the form from that read on the string port
and my expectation is that Guile advances the line/column numbers
set in the calls above. If this is not true, then I need explicit
instructions on *exactly* what I need to do in order for the
unknown location to be a known location.
But note that I didn't say that you could do this. I don't know of an
interface to this functionality (although I believe this example shows
that we need one).
It has been an issue I've been arguing for years and years and years,
ever since the trivial 1.6(4?) methodology (fiddling with obviously correct,
but very wrong to do, Guile internal data structures) became disabled.
Look in the email archives for ag_scm_c_eval_string_from_file_line.
http://lists.gnu.org/archive/html/guile-devel/2005-11/msg00052.html
I made the name very long so it would be easy to Google for. :)
So I will repeat my request (and, please forgive the irritation,
because I have, after all, been asking for a really long time):
I need to be able to locate a guile scheme expression in my ASCII
text input and hand it off to Guile, telling it the file name and
line number and column number of where I found the string. In this way,
when there is an evaluation error, something more sensible than
unknown location is displayed for the location information.
Thank you for reconsidering.
Regards, Bruce
unknown location: definition in expression context in subform optname-from of _^
Hi, Say, what??? I don't understand. ice-9/psyntax.scm:866:30: In procedure dobody: ice-9/psyntax.scm:866:30: Syntax error: unknown location: definition in expression context in subform optname-from of _^ Scheme evaluation error. AutoGen ABEND-ing in template /old-home/ROOT/usr/local/share/autogen/aginfo.tpl on line 163 Failing Guile command: = = = = = (define opt-name ) (define extra-ct 0) (define extra-text ) (define optname-from A-Z_^) ;;=== is something wrong here? What, exactly? (define optname-to a-z--) (make-tmp-dir) what is the message trying to say?
Re: Guile BUG: What's wrong with this?
On 01/07/12 07:00, Mark H Weaver wrote: I think you are presuming that that is the only source of zero length immutable strings. Are you completely certain? Empty string literals () in the program text are still immutable, so (string-upcase! ) still throws an error. I admit that this is an arguable point. Section 3.4 (Storage model) of the R5RS (and the R7RS draft) says It is an error to attempt to store a new value into a location that is denoted by an immutable object. An empty string denotes no locations, so perhaps this should not be an error after all. The right place to fix this would probably be in `scm_i_string_start_writing' (strings.c). What do other people think? I think it too much effort for that function. I looked at it. The problem is that you'd have to pass it the start and end points, that is, change its interface. Not worth it. Either do as you've done and have a shared writable zero length string, or exit the functions that use scm_i_string_start_writing before calling that function, in the event that these string transformation functions detect a zero length string (my patch). Either way.
Re: mutable interfaces - was: Guile: What's wrong with this?
On 01/07/12 08:13, Mark H Weaver wrote: Most of the strings that I wind up altering are created with a scm_from_locale_string() C function call. BTW, beware that scm_from_locale_string() is only appropriate for strings that came from the user (e.g. command-line arguments, reading from a port, etc). When converting string literals from your own source code, you should use scm_from_latin1_string() or scm_from_utf8_string(). Similarly, to make symbols from C string literals, use scm_from_latin1_symbol() or scm_from_utf8_symbol(). Caveat: these functions did not exist in Guile 1.8. If your C string literals are ASCII-only, I guess it won't matter in practice which function you use, although it would be good to spread the understanding that C string literals should not be interpreted according to the user's locale. I go back to my argument that a facilitation language needs to focus on being as helpful as possible. That means doing what is likely wanted instead of throwing errors at every possibility. It also means not changing interfaces. It is certainly much more stable now than it was in the 1.4 to 1.6 transition era, but still. Anyway, this then? (abbreviated) #if GUILE_VERSION 107000 # define AG_SCM_STR02SCM(_s) scm_makfrom0str(_s) # define AG_SCM_STR2SCM(_st,_sz) scm_mem2string(_st,_sz) #elif GUILE_VERSION 20 # define AG_SCM_STR02SCM(_s) scm_from_locale_string(_s) # define AG_SCM_STR2SCM(_st,_sz) scm_from_locale_stringn(_st,_sz) #elif GUILE_VERSION 24 #error autogen does not work with this version of guile choke me. #else # define AG_SCM_STR02SCM(_s) scm_from_utf8_string(_s) # define AG_SCM_STR2SCM(_st,_sz) scm_from_utf8_stringn(_st,_sz) #endif
Re: Guile BUG: What's wrong with this?
On 01/07/12 08:38, Mark H Weaver wrote: * Modify the interface to `scm_i_string_start_writing' to give it the `start' and `end' indices. * Add checks to all string mutation functions: if the range is empty, then avoid calling `scm_i_string_start_writing'. Yes. All of them. All four. The advantage to the first approach is that authors of future string mutators won't have to remember to handle this case specially, and I have very little confidence that they would. I'll look into this. Either way. The advantage of quitting a string transformation function early when the length to modify is zero is you save more overhead than just calling scm_i_string_start_writing. But it's your call. Whatever.
Re: Guile: What's wrong with this?
On 01/06/12 10:13, Mark H Weaver wrote: Imagine that you were evaluating Scheme by hand on paper. You have your program written on one page, and you have another scratch page used for the data structures that your program creates during evaluation. Suppose your program contains a very large lookup table, written as a literal list. This lookup table is on your program page. Now, suppose That is where my mental model diverges!! sprintf(buf, (define %s \%s\), foo, my_str); scm_eval_string(buf); sprintf(buf, (string-upcase! %s), foo) // the string from my_str in buf is now scribbled over and completely gone scm_eval_string(buf); Since I know the program I initially wrote (the define) is now gone, the string must have been copied off somewhere. I think one's first guess is that it was copied to someplace modifiable. However, that would be incorrect. It is copied off to writable memory, but marked as read-only for the purposes of Guile. Not intuitively obvious. Guile 1.8's permissivity allowed Bruce to unwittingly create a large body of code that was inherently buggy. IMHO, it would have been much better to nip that in the bud and alert him to the fact that he was doing something that was almost certainly unwise. Fail early and fail hard. Yes. But after all these discussions, I now doubt I have too many places where I am expecting to change a static value. Most of the strings that I wind up altering are created with a scm_from_locale_string() C function call. Very few strings are ever actually initialized with (define foo something), other than when creating placeholders because you cannot define within a nested collection of functions. e.g. (if (whatever) (define foo (get this)) (define foo (get that)) ) (string-upcase! foo) Anyway, I did compile and build my toy and guile with CFLAGS='-g -O0'. The error message did not show. Instead it seg faulted while trying to make this call: scm_from_locale_string(); There must be a corruption somewhere. It is either asymptomatic with Guile 1.8 (viz. my fault) or it is introduced with Guile 2.0 (meaning a Guile code issue). More in a few days. Thank you.
Re: Guile BUG: What's wrong with this?
scm_from_locale_stringn() makes an optimization when the length is zero. It returns an immutable string of length zero. For reasons I no longer remember, I had my own ag_scm_string_upcase that called scm_string_upcase_x, presuming that scm_from_locale_stringn had returned a writable string. Two possible fixes: 1. remove the optimization 2. check the length in scm_string_upcase_x before choking. The reason for the seg fault is that scm_backtrace() faulted. I called it in the on_exit path and it couldn't cope.
Re: Guile: What's wrong with this?
On 01/04/12 08:47, Andy Wingo wrote: I was going to propose a workaround with an option to change vm-i-loader.c:43 and vm-i-loader.c:115 to use a scm_i_mutable_string_literals_p instead of 1, but that really seems like the path to perdition: previously compiled modules would start creating mutable strings where they really shouldn't. Instead, long-standing, previously written code was invalidated with 1.9, even if we were not smacked down until 2.0.1. Just because an obscure-to-those-not-living-and-breathing-Scheme-daily document said it was okay doesn't make it okay to those whacked by it. I would think recompiling should not be a great burden, *ESPECIALLY* given that it is a recent invention and therefore likely to have some initial issues that need dealing with. Like this, for example.
Re: Guile: What's wrong with this?
On 01/04/12 11:43, Andy Wingo wrote: The correct behavior is the status quo. We are considering adding a hack to produce different behavior for compatibility purposes. We don't have to worry about correctness in that case, only compatibility. IMO anyway :) It would be a nice added benefit if it worked as one would expect. viz., you make actual, writable copies of strings you pull in so that if the string-upcase function were to modify its input, then it would not affect other SCMs with values that happen to be the same sequence of bytes.
Re: Guile: What's wrong with this?
On 01/03/12 14:24, Ludovic Courtès wrote: 2. it is completely, utterly wrong to mutilate the Guile library into such a contortion that it interprets this: (define y hello) to be a request to create an immutable string anyway. It very, very plainly says, make 'y' and fill it with the string hello. Making it read only is crazy. It stems from the fact that string literals are read-only, per R5RS (info (r5rs) Storage model): [[blah, blah, blah]] In Guile this has been the case since commit 190d4b0d93599e5b58e773dc6375054c3a6e3dbf. The reason for this is that Guile’s compiler tries hard to avoid duplicating constants in the output bytecode. Thus, modifying a You have changed the interface without deprecation or any other multi-year process. Please change it back. Please fix the problem by adding (define-strict y hello) to have this new semantic. Thank you.
When was scm_sizet deprecated?
Hi, I need to know which version: 1.6? 1.7? 1.8? I don't have history, though I know the #define showed up in deprecated.h by 1.8.8. But I still have 1.6 clients, so I cannot just replace all scm_sizet's with size_t. I think I need to add another ag_scm_size_t thinegy that is sometimes #defined to scm_sizet and other times size_t. Since I do not have a history of sources, I need to know the version when scm_sizet was deprecated. Thank you.
Re: When was scm_sizet deprecated?
On 05/31/11 11:42, Andy Wingo wrote: On Tue 31 May 2011 17:41, Bruce Korbbruce.k...@gmail.com writes: which version: 1.6? 1.7? 1.8? The NEWS seems to indicate 1.6. In general for deprecations, the NEWS is the best record, apart from git history. Thank you. It has always seemed somewhat difficult for me to rely on. $ grep -E -n -i '(^Changes in |scm_sizet|scm_listofnull)' ~/tools/guile/guile-2.0.0/NEWS 8:Changes in 2.0.0 (changes since the 1.8.x series): scm_listofnull needs to be added here -- someone pointed me at it 1954:Changes in 1.8.8 (since 1.8.7) 1963:Changes in 1.8.7 (since 1.8.6) 1993:Changes in 1.8.6 (since 1.8.5) 2044:Changes in 1.8.5 (since 1.8.4) 2111:Changes in 1.8.4 (since 1.8.3) 2165:Changes in 1.8.3 (since 1.8.2) 2188:Changes in 1.8.2 (since 1.8.1): 2232:Changes in 1.8.1 (since 1.8.0): 2302:Changes in 1.8.0 (changes since the 1.6.x series): 4331:** New function: scm_c_read (SCM port, void *buffer, scm_sizet size) =+ 4339:** New function: scm_c_write (SCM port, const void *ptr, scm_sizet size) =+ 4612:** Deprecated typedef: scm_sizet =+ 6791:*** Function: SCM scm_make_smob_type (const char *name, scm_sizet size) 6811: scm_sizet (*print) (SCM, 6955:Changes in Guile 1.3 (released Monday, October 19, 1998): [...] But it looks like there has been a lot more rigor since 1.8.0. Anyway, it looks like I should just always use size_t on this one. Thank you! Regards, Bruce
Re: reprise: scm_c_eval_string_from_file_line
Hi Andy, On 03/09/11 12:15, Andy Wingo wrote: So, this should go under: #if GUILE_VERSION 20 // anything after 2.0, e.g. 2.0.1 ?? Rather use AC_CHECK_FUNC. You'd have to check for (ice-9 eval-string) as well, added at the same time. Then scm_call_5 implies (ice-9 eval-string), and vice versa. AC_CHECK_FUNC is the correct approach for testing platform features coming from different vendors. It is not the right approach for dealing with one platform (the Guile library) that has well understood features and feature (interface) changes. I've actually developed an entire glue layer. My ag interface layers on top of the gh/scm/whatever and is provided by a header and a little code. The header is enclosed for your amusement. I don't think 30 feature tests is appropriate. autoconf takes long enough as it is, hence my little libposix project. To elaborate here a bit, it basically installs fixed or missing POSIX stuff on a platform. By testing for the existence and version (note: VERSION) of that library, you can safely presume all the POSIX bits are present and working, and eliminate all the is this POSIX feature present feature tests. The bulk of my build time is autoconf feature testing. #if GUILE_VERSION 107000 # define AG_SCM_APPLY2(_op, _f, _tst) gh_call2(_op, _f, _tst) # define AG_SCM_BOOL_P(_b)SCM_BOOLP(_b) # define AG_SCM_BOOT_GUILE(_ac, _av, _im) \ gh_enter((_ac), (_av), (_im)) # define AG_SCM_CHAR(_c) gh_scm2char(_c) # define AG_SCM_CHARS(_s) SCM_CHARS(_s) # define AG_SCM_CHAR_P(_c)SCM_CHARP(_c) # define AG_SCM_DISPLAY(_s) gh_display(_s) # define AG_SCM_FALSEP(_r)SCM_FALSEP(_r) # define AG_SCM_FROM_LONG(_l) gh_long2scm(_l) # define AG_SCM_INT2SCM(_i) gh_int2scm(_i) # define AG_SCM_IS_PROC(_p) SCM_NFALSEP( scm_procedure_p(_p)) # define AG_SCM_LIST_P(_l)SCM_NFALSEP( scm_list_p(_l)) # define AG_SCM_LISTOFNULL() scm_listofnull # define AG_SCM_LONG2SCM(_i) gh_long2scm(_i) # define AG_SCM_NFALSEP(_r) SCM_NFALSEP(_r) # define AG_SCM_NULLP(_m) scm_is_null(_m) # define AG_SCM_NUM_P(_n) SCM_NUMBERP(_n) # define AG_SCM_PAIR_P(_p)SCM_NFALSEP( scm_pair_p(_p)) # define AG_SCM_STR02SCM(_s) scm_makfrom0str(_s) # define AG_SCM_STR2SCM(_st,_sz) scm_mem2string(_st,_sz) # define AG_SCM_STRING_P(_s) SCM_STRINGP(_s) # define AG_SCM_STRLEN(_s)SCM_STRING_LENGTH(_s) # define AG_SCM_SYM_P(_s) SCM_SYMBOLP(_s) # define AG_SCM_TO_INT(_i)gh_scm2int(_i) # define AG_SCM_TO_LONG(_v) gh_scm2long(_v) # define AG_SCM_TO_NEWSTR(_s) gh_scm2newstr(_s, NULL) # define AG_SCM_TO_ULONG(_v) gh_scm2ulong(_v) # define AG_SCM_VEC_P(_v) SCM_VECTORP(_v) #elif GUILE_VERSION 108000 # define AG_SCM_APPLY2(_op, _f, _tst) gh_call2(_op, _f, _tst) # define AG_SCM_BOOL_P(_b)SCM_BOOLP(_b) # define AG_SCM_BOOT_GUILE(_ac, _av, _im) \ gh_enter((_ac), (_av), (_im)) # define AG_SCM_CHAR(_c) gh_scm2char(_c) # define AG_SCM_CHARS(_s) SCM_STRING_CHARS(_s) # define AG_SCM_CHAR_P(_c)SCM_CHARP(_c) # define AG_SCM_DISPLAY(_s) gh_display(_s) # define AG_SCM_FALSEP(_r)scm_is_false(_r) # define AG_SCM_FROM_LONG(_l) gh_long2scm(_l) # define AG_SCM_INT2SCM(_i) gh_int2scm(_i) # define AG_SCM_IS_PROC(_p) scm_is_true( scm_procedure_p(_p)) # define AG_SCM_LIST_P(_l)scm_is_true( scm_list_p(_l)) # define AG_SCM_LISTOFNULL() scm_listofnull # define AG_SCM_LONG2SCM(_i) gh_long2scm(_i) # define AG_SCM_NFALSEP(_r) scm_is_true(_r) # define AG_SCM_NULLP(_m) scm_is_null(_m) # define AG_SCM_NUM_P(_n) scm_is_number(_n) # define AG_SCM_PAIR_P(_p)scm_is_true( scm_pair_p(_p)) # define AG_SCM_STR02SCM(_s) scm_from_locale_string(_s) # define AG_SCM_STR2SCM(_st,_sz) scm_from_locale_stringn(_st,_sz) # define AG_SCM_STRING_P(_s) scm_is_string(_s) # define AG_SCM_STRLEN(_s)SCM_STRING_LENGTH(_s) # define AG_SCM_SYM_P(_s) SCM_SYMBOLP(_s) # define AG_SCM_TO_INT(_i)gh_scm2int(_i) # define AG_SCM_TO_LONG(_v) gh_scm2long(_v) # define AG_SCM_TO_NEWSTR(_s) scm_to_locale_string(_s) # define AG_SCM_TO_ULONG(_v) gh_scm2ulong(_v) # define AG_SCM_VEC_P(_v) SCM_VECTORP(_v) #elif GUILE_VERSION 109000 # define AG_SCM_APPLY2(_op, _f, _tst) \ scm_apply(_op, _f, scm_cons(_tst, AG_SCM_LISTOFNULL())) # define AG_SCM_BOOL_P(_b)scm_is_bool(_b) # define AG_SCM_BOOT_GUILE(_ac, _av, _im) \ scm_boot_guile((_ac), (_av), (_im), NULL) # define AG_SCM_CHAR(_c) SCM_CHAR(_c) # define AG_SCM_CHARS(_s) scm_i_string_chars(_s) # define AG_SCM_CHAR_P(_c)SCM_CHARP(_c) # define AG_SCM_DISPLAY(_s) \
Re: reprise: scm_c_eval_string_from_file_line
Hi Andy!
On 03/08/11 14:28, Andy Wingo wrote:
SCM
ag_scm_c_eval_string_from_file_line(
char const * pzExpr, char const * pzFile, int line)
So! I implemented something, but it's not quite what you asked for.
Sufficiently close that the resulting code isn't icky. :)
It no longer has the feel of tendrils stuck into the
workings of Guile code. It isn't as trivial to me, but then
maybe there aren't a lot of folks pulling text from various
files and feeding it to eval-string.
So, this should go under:
#if GUILE_VERSION 20 // anything after 2.0, e.g. 2.0.1 ??
You can change your implementation to this:
{
static SCM eval_string_var = SCM_BOOL_F;
if (scm_is_false (eval_string_var))
eval_string_var = scm_c_public_lookup (ice-9 eval-string,
eval-string);
return scm_call_5 (scm_variable_ref (eval_string_var),
string,
Wouldn't this arg need to be SCM-ized? viz. scm_from_locale_string (string)
scm_from_locale_keyword (file),
pzFile ? scm_from_locale_string (pzFile) : SCM_BOOL_F,
scm_from_locale_keyword (line),
scm_from_int (line));
}
If you want to compile the expression, add #:compile? #t to the keyword
arguments.
I guess I'll need to read docs. From this sentence, I'd be guessing
that I'd need to use scm_call_7 and add:
scm_from_locale_keyword(#:compile?), scm_from_locale_keyword(#t),
to the arg list. I think you just added scm_call_5 for this purpose.
Anyway, thank you ! I do appreciate. Regards, Bruce
Re: One config issue solved, only to trip over another.
Thanks, Mike, but: On Mon, Feb 28, 2011 at 10:43 AM, Mike Gran spk...@yahoo.com wrote: No package 'libffi' found On Fedora at least, libffi's been packaged for a long time. I think it is widely available generally as a pre-built package. Saying that if you use Linux, then it must be Red Hat wouldn't fly far. I happen to use OpenSuSE, but the real problem is that I don't have a list that I can just say, go fetch and install these. Tripping over first one, then the next, then how many more? I know I weary easily, but I've stubbed my toe several times in succession before only to finally download a package that doesn't build at all. So I just don't do it any more. :( I'm spoiled. Stuff needs to be completely straight forward.
Re: One config issue solved, only to trip over another.
Hi, On Mon, Feb 28, 2011 at 11:25 AM, Noah Lavine noah.b.lav...@gmail.com wrote: Hello, I think the list you want is in Guile's README file, which says that Guile depends on these libraries: More or less. - libgmp OK - libiconv Not available for openSuSE - libintl A perl library? - libltdl - libunistring - libgc OK - libffi It's installed. The configure script doesn't detect it. It was installed via Yast from the openSuSE site, so I would hope the sentence, Consider adjusting the PKG_CONFIG_PATH environment variable if you installed software in a non-standard prefix. does not apply. $ find /usr/lib* /usr/local/lib* -name 'libffi.*' /usr/lib/libffi.so.4.0.1 /usr/lib/debug/usr/lib64/libffi.so.4.0.1.debug /usr/lib/libffi.so /usr/lib/libffi.so.4 /usr/lib/libffi.a /usr/lib64/libffi.so.4.0.1 /usr/lib64/libffi.so /usr/lib64/libffi.so.4 /usr/lib64/libffi.a
Re: SCM_BOOL_T became #nil -- et al. ?
On 02/24/11 08:35, Ken Raeburn wrote: On Feb 23, 2011, at 15:14, Bruce Korb wrote: * guile should provide autoconf macros to do checking, like for wrong version headers. That seems like a good idea, but unless all the other packages' header directories have already been added to the include path If the library ABI is tweaked to code the version into a symbol name, this test could become a simple compile-and-link test. Exactly. Of course, that approach has other issues, like getting backwards-compatible library upgrades to work without recompiling applications. The .so simply includes the versioned interfaces it supports. They are simply not declared in the current interface. I vaguely remember reading an argument years back for including individual headers by pathname, rather than building up The problem is naming conflicts. The standard way to avoid this is by including some directory information in the include name. e.g. libguile/guile.h instead of libguile.h. If someone really wants to ensure 2.0 vs. 1.8, then you can put versioned subdirectories under /usr/include/libguile and add a symlink farm to redirect requests to the current version. But we're here now and I am saying that a mechanism needs to be put into place whereby there is a hard build time failure when /usr/include/libguile.h gets pulled in ahead of the versioned header. How precisely that is done is an exercise for the Guile maintainers. I'd make suggestions, but I have to presume that you-all are inventive people, too. * Developers should be clearly warned that -I/usr/local/include needs to be after all other -I options, due to guile header naming conflicts. Again, this problem isn't unique to Guile No, it is one of those commonly known things that isn't particularly commonly known. It would be a jog to people's memories in an attempt to help make it actually commonly known. (: Suggested here mainly because Guile introduces such a conflict. :) * I have to vary various interfaces because of the obsolescence that happens from release to release. Consistency would be really nice: There should be a macro that has the value 0x20 or some such that includes the revision number, too. scm_init_guile_with_version_check would just ignore the last 12 bits (or divide by 1000, whatever works...) I've seen this approach used elsewhere, and it seems like a good idea. Configure-time feature tests are great and all, but some features are subtle to test for, and some packages don't use configure scripts that can do feature tests. OpenSSL even encodes an extra digit for development version vs beta or release; I'm not sure if we need to go that far. If you promise to never, ever make any change that makes any client adjust code in any way, then the micro version can be left off. OTOH, adding in a few more bits just in case you have to is pretty cheap Besides, people are already doing it, this would just put the practice into the Guile header instead of my config.h header.
Re: reprise: scm_c_eval_string_from_file_line
On 02/24/11 08:56, Ludovic Courtès wrote:
It compiles fine up to here:
--8---cut here---start-8---
make[4]: Entering directory `/home/ludo/tmp/autogen-5.11.7pre1/getdefs'
exec gd.c ; \
echo '#include config.h' ; \
echo '#undef PKGDATADIR' ; \
echo '#define PKGDATADIR /home/ludo/soft/share/autogen' ; \
for f in opts.c getdefs.h proto.h getdefs.c gdemit.c gdinit.c ; \
do echo #include \$f\ ; done
top_builddir=.. top_srcdir=.. PATH=`cd ../columns /dev/null pwd`:$PATH ;
export top_builddir to
p_srcdir PATH ; /home/ludo/tmp/autogen-5.11.7pre1/agen5/autogen
-L../autoopts/tpl -L../autoopts/tpl
-MF.deps/opts-dep -MTstamp-opts ./opts.def
module/ice-9/psyntax.scm:896:30: In procedure dobody:
module/ice-9/psyntax.scm:896:30: Syntax error:
../autoopts/tpl/optlib.tlib:167:22: definition in expression context in
subform UP-prefix of (string-append (string-upcase! (get prefix)) _)
Scheme evaluation error. AutoGen ABEND-ing in template
../autoopts/tpl/optlib.tlib on line 66
[...]
The failing code is:
--8---cut here---start-8---
(if (exist? prefix)
(begin
(define UP-prefix (string-append (string-upcase! (get prefix)) _))
--8---cut here---end---8---
‘define’ is no longer allowed here (search ‘NEWS’ for ‘prohibiting
definitions in expression’.)
This is an example of why it is important to be able to specify
the source file and line number where the scheme expression gets
extracted from. This ../autoopts/tpl/optlib.tlib:167:22 thing
led Ludovic directly to the problematic code. (He sees the problem,
I do not.) But in order to get the Guile library to understand
where the code comes from, I have to go through what I consider
to be somersaults.
Anyway, picking up threads from 2003 and 2008:
http://osdir.com/ml/lisp.guile.devel/2003-05/msg00202.html
http://www.mail-archive.com/guile-devel@gnu.org/msg02825.html
http://www.mail-archive.com/guile-devel@gnu.org/msg02826.html
I would really, _really_ appreciate being able to yank it out of
my code. Below is an example of what I go through to do it.
It is simplified somewhat since I no longer support Guile 1.4.
It simply doesn't feel like a straight forward interface.
It feels like I am starting a process this string function,
then inject some information, then call a function to scan
a bit then process a bit. How would it ever get compiled?
It'd be nice to be able to say, here's some text, from this
file and this line number, give me back the compiled form
and then call the run it function. But I can't. I have to
insert the file and line information. It's icky code.
Thank you. Regards, Bruce
SCM
ag_scm_c_eval_string_from_file_line(
char const * pzExpr, char const * pzFile, int line)
{
SCM port = scm_open_input_string(AG_SCM_STR02SCM(pzExpr));
if (OPT_VALUE_TRACE = TRACE_EVERYTHING)
fprintf(pfTrace, eval from file %s line %d:\n%s\n, pzFile, line,
pzExpr);
{
static SCMfile = SCM_UNDEFINED;
static char * pzOldFile = NULL;
if ((pzOldFile == NULL) || (strcmp(pzOldFile, pzFile) != 0)) {
if (pzOldFile != NULL)
AGFREE(pzOldFile);
AGDUPSTR(pzOldFile, pzFile, scheme file source);
file = AG_SCM_STR02SCM(pzFile);
}
{
#if GUILE_VERSION 107000
scm_t_port * pt = SCM_PTAB_ENTRY(port);
pt-line_number = line - 1;
pt-file_name = file;
#else
SCM ln = scm_from_int(line);
scm_set_port_filename_x(port, file);
scm_set_port_line_x(port, ln);
#endif
}
}
{
SCM ans = SCM_UNSPECIFIED;
/* Read expressions from that port; ignore the values. */
for (;;) {
SCM form = scm_read(port);
if (SCM_EOF_OBJECT_P(form))
break;
ans = scm_primitive_eval_x(form);
}
return ans;
}
}
Re: SCM_BOOL_T became #nil -- et al. ?
On 02/22/11 20:15, Ken Raeburn wrote: On Feb 22, 2011, at 07:00, Hans Aberg wrote: Perhaps 2.0 should have some check that it gets the right header. It wouldn't be that tough to do something like: #define scm_init_guile scm_init_guile_v2_0 // encode version in symbol [...] and tell people to use the macro. Ugly, maybe, but not tough. :-) If you use `guile-config compile` (and `guile-config link`) in your Makefile it will come out right. Unless you're also using some other foo-config script. Fail early and fail hard. Please find a way to fail a test program, once configure has arranged the -I list. Also: * guile should provide autoconf macros to do checking, like for wrong version headers. * Developers should be clearly warned that -I/usr/local/include needs to be after all other -I options, due to guile header naming conflicts. * I have to vary various interfaces because of the obsolescence that happens from release to release. Consistency would be really nice: There should be a macro that has the value 0x20 or some such that includes the revision number, too. scm_init_guile_with_version_check would just ignore the last 12 bits (or divide by 1000, whatever works...) I have to if-def code due to the interface migration. BSD has moved on to 1.6, so I expect they won't be going to 2.0 any time soon. Speaking of moving interfaces, since this call: scm_list_1(SCM_EOL); yields a value that gets garbage collected and since it is equivalent to the accidentally removed scm_listofnull, I am interested in a stable do it this way equivalent. By replacing scm_listofnull with ag_scm_listofnull and initializing it: SCM ag_scm_listofnull = scm_list_1 (SCM_EOL); In Guile 1.9.3, you have to scm_gc_protect_object this value (info (guile) Garbage Collection Functions). and it sounds like scm_gc_protect_object(ag_scm_listofnull) won't work in 2.0. Would you-all please put scm_listofnull back? Thank you. Regards, Bruce P.S. the listofnull piece of my guile interface glue now looks like this: #if GUILE_VERSION 107000 [.] # define AG_SCM_LISTOFNULL() scm_listofnull #elif GUILE_VERSION 108000 [.] # define AG_SCM_LISTOFNULL() scm_listofnull #elif GUILE_VERSION 109000 [.] # define AG_SCM_LISTOFNULL() scm_listofnull #elif GUILE_VERSION 201000 [.] # define AG_SCM_LISTOFNULL() scm_list_1(SCM_EOL) # define scm_sizetsize_t #else #error unknown GUILE_VERSION #endif and I use AG_SCM_LISTOFNULL() instead of scm_listofnull. Does this look right?
Re: Obsoleted Guile interfaces
On 01/20/11 02:14, Harlan Stenn wrote:
Hi Bruce,
In psp-deb1:stenn/src/gnu/autogen/autogen-5.11.6pre14/A.psp-deb1/ I'm
seeing a build problem because libguile does not contain
scm_c_make_string . psp-deb is running guile 1.6.8.
By the way, that failure is only in the config stuff.
I didn't carefully scrutinize that part of the patch
the Ubuntu folks gave me. Looks like guile 1.6 doesn't
support scm_c_make_string and 1.9 has no alternative.
Thus, the config test code needs some if-def-ing.
Perhaps the Guile folks can point me to some config
test code that will identify a working Guile of the
1.4.x through 1.9.x persuasion. It is getting very
difficult.
#include libguile.h
#if ((SCM_MAJOR_VERSION * 100) + SCM_MINOR_VERSION) 109
This has not been tested with Guile 1.10. Remove this line to proceed.
#endif
int main () {
SCM fumble = SCM_UNDEFINED;
SCM bumble = SCM_UNDEFINED;
SCM stumble= SCM_UNDEFINED;
long lstumble;
stumble = scm_cons( fumble, bumble );
stumble = scm_display( fumble, bumble );
lstumble = scm_ilength( fumble );
stumble = scm_c_make_string( 1, SCM_UNDEFINED);
stumble = scm_c_eval_string( stumble );
scm_misc_error( oops, bad, bumble );
stumble = scm_num_eq_p( fumble, bumble );
scm_wrong_type_arg( oops, 1, bumble );
return 0; }
P.S. note to Guile folks: I set this in my testing environment:
export GUILE_WARN_DEPRECATED=detailed
and had never been whacked with any deprecated messages
until Ubuntu could not build because deprecated interfaces
were dropped. I think this was because the deprecated
interfaces were #define-d to non-deprecated interfaces and
the libguile couldn't tell that I was using old stuff.
May I suggest *NOT* eliminating such interfaces until
they've been #define-d to something that *DOES* warn?
e.g.
#define SCM_NFALSEP(_a) scm_is_true_deprecated(_a)
Re: Obsoleted Guile interfaces
Hi Ludovic, et al., On 01/20/11 14:34, Ludovic Courtès wrote: What message are you replying to? A private thread that led to the issue where the altered config test program was trying to use scm_c_make_string() on a system still running 1.6.8. At least the BSD world looks like it has moved beyond 1.4.x. Maybe I can remove the prior-to-1.6 wrappers now. Obviously, I still have to have the 1.6 and after wrappers. Basically, I need a very short C program than links against libguile to ensure that the functions I need are there. Bruce Korb bruce.k...@gmail.com writes: Which interfaces specifically? _Very_ specifically, see the attached header. :) There are other interfaces that I use, but they haven't wiggled, so I haven't added 'em to the interface glue file. #if GUILE_VERSION 106000 # define AG_SCM_APPLY2(_op, _f, _tst) gh_call2(_op, _f, _tst) # define AG_SCM_BOOL_P(_b)gh_boolean_p(_b) # define AG_SCM_BOOT_GUILE(_ac, _av, _im) \ gh_enter((_ac), (_av), (_im)) # define AG_SCM_CHAR(_c) gh_scm2char(_c) # define AG_SCM_CHARS(_s) SCM_CHARS(_s) # define AG_SCM_CHAR_P(_c)gh_char_p(_c) # define AG_SCM_DISPLAY(_s) gh_display(_s) # define AG_SCM_FALSEP(_r)SCM_FALSEP(_r) # define AG_SCM_FROM_LONG(_l) gh_long2scm(_l) # define AG_SCM_INT2SCM(_i) gh_int2scm(_i) # define AG_SCM_IS_PROC(_p) gh_procedure_p(_p) # define AG_SCM_LIST_P(_l)gh_list_p(_l) # define AG_SCM_LONG2SCM(_i) gh_long2scm(_i) # define AG_SCM_NFALSEP(_r) SCM_NFALSEP(_r) # define AG_SCM_NULLP(_m) SCM_NULLP(_m) # define AG_SCM_NUM_P(_n) gh_number_p(_n) # define AG_SCM_PAIR_P(_p)gh_pair_p(_p) # define AG_SCM_STR02SCM(_s) gh_str02scm(_s) # define AG_SCM_STR2SCM(_st,_sz) gh_str2scm(_st,_sz) # define AG_SCM_STRING_P(_s) gh_string_p(_s) # define AG_SCM_STRLEN(_s)SCM_LENGTH(_s) # define AG_SCM_SYM_P(_s) gh_symbol_p(_s) # define AG_SCM_TO_INT(_i)gh_scm2int(_i) # define AG_SCM_TO_LONG(_v) gh_scm2long(_v) # define AG_SCM_TO_NEWSTR(_s) gh_scm2newstr(_s, NULL) # define AG_SCM_TO_ULONG(_v) gh_scm2ulong(_v) # define AG_SCM_VEC_P(_v) gh_vector_p(_v) #elif GUILE_VERSION 107000 # define AG_SCM_APPLY2(_op, _f, _tst) gh_call2(_op, _f, _tst) # define AG_SCM_BOOL_P(_b)gh_boolean_p(_b) # define AG_SCM_BOOT_GUILE(_ac, _av, _im) \ gh_enter((_ac), (_av), (_im)) # define AG_SCM_CHAR(_c) gh_scm2char(_c) # define AG_SCM_CHARS(_s) SCM_CHARS(_s) # define AG_SCM_CHAR_P(_c)gh_char_p(_c) # define AG_SCM_DISPLAY(_s) gh_display(_s) # define AG_SCM_FALSEP(_r)SCM_FALSEP(_r) # define AG_SCM_FROM_LONG(_l) gh_long2scm(_l) # define AG_SCM_INT2SCM(_i) gh_int2scm(_i) # define AG_SCM_IS_PROC(_p) SCM_NFALSEP( scm_procedure_p(_p)) # define AG_SCM_LIST_P(_l)SCM_NFALSEP( scm_list_p(_l)) # define AG_SCM_LONG2SCM(_i) gh_long2scm(_i) # define AG_SCM_NFALSEP(_r) SCM_NFALSEP(_r) # define AG_SCM_NULLP(_m) SCM_NULLP(_m) # define AG_SCM_NUM_P(_n) SCM_NUMBERP(_n) # define AG_SCM_PAIR_P(_p)SCM_NFALSEP( scm_pair_p(_p)) # define AG_SCM_STR02SCM(_s) scm_makfrom0str(_s) # define AG_SCM_STR2SCM(_st,_sz) scm_mem2string(_st,_sz) # define AG_SCM_STRING_P(_s) SCM_STRINGP(_s) # define AG_SCM_STRLEN(_s)SCM_LENGTH(_s) # define AG_SCM_SYM_P(_s) gh_symbol_p(_s) # define AG_SCM_TO_INT(_i)gh_scm2int(_i) # define AG_SCM_TO_LONG(_v) gh_scm2long(_v) # define AG_SCM_TO_NEWSTR(_s) gh_scm2newstr(_s, NULL) # define AG_SCM_TO_ULONG(_v) gh_scm2ulong(_v) # define AG_SCM_VEC_P(_v) gh_vector_p(_v) #elif GUILE_VERSION 108000 # define AG_SCM_APPLY2(_op, _f, _tst) gh_call2(_op, _f, _tst) # define AG_SCM_BOOL_P(_b)SCM_BOOLP(_b) # define AG_SCM_BOOT_GUILE(_ac, _av, _im) \ gh_enter((_ac), (_av), (_im)) # define AG_SCM_CHAR(_c) gh_scm2char(_c) # define AG_SCM_CHARS(_s) SCM_STRING_CHARS(_s) # define AG_SCM_CHAR_P(_c)gh_char_p(_c) # define AG_SCM_DISPLAY(_s) gh_display(_s) # define AG_SCM_FALSEP(_r)SCM_FALSEP(_r) # define AG_SCM_FROM_LONG(_l) gh_long2scm(_l) # define AG_SCM_INT2SCM(_i) gh_int2scm(_i) # define AG_SCM_IS_PROC(_p) SCM_NFALSEP( scm_procedure_p(_p)) # define AG_SCM_LIST_P(_l)SCM_NFALSEP( scm_list_p(_l)) # define AG_SCM_LONG2SCM(_i) gh_long2scm(_i) # define AG_SCM_NFALSEP(_r) SCM_NFALSEP(_r) # define AG_SCM_NULLP(_m) SCM_NULLP(_m) # define AG_SCM_NUM_P(_n) SCM_NUMBERP(_n) # define AG_SCM_PAIR_P(_p)SCM_NFALSEP( scm_pair_p(_p)) # define AG_SCM_STR02SCM(_s) scm_makfrom0str(_s) # define AG_SCM_STR2SCM(_st,_sz
Re: How does one specify linking to 64 bit libraries when there is a choice?
On 12/19/10 20:40, Noah Lavine wrote: Hello, I am not at all an expert on guile-config, but I will help if I can. Thank you to all who responded. Usually if you have 64-bit libs in lib64, you have to pass --libdir explicitly. We've now concluded that that is, indeed, the answer to the original question. The fallout question: How much understanding of the machinery should be expected of the hapless project builder? Nelson has been doing this stuff for quite a while and has reasonably good understanding of the process. From that understanding, he made the assumption that a standard 64 bit Red Hat Enterprise Linux Server release 5.5 (Tikanga) installation would be compatible with installing Guile via ./configure make sudo make install and not wind up with a frumitzed `guile-config link` output. The assumption was incorrect and we now know that. Perhaps we can strive to make the assumption correct in the future? Thank you! Regards, Bruce
gen-scmconfig is broken
I've installed libtool in many places to ensure that it should find it. (My private directory fails configure, so I used /usr/local for --prefix. This should *NOT* be necessary.): Version 1.8.7 on CentOS release 5.5 (Final) $ ./configure --prefix=/net/home/bkorb [[..]] $ make [[..]] cat ./scmconfig.h.top scmconfig.h.tmp ./gen-scmconfig scmconfig.h.tmp ./gen-scmconfig: error while loading shared libraries: libltdl.so.7: cannot open shared object file: No such file or directory make[2]: *** [scmconfig.h] Error 127 make[2]: Leaving directory `/usr/local/src/guile/guile-1.8.7/libguile' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/usr/local/src/guile/guile-1.8.7' make: *** [all] Error 2 $ which -a libtool /usr/local/src/guile/guile-1.8.7/libtool /net/home/bkorb/bin/libtool /usr/local/bin/libtool /usr/bin/libtool $ for f in $(which -a libtool);do $f --version |head -1 ; done ltmain.sh (GNU libtool) 2.2.6 libtool (GNU libtool) 2.2.10 libtool (GNU libtool) 2.2.10 ltmain.sh (GNU libtool) 1.5.22 (1.1220.2.365 2005/12/18 22:14:06)
Re: gen-scmconfig is broken
Hi Ludovic, On Tue, Sep 7, 2010 at 3:19 PM, Ludovic Courtès l...@gnu.org wrote: Both problems mean that libltd.so isn’t in the loader’s search path ($LD_LIBRARY_PATH). In 1.8 ‘configure’ wrecks havoc when libltdl.so isn’t found, instead of actually diagnosing this. At any rate, adding libltdl.so’s directory to the loader’s search path should fix it. I will try reconfiguring with LD_LIBRARY_PATH set, but I *CAN* link programs without having to set that. I do nothing special, just a plain ../configure --prefix=/usr/local make make install on my play time project and: $ ldd $(which autogen) libguile.so.17 = /usr/lib64/libguile.so.17 (0x00373900) libm.so.6 = /lib64/libm.so.6 (0x00373340) libdl.so.2 = /lib64/libdl.so.2 (0x00373380) libpthread.so.0 = /lib64/libpthread.so.0 (0x003733c0) libc.so.6 = /lib64/libc.so.6 (0x00373300) libgmp.so.3 = /usr/lib64/libgmp.so.3 (0x003746e0) libcrypt.so.1 = /lib64/libcrypt.so.1 (0x00374420) libltdl.so.3 = /usr/lib64/libltdl.so.3 (0x00373980) /lib64/ld-linux-x86-64.so.2 (0x003732c0) so *IT* seems to find libltdl.so just fine. Now that I'm looking at it, I see that our uber-conservative installation is using libltdl.so.3 and your config is demanding .7. What I actually need is a static libguile, but there is no such beast for CentOS. So I was going to build libguile, but it seems it demands a particular libltdl. I'm not going there. Thus, I cannot use libguile. (The .so won't be available on the target -- out of my control.) Too much trouble. Thank you. Regards, Bruce
Re: [Fwd: autogen 5.9.8 doesn't build on IA64] -- libguile conflict
On Tue, Jul 14, 2009 at 12:29 AM, Neil Jerramn...@ossau.uklinux.net wrote: Bruce Korb bruce.k...@gmail.com writes: Hi, I just got this bug report for my project. My version of the __scm.h header guards the definition of the type with #ifdef vms and #ifdef _CRAY1. If there is a version of lib guile around that doesn't guard it, could you let me know? I'll make my project error or on an incompatible Guile in that case. Thanks -Bruce Hi Bruce, This is a known problem, and on my list for addressing quite soon. Debian has a patch, which I guess would work for you too, so you may want to look at trying that. Regards, Neil Hi Neil, It isn't clear to me how to patch autogen to cope with the issue, unless I can detect the problem with some configury magic and force autogen to not #include setjmp.h. I think it is easier to just require a different version of guile. Anyway, my question is: How do I detect the broken installation of Guile? that way, I can fiddle the configury stuff to do one thing or the other. Thanks -Bruce
[Fwd: autogen 5.9.8 doesn't build on IA64] -- libguile conflict
Hi, I just got this bug report for my project. My version of the __scm.h header guards the definition of the type with #ifdef vms and #ifdef _CRAY1. If there is a version of lib guile around that doesn't guard it, could you let me know? I'll make my project error or on an incompatible Guile in that case. Thanks -Bruce Original Message Subject: [ autogen-Bugs-2820112 ] autogen 5.9.8 doesn't build on IA64 Date: Sat, 11 Jul 2009 16:56:52 + From: SourceForge.net nore...@sourceforge.net To: nore...@sourceforge.net Bugs item #2820112, was opened at 2009-07-11 16:56 Message generated for change (Tracker Item Submitted) made by nobody You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=103593aid=2820112group_id=3593 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: autogen Group: autogen Status: Open Resolution: None Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Bruce Korb (bkorb) Summary: autogen 5.9.8 doesn't build on IA64 Initial Comment: Invoking make on autogen 5.9.8 stops with the following error: 'error: conflicting types for 'jmp_buf'. gcc 4.4.0 shows that the type is defined in both /usr/include/setjmp.h and guile's libguile/__scm.h. For IA64 those type definitions differ, indeed. Guile version I use: 1.8.7.
Re: RFD: add an interface scm_c_eval_string_from_file_line
Hi, On Mon, Sep 22, 2008 at 8:16 AM, Ludovic Courtès [EMAIL PROTECTED] wrote: SCM expr = scm_makfrom0str( pzExpr ); That's deprecated as of 1.8, use `scm_from_locale_string ()'. This is used iff Guile antedates 1.6. I guess that can be junked now? scm_t_port* pt; I wouldn't recommend using this structure as it's in a semi-internal, undocumented state. :-) This is used iff Guile antedates 1.8. To my knowledge, there is no other way to set the line number, prior to 1.8. Anyway, why not just use `scm_c_eval_string ()'? It'd be really safer than rolling your own. Because the strings are extracted from large text files and it is important that the error message reveal the correct file and line number. It is precisely because of the issues with cruft like using internal Guile structures that I'd be so extremely happy to (finally) see a a proper export of: scm_c_eval_string_from_file_line(SCM string, SCM file, SCM line) Then for GUILE_VERSION = 109000 I could just #define my variation to the Proper Call. :) Thank you! Regards, Bruce
Re: RFD: drop the GH interface.
Ludovic Courte`s wrote: Hi, Han-Wen Nienhuys [EMAIL PROTECTED] writes: Do we have a consensus? Yes, fine by me, but no rush. ;-) From a Guile-user and not developer perspective, the sequence needs to be: 1. the most retrograde platform must have all the GH capabilities in the SCM interfaces for their releases. It seems to take quite a few years for BSD to get around to building newer versions. 2. Once that happens, a couple of years must pass 3. I finally get around to removing GH stuff from my code (is there a guide?) 4. a couple more years pass 5. now it's okay by me for released code to not have GH. I think we're to step 3 now, but I need to check the Guile version distributed with net/open/free BSD. Last I looked (~4 or 5 years ago...), it was either 1.4.x or, perhaps, 1.6.x. It was many years behind. In any case, I would suggest checking with your customers and redistributors instead of this list. IMHO, anyway. Regards, Bruce
Re: how does one debug a SEGV in scm_threads_prehistory?
On Wed, Jun 18, 2008 at 12:29 PM, Greg Troxel [EMAIL PROTECTED] wrote: Our main development server was upgraded to 64 bits, but mostly still runs 32 bit software, so this is from a 32 bit build on a 64 bit platform. Naturally, this all works on 32 on 32 and on 64 on 64. But with 32 on 64, not so well: I presume you are talking about Linux and going from i386 to amd64/x86_64 (not sure which name is used in Linux). I would be It depends on which Linux: SuSE is x86_64 and Debian amd64. Unclear why the first name needed to be rethought. Whatever. suspicious that the i386 binary is getting linked with some amd64 libs ldd showed which libguile, and it was the 32 bit flavor. (I did go there, too. It's just hard to recount all the rabbit trails I've gone down) somehow - to first order it would seem to be an OS bug if the emulated i386 binary doesn't run the same as on i386. But I could certainly see an allowable difference leading to triggering a latent bug in guile. Can you trigger this with a simple example? I have i386 and now amd64 boxes, and would be curious to try the NetBSD i386 binary on amd64, as well as native. simple example is always a stumbling block. Especially when it is happening in libguile (which is not simple) and triggered by my app (which is as large as Guile is). I'll see what I can do. Probably next week or so. Thanks - Bruce
Re: deprecated features
Han-Wen Nienhuys wrote: Bruce Korb escreveu: By the way, have you all given any consideration to releasing a valgrind config file that would clean out valgrind chaff? I recently needed to do a valgrind run and it was quite painful. I always use the file below. I am not sure what the best way to distribute it would be. I think there are two reasonable ways: 1. on the web site and referenced in the docs that it lives there 2. stash in the datadir and make it obtainable via: $ cp `guile-config datadir`/guile.supp $my_debug_dir Either way would be a lot easier than trying to figure it out every few years. :-) Thank you for sending me your copy! Cheers - Bruce ___ Guile-devel mailing list Guile-devel@gnu.org http://lists.gnu.org/mailman/listinfo/guile-devel
Re: deprecated features
Han-Wen Nienhuys wrote: Well, as long as we keep 'supporting' the 1.4 interfaces, there is little incentive for developers to upgrade to the 1.6 or 1.8 API. Let me be clear about this: it is (most likely) not the developers. It is my clients. Some of them upgrade to bleeding edge Guile and the obsoleted interfaces choke my program. I update the interfaces and somebody running on a platform still on Guile 1.4 complains that it chokes and dies on their system. I could, of course, incorporate the Guile library into my project, but I've determined that that is way, way, way over the top. If the interfaces are not stable enough for me to readily be able to support the current active platforms, then it is changing too quickly. As it is, I have a long collection of interface macros that wrap around Guile interfaces. Maintaining that isn't fun. :( [even less fun is the scm_c_eval_string_from_file_line() thing, the subject of posts in the past...] WRT the BSD distro: It's been a couple of years since I encountered the issue. I don't actively track it. A friend at UofU lets me play on some of his build platforms, so I'll try to remember to check next time I log in there. I'm certain it is pretty old. Cheers - Bruce ___ Guile-devel mailing list Guile-devel@gnu.org http://lists.gnu.org/mailman/listinfo/guile-devel
Re: Unnecessary warnings
On 9/25/06, Ludovic Courtès [EMAIL PROTECTED] wrote: Hi, Bruce Korb [EMAIL PROTECTED] writes: /usr/local/gnu/include/libguile/smob.h:149: warning: declaration of 'free' shadows a global declaration /usr/local/gnu/include/libguile/filesys.h:75: warning: declaration of 'dirname' shadows a global declaration /usr/local/gnu/include/libguile/ports.h:233: warning: declaration of 'write' shadows a global declaration /usr/local/gnu/include/libguile/ports.h:254: warning: declaration of 'truncate' shadows a global declaration /usr/local/gnu/include/libguile/numbers.h:258: warning: declaration of 'div' shadows a global declaration /usr/local/gnu/include/libguile/stime.h:55: warning: declaration of 'time' shadows a global declaration /usr/include/iso/time_iso.h:91: warning: shadowed declaration is here /usr/local/gnu/include/libguile/stime.h:56: warning: declaration of 'time' shadows a global declaration /usr/include/iso/time_iso.h:91: warning: shadowed declaration is here /usr/local/gnu/include/libguile/stime.h:60: warning: declaration of 'stime' shadows a global declaration These are all due to argument names in prototype declarations. What compiler issues those messages? To me, it looks like the compiler is kind of broken, because there's no reason (AFAIK) there can be name clashes between argument names and global declarations. GCC on Solaris. I agree that it is just a documentation name and serves no other purpose, but there it is. I do like -Wshadow, but it is not so useful if cluttered up with these spurious messages. As for the function is not a prototype messages, having a typedef for the particular procedure profile being passed around allows for better profile matching in the calling code anyway. It also cleans up the appearance of your prototype. Thanks! - Bruce ___ Guile-devel mailing list Guile-devel@gnu.org http://lists.gnu.org/mailman/listinfo/guile-devel
Re: Unnecessary warnings
Hi Ludovic, On 9/25/06, Ludovic Courtès [EMAIL PROTECTED] wrote: GCC on Solaris. I agree that it is just a documentation name and serves no other purpose, but there it is. I do like -Wshadow, but it is not so useful if cluttered up with these spurious messages. So _all_ these messages were with `-Wshadow'? Sorry I wasn't clear about that. You only get shadowing warnings when you turn that on. Thanks, Thank _you_! :) Cheers - Bruce ___ Guile-devel mailing list Guile-devel@gnu.org http://lists.gnu.org/mailman/listinfo/guile-devel
Unnecessary warnings
/usr/local/gnu/include/libguile/smob.h:149: warning: declaration of 'free' shadows a global declaration /usr/local/gnu/include/libguile/filesys.h:75: warning: declaration of 'dirname' shadows a global declaration /usr/local/gnu/include/libguile/ports.h:233: warning: declaration of 'write' shadows a global declaration /usr/local/gnu/include/libguile/ports.h:254: warning: declaration of 'truncate' shadows a global declaration /usr/local/gnu/include/libguile/numbers.h:258: warning: declaration of 'div' shadows a global declaration /usr/local/gnu/include/libguile/stime.h:55: warning: declaration of 'time' shadows a global declaration /usr/include/iso/time_iso.h:91: warning: shadowed declaration is here /usr/local/gnu/include/libguile/stime.h:56: warning: declaration of 'time' shadows a global declaration /usr/include/iso/time_iso.h:91: warning: shadowed declaration is here /usr/local/gnu/include/libguile/stime.h:60: warning: declaration of 'stime' shadows a global declaration These are all due to argument names in prototype declarations. Please suffix the names with _arg or something. Meanwhile, compilations will choke with -Wshadow. /usr/local/gnu/include/libguile/gsubr.h:65: warning: function declaration isn't a prototype /usr/local/gnu/include/libguile/gsubr.h:68: warning: function declaration isn't a prototype /usr/local/gnu/include/libguile/gsubr.h:70: warning: function declaration isn't a prototype /usr/local/gnu/include/libguile/gsubr.h:73: warning: function declaration isn't a prototype /usr/local/gnu/include/libguile/gsubr.h:81: warning: function declaration isn't a prototype /usr/local/gnu/include/libguile/gsubr.h:86: warning: function declaration isn't a prototype Here, the complaint is about stuff like this: extern SCM scm_c_make_gsubr (const char *name, int req, int opt, int rst, SCM (*fcn) ()); where fcn does not look like a prototype. It needs (void) as the argument list. Better is to: typedef SCM (scm_gsubr_callout_t) __P((void)); and use scm_gsubr_callout_t * in the argument list. This works with KR, by the way. Thanks - Bruce ___ Guile-devel mailing list Guile-devel@gnu.org http://lists.gnu.org/mailman/listinfo/guile-devel
Re: SCM_STRING_CHARS is deprecated. See the manual for alternatives.
Neil Jerram wrote: Bruce Korb [EMAIL PROTECTED] writes: Here's the deal: I just want access to the array of characters. OK, for this you should use scm_to_locale_string(). Which allocates and copies, leaving the free() to me. At least I get what I have to have. I did not find it 'cuz I was looking for scm_c_* procedures. *sigh*. I already made a release using scm_i_string_chars(), though, since I stumbled across it investigating how SCM_CHARS(), er, I mean SCM_STRING_CHARS() works. I am sure you don't like that, but in the end scm_to_locale_string() did not pop out and I needed to use something. I've put macro wrappers around every single Guile function and versioned them all, based on Guile version. It changes too much. I still wish you would add scm_c_eval_string_from_file_line(). That interface is stable, but the guts are ifdef-ed based on Guile version. But please note that the main reason for the new API is the need to handle character encoding, in particular future Unicode support. See the Conversion to/from C node in the manual for a bit more on this. In my particular open source app, I mostly deal with byte arrays terminated with a NUL byte. I am a little unclear on the implied intent, after reading that section. I certainly hope it is not your intention to change Guile to try to understand the contents of these byte arrays. Instead, I would expect and hope that you would create a new family of functions that might, say, contain the word unicode to imply that they work with unicode strings instead of byte strings. So, I will use string functions to work with NUL terminated arrays of bytes, and stringn functions to work with known-length, unterminated arrays of bytes. I will switch to unicode functions where appropriate and when available. Please do not do that under the covers. Thank you. Regards, Bruce ___ Guile-devel mailing list Guile-devel@gnu.org http://lists.gnu.org/mailman/listinfo/guile-devel
Re: 1.8 status
On 8/10/06, Greg Troxel [EMAIL PROTECTED] wrote: Here's the list of programs that use guile (1.6) in pkgsrc. ./cad/libgeda ./databases/guile-pg ./devel/autogen Does any know of any problems with any of them with 1.8? I am trying to iron out deprecated constructs in autogen. The latest release or two should work fine, other than the deprecated warnings: #if GUILE_VERSION = 107000 if (getenv( GUILE_WARN_DEPRECATED ) == NULL) putenv( (char*)(void*)GUILE_WARN_DEPRECATED=no ); #endif ___ Guile-devel mailing list Guile-devel@gnu.org http://lists.gnu.org/mailman/listinfo/guile-devel
Re: Fwd: Emacs-like file buffers
Jason Meade wrote: Is there a standard for regular expressions somewhere? a standard? No. are standards? Yes. Many. Naturally, that is the problem. It seems like most implements (from grep through tcl, perl, and beyond) seem to agree on simple stuff like ^[a-c]?002*[^b]+$ etc... (not all understand ? and + I've noticed) but very few seem to share an affinity for \w or \ ... \ etcetera. I don't use regular expressions (outside of grep) everyday, but when I do use them, it's usually for some serious pattern matching, with variable capture (via $1, or \#1 etc). I'm starting to incorporate search-forward and search-backwards into my filebuffer lib. For that kind of work, even strchr will work (sorta. binary data is a problem). However, eventually I'll want to be able to regex my buffers, and once I add the guile hooks, it would be nice to share the same regex syntax with everyone else. After all, the last thing you want is to load a module, only to find that it's not syntax compatible with the rest of the language! The most comprehensible and still useful thing would be to provide a regcomp funtion that had a usable implementation of the REG_BASIC flag and, perhaps, added such tweaks as REG_PERL et al. The reason I said, usable implementation is because in my implementation of regexec(3C), REG_BASIC is not defined so there is no way to tell the regex compiler that I want a basic re. SO, into the guile.h family of headers, add: #ifndef REG_BASIC # define GUILE_REG_BASIC 0x1 #else # define GUILE_REG_BASIC REG_BASIC #endif then overload make-regexp and regexp-exec to cope with this and I'd-rather-use-Perl-syntax flags. Or even a I-want-fnmatch- style-globbing match flag. It brings all the pattern matching stuff together making it findable (very important in a huge interface) and relatively easy to use (i.e. remember). :) That's my nickel. Cheers - Bruce P.S. one thing missing from the ice-9 regex functions seems to be a way to pass such flags through to the implementing libguile functions. Perhaps I just missed how to do it? (define (string-match pattern str . args) (let ((rx (make-regexp pattern)) (start (if (pair? args) (car args) 0))) (regexp-exec rx str start))) ___ Guile-devel mailing list Guile-devel@gnu.org http://lists.gnu.org/mailman/listinfo/guile-devel
Re: [ntp:hackers/Guile devel] ntp-dev changes
Reg Clemens wrote: Humm. Linux Fedora4 came with gcc 4.00 and was upgraded to 4.0.2 as some point, so I dont easily have access to an older version on my home machines. Checking at the Lab, where I still have Fedora2 loaded, I find gcc 3.3.3, and guile-1.6.7 DOES compile there. Still, the error reported sounds more like something has changed between OS levels than a problem with the compiler itself. I can try moving the compiled version back home, but from what Harlan says, I wont be able to test it for a week or so. Chasing through Guile sources, I get this: #ifdef DYNAMIC_LINKING /* libtool automagically inserts this variable into your executable... */ extern const scm_lt_dlsymlist lt_preloaded_symbols[]; // Line 91 scm_lt_dlpreload_default (lt_preloaded_symbols); #endif The message is: guile.c: In function 'main': guile.c:91: error: array type has incomplete element type guile.c:91: warning: unused variable 'lt_preloaded_symbols' So, it seems to me that there is an inconsistency in the build environment and the defining of DYNAMIC_LINKING. The problem is almost certainly in Guile. But, I have heard complaints (that I only fuzzily remember) that Guile does not build with GCC-4. Assuming I am remembering correctly :) , the headers that GCC-4 bring along with itself are causing scm_lt_dlsymlist to be an incomplete type and scm_lt_dlpreload_default to be a macro that expands to the empty string (unreferenced variable). I'll poke into this a bit more, but I do wish a Guile developer could chime in with a word or two. Thanks - Bruce ___ Guile-devel mailing list Guile-devel@gnu.org http://lists.gnu.org/mailman/listinfo/guile-devel
Re: [ntp:hackers/Guile devel] ntp-dev changes
Rob Browning wrote:
Bruce Korb [EMAIL PROTECTED] writes:
Guile folks, please, how is this supposed to work? The guile.c
module needs to see all three of these code fragments to compile
correctly. Anyway, for me it builds with GCC 3.x and fails with
4.x, but looks like it should fail no matter what the compiler. What
gives?
I think this may have been fixed in 1.6 CVS. If so, the 1.6.8-rc1
test archive that I recently announced should contain the changes.
I haven't pulled CVS, but if this crucial fix is simply:
$ diff -u $(find guile-1.6.7 guile-1.6.7-build -name guile.c)
--- guile-1.6.7/libguile/guile.c2002-12-07 14:41:32.0 -0800
+++ guile-1.6.7-build/libguile/guile.c 2006-04-16 09:48:21.402050194 -0700
@@ -88,8 +88,8 @@
{
#ifdef DYNAMIC_LINKING
/* libtool automagically inserts this variable into your executable... */
- extern const scm_lt_dlsymlist lt_preloaded_symbols[];
- scm_lt_dlpreload_default (lt_preloaded_symbols);
+ extern const int lt_preloaded_symbols;
+ scm_lt_dlpreload_default ((scm_lt_dlsymlist*)lt_preloaded_symbols);
#endif
scm_boot_guile (argc, argv, inner_main, 0);
return 0; /* never reached */
then it would be really nice to bump out a 1.6 1.8 patch asap
and include any other more destabilizing fixes in a later patch.
Thanks - Bruce
___
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel
Re: [ntp:hackers/Guile devel] ntp-dev changes
Hi Harlan, Reg, NTP developers (via relay) Guile developers: This is a problem. I (almost) only ever use pre-built Guile packages and let others struggle with the porting issue. Occasionally, I do build it just to verify that current versions haven't wiggled too much for AutoGen to operate, but otherwise, no. So, Reg, can you please tell us all the platform and compiler you used that triggered the Guile build failure? Thank you. Regards, Bruce Harlan Stenn wrote: Subject: Re: [ntp:hackers] ntp-dev changes From: Reg Clemens [EMAIL PROTECTED] Date: Thu, 13 Apr 2006 11:57:48 -0600 To: Harlan Stenn [EMAIL PROTECTED] Autogen will not be required until next week, as I'm not going to be adding the AutoGen stuff until after 4.2.2 is out (4.2.1 is now being called 4.2.2 as the last number is now 'even' for 'stable' releases). It's a GNU tool, so any GNU archive should have it. Bruce Korb is the author, and he is (kindly) working with me on this project as we're doing some new things with it. Just a quick note, Ive got to take a shower and get down to the lab. But, pulled autogen from www.gnu.org, tried compiling it. It wanted libguile, which I also dont have. I pulled guile-1.6.7 from the same place, that seemed to be what I wanted. It died during the build with guile.c:91: error: array type has incomplete element type Ill look at that when I get home this evening, but this could cause folks to be unhappy with the change... P.S. Reg, it should be possible to Google around and find a pre-built Guile package for your platform. AutoGen has been jiggered and re-jiggered to work with Guile 1.4.7(?) through 1.8 (latest AutoGen only). BTW, AutoGen should only be required for constructing a distribution, and not required for building the distribution itself. It is a development tool. ___ Guile-devel mailing list Guile-devel@gnu.org http://lists.gnu.org/mailman/listinfo/guile-devel
Re: [ntp:hackers/Guile devel] ntp-dev changes
Someone, please correct me if I am wrong, but I think GCC-4 is still too green for industrial use. Have you a GCC-3.x handy? Reg Clemens wrote: Hi Harlan, Reg, NTP developers (via relay) Guile developers: This is a problem. I (almost) only ever use pre-built Guile packages and let others struggle with the porting issue. Occasionally, I do build it just to verify that current versions haven't wiggled too much for AutoGen to operate, but otherwise, no. So, Reg, can you please tell us all the platform and compiler you used that triggered the Guile build failure? I tried building guile-1.6.7 from the gnu site. Not knowing anything about the options available, I did a straight ./configure make The configure runs with no errors, but the make terminates with --- guile.c: In function 'main': guile.c:91: error: array type has incomplete element type guile.c:91: warning: unused variable 'lt_preloaded_symbols' make[2]: *** [guile.o] Error 1 make[2]: Leaving directory `/mnt/home/reg/Source/System/Autogen/guile-1.6.7/libguile' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/mnt/home/reg/Source/System/Autogen/guile-1.6.7' make: *** [all] Error 2 --- This is on Linux Fedora4, with gcc-4.0.2-8.fc4 am I missing something? I looked arround, and didnt see a prebuilt package anywhere. I Googled for ``guile package|rpm redhat|fedora''. You have to look around a bit: http://ccrma.stanford.edu/planetccrma/software/redupdates.html http://dir.filewatcher.com/d/Fedora/i386/Development/Languages/guile-1.6.4-14.i386.rpm.763778.html ___ Guile-devel mailing list Guile-devel@gnu.org http://lists.gnu.org/mailman/listinfo/guile-devel
Re: What's the matter?
On Monday 05 December 2005 02:27 pm, you wrote:
Bruce Korb [EMAIL PROTECTED] writes:
In particular, using scm_makstr(_s, _ch) causes faults,
Looks like it ought to be ok. Post a failing example to guile-devel
if you like.
Hi Kevin,
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. Anyway, to be safer, I have removed
all use of SCM_CHARS and that made scm_makstr unusable so I am using a
new approach. I do not use scm_makstr anymore.
Since it takes a *LOT* of work to get autogen-5.7.2 to run under
Guile 1.7.x, I don't think it worth the bother to try to use that
as an example. If someone were to say, I will work on the issue,
then I'll hack my autogen-5.8preXXX to use that function once again.
And fail. Otherwise, lets forget it.
Thanks for your help. Regards, Bruce
Bruce Korb [EMAIL PROTECTED] writes:
I should be getting stack traces on Scheme errors. I'm not.
(And, yes, I invoke either ``(backtrace)'' or ``scm_backtrace()''
when a failure is detected.)
I think I've been having trouble with backtraces not appearing too
(just from plain scheme code) but I didn't know where to look for
what's wrong.
Me, either. I did a bunch of grepping into the 1.4.1 and 1.6.7 source,
but nothing jumped out as the way it was accomplished. Black magic? :)
In the end, I've altered my test thus:
cat ${testname}.samp6 EOF
${testname}.tpl6:7:4: In expression (stumble-over-unbound-variable):
${testname}.tpl6:7:4: Unbound variable: stumble-over-unbound-variable
Scheme evaluation error. AutoGen ABEND-ing in template
error.tpl6 on line 3
EOF
if test ${GUILE_VERSION} -gt 107000
then
echo WARNING: Guile 1.7.x cannot display error line numbers 2
exec 3 ${testname}.samp6-tmp
echo 'ERROR: Unbound variable: stumble-over-unbound-variable' 3
sed 1,2d ${testname}.samp6 3
exec 3-
mv -f ${testname}.samp6-tmp ${testname}.samp6
fi
___
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel
Progress in porting to 1.7, but still work to do
I have *two* problems. First, after emitting the error text below,
Guile 1.7.2 is calling, exit(0) not exit(EXIT_FAILURE).
That's wrong. Additionally, I am not getting the file/line
stuff using the code I thought we worked out.
--- error.out6 Sun Dec 4 13:41:27 2005
***
*** 1,5
! error.tpl6:7:4: In expression (stumble-over-unbound-variable):
! error.tpl6:7:4: Unbound variable: stumble-over-unbound-variable
Scheme evaluation error. AutoGen ABEND-ing in template
error.tpl6 on line 3
Failing Guile command: = = = = =
--- 1,4
! ERROR: Unbound variable: stumble-over-unbound-variable
Scheme evaluation error. AutoGen ABEND-ing in template
error.tpl6 on line 3
Failing Guile command: = = = = =
+ exit 1
Wasn't this supposed to work?
SCM port = scm_open_input_string( scm_from_locale_string( pzExpr ));
{
static SCM file = SCM_UNDEFINED;
static char* pzOldFile = NULL;
if ((pzOldFile == NULL) || (strcmp( pzOldFile, pzFile ) != 0)) {
if (pzOldFile != NULL)
free( pzOldFile );
pzOldFile = strdup( pzFile );
}
file = scm_from_locale_string( pzFile );
scm_set_port_filename_x( port, file );
}
{
SCM ln = scm_from_int( line );
scm_set_port_line_x( port, ln );
}
{
SCM ans = SCM_UNSPECIFIED;
/* Read expressions from that port; ignore the values. */
for (;;) {
SCM form = scm_read( port );
if (SCM_EOF_OBJECT_P( form ))
break;
ans = scm_primitive_eval_x( form );
}
return ans;
}
___
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel
Re: No way out.
On Wednesday 30 November 2005 04:44 pm, Kevin Ryde wrote:
Collateral damage from the change to scm_inexact_p (other message).
Not sure how one or both ought to work.
All *_p functions ought to accept anything without throwing an error.
Even if it doesn't seem to make sense. That way, I know I don't have
to validate before calling a validation routine. :-}
Anyway, *real bugs* in Guile 1.7.2 are:
1. When an error is thrown, exit should be called with EXIT_FAILURE, not 0.
2. After these commands:
(use-modules (ice-9 stack-catch))
(debug-enable 'backtrace)
I should be getting stack traces on Scheme errors. I'm not.
(And, yes, I invoke either ``(backtrace)'' or ``scm_backtrace()''
when a failure is detected.)
3. Either of these two implementations:
port = scm_open_input_string( AG_SCM_STR02SCM( pzExpr ));
#if GUILE_VERSION 107000
{
static SCM file = SCM_UNDEFINED;
static char* pzFl = NULL;
scm_t_port* pt;
if ( (pzFl == NULL)
|| (strcmp( AG_SCM_CHARS( file ), pzFile ) != 0) ) {
if (pzFl != NULL)
free(pzFl);
pzFl = strdup( pzFile );
file = AG_SCM_STR02SCM( pzFile );
}
pt = SCM_PTAB_ENTRY(port);
pt-line_number = line - 1;
pt-file_name = file;
}
#else
{
static SCM file = SCM_UNDEFINED;
static char* pzOldFile = NULL;
if ((pzOldFile == NULL) || (strcmp( pzOldFile, pzFile ) != 0)) {
if (pzOldFile != NULL)
free( pzOldFile );
pzOldFile = strdup( pzFile );
file = scm_from_locale_string( pzFile );
}
scm_set_port_filename_x( port, file );
}
{
SCM ln = scm_from_int( line );
scm_set_port_line_x( port, ln );
}
#endif
should be enabling file and line numbers in errors. I've tried both methods
with 1.7 (and some others suggested in the discussion), to no avail. I can
get file and line information for 1.6.7 and earlier *only*. There seems to
be no way to do it in 1.7.
Thanks for your help! Regards, Bruce
___
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel
Re: Guile 1.6.7 on HP/UX
On Sunday 12 June 2005 11:13 am, Bruce Korb wrote: HP/UX: guile never finishes generating guile.texi. I solved it by copying it + guile-procedures.texi from the Solaris build. I am still building, so I don't know what else I'll encounter. Well, the other issue I encounter is that guile-config invokes that guile program which will never exit. libguile works just fine, but the convoluted guile-config script won't exit and is a bit on the painful side to figure out. Have you-all a pkg-config file that can be installed? That would make life easier Thanks! Regards, Bruce ___ Guile-devel mailing list Guile-devel@gnu.org http://lists.gnu.org/mailman/listinfo/guile-devel
Re: 1+ and 1- in C
On Sunday 10 April 2005 03:17 pm, Kevin Ryde wrote: I propose to do 1+ and 1- in C so they're as fast as plain + and -. Calling scm_sum and scm_difference will still get goops/generics dispatch the same as the scheme code, if I'm not mistaken. Shouldn't the name for the subtraction code be ``less one'' or the alias be ``-1+'' or some such? You are decrementing, yes? ___ Guile-devel mailing list Guile-devel@gnu.org http://lists.gnu.org/mailman/listinfo/guile-devel
Re: Should we distribute libltdl?
Hi Marius, I think this is more a question for libtool folks. My opinion: the more impediments to installation that there are results in more folks deciding that it isn't worth the bother. I really hate downloading a package only to find that there's a bunch of other stuff to find, download and install first. Regards, Bruce On Monday 07 March 2005 05:09 pm, Marius Vollmer wrote: Hi, we currently distribute a copy of libltdl as part of guile-core and install it when libltdl is not already found in the system. I think this is wrong since libltdl belongs to libtool and should be installed by libtool and not by any number of programs that use it. We do not distribute libgmp although we rely on it and we shouldn't distribute libltdl although we rely on it. I had the concrete problem that I couldn't do a make distcheck without prior make install on a system where in fact libltdl was not available. But even if this is due to some bugs in the way that we use libltdl, I think we should just treat libltdl as any other external library. It makes installing Guile slightly harder, but the behavior of Guile is in fact simpler. Opinions? (I have committed the removal of libltdl already.) ___ Guile-devel mailing list Guile-devel@gnu.org http://lists.gnu.org/mailman/listinfo/guile-devel
