Jonas Hahnfeld writes:
> On Thu, 2025-03-20 at 09:21 -0700, Mike Gran wrote:
>> "Dr. Arne Babenhauserheide" writes:
>> > Did you manage to move forward with the patches?
>>
>> That CI/CD is running my old Guile patchset. So now I'm actually ready
Jonas Hahnfeld writes:
> On Sun, 2025-03-30 at 23:08 -0700, Mike Gran wrote:
>> Mike Gran writes:
>>
>> I've created a new branch in the main Guile repo on savannah called
>> wip-guile-2025, pulling in enough of various patchsets to get `make` and
>> `
Mike Gran writes:
> I'm making progress. I just pushed back into Guile's main branch a
> patchset that makes the 32-bit MinGW build again, which was broken. The
> 32-bit build is now working on my native MinGW on Windows 11, and I'll
> know today if it wor
w I'm actually ready
to replace my Guile patchset with mainline Guile and then the Lilypond
patches, so I can soon actually answer the original question of if these
Lilypond patches are good to go.
It has taken me a bit longer than I thought to get all this stood up,
because day job is quite busy. Apologies.
Regards,
Mike Gran
s, I would first have
> to
> make sure it still works with main.
Don't worry about rebasing for now. I'd just like to see what you have
working already in whatever form it is currently. My hope is that we can
prefer your patches, and then I can tweak around them for any problems
that remain.
Regards,
Mike Gran
e these patches along
with my own patchset to complete this work.
Regards,
Mike Gran
bit MSVCRT version has a name of the form mingw-w64-i686-gmp.
And there are
several others. Just gotta make sure your libraries all have the same basic
type; you can't mix and match.
Regards,
Mike Gran
#x27;ve spun up build actions for
- Ubuntu
- Ubuntu Distcheck
- Cygwin
- Cygwin Distcheck
- Msys
- MinGW
- MacOS
Regards,
Mike Gran
we're talking about in this e-mail
chain, or is there a PR elsewhere?
Regards,
Mike Gran
On Sunday, July 7, 2024 at 08:58:34 AM PDT, Eli Zaretskii wrote:
>> I don't think it's worth it. If anybody's going to work on this problem,
>> I'd recommend simply adding APIs like program-arguments-bytevector,
>> getenv-bytevector and the like, returning raw bytevectors instead of strings,
>> a
> A benefit of SRFI-64 is that the SRFI-64 implementation has tests
> whereas (IIRC) Guile's custom thing doesn't.
OK two separate issues.
1. Mike G's gripes about SRFI-64.
2. Updating over 65,000 lines of test code
I don't want to be put in the position of having to make a critique of
SRFI-64,
> Hi,
> Would a rewrite of the Guile tests using SRFI-64 be a welcome idea?
> IMO the advantages of doing so are:
...
>Opinions?
IMHO, I think Guile should not depend too heavily on Guile for testing itself.
It is bad bootstrapping practice.
And personally, I find that errors in srfi-64 tests
Daniel-
>> How do you actually close a bug?
> An email to -done @ debbugs.gnu.org will close the bug. This is
> explained in https://elpa.gnu.org/packages/doc/debbugs-ug.html
Oh, there's an emacs mode for debbugs. Sounds useful. I'll check it out.
That doc doesn't seem to explain that sendi
Hi,
I was looking at https://debbugs.gnu.org/db/pa/lguile.html
and saw that 10519 (add mini-gmp) should be closed.
How do you actually close a bug?
Thanks,
Mike Gran
Hey Guile-
So I'm still plugging away at this Guile on Windows stuff.
In a tree on Github [1], I started from the top and cleaned up
the 64-bit Cygwin and MSYS problems. Cygwin and MSYS
are two related projects where you compile with GCC,
with the newlib C library, and a link to a library that
p
demonstrate current best practice.
Also, I have some doubt that users are looking at that code
for inspiration, rather than what online sources provide.
It uses "make installcheck", which is uncommon.
Regards,
Mike Gran
interactions, or like in independent medical
> issues that happened at the same time as working on Guile/Guix stuff?
>I don't need to know per se but this footnote is ambiguous.
Oh sorry, I didn't imagine it could be read that way. Medically ill.
I recommend against getting old, if you can avoid it.
Regards,
Mike Gran
On Tuesday, June 6, 2023 at 02:10:25 PM PDT, Thompson, David
wrote:
...
>> Janneke has also poked at Windows support a few times as well, and
>> he actually got it to run on 64-bit Windows.
>Did JIT work? When I tried this years ago it didn't. Would be a major
>victory if it works now.
There
o quickly.
Also, it might be that this isn't worth doing. After all, you can run
Guile on Cygwin and Guix on WSL on Windows 10/11 already.
But some projects that depend on Guile do deliver on
Windows using customized versions of 2.2 or 1.8.
Let me know what you think.
-Mike Gran
[1]
On Thu, Sep 15, 2022 at 10:20:26PM -0700, Mike Gran wrote:
> Hello Guile Devel,
>
> I pushed a git branch: wip-modernize-autotools.
>
> It removes some obsolete tests by presuming we at least have a
> C89-compliant C library. It also uses LT_INIT for libtool, and removes
ed that it
compiles.)
Let me know what you think.
Thanks,
Mike Gran
Hello Guile-
By convention, DLLs in cygwin start with 'cyg' instead of 'lib' to avoid name
clashing.
In an autotools build like Guile, dlls are build as 'cyg'
Now that we've dumped libltdl, we don't automatically search for both 'lib' and
'cyg' on cygwin.
Should we emulate this in foreign-library
e reply to this e-
mail so I can gauge the feasibility of some sort of participation swag.
Regards,
Mike Gran, on behalf of the Guile team
l send a reworked patch for you to consider.
Regards,
Mike Gran
.
Regards,
Mike Gran
ke it
easier to submit patches. We need to make it easier to incorporate
patches.
Some projects (like Pixman) have a rule that if a patch receives no
opposition after a few weeks and a couple of pings, you are free to
push it. I wonder if that would work here? Or would it be too
chaotic?
My two cents,
Mike Gran
On Tue, Nov 20, 2018 at 06:16:32PM +0100, Christoph Buck wrote:
> Mike Gran writes:
>
> > Hey Chris,
> >
> > This is one of two errors. One problem is that Guile makes assumptions
> > about the size of long vs the size of a pointer, as do some the
> > l
On Wed, Sep 05, 2018 at 07:07:11PM -0300, David Pirotte wrote:
>
> If I were you, I'd try to run and use sbank:
>
>https://github.com/rotty/sbank.git
>
> [ even though itis a bit old and will need some love, it's retty well
> [ written and is in schee already ...
>
> t needs
such project ready for use?
If nothing is happening on that front, I would like to put some time
into it.
Regards,
Mike Gran
ted in interesting ways.
I went ahead and threw that up on the libreplanet wiki for now
Regards,
Mike Gran
ad a goal of making
something as simple to use as the Twine interactive fiction engine. I
posted that on the wiki for now.
-Mike Gran
> UTF-8-encoded ELF symbols may be more of a problem. How could NULs in
> symbols be handled?
You could re-map NUL to one of the PUA characters, perhaps. It seems unlikely
that ELF symbols should ever contain private use characters.
-Mike
> From: Stjepan Horvat
>ls /usr/share/guile/site
>colorized.scm shell.scm src.scm
I guess they probably should have been put in
/usr/share/guile/site/nala/
-Mike
>> I discovered that 'scm_unget_byte' is kind of dumb. It puts the
> bytes
>> at the beginning of the pushback buffer instead of the end. This means
>> that every time you unget a byte, it has to shift up the existing
>> contents of the buffer, so ungetting N bytes takes O(N^2) time.
>>
>>
>>> + /* If the specified encoding is UTF-16 or UTF-32, then make
>>> + that more precise by deciding what endianness to use. */
>>> + if (strcasecmp (pt->encoding, "UTF-16") == 0)
>>> + precise_encoding = decide_utf16_encoding (port, mode);
>>> + else if (strcas
Hi Mark
>>> Here's the new patch. Any more suggestions?
There are a couple of lines in your doc patch that aren't quite right.
"@code{UTF-16BE}, @code{UTF-16LE}, @code{UTF-16BE}, or @code{UTF-16LE}"
I assume that two of these should be UTF-32.
Also
"This is intended to multiple logical te
> From: Mark H Weaver
> Thanks for nudging me to do the measurement. To be honest, the original
> patch I posted slowed things down by 4.5%, which I found extremely
> surprising. I fixed it by adding an internal 'static' version of
> 'scm_fill_input'. So for those who doubt the cost of functio
> From: Mark H Weaver
>
>Andy suggested this. Okay to push to stable-2.0?
Hi Mark,
I can't imagine any possible way that this patch could make
performance worse, but, it is in the very core of the ports.
I don't think you can get away without at least a bit of
profiling.
-Mike
Hi Ludo
> Attached is a patch to use Guile’s Texinfo support [0] to build said
> file. Guile’s Texinfo parser is incomplete but sufficient to handle
> those docstrings.
> OK to commit?
If Guile depends on Guile for multiple stages the build, it becomes
difficult to recover from a problem when
Hello.
There seem to be four ways to force an exit.
In boot-9, a function `quit' is defined. It appears in the manual,
but, in boot-9 it can take an argument. In the manual it never
takes an argument.
In boot-9, `exit' is aliased to quit. In the manual `exit' is
undocumented; however, in th
> From: Andy Wingo
>I made some notes there.
>
Hi Andy,
I noticed in your comments to Nala G that you recommend using
`print-exception'. Is that intended to be public API? It doesn't
appear in the manual.
Thanks,
Mike
> From: Mike Gran
> What would you think about applying the following patch?
>
> It is a standalone test that, in effect, checks to see if
> BDW-GC is running marking in its own non-Guile thread. If
> BDW does have parallel marking enabled, this test will SEGV.
> If it
76d0d Mon Sep 17 00:00:00 2001
From: Mike Gran
Date: Tue, 26 Feb 2013 08:27:22 -0800
Subject: [PATCH] Add standalone test for smob marking
* test-suite/standalone/Makefile.am: add test-smob-mark
* test-suite/standalone/test-smob-mark.c: new test
* test-suite/standalone/.gitignore: ignore test-smob
> From: Andy Wingo
> So, what do you think about always adding O_BINARY to files that Guile
> opens?
Lilypond, Gnucash, Denemo, Autogen and Emacs all run on Windows
to varying degrees. As does Gnome Games. If it doesn't break
any of them, then it might be okay. In an ideal world, there would
b
> From: David Pirotte
> do we actually have a matrice calculus [offset based the better] lib or
> binding
> or
> scheme package ? any pointer is welcome
There once was a package called guile-num. You can find it here.
www.nongnu.org/guile-num
But, it would take some work to get it to run aga
From: Noah Lavine
>Hello,
>>On Wed 23 Jan 2013 13:20, Daniel Llorens writes:
>>
>>> In [2]: a = np.array([[1, 2, 3], [4, 5, 6], [7, 8, 9]])
>>
>>> In [4]: a[1]
>>> Out[4]: array([4, 5, 6])
>>> In [5]: a[1, 1]
>>> Out[5]: 5
>>>
>>> array-ref can be extended very simply to do that. It accumulates o
Hi-
There's something we discussed in bug report #13611 that
might be of general interest.
If you're using a gc built with --enable-parallel-marks
with Guile, you can get a SEGV during garbage collection
of a SMOB. BDW-GC v7.3 has that flag enabled by default.
It allows the garbage collector to
> I have the feeling that we should implement our own dynamic-link
> function without libltdl. It would eliminate a dependency and allow us
> to use other search path rules, like ones that could deal with this
> case. I think the situation would actually be better on other
> architectures because
> From: Nala Ginrut
>
> Hi Boriani & Vepstas !
> I'm dealing with a web-framework and using guile-dbi & guile-dbd, which
> are nice thing to handle the databases. ;-)
> I found there're something obsoleted in the current code, when I tried
> to format a patch I've noticed the bug-report&patches h
oretical possibility
that a doc in encodings like ISO-8859-2 through 8859-5
could begin with 0xff 0xfe or 0xfe 0xff. They are
valid characters.
So if there is a "coding:" line in the doc, I think it
should nullify giving precedence to a UTF-16 BOM.
-Mike Gran
Hi Andy,
> From: Andy Wingo
> But no, currently the answer is locale-specific. It encodes the string
> according to the current locale, then decodes it from that encoding. If
> your locale can't encode the string, tough luck for you!
>
> This is a bit crazy. Surely the port should be textual?
> From: Mark H Weaver
> To: guile-devel@gnu.org
> Cc: Michael Gran
> Sent: Sunday, January 13, 2013 10:25 AM
> Subject: Scanning for coding declarations in all files (not just source)
>
Hi Mark,
> I just discovered that Guile is scanning for coding declarations in
> *all* files opened with 'ope
egative image
8 concealed characters
30 black display
31 red display
32 green display
33 yellow display
34 blue display
35 magenta display
36 cyan display
37 white display
40 black background
41 red background
42 green background
43 yellow background
44 blue background
45 magenta background
46 cyan background
47 white background
Of course, each terminal
is different in practice. The only way to be sure you
are getting it right is to go through terminfo.
OTOH, these days when everything behaves almost like
color xterm, maybe parsing terminfo is just being
pedantic.
Thanks,
Mike Gran
> From: Mike Gran
>
> For what it is worth, R7RS WG1 draft 6 says "If more than one
> strings have the same length,
> when the shortest string runs out."string is given and not
> allstring-for-each terminates
Gah! Sorry, worst cut-and-paste ever. That's wha
ng is given and not allstring-for-each
terminates
Since R7RS is just going to undo the change, it hardly seems
worth changing, in my opinion.
http://www.scheme-reports.org/2012/working-group-1.html
-Mike Gran
> From: Ludovic Courtès
>> I imagine if this particular fix goes smoothly, i will be motivated to
>> continue w/ this kind of maintenance work, where the focus is on
>> continuity and stability (perhaps likewise showing 1.6 and 1.4 some
>> love, as well).
>
> Hmm, I’d find it more important
>Second, in commit 9f6e3f5a997f484548bd03e7e7573c38a95c8d09, I changed
>string ports to honor it, like other port types, instead of forcing
>'error. This seems like the right thing to me, for the sake of
>consistency (in fact, I’d consider the previous behavior as a bug), but
>it’s an observable c
> From: Andy Wingo
>
>Hi all,
>
>I have been thinking about ports recently. I know other folks have had
>some thoughts here too, so it's probably good to have a discussion about
>how they should look.
...
>Obviously we need ports implemented in C because of bootstrapping
>concerns. But can
> 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!
> From: Andy Wingo
>> As an aside, I can get a similar sort of deadlock during garbage
>> collection of SMOBs if my smob_free function calls a scheme function.
>> But the manual does note that you should not call any functions in
>> SMOB GC finalizers, so that wouldn't happen if I actually f
> From: Andy Wingo
>> Can you explain what happens here? Is it a deadlock? What’s at
>> ports.c:575?
>
> It was a deadlock, but I fixed it. It was something that locked all
> weak sets, but while doing so allocated memory. Allocating memory ran
> finalizers which tried to manipulate the po
> From: Andy Wingo
>Subject: ice-9 async-queue
>;;; Asynchronous queues
Hey Andy,
FYI, there is also an (ice-9 q). I haven't really looked
at it, but, maybe either (ice-9 q) or (ice-9 async-queue)
could become a generalized version and the other could
become a specific version or the same code
> Hi Mike,
>
> Thanks for the Unicode 6.1 update! Now, however:
>
> FAIL: srfi-14.test: Latin-1 (8-bit charset): char-set:symbol
>
> Would you be willing to investigate?
Looks like Unicode 6.1 has recategorized some of the symbols, including
a few in Latin-1.
"§" U+00A7 SECTION SIGN from S
Hi Mark-
> Thanks for the Unicode 6.1 update! Now, however:
>
> FAIL: srfi-14.test: Latin-1 (8-bit charset): char-set:symbol
>
> Would you be willing to investigate?
Strange. I'll check it out today.
-Mike
> From: Bruce Korb
> 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,
>>
>To: Mike Gran
>> 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
> 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 Guile command: = = = = =
>>
>> (define
> From: Andy Wingo
> That would indeed be a mean thing to do! It's not what I'm suggesting
> though. Deprecation means causing Guile to emit warnings, at
> compile-time or at runtime, indicating that a particular interface will
> go away at some point, and noting the interface that should be use
> From: Andy Wingo
>> (seed->random-state (current-time)) seems to be a common idiom that
>> you would end up breaking.
>
>This is a common idiom that is worth deprecating. Mark's new functions
>that seed the random state from /dev/urandom are much better.
Are you suggesting that you'll break t
> From: Andy Wingo wi...@pobox.com
>How about, we extend seed->random-state to operate on bytevectors, and
>have that interface do the right thing. We deprecate the number
>interface. At some point in the future we deprecate the string
>interface as well.
The number or string argument to seed->
> From: Andy Wingo
> If I could vote for one thing to focus on in 2012, for the broader Guile
> community, I'd pick two things ;-) I'd pick Guile in Emacs, first of
> all. We have the hack power, the time is right, and we just need to
> focus on the task. By the end of the year we could have a c
> From: Ludovic Courtès
> Hi Mike,
>
> I think “Standard Library” should eventually be merged into “Guile
> Modules”.
I could try it. It'll take me a few weeks to geto to it, though.
> Regarding standard/extended/3rd-party library, how about adding
> second-level sections to sort by theme?
> From: Mark H Weaver
>> What do you think about that? Do zero-length substrings need to
>> still share stringbufs with their parent strings?
>
> I think the answer is: no they don't, and avoiding that might be a
> worthwhile optimization, mainly to avoid needlessly holding a reference
> to a
> From: Ludovic Courtès
> I just noticed that there are i18n.test failures on Hydra, which point
> at this commit:
>
> http://hydra.nixos.org/build/1790097
>
> I think this is under the C locale, but I haven’t been able to reproduce
> it yet.
>
> Anyway, it seems that before, you couldn’t get
> From: Ludovic Courtès
> A related question: can we have both narrow and wide empty strings?
The intention is that a string is encoded as wide only if it can't
be encoded as narrow. So _newly created_ empty strings should only be narrow.
Right now it seems that zero-length shared substring of
Hi-
So I was reading through the reference manual. There is the
"API Reference" and "Guile Modules" chapter followed by the
"Standard Library" chapter. I know historically why they
are separated that way, but if you didn't know about guile-lib
you aren't going to understand why they're divided t
> From: Mark H Weaver
>
> I wrote:
>> 3. Make scm_nullstr into a mutable string. After all, it can't be
>> changed anyway, and the _only_ reference to it is from
>> scm_from_stringn, so the result should always be mutable.
>
> For the record: my statement above was in error; scm_nullst
> From: Mark H Weaver
>> It is curious that action of 'copy' really means the
>> action of 'create a copy with different properties'.
>>
>> Shouldn't (string-copy "a") create another immutable string?
>
> Why would you want to copy an immutable string?
>
>> Likewise, shouldn't (substring
> `define' merely makes a new reference to an existing object. If you
> want a copy, you must explicitly ask for one (though this could be
> hidden by custom syntax). It would not be desirable for the language to
> make copies automatically as part of the core `define' syntax. For one
> thing, s
> From: Bruce Korb
>>> 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,
> otherwise it is not really a d
ry, there should be some kind of fingerprint put
> in both the go-bundle and the C file index. Check the fingerprint
> before trying to load things from the go-bundle.
That's good advice.
Thanks much,
Mike Gran
ised to find that
the above is what you need to do to create an initialize a mutable string,
I think.
But 'define' just as easily can be considered a generic constructor
that is overloaded in a C++ sense, and when "hello" is a string, y is
assigned a copy-on-write version of the immutable string.
It was wrong to change this without deprecating it first.
Thanks,
Mike Gran
> In many systems it is desirable for constants (i.e. the values of literal
> expressions) to reside in read-only-memory. To express this, it is
> convenient to imagine that every object that denotes locations is
> associated with a flag telling whether that object is mutable or immutable.
> From: Mark H Weaver
> What is the advantage of including our own little read-only filesystem,
> when every OS already provides this functionality? Is it really
> significantly easier to install 3 files than to install 300?
>
> Admittedly, I can see how it might make a psychological difference
> From: Ludovic Courtès
> OK, but back to the example above, you wouldn’t want Lilypond’s tarball
> to contain these binaries, would you?
For Lilypond on Win32, where the culture is to download
compiled binaries, I'd want to be able to provide a download location
for a pre-compiled Win7 x86 lib
> From: Ludovic Courtès
> Hi Mike!
>
> Mike Gran skribis:
>
>> It'll be fun to try to minimize it down to just
>> the guile executable, libguile-*, and a scheme archive file. And it
>> might help with distribution of prebuilt versions.
>
>
> From: Ludovic Courtès
>> scm_display
>
> A matter of adding it as a @deffnx below ‘display’ under “Scheme Write”.
>
>> scm_puts
>
> This and scm_putc should be documented, yes.
>
>> scm_new_port_table_entry
>
> Actually the whole port subsystem is undocumented. :-( So yes, would
> be
> From: Bruce Korb
> 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
> From: Bruce Korb
> 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 work
try
scm_sym2var
Regards,
Mike Gran
> From: Mike Gran
>
> Hi-
>
> Re point 2: hard to distribute.
>
> A while ago I was looking at the idea of minimizing the number of
> files needed to ship Guile as a dependency. At the time, I thought
> that one could retool the build so that it produced
> -
locale only
- Fixnum integers only
- No ability to load ltdl or ffi
- no ability to use whatever libcrypt is used for
This would be for the purpose of being a minimalist extension
engine.
What do you think?
-Mike Gran
> From: Ludovic Courtès
>> Here's a suggestion. One could add an option to the guile
> interpreter's command
>> line args (--locale=ARG perhaps) that has the effect of calling
>> setlocale(LC_ALL,"ARG") first thing. If --locale is called
> with no ARG
>> specified, it would call to setloc
>From: Ludovic Courtès
>>Bruno Haible skribis:
>
>> No, I'm suggesting to let the Scheme code know that is it using the user's
>> locale.
>>
>> Yes, this is a backward-incompatible change, so probably you won't want to
>> do it on the guile 2.0.x branch, and you will want to advertise it in the
>
Hi-
Would it be okay for me to add scm_is_exact and scm_is_inexact
C functions as companions to the existing scm_exact_p and
scm_inexact_p?
If so, which branch?
-Mike
Hello all-
Is the SCM_ASSERT_TYPE macro considered to be a stable public API
or internal to Guile? It has never been mentioned in the manual,
but both Lilypond and GNU Serveez have used it.
And what about the seldom-used SCM_ASRTGO?
Thanks,
Mike
>So what do you all think about:
>
> (define-module (foo)
>#:import ((bar)
> (only (baz) qux foo)
> ...))
We once discussed having a plural #use-modules in this thread.
http://lists.gnu.org/archive/html/guile-user/2007-10/msg2.html
-Mike Gran
>We have finally figured it out after some debugging via IRC: David has
>had set PKG_CONFIG=true when configuring Guile, which lead to an
>installation with a (silently) broken guile-config script;
>meta/guile-config.in contains:
>
>(define %pkg-config-program "@PKG_CONFIG@")
>
>The mayhem that re
> From:Andy Wingo
>
> module/ice-9/boot-9.scm:118:20: In procedure module-lookup: Unbound
> variable: %uri?-procedure
FWIW, I got the same error while hacking one day. I couldn't track it down so
I did a make distclean and it went away. Glad to know that it wasn't just me.
-Mike
> "Portability fixes for win32 cross compiling"
> http://www.mail-archive.com/guile-devel@gnu.org/msg05308.html
>
> > In any case, I don't understand the mechanism here, but I believe the
> > point was to make it so that #include would not pull in
> > iconv headers. gen-scmconfig looks u
1 - 100 of 290 matches
Mail list logo
