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 t

Re: Why is Guile unable to find libtool?

How? I'm sure it is somewhere under /usr but not /usr/local, but now it _is_ under /usr/local 'cuz I did a source install. I'd rather dump that one so I'm not on the hook to update it all the time. On Thu, Jul 26, 2018 at 5:04 PM Brett Gilio wrote: > > > Bruce Korb

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.

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 ent

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.

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 -

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 addit

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 l

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

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

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()

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 > > for details.

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

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.

[PATCH] do not augment environment

>From b7a04164b9de62fe1e80f061f926c9255c84e710 Mon Sep 17 00:00:00 2001 From: Bruce Korb 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_P

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

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 o

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 h

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

bdwgc

I cannot build Guile for OS/X without first building package after package after package after package. It goes on nearly forever. After going through 3 successful library builds and installs and 3 build tool builds and installs, I hit this bdwgc wall: $ for t in autoconf automake libtool;do $t -

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_f

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. th

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

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/b

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 p

Re: Program received signal SIGSEGV, Segmentation fault.

On 11/16/12 11:19, Mark H Weaver wrote: > Hi Bruce, > > Bruce Korb 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

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) >

Re: Program received signal SIGSEGV, Segmentation fault.

On 11/16/12 13:23, Mark H Weaver wrote: >> Actually, it was scm_from_utf8_string, since GUILE_VERSION was 25 > > Okay, that's the problem. You told Guile that the C string was encoded > in UTF-8, but actually it was encoded in Latin-1: OK, so I tried latin1, too. (replacing scm_from_utf3_st

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

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 m

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

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 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 rea

Re: There is no returning

On 11/10/13 00:13, Harlan Stenn wrote: Bruce, I'm seeing build errors on psp-fb1 with the guile headers as well, and autogen-5.18.2. Errors like this: /usr/bin/gcc-4.6 -std=gnu99 -DHAVE_CONFIG_H -I. -I.. -I.. -I../autoopts \ -g -O2 -MT autogen-ag.o -MD -MP -MF .deps/autogen-ag.Tpo -c -o

Re: There is no returning

On 11/10/13 12:41, Paul Eggert wrote: A better solution, if you want to be portable to MSVC, is to use _Noreturn instead of noreturn. This is for reasons described in stdnoreturn.in.h. '_Noreturn' is a bit ugly; if you don't care about MSVC, then __attribute__((__noreturn__)) is a good way to go

Re: There is no returning

On 11/10/13 12:25, Bruce Korb wrote: headers. So rather than unwinding "noreturn" attributes for functions that do not return, I'll hack up some really ugly stuff: That almost works -- I have to make my own copy of libguile.h, too, to trick the compiler into seeing my __scm.h

Re: There is no returning

On 11/13/13 23:52, Mark H Weaver wrote: '_Noreturn' is a bit ugly; if you don't care about MSVC, then __attribute__((__noreturn__)) is a good way to go. Hi Paul, Thanks. As mentioned in the GCC pages, using the prefix/suffix of "__" is the right way to go -- for Guile. FYI, I recently made

Re: There is no returning

On 11/14/13 16:46, Paul Eggert wrote: Yes, that sounds right. If user code employs SCM_NORETURN in that position and you therefore you can't change SCM_NORETURN to mean _Noreturn, it might be simpler to keep SCM_NORETURN the way it is for backwards compatibility. But you can change all its use

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" i

[Fwd: autogen 5.9.8 doesn't build on IA64] -- libguile conflict

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: Inv

Re: [Fwd: autogen 5.9.8 doesn't build on IA64] -- libguile conflict

On Tue, Jul 14, 2009 at 12:29 AM, Neil Jerram wrote: > Bruce Korb 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&q

imported module (srfi srfi-60) overrides core binding

Hi, I am getting this error message: WARNING: (guile-user): imported module (srfi srfi-60) overrides core binding `bit-count' What is this trying to say? I just need the arithmetic-shift function. Thank you.

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 [[

Re: gen-scmconfig is broken

Hi Ludovic, On Tue, Sep 7, 2010 at 3:19 PM, Ludovic Courtès 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’

Re: How does one specify linking to 64 bit libraries when there is a choice?

Hi Nelson, On Fri, Dec 17, 2010 at 9:09 AM, Nelson H. F. Beebe wrote: > The recent exchanges about the /usr/local/lib vs /usr/local/lib64 > problem with libtool + autogen + guile gave me a critical clue.  I > examined all of the /usr/local/lib64/*.la files, and found dozens that > mention (incorr

Re: How does one specify linking to 64 bit libraries when there is a choice?

Hi Nelson, I am nearly certain we (you) have reached a point where libtool folks are going to say, "it is Guile", and Guile folks are going to say, "it is libtool". I am going to say, "I'd like some help from either or both". Because the guile-config invokes the guile binary in order to print ou

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

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 di

Re: Obsoleted Guile interfaces

ved 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 writes: > Which interfaces spe

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 te

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 directori

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' ;

One config issue solved, only to trip over another.

I was trying to build Guile 2.0, but I stubbed my toe on "Oh, you haven't installed libunistring". So, I found one and installed it: checking for LIBFFI... configure: error: Package requirements (libffi) were not met: No package 'libffi' found Consider adjusting the PKG_CONFIG_PATH environmen

Re: One config issue solved, only to trip over another.

Thanks, Mike, but: On Mon, Feb 28, 2011 at 10:43 AM, Mike Gran 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 f

Re: One config issue solved, only to trip over another.

Hi, On Mon, Feb 28, 2011 at 11:25 AM, Noah Lavine 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 > - libun

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 longe

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-s

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

Re: When was scm_sizet deprecated?

On 05/31/11 11:42, Andy Wingo wrote: On Tue 31 May 2011 17:41, Bruce Korb 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

What's wrong with this?

My "(get ...)" function always returns a string. This result was assigned to "tmp-text" and the "(string-upcase ...)" is complaining that the input is read only. Well, it isn't, so the real complaint is being hidden by the "string is read-only" message. It worked until I "upgraded" to openSuSE

Re: Guile: What's wrong with this?

Hi Mike, Thank you for the explanation. However: On 01/03/12 07:03, Mike Gran wrote: It worked until I "upgraded" to openSuSE 12.1. $ guile --version guile (GNU Guile) 2.0.2 . (set! tmp-text (get "act-text")) (set! TMP-text (string-upcase tmp-text)) >>> ERROR: In pr

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' a

Re: Guile: What's wrong with this?

On 01/03/12 15:33, Ludovic Courtès wrote: Could you point me to the affected code? What would you think of using string-copy as I suggested? The disadvantage is that you need to modify your code, but hopefully that can be automated with a sed script or so; the advantage is that it would work wi

Re: Guile: What's wrong with this?

On 01/04/12 04:19, Ian Price wrote: ... As for mutable strings, I consider them a mistake to begin with,... Let's step back and consider the whole point of Guile in the first place. My understanding is that one primary purpose is to be a facilitation language so that application developers ha

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 mutabl

Re: bytevector -- was: Guile: What's wrong with this?

Hi, On 01/03/12 19:12, Noah Lavine wrote: Then it turned out that the string functions would now clear the high order bit on strings, so they are no longer byte arrays and there is no replacement but to roll my own. I stopped supporting byte arrays. A noticable nuisance. This is just a side

Re: Guile: What's wrong with this?

On 01/04/12 10:26, Ian Price wrote: 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. There's an old saying, "Ignorance of the law is no excuse". If I wrote C code that doesn't conform to the C standard

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

Re: Guile: What's wrong with this?

On 01/04/12 12:56, Andy Wingo wrote: On Wed 04 Jan 2012 15:08, Bruce Korb writes: 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 correc

Re: Guile: What's wrong with this?

On 01/04/12 13:52, Ian Price wrote: So my main question is: Which is the higher priority, language purity or ease of use? That is a loaded question, as it presupposes ease of use is always the same thing as impurity e.g. ... Absolutely not. Making decisions is always about trade-offs, oth

Re: Guile: What's wrong with this?

Hi Ludo, On 01/04/12 13:17, Ludovic Courtès wrote: If the users files are evaluated rather than compiled/loaded, this is not a problem: I do *all* guile processing via the ag_scm_c_eval_string_from_file_line function. I suck up a string from my input file, determine that it needs guile proces

Re: Guile: What's wrong with this?

On 01/04/12 15:19, Mark H Weaver wrote: Bruce Korb writes: ERROR: In procedure string-upcase: ERROR: string is read-only: "" Scheme evaluation error. AutoGen ABEND-ing in template confmacs.tlib on line 209 Failing Guile command: = = = = = (set! tmp-text (get

Re: Guile: What's wrong with this?

On 01/04/12 15:59, Mark H Weaver wrote: Implementing copy-on-write transparently without the user explicitly making a copy (that is postponed) is _impossible_. The problem is that although we could make a new copy of the string, we have no way to know which pointers to the old object should be c

Re: non-reproduction of initial issue -- was: Guile: What's wrong with this?

On 01/04/12 16:01, Ludovic Courtès wrote: BTW, were you able to find a stripped-down example that reproduces the ‘string-upcase’ problem? Here's the stripped down example, but it does not reproduce the problem. :( I didn't copy into it my variation on scm_c_eval_string, but I hope that isn't t

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 look

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

Re: Guile BUG: What's wrong with this?

On 01/06/12 14:23, Bruce Korb wrote: Since I'm dead in the water, I've patched the 2.0.3 source: $ diff -u srfi-13.c~ srfi-13.c --- srfi-13.c~ 2011-07-06 15:50:00.0 -0700 +++ srfi-13.c 2012-01-06 15:26:44.963324773 -0800 @@ -2088,6 +2088,8 @@ string_upcase_x (SCM v, si

Re: Guile BUG: What's wrong with this?

On 01/06/12 15:11, Mark H Weaver wrote: Bruce Korb writes: scm_from_locale_stringn() makes an optimization when the length is zero. It returns an immutable string of length zero. Good catch! Two possible fixes: 1. remove the "optimization" 2. check the length in scm_string_upcas

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 a

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, e

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.

Re: Guile BUG: What's wrong with this?

On 01/09/12 07:41, Mark H Weaver wrote: Yes. All of them. All four. For the record, there were 7 string mutation functions to fix :-P I guess my cscope search was not exhaustive enough. Thanks! We are talking 2.0.4, yes? When might that be? :) Regards, Bruce

Re: Guile BUG: What's wrong with this?

On 01/09/12 10:32, Andy Wingo wrote: On Mon 09 Jan 2012 18:27, Bruce Korb writes: We are talking 2.0.4, yes? When might that be? :) A week? :) Wonderful! I just wanted reassurance it wasn't months. My own round tuits for hobby time things are often measured in months. :(

Re: A plea for local-eval in 2.0.4

On 01/12/12 13:43, Mark H Weaver wrote: I worked very hard to produce a simple and maintainable implementation of `local-eval' in time for 2.0.4, so that we might rectify this unfortunate Lilypond unhappiness. It would be a shame if that work were wasted. Just for the record, I'm okay with tak

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/loc

Re: unknown location: definition in expression context in subform optname-from of "_^"

On 01/25/12 20:22, Mike Gran wrote: From: Bruce Korb 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 Gui

Re: unknown location: definition in expression context in subform optname-from of "_^"

Hi Mike, On Thu, Jan 26, 2012 at 1:21 PM, Mike Gran wrote: >>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! > > Sorry.  Maybe Andy and Ludo have a better a

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 r

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" w

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); }

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 th

Re: unknown location: definition in expression context in subform optname-from of "_^"

le complaints then!! > Scheme evaluation error.  AutoGen ABEND-ing in template>         > /old-home/ROOT/usr/local/share/autogen/aginfo.tpl on line 163 > Bruce Korb writes: > > I need to be able to locate a guile scheme expression in my ASCII > > text input and hand i

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 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

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 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 introduc

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

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

(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.

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" "(r

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 h

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

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 i

  1   2   >