Re: A Guile debugger workgroup?

[Neil Jerram]

I wrote something called GDS, back in 1.8 days, that combined some of
the Emacs interaction features that we now have with Geiser, with
step-by-step debugging and breakpoints.  You can read about that here:
https://www.gnu.org/software/guile/docs/docs-1.8/guile-ref/Using-Guile-in-Emacs.html#Using-Guile-in-Emacs

Unfortunately the debugging side of GDS was based on the low level
traps in the 1.8 interpreter, and that was all blown away in the 2.0
rewrite, so GDS stopped working at that point.  I don't know what
modern equivalent 3.x has to the 1.8 low level traps - perhaps we
would instead advocate for recompiling the relevant code with extra
instrumentation, like edebug does?

On Tue, 29 Nov 2022 at 17:21, Olivier Dion via Developers list for
Guile, the GNU extensibility library  wrote:
>
> Greetings Guilers,
>
> There's been a discussion on the state of debugging with Guile on the
> guix-devel mailing list.  Here's the relevant link if you want the full
> discussion:
> 
> which is a reply to .
>
> I'm going to resume what I've gather here.  I've mainly cutoff Guix
> related stuff.  I'm also putting names here for the sake of clarity.
>
> I think it would be interesting to have more inputs from the Guile users
> at large -- outside of Guix -- on that topic.  From my personal
> experience and the echo I get back from other users, the debugging
> experience in Guile is frustrating.
>
> Things I've gather in this reading and on the IRC with other users.
> This is by no way a wish list, but simply ideas to improve the debugging
> experience:
>
>   1. Documentation on debugging should be improved.  e.g. The `pk`
>  procedure.
>
>   2. A tutorial on how to debug a project with `pk` and the REPL.
>
>   3. A single-step (instruction and line) debugger.
>
>   4. Integration in GDB.  e.g. GDB could insert breakpoints in Scheme
>  code.
>
>   5. Maybe not make a debugger with a paradigm for language like C but
>  instead take inspiration from other Scheme implementation like
>  Racket.
>
> Resume start here:
>
> zimon:
>
>   Preparing some materials for introducing Guile to GuixHPC folk, I am
>   trying to collect some tips and, if I am honest, the debugging
>   experience with Guile is really poor; compared to others (as Python).
>   For example, DrRacket provides an easy and nice user experience
>
>   Well, IMHO, we are somehow suffering from some Guile limitations and
>   improvements in this area are an hard task.
>
> Maxim:
>
>   I also agree!  It's hard to convince people to pick Guile for their
>   project when there is:
>
>   1. Lack of a debugger that can break and step anywhere in your source
>  code
>
>   2. Lack of debugger integration to an IDE (it's not even integrated
>  into Emacs)
>
>   Perhaps we should assemble a Guile debugger workgroup that'd review
>   what's broken, what's missing, what can be borrowed from other Scheme
>   or languages for inspiration
>
> Ludo:
>
>   Well, Guile has a debugger that lets you do that [...] Geiser is not
>   Visual Studio™ but it does a good job.
>
>   Also, [...] I mentioned before that I almost never use breakpoints on
>   Guile code [...]  because it’s rarely the right tool for the job.
>
>   I believe this is largely due to (1) writing functional code, and (2)
>   doing live programming at the REPL.  Why would you use breakpoints
>   when you can just call the relevant procedures on some input to see
>   how they behave?
>
>   So I think you won’t convince people to pick Guile for their project
>   by selling it as a C/C++/Python drop-in replacement.  Guile is about
>   functional programming and live coding so the set of tools differs.
>
>   Despite what I wrote, I think it’s a good idea.  I suppose inspiration
>   would come from other Schemes, in particular Racket, and perhaps from
>   other live-coding systems (Common Lisp, Smalltalk, etc.), rather than
>   from Python or C.
>
> Zimon:
>
>   Maybe I am wrong or miss some Guile features.  From my experience, the
>   issue is not the way that the information is presented or how we
>   interact with it (Geiser or else) but, instead, the issue is the
>   availability of such information.
>
>   Well, so you are using the good ol’ way putting ’pk’ here or there,
>   right?  One thing when debugging is to inspect the current state of
>   the program; [...] And, ’pk’ is the poor man breakpoint. :-)
>
>   Racket is an example of functional programming and live coding.
>   Haskell is another; it is functional programming and if I might, I
>   would recommend to give a look at the interactive GHCi debugger
>
> Maxim:
>
>   When searching for how the debugger work in the Guile Reference info
>   manual, I also don't find anything useful: only the gut of the
>   debugging API of the Guile VM appears to be documented ("Debugging
>   Infrastructure"), so documentation is another 

Re: a cookbook

[Neil Jerram]

On Wed, 16 Feb 2022 at 21:14, Catonano  wrote:
>
>
>
> Il giorno mer 16 feb 2022 alle ore 10:54 Neil Jerram  
> ha scritto:
>>
>>
>>
>>
>> > As for you creating a web site, I'd prefer such a website to be a 
>> > communitarian effort, rather than depend on a single person
>> >
>> > Maybe a wiki on Gitlab could do and it could have several mantainers ?
>> > I'd be happy to be one
>>
>> Yes, definitely feels right to crowd-source this, instead of having it
>> centralized in the core Guile repo.
>>
>> It feels to me that with the right structure in place, people will
>> readily come and contribute the detailed material to it.  So it's
>> worth spending a little time to decide the right structure.
>
>
> Have you any suggestion about a structure you would deem appropriate ?

No, I want to let others lead on this.  (As Blake just reminded me, I
had a go at something like this several years ago, and it didn't work.
Also worry that I'd only disappoint, because of lack of my own
available time.)

Best wishes,
 Neil

Re: a cookbook

[Neil Jerram]

On Wed, 16 Feb 2022 at 09:04, Catonano  wrote:
>
> Il giorno lun 14 feb 2022 alle ore 18:01 Vijay Marupudi 
>  ha scritto:
>>
>> > Is there any interest/possibility to have such a cookbook hosted
>> > within the Guile official documentation (as it is for Guix) ?
>>
>> I personally think that a Cookbook should be an independent effort, with
>> links from the Guile Manual if possible. This would lighten the load on
>> the maintainers, and allow for quicker collaboration.
>
>
> but then the discoverability of the cookbook would be diminished 

Yes, agree that the resulting cookbook needs to be easily
discoverable.  Perhaps that means that if you install a guile-doc
package, it appears as a top-level Info item like Guile Reference
does.  Perhaps it doesn't need to be quite as specific as that.
(Although personally I really like doc being available locally, e.g.
in Info form, instead of always going online.)

But as you also say...

> [...]
>
> As for you creating a web site, I'd prefer such a website to be a 
> communitarian effort, rather than depend on a single person
>
> Maybe a wiki on Gitlab could do and it could have several mantainers ?
> I'd be happy to be one

Yes, definitely feels right to crowd-source this, instead of having it
centralized in the core Guile repo.

It feels to me that with the right structure in place, people will
readily come and contribute the detailed material to it.  So it's
worth spending a little time to decide the right structure.

Best wishes,
Neil

Re: Stepping back up as a co-maintainer

[Neil Jerram]

I'm afraid arguing by analogy or proverb rarely helps, because the analogy
is usually inaccurate in some way.

Also, what about Horchata? :-)

On Thu, 17 Oct 2019 at 11:53, zx spectrumgomas 
wrote:

> Let's hope so. But in Spain we have a proverb: "Blanco y en botella,
> leche". "White and bottle -> milk". Let's hope it doesn't come true.
>
> On Thu, Oct 17, 2019 at 12:24 PM Mikael Djurfeldt 
> wrote:
>
>> I think we should trust what Mark says and not second guess him.
>>
>> Helping or being friend with someone is not among the worst crimes on my
>> list.
>>
>> Den tors 17 okt. 2019 11:28zx spectrumgomas 
>> skrev:
>>
>>> I'm a simple Guile user and I hope I'm wrong, but I think Mark H weaver
>>> are
>>> saying half-thruth here
>>> https://lists.gnu.org/archive/html/guile-devel/2019-10/msg00021.html
>>> because he has a very close friendship witch Richard Stallmam:
>>> "I've known RMS for a long time. For a few years, I spent most of my time
>>> two doors down from him at the MIT AI lab. I was the FSF staff sysadmin
>>> for
>>> a while, and did sysadmin work on RMS's laptop. I was his preferred
>>> typist
>>> when he shattered his elbow and helped him replace his bandages, etc."
>>> http://logs.guix.gnu.org/guile/2014-08-09.log
>>>
>>> I think the joint statement
>>> https://guix.gnu.org/blog/2019/joint-statement-on-the-gnu-project/ is
>>> the
>>> true key factor of his return.
>>>
>>> On Wed, Oct 16, 2019 at 7:42 AM Mark H Weaver  wrote:
>>>
>>> > Hello all,
>>> >
>>> > In light of recent events, I've decided to step back up as a
>>> > co-maintainer of GNU Guile.
>>> >
>>> >  Thanks,
>>> >Mark
>>> >
>>> >
>>>
>>

Re: Distributed verification of release tarballs using Guix? (was Re: Releasing 2.2.5?)

[Neil Jerram]

On Thu, 20 Jun 2019 at 22:56, Mark H Weaver  wrote:

> Hi Ludovic,
>
> Ludovic Courtès  writes:
>
> > Mark H Weaver  skribis:
> >
> >> I've finished my updates to the NEWS file in preparation for the 2.2.5
> >> release.  Feel free to reorganize, edit, or expand on the NEWS entries
> >> as you think best.  I believe that all of the relevant changes are
> >> listed, anyway.
> >
> > Thanks a *lot* for all the preparation work, that made things really
> > easy for me.
>
> Given the enormous amount of important work you've been doing on Guix,
> and Andy's exciting work on the JIT compiler, it's entirely appropriate
> for me to take care of most of the Guile stable release work.
>

Thank you to all of you for continuing to push Guile forward!  It seems
like interesting and rigorous developments are coming all the time now, and
I also love how central it is in Guix.

Best wishes,
Neil

Re: make-c-struct and pointer->string

[Neil Jerram]

On Fri, 29 Mar 2019, 09:46 David Pirotte,  wrote:

> Hi again,
>
> > ...
> > Following your explanation and example, I tried this and thought it
> would work
> > then, but it also failed:
>
> > GNU Guile 2.2.4.1-cdb19
>
> > Enter `,help' for help.
> > scheme@(guile-user)> ,use (system foreign)
> > scheme@(guile-user)> (define str-1 "Hello")
> > scheme@(guile-user)> (define str-2 "there!")
> > scheme@(guile-user)>  (make-c-struct (list '* '*) (list
> (string->pointer str-1)
> > (string->pointer str-2))) $2 = #
> > scheme@(guile-user)> (parse-c-struct $2 (list '* '*))
> > $3 = (# #)
> > scheme@(guile-user)> (map pointer->string $3)
> > $4 = ("" "`\v?\x02?U")
>
> Here are another couple of examples:
>
> scheme@(guile-user)> ,use (system foreign)
> scheme@(guile-user)> (define str-1 "Hello")
> scheme@(guile-user)> (define str-2 "there!")
> scheme@(guile-user)>  (make-c-struct (list '* '*) (list (string->pointer
> str-1) (string->pointer str-2)))
> $2 = #
> scheme@(guile-user)> (parse-c-struct $2 (list '* '*))
> $3 = (# #)
> scheme@(guile-user)> (map pointer->string $3)
> $4 = ("Hello" "there!")
>
> But then:
>
> scheme@(guile-user)> str-1
> $5 = "Hello"
> scheme@(guile-user)> str-2
> $6 = "there!"
> scheme@(guile-user)> (map pointer->string $3)
> $7 = ("?\\?q\x7f" " ??E?U")
> scheme@(guile-user)> (map pointer->string $3)
> $8 = ("?\\?q\x7f" " ??E?U")
>
> I guess that what the GC recollected are the pointers, or even $3, the list
> Let's hold on it then:
>
> scheme@(guile-user)> (define c-struct (make-c-struct (list '* '*) (list
> (string->pointer str-1) (string->pointer str-2
> scheme@(guile-user)> (parse-c-struct c-struct (list '* '*))
> $9 = (# #)
> scheme@(guile-user)> (map pointer->string $9)
> $10 = ("\x02" "0??E?U")
>
> Not good either. Let's hold on the parse-c-struct to then:
>
> scheme@(guile-user)> (define parsed (parse-c-struct c-struct (list '*
> '*)))
> scheme@(guile-user)> parsed
> $16 = (# #)
> scheme@(guile-user)> (map pointer->string $16)
> $17 = ("0??E?U" "?\x01?F?U")
> scheme@(guile-user)> (map pointer->string parsed)
> $18 = ("\x03" "?\x01?F?U")
>
> Didn't do it either
> Ok, let's hold-on to the pointers (which I thought would not be necessary
> after
> holding-on c-struct and/or parsed):
>
> scheme@(guile-user)> (define p1 (string->pointer str-1))
> scheme@(guile-user)> (define p2 (string->pointer str-2))
> scheme@(guile-user)> (make-c-struct (list '* '*) (list p1 p2))
> $19 = #
> scheme@(guile-user)> (parse-c-struct $19 (list '* '*))
> $20 = (# #)
> scheme@(guile-user)> p1
> $21 = #
> scheme@(guile-user)> p2
> $22 = #
> scheme@(guile-user)> (map pointer->string $20)
> $23 = ("Hello" "there!")
>
> That worked, but I wonder if this is what is expected from us (users)?
>

Yes, that would seem very odd to me, as I thought that a 'pointer' really
was just an address.

(Hopefully some more light will be thrown when the maintainers are back
around again!)

Best wishes,
 Neil


> Cheers,
> David
>

Re: make-c-struct and pointer->string

[Neil Jerram]

On Thu, 28 Mar 2019 at 15:15, Amirouche Boubekki
 wrote:
>
> Eventually, I can reproduced the issue with guile-next from guix:
>
> scheme@(guile-user) [1]> (make-c-struct (list '* '*) (list (string->pointer 
> "hello ") (string->pointer "there!")))
> $5 = #
> scheme@(guile-user) [1]> (parse-c-struct $5 (list '* '*))
> $6 = (# #)
> scheme@(guile-user) [1]> (map pointer->string $6)
> $7 = ("hello " "there!")
> scheme@(guile-user) [1]> (make-c-struct (list '* '*) (list (string->pointer 
> "hello") (string->pointer "there!")))
> $8 = #
> scheme@(guile-user) [1]> (parse-c-struct $8 (list '* '*))
> $9 = (# #)
> scheme@(guile-user) [1]> (map pointer->string $9)
> $10 = ("hello" "there!")
> scheme@(guile-user) [1]> (make-c-struct (list '* '*) (list (string->pointer 
> "hello") (string->pointer "there!")))
> $11 = #
> scheme@(guile-user) [1]> (parse-c-struct $11 (list '* '*))
> $12 = (# #)
> scheme@(guile-user) [1]> (map pointer->string $12)
> $13 = ("?<\"?\x0e\x7f" "@?f\x01")
> scheme@(guile-user) [1]>
> scheme@(guile-user)>
>
>
> Le mar. 26 mars 2019 à 14:19, David Pirotte  a écrit :
>>
>> Hello,
>>
>> guile 2.2.4.1-cdb19
>>
>> ,use (system foreign)
>>
>> ;; this fails
>>
>> scheme@(guile-user)> (make-c-struct (list '* '*) (list (string->pointer 
>> "hello ") (string->pointer "there!")))
>> $16 = #
>> scheme@(guile-user)> (parse-c-struct $16 (list '* '*))
>> $17 = (# #)
>> scheme@(guile-user)> (map pointer->string $17)
>> $18 = ("?g?գU" "`!?գU")
>>
>> ;; but this works
>>
>> scheme@(guile-user)> (map pointer->string (parse-c-struct (make-c-struct 
>> (list '* '*) (list (string->pointer "hello ") (string->pointer "there!"))) 
>> (list '* '*)))
>> $19 = ("hello " "there!")

I guess it may be GC.  I've had problems with code like

   (procedure->pointer void (lambda (...) ...) args...)

because procedure->pointer does not protect the (lambda ...) from being GC'd.

For example: 
http://git.savannah.nongnu.org/cgit/ossaulib.git/commit/?id=1d31a87b53e9375b5fdd5120b7d409e6dde6aa47

I wonder if there's a similar problem here with the string->pointer data.

Best wishes,
 Neil

Re: Simple picture language

[Neil Jerram]

Matt Wette  writes:

> On 03/27/2018 05:40 AM, Thompson, David wrote:
>> On Mon, Mar 26, 2018 at 5:51 PM, Ricardo Wurmus  wrote:
>>> Hi Guilers,
>>>
>>> I wrote a simple SVG-based picture language.
>> Wow! I never would have thought to use sxml to generate svg files. I
>> always thought we would have to use cairo or some custom renderer in
>> order to have a picture language. This is a great hack!
>>
>
> Read Andy Wingo's paper on tree fold (mentioned in the Guile Manual).
> I also use sxml for svg but never realized images could be rendered with 
> Geiser.

Likewise.

> Pretty sweet.

Yes, this is great fun - thanks Ricardo!

 Neil

Re: a draft for the top of the NEWS for 2.0.12

[Neil Jerram]

Nice work! I noted a couple of typos :

- documention should be documentation 

- miss behaviour should be misbehaviour. 

   Neil

  Original Message  
From: David Pirotte
Sent: Wednesday, 22 June 2016 21:46
To: guile-devel
Subject: a draft for the top of the NEWS for 2.0.12

Heya,

Here below a draft for the top of the NEWS file for Guile 2.0.12
It needs review, in particular the 'Notable changes - Goops entry',
see FIXME in the text.

Cheers,
David


Guile NEWS --- history of user-visible changes.
Copyright (C) 1996-2016 Free Software Foundation, Inc.
See the end for copying conditions.

Please send Guile bug reports to bug-gu...@gnu.org.

* Changes in 2.0.12 (since 2.0.11):

** Notable changes

*** Dependencies

Guile 2.0.12 needs libunistring >= 0.9.3
This check is now part of the configure step.

*** Goops

Two major changes have been made:

1- #:init-value on class-allocated slots: allocating an instance of a
class with a #:class or #:each-subclass slot allocation should not
re-initialize the class-allocated slot.

2- accessor methods only apply to subclasses with their slot

FIXME
(a) let users know that it will break Goops user code relying on
previsouly inherited getters, setters and accessors ... (b) why this: so
that Guile 2.x.x behave like guile-1.8 wrt Goops. But the full picture
is rather strange, and will be (re)fixed soon, see this discussion
http://thread.gmane.org/gmane.lisp.guile.user/11218/focus=11813 for some
details.
ENDFIXME

*** FFI: Add support for functions that set 'errno'

When accessing POSIX functions from a system's libc via Guile's dynamic
FFI, you commonly want to access the ‘errno’ variable to be able to
produce useful diagnostic messages.

This is now possible, check the Guile's dynamic FFI documentation for
the details, in paticular the following entries have been updated
accordingly: pointer->procedure, scm_pointer_to_procedure and
scm_pointer_to_procedure_with_errno.

*** Add SRFI-25 implementation

Adds an implementation of SRFI 25 on top of Guile's native arrays. The
implementation does not introduce a disjoint type; Guile arrays and
SRFI-25 arrays can be used interchangably, though with different, partly
conflicting APIs.

*** Add SRFI-28 implementation

Adds an implementation of SRFI 28 Basic Format Strings.

*** The #!r6rs directive now influences read syntax

The #!r6rs directive now changes the per-port reader options to make
Guile's reader conform more closely to the R6RS syntax. In particular:

- It makes the reader case sensitive.
- It disables the recognition of keyword syntax in conflict with the
R6RS (and R5RS).
- It enables the `square-brackets', `hungry-eol-escapes' and
`r6rs-hex-escapes' reader options.

*** SRFI-14 character data set

SRFI-14 character data set has been regenerated for Unicode 8.0.0.

*** Web modules

The (web server) module now exports 'server-impl' procedures, (web server
http) exports the 'http' server implementation.

Also, http location header accepts URI-reference, not just absoluteURIs.

*** Strings

The following 2 new procedures have been added: 'string-utf8-length' and
'scm_c_string_utf8_length'.

'string-hash' has been optimized: this yields a 50% improvement on the
"narrow string" benchmark of 'hash.bm', 41% on "wide string", and 76% on
"long string".

'write' has been optimized: this shows a 19% improvement on the "string
without escapes" micro-benchmark of 'write.bm', and 12% on "string with
escapes".

'read-string' speed up: this yields a 20% improvement on the
"read-string" benchmark.

'scm_string_hash' has been deprecated.

'scm_read_string_like_syntax' now accept "\(" as equivalent to "(".

*** Libguile

Tow new macros have been added: 'SCM_VALIDATE_SIZE_COPY' and
SCM_NUM2SIZE.

*** New Module

Add (ice-9 unicode) module.

*** SMOBs

Functionalities have been added to disable automatic finalization: see
the (Smobs) documentation node for the details and new functions.

*** Posix

'EXIT_SUCCESS' and 'EXIT_FAILURE' added and documented.

*** Architectures

The following ARM target have been added: "arm.*eb", "^aarch64.*be", and
"aarch64".

** Fixed Bugs

The following bugs and/or 'miss behavior' have been fixed:

*** 17399 - detect too-old libunistring at configure-time
*** n/a - SRFI-2 (and-let*) has been re-implementated
*** n/a - size measurement in bytevector_large_set
*** n/a - uri-decode behavior for "+"
*** 18477 - use source file permissions for compiled files
*** 14347 - call-with-prompt continuation, returned value(s)
*** 22406 - sizeof (long) support for LLP64 data model
*** 22152 - fat_mutex, fat_mutex_unlock
*** 23421 - http, date strings with a leading space for hours
*** n/a - SRFI-19, update the table of leap seconds
*** 22273 - http, Accept empty reason phrases
*** n/a - get[set]sockopt now have their arg of type 'int'
*** 20302 - seeking on binary input ports with putback buffers
*** n/a - web, use 'close-port' for delimited input ports
*** n/a - match-each+, non-pair syntax object in a dotted tail

Re: Fw: guile-gnome, devel: corba test suite fails if using scm_make_vtable

[Neil Jerram]

On 2014-09-04 23:37, David Pirotte wrote:

Heya,

ping!

	I'm pretty sure it is a guile core and/or a test suite problem, not 
related
	to corba itself [which as a matter of fact I do not know and do not 
use

either :)]

I'd like to solve this problem before to release a guile-gnome-platform 
2.16.3

[which is a good idea anyway, but in the end it will also allow distro
to get rid of
guile-1.8 ...]

Before to release I believe indeed that we _should_ get rid of all 
guile related

deprecated messages, which motivated my changes to
git-clone/corba/gnome/corba/guile-gnome-corba-types.c

I'm looking for a C knowledgeable guile developer or co-maintainer who
knows what
scm_make_vtable is supposed to do, args, ... to think about what could
be the cause
of the problem [comparing the original function and its proposed 
substitution

in guile core maybe] and/or come and talk to me on irc [daviid] to
debug together...

Thanks,
David


Hi David,

I think that the commits at 
http://git.savannah.gnu.org/cgit/guile.git/log/?h=stable-2.0qt=grepq=make-vtable 
may indicate the correct code transformation that you need to make for 
old uses of scm_make_vtable_vtable.  Those commits only show Scheme code 
examples, but I would guess that it will not be hard to work out the 
corresponding C code transformation.


Regards,
 Neil

Re: scm_c_catch question

[Neil Jerram]

On 2014-08-18 03:14, Ian Grant wrote:

Hi Neil,

Sorry, I am replying to my message because I'm not on guile-devel, it
seems. I'll join later.

Thanks for clarifying that. The misleading statement in the manual is
just above the paragraph you quote: on
https://www.gnu.org/software/guile/manual/html_node/Catch.html#Catch
[2] it says

    Handler is invoked outside the scope of its own catch. If
handler
    again throws to the same key, a new handler from further up the
    call chain is invoked.

It doesn't mention pre_unwind_handler, which implies that the
statement does _not_ apply to pre_unwind_handler.


Yes, I believe it is correct that those statements do not apply to the 
pre-unwind handler.



So this should be
amended.

But it would be more useful if there were a way to allow a throw to be
aborted as I was expecting. How hard would that be to implement? If
you think the semantics are in fact different, it could be given a new
name, scm_c_catch_and_rethrow or something. What I want is something
like BSD signals semantics, where the handler is not reset when the
signal occurs.

You ask In your code, the pre-unwind handler calls failwith() and
doesn't expect it to return - so where does it jump to?

I thought I had explained that, sorry. The call to failwith() does a C
longjmp back into the CAML bytecode interpreter (i.e. back down below
the call stack into caml_main). This is not a non-local exit, as far
as Guile is concerned, because it is just a 'naked' C longjmp. So in
that sense, the second time Guile throws an exception it is being
thrown from within pre_unwind_handler.


OK, I think I see now.  From Guile's point of view, the dynamic context 
of the 'catch' remains in effect - as you want - but with a flag to say 
that the pre-unwind handler is already running (actually implemented by 
the %running-exception-handlers fluid in boot-9.scm).  That explains why 
the _next_ exception causes the catch's main handler to be called, 
instead of the pre-unwind handler again.



Is there a way to implement what I want with fluids?


I don't think so, no.  Basically what you need is to make some call, 
from the pre-unwind handler code, just before calling failwith(), that 
says this pre-unwind handler should now be reactivated and is 
implemented by removing itself from %running-exception-handlers.  But 
%running-exception-handlers is hidden inside a lexical environment, so 
that isn't possible without hacking the boot-9 code.


You could try hacking the boot-9 code, though, to see if that idea 
works, and then propose a patch.


Regards,
 Neil

Re: scm_c_catch question

[Neil Jerram]

On 2014-08-16 00:13, Ian Grant wrote:

Hello Guile types,


Hi Ian,


I have been experimenting with using libguile from within another
byte-code interpreter: Moscow ML. I have a version of Moscow ML with
an GNU lightning interface in which I JIT compile primitives to give
access to libguile functions from Standard ML.

Moscow ML uses an old version of the CAML light runtime which is a
byte-code interpreter implemented in C. The CAML runtime provides
exceptions implemented using a longjmp buffer.

The Moscow ML top-level REPL is implemented as a byte-code compiled ML
function which is invoked by main(). What I would like to do would be
to catch any unhandled Guile exceptions and re-throw them as ML
exceptions so that the toplevel isn't exit'ed by an un-handled scheme
exception. To this end I call the CAML main from the scm_boot_guile
callback, under a scm_c_catch. This code is in the guilert.c file
https://github.com/IanANGrant/red-october/blob/master/src/runtime/guilert.c
[1] The only CAML'ism here is the call to failwith(message). This
does a longjump 'into the CAML exception bucket'

The problem is that after the first successful catch by the pre-unwind
handler, the next Guile exception is handled by the main_handler. This
is not what I expected. The manual seems to say that it is only after
the main_handler is invoked, that the catch is cancelled. Is this not
the right understanding?


It was a while ago, but it was me who first implemented that pre-unwind 
handler.  So maybe I can help here.


No, I don't think that is the right understanding.  The manual (at least 
for 2.0.11) says:


 A PRE-UNWIND-HANDLER can exit either normally or non-locally.  If
 it exits normally, Guile unwinds the stack and dynamic context and
 then calls the normal (third argument) handler.  If it exits
 non-locally, that exit determines the continuation.

In either case, I believe the intention is for any exception to 
terminate the catch.  In the case where the pre-unwind handler exits 
normally, the catch is terminated after the main handler has been 
called.  In the case where the pre-unwind handler exits non-locally, I 
think it's assumed that the new context is somewhere outside of the 
catch, and hence that the catch is no longer in effect.


In either case, therefore, handling any subsequent exception should 
require establishing a new catch.


In your code, the pre-unwind handler calls failwith() and doesn't expect 
it to return - so where does it jump to?


Regards,
 Neil

Re: MinGW vs. c-api.test

[Neil Jerram]

Eli Zaretskii e...@gnu.org skribis:


From: l...@gnu.org (Ludovic Courtès)
Cc: guile-devel@gnu.org
Date: Thu, 12 Jun 2014 21:48:48 +0200

  +(define %null-device
  +  ;; On Windows (MinGW), /dev/null does not exist and we must instead
  +  ;; use NUL.  Note that file system procedures automatically translate
  +  ;; /dev/null, so this variable is only useful for shell snippets.
  +  (if (file-exists? /dev/null)
  +  /dev/null
  +  NUL))
 
  Not sure this is a good idea: I can create a file /dev/null on
  Windows, but that doesn't mean it is my null device.

 Yes, but using %host-type isn’t perfect either, no?  What would you
 prefer?

 How about testing if the absolute name of the current directory starts
 with a drive letter?

Like (string-match ^[a-zA-Z]:[/\\] (getcwd)) ?


Yes.


But my Git Bash shell on Windows (at work) gives me paths like /drive 
letter/...

For example:

  nj@PC3946 /c/work/icp (master)
  $ pwd
  /c/work/icp

I think that shell is provided by MinGW/MSYS - so does that mean that 
the regexp check

above might not be correct in all contexts on Windows?

   Neil

Re: MinGW vs. c-api.test

[Neil Jerram]

On 2014-06-13 17:19, Eli Zaretskii wrote:

From: l...@gnu.org (Ludovic Courtès)
CC: Eli Zaretskii e...@gnu.org, guile-devel@gnu.org
Date: Fri, 13 Jun 2014 18:04:57 +0200

 Like (string-match ^[a-zA-Z]:[/\\] (getcwd)) ?

 Yes.

 But my Git Bash shell on Windows (at work) gives me paths like /drive
 letter/...
 For example:

   nj@PC3946 /c/work/icp (master)
   $ pwd
   /c/work/icp


Git Bash is an MSYS program.  MSYS is a fork of an old version of
Cygwin, and the pseudo-Posix file names it returns is one of its
features, designed to make Posix shell scripts work without choking on
Windows file names with drive letters.

So this has nothing to do with native Windows programs produced by
MinGW, which is what we are discussing here: how to redirect to a null
device in a native MinGW compiled Guile whose 'system' procedure
invokes the Windows shell cmd.exe.


Isn’t it rather provided by Cygwin?


Yes, Cygwin and MSYS.


I would think that (getcwd) on Cygwin would return /c/... whereas
(getcwd) on MinGW would return C:\..., no?


The MinGW version should produce either C:\... or C:/..., yes.


Thanks for explaining.  I didn't know of the connection between MSYS and 
Cygwin.


 Neil

Re: MinGW vs. c-api.test

[Neil Jerram]

On 2014-06-09 20:32, l...@gnu.org wrote:

What’s the name of /dev/null on Windows?


NUL

For example:

  C:\Users\njecho hello NUL

  C:\Users\nj

Regards,
 Neil

WebSockets

[Neil Jerram]

Hi there,

I'm interested in adding support for WebSockets 
(http://tools.ietf.org/html/rfc6455) to Guile's web modules.  Is anyone 
else interested in - or possibly already working on - that?


Thanks,
Neil

Re: Memory accounting in libgc

[Neil Jerram]

On 2014-03-12 06:57, Mark H Weaver wrote:

Andy Wingo wi...@pobox.com writes:


How does this affect libgc?

First of all, it gives an answer to the question of how much memory
does an object use -- simply stop the world, mark the heap in two 
parts

(the first time ignoring the object in question, the second time
starting from the object), and subtract the live heap size of the 
former
from the latter.  Libgc could do this without too much problem, it 
seems

to me, on objects of any kind.  It would be a little extra code but it
could be useful.  Or not?  Dunno.


This could be generalized to the far more useful question: How much
memory does this set of objects use?, although that's a slippery
question that might better be formulated as How much memory would be
freed if this set of objects were no longer needed?.

For example, suppose you have a large data structure that is referenced
from two small header objects, A and B.  If you ask How much memory
does A use?, the answer will be the size of the small header, and 
ditto

for B.  Without being able to ask the more general question, there's no
way to find out how much would be freed by releasing both.

 Mark


Absolutely agree that this would be useful, but I suspect a problem in 
how far one can push libgc to simulate a set of objects being freed 
without them actually _being_ freed.  For example there could be 
guardians associated with the objects, and I think one can validly 
imagine them doing either of the possible extremes (or anywhere in 
between), namely:


- resurrecting the objects again

- freeing up a whole load more objects/memory that the guardians know to 
be associated with the original objects, but which wasn't (for some 
reason) simply referenced by them.


Hope that's a useful thought - interesting subject!

Neil

Re: MinGW patches

[Neil Jerram]

Eli Zaretskii e...@gnu.org writes:

 For my convenience, I prefer to prepare a real ChangeLog entry, then
 copy that to a commit message, which leaves a ChangeLog file around.
 May I add ChangeLog to libguile/.gitignore, so that ChangeLog is not
 flagged by git status?

In case you don't already know: to-be-ignored files can also be added to
.git/info/exclude.  In that case the ignoring is part of your own local
metadata, and will usefully apply retrospectively to your whole
repository, rather than being committed at a particular point to the
repository content.

Regards,
 Neil

Re: Docstring as only form in a function

[Neil Jerram]

On 2014-02-20 16:59, Arne Babenhauserheide wrote:

Hi,

I recently experimented with docstrings, and I stumbled over not being
able to define a function which only has a docstring as body:


(define (foo)
  bar)

(procedure-documentation foo)
⇒ #f


Adding a form makes the string act as docstring:


(define (foo)
  bar
  #f)

(procedure-documentation foo)
⇒ bar


I feel that this is inconsistent, which hurts even more, because it
breaks for the simplest showcase of docstrings.


My use case for using docstrings like this is that when I start writing
a function, I begin with the docstring. There I explain what I want to
do. Then I commit. Then I implement the function.


How does calling 'procedure-documentation' fit into this use case?  
Surely the most natural way, of reminding yourself what a 
not-yet-implemented function is supposed to do, is simply to look at its 
source code?


Regards,
  Neil

Re: Guile Emacs: Elisp nil/t and Guile #nil/#t

[Neil Jerram]

taylanbayi...@gmail.com (Taylan Ulrich B.) writes:

 Hi,

 It occurred to me that nil and t are basically just symbols in Elisp,
 just with some magical properties.  Like any symbol, they respond to
 symbolp, have a plist, value and symbol slot (although the value slot is
 immutable), etc.  They're self-quoting, so 'nil and 't also just return
 nil and t.  Nasty stuff.  Given all that, the #nil and #t values of
 Guile are obviously not nearly interchangeable.  Did anyone already have
 a solution in mind?

Solution for what problem?

I'm mostly just lurking on the Guile lists these days, but I did work a
while back on the Scheme/Elisp area, so I'm interested to understand the
problem.

Regards,
Neil

Re: always O_BINARY?

[Neil Jerram]

Andy Wingo wi...@pobox.com writes:

 Hi,

 Just thinking aloud here -- Windows has this O_BINARY thing that
 translates CRLF to LF when reading, and LF to CRLF when writing.  It
 seems to me to be a useless thing.  We already have our own i/o
 abstractions and should deal with CRLF vs LF in Scheme, I think:

   The (newline) function can write CRLF
   The ~% format directive should DTRT
   read-line should DTRT

 And since all of our hackers have been on POSIX systems, we're used to
 there being no O_BINARY/O_TEXT distinction.

 So, what do you think about always adding O_BINARY to files that Guile
 opens?

Maybe look at what Emacs on Windows does?  I would guess it has the same
question, and probably the same answer as you've suggested.

   Neil

Re: byte-order marks

[Neil Jerram]

Andy Wingo wi...@pobox.com writes:

 What do people think about this attached patch?

 Andy


From 831c3418941f2d643f91e3076ef9458f700a2c59 Mon Sep 17 00:00:00 2001
 From: Andy Wingo wi...@pobox.com
 Date: Mon, 28 Jan 2013 22:41:34 +0100
 Subject: [PATCH] detect and consume byte-order marks for textual ports

In case an example is of any help for this discussion, here's some code
that I wrote to consume a possible BOM on contacts data downloaded from
Google:

(define (read-csv file-name)
  (let ((s (utf16-string (get-bytevector-all (open-input-file file-name))
  'little)))

;; Discard possible byte order mark.
(if (and (= (string-length s) 1)
 (char=? (string-ref s 0) #\xfeff))
(set! s (substring s 1)))

...))

I wonder if I chose to use utf16-string because there wasn't - at that
time - a way of handling the BOM without slurping into a string first?
However it was a long time ago now so I really can't be sure what the
context was. 

Regards,
Neil

Re: byte-order marks

[Neil Jerram]

Andy Wingo wi...@pobox.com writes:

 On Tue 29 Jan 2013 20:22, Neil Jerram n...@ossau.homelinux.net writes:

 (define (read-csv file-name)
   (let ((s (utf16-string (get-bytevector-all (open-input-file file-name))
'little)))

 ;; Discard possible byte order mark.
 (if (and (= (string-length s) 1)
   (char=? (string-ref s 0) #\xfeff))
  (set! s (substring s 1)))

 ...))

 FWIW the procedure I had was:

 (define (consume-byte-order-mark port)
   (let ((enc (or (port-encoding port) ISO-8859-1)))
 (set-port-encoding! port ISO-8859-1)
 (case (peek-char port)
   ((#\xEF)
(read-char port)
(case (peek-char port)
  ((#\xBB)
   (read-char port)
   (case (peek-char port)
 ((#\xBF)
  (read-char port)
  (set-port-encoding! port UTF-8))
 (else
  (unread-char #\xBB port)
  (unread-char #\xEF port)
  (set-port-encoding! port enc
  (else
   (unread-char #\xEF port)
   (set-port-encoding! port enc
   ((#\xFE)
(read-char port)
(case (peek-char port)
  ((#\xFF)
   (read-char port)
   (set-port-encoding! port UTF-16BE))
  (else
   (unread-char #\xFE port)
   (set-port-encoding! port enc
   ((#\xFF)
(read-char port)
(case (peek-char port)
  ((#\xFE)
   (read-char port)
   (set-port-encoding! port UTF-16LE))
  (else
   (unread-char #\xFF port)
   (set-port-encoding! port enc
   (else
(set-port-encoding! port enc)

 The encoding dance is because there is no unread-u8 from Scheme, only
 unread-char.

I can see why you'd want to do something about that!

Regards,
Neil

Re: Running non-scheme scripts: some thoughts

[Neil Jerram]

William ML Leslie william.leslie@gmail.com writes:

 For most entry-points, there is no extension. When you install your
 program, you normally install it as /usr/bin/foo, rather than
 /usr/bin/foo.[ss|scm|py|js|whatever].  This is the motivation for
 guile-foo symlinks or --lang options.  I favour the symlinks slightly,
 because not all languages are going to work with guile's extended
 mesh-wow system, and indirection via env already costs you one
 argument.

Yes, and in the hoped future when Guile runs Python better and faster
than any other implementation, we certainly need the symlinks so that
someone can do

# cd /usr/bin  rm python  ln -s guile-python python

to let Guile run all existing Python programs on their system.

Then, clearly, guile-python needs to handle all the command line
arguments that are traditional for Python - not the traditional Guile
arguments - and munge them into a suitable startup incantation/sequence
for Guile.

And then there are two detailed arguments which both suggest handling
guile-python within the main Guile executable, instead of in an
accompanying shell script.  Firstly it's more flexible to transform
guile-python arguments directly into Guile startup code, instead of a
two step transformation first to traditional Guile arguments and then to
code.  (What if there isn't an appropriate traditional Guile argument?)
Secondly it feels more maintainable and integrated to have that logic
within the main Guile code, instead of in a shell script to one side.

I think that means the necessary support should be added to
compile-shell-switches in (ice-9 command-line), and to the C code in
script.c that calls that, to allow compile-shell-switches to set up for
different languages according to $0.

Regards,
Neil

Re: a few proposed patches

[Neil Jerram]

Ken Raeburn raeb...@raeburn.org writes:

 * Require libgc 7.2 or better.  Too often the fix to flaky problems
 seems to be try updating to the latest libgc and see if that fixes
 it, so let's just require it.  Or is 7.1 really *that* consistently
 reliable for our use cases on some platforms?

7.2 is required for ARM.  (At least, there are fixes between 7.1 and 7.2
that are definitely required for ARM.  I haven't yet tried the 7.2
release exactly.)

Regards,
Neil

Re: our benchmark-suite

[Neil Jerram]

Andy Wingo wi...@pobox.com writes:

 Neat :)  (Do you pngcrush these?  They seem a little slow to serve.)

I just tried running pngcrush on all the .pngs, and didn't get more than
6-8% reduction.  So unfortunately it doesn't look like that would help
much.

Thanks for the idea though!

 Neil

Re: Making every goops object applicable

[Neil Jerram]

Mark H Weaver m...@netris.org writes:

 Krister Svanlund krister.svanl...@gmail.com writes:
 For example an instance of a class inheriting a class that inherits
 applicable-struct that defines 'procedure is not applicable.

 Looking at the code, it is clear that in order for a GOOPS instance to
 be applicable, it is not enough for applicable-struct to be a
 superclass.  It is also necessary for the _metaclass_ of its class to
 have the SCM_VTABLE_FLAG_APPLICABLE_VTABLE bit set.

 One such metaclass is already built-in: applicable-struct-class, which
 is the metaclass for applicable-struct,

So the solution to Krister's problem is to make sure that every class
he's interested in is defined as

  (define-class whatnot (supers...)
...
#:metaclass applicable-struct-class)

Right?

 but if you'd like to define
 your own metaclass for applicable objects, you can set the bit manually
 on the metaclass as described by Ludovic.

Would this be needed, if the above works?

 However, keep in mind that the presence of that bit in the metaclass
 indicates that the first slot of all instances _must_ be the procedure
 slot.

Might the (define-class ... #:metaclass applicable-struct-class)
ensure that, by some kind of of compute-slots customisation...?  I took
a look but unfortunately couldn't see this in the code.

   Neil

Re: our benchmark-suite

[Neil Jerram]

 For http://ossau.homelinux.net/~neil I do still have all of the raw data
 including iteration counts, so I could easily implement dividing by the
 iteration count, and hence allow for future iteration count changes.

 Is there any downside from doing that?  (I don't think so.)

 No, I guess.  And as you show, having raw data instead of synthesized
 figures gives more freedom.

It turns out I'm already scaling by iteration count - in fact since
November 2009. :-)

Still, I wanted to do something new, so I've added further graphs
showing just the last 50 measurements for each benchmark (whereas the
existing graphs showed all measurements since my data collection
began).  The generation of those is still running at the moment, but
should be complete in an hour or so.

Regards,
Neil

Re: our benchmark-suite

[Neil Jerram]

l...@gnu.org (Ludovic Courtès) writes:

 My proposal is to rebase the iteration count in 0-reference.bm to run
 for 0.5s on some modern machine, and adjust all benchmarks to match,
 removing those benchmarks that do not measure anything useful.

 Sounds good.  However, adjusting iteration counts of the benchmarks
 themselves should be done rarely, as it breaks performance tracking like
 http://ossau.homelinux.net/~neil/bm_master_i.html.

 Finally we should perhaps enable automatic scaling of the iteration
 count.  What do folks think about that?

 On the positive side, all of our benchmarks are very clear that they are
 a time per number of iterations, and so this change should not affect
 users that measure time per iteration.

 If the reported time is divided by the global iteration count, then
 automatic scaling of the global iteration count would be good, yes.

For http://ossau.homelinux.net/~neil I do still have all of the raw data
including iteration counts, so I could easily implement dividing by the
iteration count, and hence allow for future iteration count changes.

Is there any downside from doing that?  (I don't think so.)

Regards,
Neil

Re: Comments on ‘wip-nio’

[Neil Jerram]

Andy Wingo wi...@pobox.com writes:

 On Thu 22 Mar 2012 22:36, Neil Jerram n...@ossau.homelinux.net writes:

 It seems like the module has to anticipate the main loop infrastructure
 that any using programs will use - which isn't a nice solution.

 How about, you write your code in such a way that it deals with eports.
 You could surround your code in a prompt that if an eport operation
 aborts because it would block, you save the continuation and ask your
 main loop to call you again when the port is readable / writable.  When
 it calls you again you resume the partial continuation.

 If you need to sleep, you use sleep from (ice-9 ethreads).  Somehow we
 make it so that ethreads can use other main loops, like the dbus, efl,
 etc loops.

 Dunno.  So many possibilities!

Thanks for the ideas.  I unfortunately have a bit of a cognitive deficit
backlog before I can understand them fully.  I haven't yet understand
prompts properly, and I see that ethreads are built on top of those.
But I'll continue working at it!

 Neil

Re: Comments on ‘wip-nio’

[Neil Jerram]

l...@gnu.org (Ludovic Courtès) writes:

 Hi,

 Nala Ginrut nalagin...@gmail.com skribis:

 On Thu, Mar 22, 2012 at 6:39 AM, Ludovic Courtès l...@gnu.org wrote:

 Hello,

 I had a quick look at ‘wip-nio’, and here are initial comments.

  • epoll is Linux-specific.  Any idea how a more multi-platform API
could be provided?  I guess libevent could be used, but we don’t
want to add one more dependency in 2.0.  How much is (ice-9 nio)
dependent on epoll vs. poll, for instance?


 Maybe add a module named (ice-9 linux)? And we may add more
 Linux-specific things.

 I’d rather have (ice-9 event) or such, and do our best to provide a
 portable implementation of the feature.

Here's another thought on requirements that might feed into that kind of
support.

I've recently been doing some UI programming, that also 
involves D-Bus.  Now the UI is Enlightenment, so my program's main loop
is the Enlightenment main loop (ecore_main_loop_begin).  But if the UI
used Gtk instead, then obviously the main loop would be gtk_main_loop.

Now consider another module that's mostly dealing with a D-Bus API.
This module has situations where it wants to implement try calling this
API again in 10 seconds time (possibly sadly, because it shouldn't have
to poll; but let's say that it does anyway).  How does it do that, while
integrating with the main loop of whatever programs might be using that
module?

It seems like the module has to anticipate the main loop infrastructure
that any using programs will use - which isn't a nice solution.

Having written this, I've realised that in the D-Bus case the module is
actually constrained already, because the concept of being able to
receive a D-Bus signal already implies integration with some kind of
main loop infrastructure.  In my case that's GDBus/GIO/glib, and the
integration with the Enlightenment UI is handled by calling
ecore_main_loop_glib_integrate; but I would guess that there are cases
where a module isn't already constrained like this, and still might want
to use a do X in N seconds time function.

Regards,
Neil

Re: Build/performance trouble?

[Neil Jerram]

l...@gnu.org (Ludovic Courtès) writes:

 Hi Neil!

 Thanks for keeping those benchs running!

No prob; it all just runs itself.

Except... that there does now seem to be a significant problem with
master's compilation time.  In practice this is now taking so long that
it has no chance of completing (on my build machine) within a day.
Hence for now I'm going to disable the master build.

 Neil Jerram n...@ossau.homelinux.net skribis:

 Also, looking at the benchmark graphs at
 http://ossau.homelinux.net/~neil/bm_master_i.html, there's a bunch of
 benchmarks related to latin-1 / UTF-8 that are apparently taking 100s of
 times longer than they used to.  This applies both to master and
 stable-2.0.

 Commit da35d2eaa9dbc1d3cf098c9a1c9bc62dcb2515bd changes ‘ports.bm’ in a
 way that affects timings, which is what we observe on the graphs of
 these specific benchmarks.

Ah right, thanks for pointing that out.

 Neil

Re: Trouble using (current-filename)

[Neil Jerram]

Noah Lavine noah.b.lav...@gmail.com writes:

 Hello,

 What ever happened to this issue? Is it considered resolved now, or is
 there more to do?

For my use case it's resolved, in the sense that I really needed a
runtime directory that may not be the same as the source compilation
location; and hence 'current-filename' wasn't the right solution after
all.

For other use cases, I guess it depends what those are.

 Neil

Build/performance trouble?

[Neil Jerram]

FYI, something seems awry in my automatic daily Guile build.

I noticed that the build machine is spending much longer churning away
than it normally does.  Today I found that this is while building the
master branch, and that it apparently spent all day trying
unsuccessfully to

  GUILEC language/tree-il/analyze.go

Also, looking at the benchmark graphs at
http://ossau.homelinux.net/~neil/bm_master_i.html, there's a bunch of
benchmarks related to latin-1 / UTF-8 that are apparently taking 100s of
times longer than they used to.  This applies both to master and
stable-2.0.

The latter may be a red herring, though, because my build log for
stable-2.0 indicates a backtrace in the middle of the benchmarking,
again related to latin-1:

(the interleaving of stdout and sterr here may not be significant)

...
(srfi-13.bm: strings: modification: comparison: hash hash-ci 1000 user 0.24 
benchmark 0.23968147277832 bench/interp 0.23968147277832 gc 0.0)
(srfi-13.bm: strings: searching: prefix-length suffix-length 270 user 0.16 
benchmark 0.159913997650146 bench/interp 0.159913997650146 gc 0.0)
(srfi-13.bm: strings: searching: prefix? suffix? 270 user 0.16 benchmark 
0.159913997650146 bench/interp 0.159913997650146 gc 0.0)
(srfi-13.bm: strings: searching: i;;; note: auto-compilation is enabled, set 
GUILE_AUTO_COMPILE=0
;;;   or pass the --no-auto-compile argument to disable.
;;; compiling 
/home/neil/guile-build-tracking/stable-2.0/benchmark-suite/guile-benchmark
;;; compiling /home/neil/guile-build-tracking/stable-2.0/benchmark-suite/lib.scm
;;; compiled 
/home/neil/guile-build-tracking/stable-2.0/cache/guile/ccache/2.0-LE-4-2.0/home/neil/guile-build-tracking/stable-2.0/benchmark-suite/lib.scm.go
;;; compiled 
/home/neil/guile-build-tracking/stable-2.0/cache/guile/ccache/2.0-LE-4-2.0/home/neil/guile-build-tracking/stable-2.0/benchmark-suite/guile-benchmark.go
;;; compiling 
/home/neil/guile-build-tracking/stable-2.0/benchmark-suite/benchmarks/0-reference.bm
;;; compiled 
/home/neil/guile-build-tracking/stable-2.0/cache/guile/ccache/2.0-LE-4-2.0/home/neil/guile-build-tracking/stable-2.0/benchmark-suite/benchmarks/0-reference.bm.go
;;; compiling 
/home/neil/guile-build-tracking/stable-2.0/benchmark-suite/benchmarks/arithmetic.bm
;;; compiled 
/home/neil/guile-build-tracking/stable-2.0/cache/guile/ccache/2.0-LE-4-2.0/home/neil/guile-build-tracking/stable-2.0/benchmark-suite/benchmarks/arithmetic.bm.go
;;; compiling 
/home/neil/guile-build-tracking/stable-2.0/benchmark-suite/benchmarks/bytevectors.bm
;;; compiled 
/home/neil/guile-build-tracking/stable-2.0/cache/guile/ccache/2.0-LE-4-2.0/home/neil/guile-build-tracking/stable-2.0/benchmark-suite/benchmarks/bytevectors.bm.go
;;; compiling 
/home/neil/guile-build-tracking/stable-2.0/benchmark-suite/benchmarks/chars.bm
;;; compiled 
/home/neil/guile-build-tracking/stable-2.0/cache/guile/ccache/2.0-LE-4-2.0/home/neil/guile-build-tracking/stable-2.0/benchmark-suite/benchmarks/chars.bm.go
;;; compiling 
/home/neil/guile-build-tracking/stable-2.0/benchmark-suite/benchmarks/continuations.bm
;;; compiled 
/home/neil/guile-build-tracking/stable-2.0/cache/guile/ccache/2.0-LE-4-2.0/home/neil/guile-build-tracking/stable-2.0/benchmark-suite/benchmarks/continuations.bm.go
;;; compiling 
/home/neil/guile-build-tracking/stable-2.0/benchmark-suite/benchmarks/if.bm
;;; compiled 
/home/neil/guile-build-tracking/stable-2.0/cache/guile/ccache/2.0-LE-4-2.0/home/neil/guile-build-tracking/stable-2.0/benchmark-suite/benchmarks/if.bm.go
;;; compiling 
/home/neil/guile-build-tracking/stable-2.0/benchmark-suite/benchmarks/logand.bm
;;; compiled 
/home/neil/guile-build-tracking/stable-2.0/cache/guile/ccache/2.0-LE-4-2.0/home/neil/guile-build-tracking/stable-2.0/benchmark-suite/benchmarks/logand.bm.go
;;; compiling 
/home/neil/guile-build-tracking/stable-2.0/benchmark-suite/benchmarks/ports.bm
;;; compiled 
/home/neil/guile-build-tracking/stable-2.0/cache/guile/ccache/2.0-LE-4-2.0/home/neil/guile-build-tracking/stable-2.0/benchmark-suite/benchmarks/ports.bm.go
;;; compiling 
/home/neil/guile-build-tracking/stable-2.0/benchmark-suite/benchmarks/r6rs-arithmetic.bm
;;; compiled 
/home/neil/guile-build-tracking/stable-2.0/cache/guile/ccache/2.0-LE-4-2.0/home/neil/guile-build-tracking/stable-2.0/benchmark-suite/benchmarks/r6rs-arithmetic.bm.go
;;; compiling 
/home/neil/guile-build-tracking/stable-2.0/benchmark-suite/benchmarks/read.bm
;;; compiled 
/home/neil/guile-build-tracking/stable-2.0/cache/guile/ccache/2.0-LE-4-2.0/home/neil/guile-build-tracking/stable-2.0/benchmark-suite/benchmarks/read.bm.go
;;; compiling 
/home/neil/guile-build-tracking/stable-2.0/benchmark-suite/benchmarks/srfi-1.bm
;;; compiled 
/home/neil/guile-build-tracking/stable-2.0/cache/guile/ccache/2.0-LE-4-2.0/home/neil/guile-build-tracking/stable-2.0/benchmark-suite/benchmarks/srfi-1.bm.go
;;; compiling 
/home/neil/guile-build-tracking/stable-2.0/benchmark-suite/benchmarks/srfi-13.bm
;;; compiled 

Re: Build/performance trouble?

[Neil Jerram]

Neil Jerram n...@ossau.homelinux.net writes:

 FYI, something seems awry in my automatic daily Guile build.

 I noticed that the build machine is spending much longer churning away
 than it normally does.  Today I found that this is while building the
 master branch, and that it apparently spent all day trying
 unsuccessfully to

   GUILEC language/tree-il/analyze.go

 Also, looking at the benchmark graphs at
 http://ossau.homelinux.net/~neil/bm_master_i.html, there's a bunch of
 benchmarks related to latin-1 / UTF-8 that are apparently taking 100s of
 times longer than they used to.  This applies both to master and
 stable-2.0.

 The latter may be a red herring, though, because my build log for
 stable-2.0 indicates a backtrace in the middle of the benchmarking,
 again related to latin-1:

OK, I think the benchmark backtrace/performance is caused by me having
inadvertently uninstalled my French locales recently.  I've reinstalled
them now, so hopefully those benchmarks will return to normal
performance.

I doubt that's related to the problem compiling analyze.go though - I'll
see if I still see that tomorrow.

   Neil

Re: Dotted pair call argument

[Neil Jerram]

Mark H Weaver m...@netris.org writes:

 However, (f . (g x y)) is read as (f g x y), so it's impossible for
 'eval' to distinguish these two cases.  Unfortunately, (f g x y) has a
 very different meaning than (apply f (g x y)).  The first means to apply
 'f' to three arguments.  The second means to apply 'g' to two arguments,
 and then apply 'f' to the list of arguments resulting from (g x y).

Thanks, Mark.  I've often wondered the same thing as David, so I
appreciate your explanation.

Neil

Re: Trouble using (current-filename)

[Neil Jerram]

Sorry for chipping in late to this discussion.

l...@gnu.org (Ludovic Courtès) writes:

 I think it’s often undesirable.

 Suppose you want to use ‘current-filename’ in an ‘assert’ macro, for
 instance: what you want is a hint, not an absolute path, since that path
 is likely to be invalid at the time you see it (for instance, it could
 point to the source tree on a build machine of your distro.)

Or suppose that a script and accompanying module set is compiled in the
build tree, then installed or relocated elsewhere.  In this case, what
I'd be looking for, with this

 (add-to-load-path ...)

stuff, would be to discover the location of the running script file
_now_, and to construct a load path element relative to that.  If I'm
understanding correctly, 'current-filename' would give me the wrong
answer in that case too, because it would have the
pre-install/relocation location.

Perhaps after all the right thing, for my use case, is something based
on (car (command-line)) and (getcwd).  I currently have this
'compatibility definition' for Guile 1.8.x:

  (define (current-filename)
(let* ((script (car (command-line)))
   (scriptdir (dirname script))
   (absdir (cond ((string=? scriptdir .)
  (getcwd))
 ((string-match ^/ scriptdir)
  scriptdir)
 (else
  (in-vicinity (getcwd) scriptdir)
  (in-vicinity scriptdir (basename script

But maybe that's the better solution for 2.x as well.

Regards,
  Neil

Re: Trouble using (current-filename)

[Neil Jerram]

l...@gnu.org (Ludovic Courtès) writes:

 Hi Neil!

 Neil Jerram n...@ossau.homelinux.net skribis:

 Perhaps after all the right thing, for my use case, is something based
 on (car (command-line)) and (getcwd).  I currently have this
 'compatibility definition' for Guile 1.8.x:

   (define (current-filename)
  (let* ((script (car (command-line)))
 (scriptdir (dirname script))
 (absdir (cond ((string=? scriptdir .)
(getcwd))
   ((string-match ^/ scriptdir)
scriptdir)
   (else
(in-vicinity (getcwd) scriptdir)
(in-vicinity scriptdir (basename script

 But maybe that's the better solution for 2.x as well.

 Yes, for that case, you definitely want something that happens at
 run-time, pretty much like $ORIGIN in ELF files.

OK thanks.  I think that means you can disregard my use case when
considering the future of 'current-filename', then.

   Neil

Re: manual examples - self contained or not?

[Neil Jerram]

Nala Ginrut nalagin...@gmail.com writes:

 well, I don't believe in copy-paste code too.
 But my vote would be at least I can trust the official manual...

I did think it would be nice, a while back, if we could implement a way
of automatically checking that the examples in the manual are still
correct, and that they generate the results that the manual says they
do.  I think that would contribute to being able to trust the manual, or
else flag up any areas that might have rotted a bit.

In order to do that, without requiring too much special casing code, the
checker would need to be able to identify any required module uses.

So, in addition to the direct benefit for people reading the manual, I
think that motivates that the example should be by some definition self
contained.  As others have suggested, I'd favour automatically picking
up (use-modules ...) forms from earlier or higher up in the current
hierarchy, so that it isn't necessary to keep repeating those in every
@example.

Does anyone fancy the automatic checking project?

  Neil

Re: Thread+GC issues on ARM

[Neil Jerram]

Rob Browning r...@defaultvalue.org writes:

 Though if it wasn't too difficult to come up with a reasonable patch,
 we could ask the Debian libgc maintainer to apply it to the older
 version.

I don't yet know if there is such a patch.  I can imagine a procedure
for trying to find it: first git bisect to find the oldest libgc source
for which Guile builds and passes make check, then, either automatically
or by hand, try to identify the precise commits, up to that point, that
are what Guile needs...  But I think this would be difficult and
time-consuming.  Let's wait for a while first to see if the 7.2 release
materialises!

   Neil

Re: Thread+GC issues on ARM

[Neil Jerram]

Hi Rob,

First of all, thanks for pushing 2.0.5 into Debian so quickly!

Rob Browning r...@defaultvalue.org writes:

 Neil Jerram n...@ossau.homelinux.net writes:

 Rob Browning r...@defaultvalue.org writes:

 So do I understand correctly that in order for this to work, we'll first
 need an updated libgc in Debian unstable?

 Yes.

It appears to me that the libgc folk think they're very nearly ready for
a 7.2 release.  But they're very cautious about that, and the most
recent talk I've seen is of having to make a further (but hopefully
last) alpha release first.

On the assumption of using recent libgc git source, I'm still working on
what Guile fixes, if any, are needed on top of that, for armel.  I have
a set of fixes that works, but it may not be a minimal set.

 Great.  If we can get this and the s390 problem fixed, I'll be able to
 see about removing 1.8 from Debian testing (which I'd love to do soon --
 I'd really like to drop 1.8 from the upcoming release).

Out of interest, what are your criteria for dropping 1.8?  Is it simply
if everything else in Debian that depends on guile can be made to work
with 2.0?  Is / should there be any consideration for continuing to
provide guile-1.8 as a legacy programming environment?  Personally I'd
feel comfortable if the answer to that was no - because I think it's
positive overall to concentrate everyone's mindshare on the present and
future, and because I'm not aware of any significant support having been
lost - but just wondering.

 If so, I'll probably hold off on the guile patch for now.

 Sure.  I'm happy that it's with me, for the moment, to propose something
 coherent to the libgc maintainer.

 Could this also be related to the other current 2.0.5 arm(el|hf)
 failures:

   https://buildd.debian.org/status/package.php?p=guile-2.0suite=sid
   http://debbugs.gnu.org/cgi/bugreport.cgi?bug=10646

I don't know.  Would you like me to provide you with my current libgc
and guile changes, which give a successful build on armel, so that you
can see if they work on armhf too?

Regards,
Neil

Re: Thread+GC issues on ARM

[Neil Jerram]

Neil Jerram n...@ossau.homelinux.net writes:

 On the assumption of using recent libgc git source, I'm still working on
 what Guile fixes, if any, are needed on top of that, for armel.  I have
 a set of fixes that works, but it may not be a minimal set.

It turns out that no Guile fixes are needed after all.  So as far as
Guile on armel is concerned, we only need a new libgc release.

(The history here was that I tried some Guile fixes first, with 7.1-8,
then upgraded the libgc source, and hadn't yet tried reverting the Guile
fixes.)

  Neil

Re: [PATCH] Doc: protecting procedure-pointer pointers from GC

[Neil Jerram]

l...@gnu.org (Ludovic Courtès) writes:

 Looks great!  I had a glance at the E17 bindings, and I see that the API
 uses raw pointer objects; using “wrapped pointer types” would provide
 type checking, and a nicer UI if you add printers.  :-)

That's an excellent point; yes, I'll do that.  Using wrapped pointer
types, it should then be the case that no naked pointer values ever
go in or out from the module that provides the binding - which feels
like a nice property. 

Neil

Re: guile contributor setup

[Neil Jerram]

Andy Wingo wi...@pobox.com writes:

 On Thu 02 Feb 2012 15:44, Catonano caton...@gmail.com writes:

 I'm considering the idea of trying to contribute some Scheme code to
 guile, and I'm running into some issues with emails, patches, git and
 the such.

 What's the common setup you people use ?

 I use git, from the command line and from Emacs.  When I use it from
 Emacs, I use magit: http://philjackson.github.com/magit/

 I mostly use magit to commit, and otherwise the command line to update,
 rebase, etc.  I use gitk sometimes to get a graphical representations of
 the big picture.

 When I make a patch and want to mail it, I use magit to commit it with a
 nice log.  Then on the command-line I do git format-patch
 origin/stable-2.0..HEAD and that spits out one file for each commit I
 made that is not in upstream stable-2.0.  I then attach them to mails.

FWIW, 100% snap!

Neil

Re: [PATCH] Doc: protecting procedure-pointer pointers from GC

[Neil Jerram]

Andy Wingo wi...@pobox.com writes:

 On Mon 30 Jan 2012 22:32, Neil Jerram n...@ossau.homelinux.net writes:

 Following debugging of a strange issue where oFono appeared to be
 sending a D-Bus signal from the wrong object, but I eventually realised
 that the problem was in my own code...

 The docs are good, but the example is irritating ;)  Is there a reason
 you are unable to use guile-gnome for the object wrapping?  You can use
 the FFI to call scm_from_gtype_instance or whatever it's called, after
 loading (gnome gobject).

Because Ludo and you have made it so easy to be productive with just
(system foreign) !

But your implication is right, it is a more interesting and complex
question than just that.

My current project is a phone application for the GTA04, which is an ARM
device with most of the promising software stacks being Debian-based.
Hence, aside from Guile itself - where I still have some fixing and
upstreaming to do - I'd ideally like not to take on any dependencies
other than things that are already available for ARM in Debian unstable.
I didn't actually go ahead and check beforehand whether a Guile
2-compatible guile-gnome was available, but I know that guile-2.0 itself
has only recently landed in Debian, so I guess I assumed a compatible
guile-gnome was very unlikely to be available yet.  (And, on checking, I
believe that's still correct.)

So then it would be a matter of building and packaging guile-gnome for
my device.  I remember that from Nokia 770 days...  It's quite doable,
but it takes time (and requires slib and g-wrap first, IIRC), and
compared with that it's way easier, and doesn't impede the hack, just to
grab the entry points that I need using pointer-procedure.

Another relevant factor is that I need relatively few guile-gnome entry
points because I'm only using gobject/glib to get gdbus, and the UI is
built with Edje, not Gtk/Gnome.  In fact it's a strange (but IMO fun)
hotchpotch:

- Edje/Evas for the UI (using 17 pointer-procedures)

- GDBus to access the oFono D-Bus API (using pointer-procedures: 3
  for basic GObject stuff, 11 for GVariant handling, and 2 for GDBus).

and I will probably add in more stuff for audio routing (PulseAudio?)
and accessing contact information (whatever the latest evolution of
Evolution Data Services is).

But even if I needed a lot more guile-gnome APIs, I'd (at least
initially) be tempted to grab a .defs file and try to hack something
based on that, rather than compiling C code...

I think the key benefit is that the (system foreign) approach is so
immediate.  I just add whatever API I need there, and the hack
continues...

My only reservation - and quite a big one - is that it's a bit like
going back in time to when compilers had no type checking for pointers.
In that sense it is rather fast and loose, compared to C programming.

But overall I love it, and I'd suggest that an alternative question (to
the one you asked above) would be why do you think we need bindings
anymore?

Well I hope that's of interest, and I'm sure you'll have interesting
counter-thoughts...  In case you or anyone wants to look at the code,
I've pushed it to http://git.savannah.gnu.org/cgit/ossaulib.git/.  The
main script is at scripts/phone.

Neil

Re: GNU Guile 2.0.4 released

[Neil Jerram]

l...@gnu.org (Ludovic Courtès) writes:

 ... and I forgot to bump the SONAME.  :-/

 I guess I have to push a 2.0.5 tarball now?  Thoughts?

I'm afraid I've forgotten the implications of that...

But congratulations and thanks for the release anyway; for my FFI
hacking I particularly appreciate the fixes related to
procedure-pointer and GC.

   Neil

[PATCH] Doc: protecting procedure-pointer pointers from GC

[Neil Jerram]

Following debugging of a strange issue where oFono appeared to be
sending a D-Bus signal from the wrong object, but I eventually realised
that the problem was in my own code...

Neil

From 02d80ad14c3bb8f89d7ba807dac658be6dd06df1 Mon Sep 17 00:00:00 2001
From: Neil Jerram n...@ossau.homelinux.net
Date: Mon, 30 Jan 2012 21:12:37 +
Subject: [PATCH] Doc: protecting procedure-pointer pointers from GC

* doc/ref/api-foreign.texi (Dynamic FFI): New text covering when pointers
  need to be retained.
---
 doc/ref/api-foreign.texi |   33 +
 1 files changed, 33 insertions(+), 0 deletions(-)

diff --git a/doc/ref/api-foreign.texi b/doc/ref/api-foreign.texi
index 6ece7f8..19d6b29 100644
--- a/doc/ref/api-foreign.texi
+++ b/doc/ref/api-foreign.texi
@@ -961,6 +961,39 @@ function can be made accessible to Scheme (@pxref{Array Sort Function,
 
 And voil@`a!
 
+If you use @code{procedure-pointer} to pass a Scheme procedure as a
+callback for a C library to invoke asynchronously later --- for example,
+as a handler for a D-Bus signal --- you must somehow keep a reference to
+the pointer that @code{procedure-pointer} returns, for as long as the C
+library might invoke the callback.  Otherwise the pointer can be
+prematurely garbage collected, leading to unsafe and arbitrary behaviour
+if the now-invalid callback is called.
+
+This example, which registers a Scheme procedure as a handler for a
+GObject signal, uses @code{make-object-property} to do that:
+
+@example
+(define gobject-signal-handlers (make-object-property))
+
+(define (gobject-connect object signal proc)
+  (let ((ptr (procedure-pointer void
+ (lambda (...C callback args...)
+   (proc ...Scheme args...))
+ (list ...C callback types...
+;; Protect the pointer from being prematurely collected.
+(set! (gobject-signal-handlers object)
+  (acons signal
+ ptr
+ (or (gobject-signal-handlers object) '(
+;; Register the handler.
+(g_signal_connect_data object
+   (string-pointer signal)
+   ptr
+   %null-pointer
+   %null-pointer
+   0)))
+@end example
+ 
 Note that @code{procedure-pointer} is not supported (and not defined)
 on a few exotic architectures.  Thus, user code may need to check
 @code{(defined? 'procedure-pointer)}.  Nevertheless, it is available on
-- 
1.7.8.3

Re: add-relative-load-path ?

[Neil Jerram]

Andy Wingo wi...@pobox.com writes:

 Hi,

 On Mon 23 Jan 2012 16:45, l...@gnu.org (Ludovic Courtès) writes:

 Andy Wingo wi...@pobox.com skribis:

   (add-to-load-path (dirname (dirname (current-filename

 What about calling it ‘current-file-name’ instead?

I sympathise with that too, although I know I was inconsistent in my own
last email in this thread.

(apropos filename)
   (guile): set-module-filename!   #procedure 1546f20 at 
 ice-9/boot-9.scm:1712:2 (module val)
   (guile): module-filename#procedure 1546fa0 at ice-9/boot-9.scm:1712:2 
 (module)
   (guile): current-filename
   (guile): set-port-filename! #procedure set-port-filename! (_ _)
   (guile): port-filename  #procedure port-filename (_)
   (ice-9 readline): filename-completion-function  #procedure 
 filename-completion-function (_ _)
(apropos file-name)


 Though I am responsible for three of those, I think I was just following
 established convention.

Hmm, tricky to argue with that though.

Neil

Re: add-relative-load-path ?

[Neil Jerram]

Andy Wingo wi...@pobox.com writes:

 Hi Neil,

 Thanks for the feedback!

 On Sun 22 Jan 2012 00:17, Neil Jerram n...@ossau.homelinux.net writes:

 Thing 1 is that (current-filename) can return a relative filename, or a
 filename with a ./ in its middle
 [...]

 Would there be any downside from putting [canonicalize-path] inside
 current-filename, so that current-filename always returns a canonical
 file name?

 No, and I think that is the right thing to do in this case, because it
 avoids embedding assumptions about the current working directory into
 compiled .go files.  I have made this change.

Thanks.

 Thing 2 is that it remains slightly inelegant to cater for both 1.8 and
 2.0.  I think the minimal complete solution is to write

 (cond-expand (guile-2 (include setup-load-path.scm))
  (else (load setup-load-path.scm)))

 at top level in every uninstalled script, and then something like

 (cond-expand (guile-2
(add-to-load-path
 (dirname
  (dirname
   (canonicalize-path (current-filename))
   (else
   ;; Less elegant code for 1.8...
(let* ((bindir (dirname (car (command-line
   (absdir (cond ((string=? bindir .)
  (getcwd))
 ((string-match ^/ bindir)
  bindir)
 (else
  (in-vicinity (getcwd) bindir)
  (set! %load-path (cons (in-vicinity absdir ..)
 %load-path)

 in setup-load-path.scm.

 But without a time machine I don't think anything can be done to make
 either of those fragments more concise.

 Well, you could instead do:

   (cond-expand ((not guile-2) (load guile-2.0-compat.scm)))

Well it seems it has to be

  (cond-expand (guile-2)
   (else (load guile-2.0-compat.scm)))

because cond-expand errors if no clause is satisfied.

   (add-to-load-path (dirname (dirname (current-filename

 Then in guile-2.0-compat.scm you have shims to make guile 1.8 offer a
 2.0 interface (in this case, current-filename and add-to-load-path).

But yes, indeed that is nicer, and it obviously generalises to other
compatibility issues too.  Thanks for the idea!

Regards,
Neil

Fun (system foreign) / D-Bus / oFono hacking

[Neil Jerram]

Just in case anyone else is interested in these areas...  I had a really
fun time today using the dynamic FFI to hack up Guile code to access
oFono's D-Bus API.  It's really great to be able to do this, even if it
might be more efficient in the long run to write a proper C binding.

I've attached the extremely-thrown-together code below.  Obviously it
ought to evolve (at least) into a more generic D-Bus module, and an
oFono-specific module that uses that, but right now I'm just playing...

  Neil




(use-modules (system foreign)
 (rnrs bytevectors))


(define gobject (dynamic-link libgobject-2.0))
(define glib (dynamic-link libglib-2.0))
(define gio (dynamic-link libgio-2.0))

(write gobject)
(newline)
(write glib)
(newline)
(write gio)
(newline)

(dynamic-call g_type_init gobject)

(define FALSE 0)
(define TRUE 1)

(define g_main_loop_new
  (pointer-procedure '*
  (dynamic-func g_main_loop_new glib)
  (list '* int)))

(define loop (g_main_loop_new %null-pointer FALSE))

(write loop)
(newline)

(define g_dbus_proxy_new_for_bus_sync
  (pointer-procedure '*
  (dynamic-func g_dbus_proxy_new_for_bus_sync gio)
  (list int ; bus type
int ; flags
'*  ; interface info
'*  ; bus name
'*  ; object path
'*  ; interface name
'*  ; cancellable
'*  ; error
)))


;; bus type
(define G_BUS_TYPE_SYSTEM 1)
(define G_BUS_TYPE_SESSION 2)

;; flags
(define G_DBUS_PROXY_FLAGS_NONE 0)

(define manager-proxy
  (g_dbus_proxy_new_for_bus_sync G_BUS_TYPE_SYSTEM
 G_DBUS_PROXY_FLAGS_NONE
 %null-pointer
 (string-pointer org.ofono)
 (string-pointer /)
 (string-pointer org.ofono.Manager)
 %null-pointer
 %null-pointer))

(write manager-proxy)
(newline)

(define g_dbus_proxy_call_sync
  (pointer-procedure '*
  (dynamic-func g_dbus_proxy_call_sync gio)
  (list '*  ; proxy
'*  ; method_name
'*  ; parameters
int ; flags
int ; timeout_msec
'*  ; cancellable
'*  ; error
)))

(define return-parms (g_dbus_proxy_call_sync manager-proxy
 (string-pointer GetModems)
 %null-pointer
 0
 1000
 %null-pointer
 %null-pointer))

(define g_variant_get_child_value
  (pointer-procedure '*
  (dynamic-func g_variant_get_child_value glib)
  (list '*  ; variant
int ; index
)))

(define g_variant_print
  (pointer-procedure '*
  (dynamic-func g_variant_print glib)
  (list '*  ; variant
int ; type annotate
)))

(define g_variant_get_type
  (pointer-procedure '*
  (dynamic-func g_variant_get_type glib)
  (list '*  ; variant
)))

(define g_variant_get_string
  (pointer-procedure '*
  (dynamic-func g_variant_get_string glib)
  (list '*  ; variant
'*  ; length
)))

(define (print-variant variant)
  (if (null-pointer? variant)
  (display (null variant pointer))
  (begin
(display (pointer-string (g_variant_get_type variant)))
(display : )
(display (pointer-string (g_variant_print variant FALSE)
  (newline))

(print-variant return-parms)

(define modems (g_variant_get_child_value return-parms 0))
(print-variant modems)

(define first-modem (g_variant_get_child_value modems 0))
(print-variant first-modem)

(define modem-name (g_variant_get_child_value first-modem 0))
(print-variant modem-name)

(define modem-name-string
  (pointer-string (g_variant_get_string modem-name %null-pointer)))
(format #t First modem's name is ~a\n modem-name-string)

(define modem-proxy
  (g_dbus_proxy_new_for_bus_sync G_BUS_TYPE_SYSTEM
 G_DBUS_PROXY_FLAGS_NONE

Re: add-relative-load-path ?

[Neil Jerram]

Andy Wingo wi...@pobox.com writes:

 Then in your script you would (add-relative-load-path .).

 Maybe we need an `add-to-load-path' form that handles the eval-when,
 actually, so it would be

   (add-to-load-path (dirname (current-source-filename)))

 or something like that.  (We'd have to define current-source-filename as
 well, in terms of current-source-location.)

 What do folks think?  Is it work it?

Yes, I think so!  I think it will be a great help for uninstalled
experimentation.

I can think of a couple of plausible enhancements:

(1) factoring out any occurrences of /x/.. and /. in the directory
that results from the in-vicinity call

(2) only adding the directory to the load path if it isn't already
there.

But neither of those is crucial.

Of the possibilities above, I think I prefer

   (add-to-load-path (dirname (current-source-filename)))

Thanks for thinking about this.

   Neil

Thread+GC issues on ARM

[Neil Jerram]

Hi there!

Just in case anyone else is looking at this too, I just wanted to
announce that I'm investigating why the Debian Guile 2.0.3 fails to pass
'make check' on ARM, as can be seen here:
https://buildd.debian.org/status/package.php?p=guile-2.0.  Now that
there's a Debian package for Guile 2.0 - thanks Rob! - I couldn't resist
trying to build it on my GTA04.

It all looks quite tractable - just complex interactions between when
Guile's thread finalizer (on_thread_exit) runs, libgc's own
finalizer/cleanup, and the fact that Guile's finalizer re-registers with
the GC.

Also I think I might be able to throw light on the longstanding
threads.test hang
(http://www.mail-archive.com/guile-devel@gnu.org/msg06007.html).  When I
hit that in GDB, there were only 3 threads known to GDB, but libgc's
thread count was 4, and that will obviously cause libgc to hang.

So, more soon, I hope.

Neil

Re: WRITE linefeed

[Neil Jerram]

Ian Price ianpric...@googlemail.com writes:

 Hello guilers,

 There's a small aesthetic issue that's been bothering me for a
 while. Namely, newlines aren't treated like other escape sequences when
 printed with WRITE.

 scheme@(guile-user) (write \n)
 
 scheme@(guile-user)

 Now, I can see why this would be useful when printing multiple line
 strings, but the inconsistency with e.g. \t\f irks me. What do the
 rest of you think?

I agree, but I can imagine that there is a case for the current
behaviour too, and it's nice to preserve back-compatibility.  Emacs has
`print-escape-newlines', and I guess we need something like that here -
an addition to `print-options'?

   Neil

Re: [PATCH] Configure GMP to use GC allocation functions, remove bignum finalizers

[Neil Jerram]

l...@gnu.org (Ludovic Courtès) writes:

 Hi!

 Mark H Weaver m...@netris.org skribas:

 The main reason I haven't already pushed this patch is that there is a
 slight complication: when you register custom allocation functions for
 use by GMP, they get used for _all_ allocation, not just for digits.  In
 particular, they get used to allocate the block returned by mpz_get_str
 (when the first argument is NULL).  This means that if the user of
 mpz_get_str uses the standard free to deallocate this block, it will
 fail badly.  This could potentially affect programs which use libguile
 but also use the GMP functions directly.

 Yes, that's a problem, probably even be a showstopper for 2.0.  :-(

 What do others think?

Provide an API to allow the trade-off to be decided by the application
developer?

The application developer would know if they were using GMP other than
via Guile, and in that case they'd choose to have GMP use GC
allocation.  Alternatively they might know that their application's use
of GMP/Guile was not such as to generate lots of GMP garbage as the
factorial example does, and so choose to use normal malloc.

Of course, that's only if there really is no more perfect solution here.

  Neil

Re: [PATCH] Configure GMP to use GC allocation functions, remove bignum finalizers

[Neil Jerram]

Neil Jerram n...@ossau.uklinux.net writes:

 The application developer would know if they were using GMP other than
 via Guile, and in that case they'd choose to have GMP use GC
 allocation.  Alternatively they might know that their application's use
 of GMP/Guile was not such as to generate lots of GMP garbage as the
 factorial example does, and so choose to use normal malloc.

I missed a not there.  But I'm sure you get the idea anyway.

   Neil

Re: [PATCH] Simplifying guile-tools

[Neil Jerram]

Andy Wingo wi...@pobox.com writes:

 On Tue 24 May 2011 00:23, Neil Jerram n...@ossau.uklinux.net writes:

 Neil Jerram n...@ossau.uklinux.net writes:

  [PATCH 1/5] Fix occurrances typos in getopt-long code and test
  [PATCH 2/5] Simplify getopt-long handling of option values, esp with 
 multiple occurrences
  [PATCH 3/5] Handle short option unclumping progressively, instead of all 
 upfront
  [PATCH 4/5] Implement #:stop-at-first-non-option option for getopt-long
  [PATCH 5/5] Reveal guile-tools's inner simplicity...

 Just a gentle ping regarding these patches...  Andy / Ludo, I guess you
 might be assuming that I'd just go ahead and push these anyway - but I'd
 prefer an explicit opinion or OK from you.

 (And the same for the 1-based line number fix.)

 Sorry for the delay.  They look great to me!  The 1-based line number
 fix too.

Thanks; those patches are in now.  I'll also soon provide a doc update
for the new getopt option.

   Neil

Re: [PATCH] Simplifying guile-tools

[Neil Jerram]

Neil Jerram n...@ossau.uklinux.net writes:

 The end result is that guile-tools is a lot shorter and (IMO) sweeter.

 Here are the titles of the following patches.

  [PATCH 1/5] Fix occurrances typos in getopt-long code and test
  [PATCH 2/5] Simplify getopt-long handling of option values, esp with 
 multiple occurrences
  [PATCH 3/5] Handle short option unclumping progressively, instead of all 
 upfront
  [PATCH 4/5] Implement #:stop-at-first-non-option option for getopt-long
  [PATCH 5/5] Reveal guile-tools's inner simplicity...

 What do you think?

Just a gentle ping regarding these patches...  Andy / Ludo, I guess you
might be assuming that I'd just go ahead and push these anyway - but I'd
prefer an explicit opinion or OK from you.

(And the same for the 1-based line number fix.)

Regards,
   Neil

Re: Indexing Scheme and C identifiers separately

[Neil Jerram]

David Pirotte da...@altosw.be writes:

 Looking at 'Procedure Index', for example not really knowing what your 
 looking for
 but presumably starting with letter 's', as a 'pure' scheme programmer, 
 reaching
 scm-xxx, you'll have to hit more or less 33 times page down [depending on your
 display and browser size obviously] to 'continue' with other 'scheme' indice 
 entries
 [they may be other entries, at the beginning they are *scm_]. If you realize 
 you
 probably have passed and missed the item you're looking for, you'll have to 
 hit 33
 times page-up ... not a big deal but it would be really nice to have 'per 
 language'
 indices.

 If [and only if :-)] it can be easily done [which I assumed, but ...], i would
 suggest the following [assuming a 'grouping' by language but i don't have a 
 problem
 if it is by 'proc' 'var' and 'type'

   Indices

   . Concept Index
   . Scheme Procedure Index
   . Scheme Variable Index
   . Scheme Type Index
   . C Procedure Index
   . C Variable Index
   . C Type index
   . R5RS Index 

I have supported this idea in the past, and I've recently taken a look
at how it might be implemented.

Unfortunately, I don't currently see a way of doing it.  Unless the
@deffns in the manual are restructured in some big way, it means that
we'd need a @deffn command and one or more following @deffnx commands to
generate entries in different indices.  That appears to be not currently
possible, and I've not managed to find any indication that it's even on
Texinfo's radar.

I'm happy to keep looking at this if people have other ideas about it;
but at the moment I'm stuck.

Regards,
  Neil

Re: scheme problem!

[Neil Jerram]

Stefan Israelsson Tampe stefan.ita...@gmail.com writes:

 Somewhere in the program I have,

 (pk x)
 (pk (caar l))
 (pk (equal? x (caar l)))

 It outputs

 ;;; (number)

 ;;; (number)

 ;;; (#f)



 #f  is there more to this then meets the eye?
 /Stefan

Well...

scheme@(guile-user) (equal? 'number (make-symbol number))
$7 = #f

Is it possible that either or both of x and (caar l) is uninterned?

(As far as I recall, it's intended that uninterned symbols are
distinct.)

Neil

[PATCH] Emit a 1-based line number in error messages

[Neil Jerram]

* module/ice-9/boot-9.scm (exception-printers): Add 1 to the 0-based
  line number.
---
 module/ice-9/boot-9.scm |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/module/ice-9/boot-9.scm b/module/ice-9/boot-9.scm
index 60d133f..6130f85 100644
--- a/module/ice-9/boot-9.scm
+++ b/module/ice-9/boot-9.scm
@@ -682,7 +682,7 @@ If there is no handler at all, Guile prints an error and 
then exits.
   (let ((filename (or (cadr source) unnamed port))
 (line (caddr source))
 (col (cdddr source)))
-(format port ~a:~a:~a:  filename line col))
+(format port ~a:~a:~a:  filename (1+ line) col))
   (format port ERROR: 
 
   (set! set-exception-printer!
-- 
1.7.4.1

Re: [PATCH 5/5] Reveal guile-tools's inner simplicity...

[Neil Jerram]

Neil Jerram n...@ossau.uklinux.net writes:

 ...by not using its own-rolled getopt, and moving the `list' function
 to a separate script

That one wasn't quite right, please refer to the attached instead.

Neil

From c106e51707004fb1549add9d1db59c0b45bfed18 Mon Sep 17 00:00:00 2001
From: Neil Jerram n...@ossau.uklinux.net
Date: Sun, 8 May 2011 22:51:07 +0100
Subject: [PATCH] Reveal guile-tools's inner simplicity...

...by not using its own-rolled getopt, and moving the `list' function
to a separate script

* meta/guile-tools.in: Use (ice-9 getopt-long).

  (directory-files, strip-extensions, unique, find-submodules,
  list-scripts): Deleted (and moved to new `list.scm' file).

  (getopt): Deleted.

  (main): Use getopt-long.  Default to calling the `list' script if no
  script is specified.

* module/scripts/list.scm: New script.

* module/Makefile.am (SCRIPTS_SOURCES): Add list.scm.
---
 meta/guile-tools.in |  162 +++---
 module/Makefile.am  |1 +
 module/scripts/list.scm |   83 
 3 files changed, 109 insertions(+), 137 deletions(-)
 create mode 100644 module/scripts/list.scm

diff --git a/meta/guile-tools.in b/meta/guile-tools.in
index 7f156ff..2f335b8 100755
--- a/meta/guile-tools.in
+++ b/meta/guile-tools.in
@@ -24,7 +24,7 @@ exec guile $GUILE_FLAGS -e '(@@ (guile-tools) main)' -s $0 $@
  Boston, MA 02110-1301 USA
 
 (define-module (guile-tools)
-  #:use-module ((srfi srfi-1) #:select (fold append-map))
+  #:use-module (ice-9 getopt-long)
   #:autoload (ice-9 format) (format))
 
 ;; Hack to provide scripts with the bug-report address.
@@ -55,146 +55,34 @@ This is free software: you are free to change and redistribute it.
 There is NO WARRANTY, to the extent permitted by law.
  (version) (effective-version)))
 
-(define (directory-files dir)
-  (if (and (file-exists? dir) (file-is-directory? dir))
-  (let ((dir-stream (opendir dir)))
-(let loop ((new (readdir dir-stream))
-   (acc '()))
-  (if (eof-object? new)
-  (begin
-(closedir dir-stream)
-acc)
-  (loop (readdir dir-stream)
-(if (or (string=? .  new) ; ignore
-(string=? .. new)); ignore
-acc
-(cons new acc))
-  '()))
-
-(define (strip-extensions path)
-  (or-map (lambda (ext)
-(and
- (string-suffix? ext path)
- (substring path 0
-(- (string-length path) (string-length ext)
-  (append %load-compiled-extensions %load-extensions)))
-
-(define (unique l)
-  (cond ((null? l) l)
-((null? (cdr l)) l)
-((equal? (car l) (cadr l)) (unique (cdr l)))
-(else (cons (car l) (unique (cdr l))
-
-(define (find-submodules head)
-  (let ((shead (map symbol-string head)))
-(unique
- (sort
-  (append-map (lambda (path)
-(fold (lambda (x rest)
-(let ((stripped (strip-extensions x)))
-  (if stripped (cons stripped rest) rest)))
-  '()
-  (directory-files
-   (fold (lambda (x y) (in-vicinity y x)) path shead
-  %load-path)
-  string?
-
-(define (list-scripts)
-  (for-each (lambda (x)
-  ;; would be nice to show a summary.
-  (format #t ~A\n x))
-(find-submodules '(scripts
-
 (define (find-script s)
   (resolve-module (list 'scripts (string-symbol s)) #:ensure #f))
 
-(define (getopt args grammar)
-  (define (fail)
-(format (current-error-port)
-Try `guile-tools --help' for more information.~%)
-(exit 1))
-
-  (define (unrecognized-arg arg)
-(format (current-error-port)
-guile-tools: unrecognized option: `~a'~% arg)
-(fail))
-
-  (define (unexpected-value sym val)
-(format (current-error-port)
-guile-tools: option `--~a' does not take an argument (given ~s)~%
-sym val)
-(fail))
-
-  (define (single-char-table grammar)
-(cond
- ((null? grammar) '())
- ((assq 'single-char (cdar grammar))
-  = (lambda (form)
-   (acons (cadr form) (car grammar)
-  (single-char-table (cdr grammar)
- (else
-  (single-char-table (cdr grammar)
-  
-  (let ((single (single-char-table grammar)))
-(let lp ((args (cdr args)) (options '()))
-  (cond
-   ((or (null? args) (equal? (car args) -))
-(values (reverse options) args))
-   ((equal? (car args) --)
-(values (reverse options) (cdr args)))
-   ((string-prefix? -- (car args))
-(let* ((str (car args))
-   (eq (string-index str #\= 2))
-   (sym (string-symbol
- (substring str 2 (or eq (string-length str

[PATCH] Simplifying guile-tools

[Neil Jerram]

Hi there!  While we were discussing the name of guile-tools, back in
March, I wrote:

 I think I might find guile-tools (as is) less bothering if its
 built-in commands (help, version and list) were rewritten as scripts
 themselves.  Then it would be clearer that the remaining code in
 guile-tools was just implementing the main-invocation convention for
 scripts/*.

Following this email is a series of patches in this direction.  It
didn't work to try to move `help' and `version' into separate scripts
because those are given as options and not script names.  But it did
work out nicely for `list', and also I managed to simplify and enhance
(ice-9 getopt-long) such that guile-tools doesn't need to have its own
getopt variant.

The end result is that guile-tools is a lot shorter and (IMO) sweeter.

Here are the titles of the following patches.

 [PATCH 1/5] Fix occurrances typos in getopt-long code and test
 [PATCH 2/5] Simplify getopt-long handling of option values, esp with multiple 
occurrences
 [PATCH 3/5] Handle short option unclumping progressively, instead of all 
upfront
 [PATCH 4/5] Implement #:stop-at-first-non-option option for getopt-long
 [PATCH 5/5] Reveal guile-tools's inner simplicity...

What do you think?

Thanks,
  Neil

[PATCH 3/5] Handle short option unclumping progressively, instead of all upfront

[Neil Jerram]

This is needed as a prerequisite for the following
don't know how far through the command line we should go with unclumping.

* module/ice-9/getopt-long.scm (expand-clumped-singles): Delete.

  (process-options): Add a loop variable to indicate how many elements
  at the start of `argument-ls' are known not to be clumped.  When we
  see a short option and this variable is = 0, perform unclumping
  (using code that used to be in expand-clumped-singles) and loop with
  the variable  0.

  (getopt-long): Don't call expand-clumped-singles upfront here.
---
 module/ice-9/getopt-long.scm |   57 ++---
 1 files changed, 25 insertions(+), 32 deletions(-)

diff --git a/module/ice-9/getopt-long.scm b/module/ice-9/getopt-long.scm
index 5c73f9a..0c2d835 100644
--- a/module/ice-9/getopt-long.scm
+++ b/module/ice-9/getopt-long.scm
@@ -226,27 +226,6 @@
 (define long-opt-no-value-rx   (make-regexp ^--([^=]+)$))
 (define long-opt-with-value-rx (make-regexp ^--([^=]+)=(.*)))
 
-(define (expand-clumped-singles opt-ls)
-  ;; example: (--xyz -abc5d) = (--xyz -a -b -c 5d)
-  (let loop ((opt-ls opt-ls) (ret-ls '()))
-(cond ((null? opt-ls)
-   (reverse ret-ls));;; retval
-  ((regexp-exec short-opt-rx (car opt-ls))
-   = (lambda (match)
-(let ((singles (reverse
-(map (lambda (c)
-   (string-append - (make-string 1 c)))
- (string-list
-  (match:substring match 1)
-  (extra (match:substring match 2)))
-  (loop (cdr opt-ls)
-(append (if (string=?  extra)
-singles
-(cons extra singles))
-ret-ls)
-  (else (loop (cdr opt-ls)
-  (cons (car opt-ls) ret-ls))
-
 (define (looks-like-an-option string)
   (or (regexp-exec short-opt-rx string)
   (regexp-exec long-opt-with-value-rx string)
@@ -264,22 +243,22 @@
(cons (make-string 1 (option-spec-single-char spec))
  spec))
  (remove-if-not option-spec-single-char specs
-(let loop ((argument-ls argument-ls) (found '()) (etc '()))
+(let loop ((unclumped 0) (argument-ls argument-ls) (found '()) (etc '()))
   (define (eat! spec ls)
 (cond
  ((eq? 'optional (option-spec-value-policy spec))
   (if (or (null? ls)
   (looks-like-an-option (car ls)))
-  (loop ls (acons spec #t found) etc)
-  (loop (cdr ls) (acons spec (car ls) found) etc)))
+  (loop (- unclumped 1) ls (acons spec #t found) etc)
+  (loop (- unclumped 2) (cdr ls) (acons spec (car ls) found) etc)))
  ((eq? #t (option-spec-value-policy spec))
   (if (or (null? ls)
   (looks-like-an-option (car ls)))
   (fatal-error option must be specified with argument: --~a
(option-spec-name spec))
-  (loop (cdr ls) (acons spec (car ls) found) etc)))
+  (loop (- unclumped 2) (cdr ls) (acons spec (car ls) found) etc)))
  (else
-  (loop ls (acons spec #t found) etc
+  (loop (- unclumped 1) ls (acons spec #t found) etc
   
   (match argument-ls
 (()
@@ -288,10 +267,24 @@
  (cond
   ((regexp-exec short-opt-rx opt)
= (lambda (match)
-(let* ((c (match:substring match 1))
-   (spec (or (assoc-ref sc-idx c)
- (fatal-error no such option: -~a c
-  (eat! spec rest
+(if ( unclumped 0)
+;; Next option is known not to be clumped.
+(let* ((c (match:substring match 1))
+   (spec (or (assoc-ref sc-idx c)
+ (fatal-error no such option: -~a c
+  (eat! spec rest))
+;; Expand a clumped group of short options.
+(let* ((extra (match:substring match 2))
+   (unclumped-opts
+(append (map (lambda (c)
+   (string-append - (make-string 1 
c)))
+ (string-list
+  (match:substring match 1)))
+(if (string=?  extra) '() (list 
extra)
+  (loop (length unclumped-opts)
+(append unclumped-opts rest)
+found
+etc)
   ((regexp-exec long-opt-no-value-rx opt)
= (lambda (match)
 (let* 

[PATCH 2/5] Simplify getopt-long handling of option values, esp with multiple occurrences

[Neil Jerram]

Basically, accumulate values in the `process-options' loop variables,
instead of using set-option-spec-value!

* module/ice-9/getopt-long.scm (option-spec): Delete the `value' slot.

  (process-options): Delete `val!loop' and just use `loop' everywhere
  instead.  When adding an option spec to `found', add the
  corresponding value too; hence `found' becomes an alist, where it
  was previously a list of specs.

  (getopt-long): Use assq-ref to get values out of `found'.  Remove
  unhittable error condition for detecting an option that requires an
  explicit value, where a value wasn't supplied.  This condition is
  actually caught and handled in `process-options'.  Rewrite the end
  of the procedure much more simply.
---
 module/ice-9/getopt-long.scm |   52 +-
 1 files changed, 11 insertions(+), 41 deletions(-)

diff --git a/module/ice-9/getopt-long.scm b/module/ice-9/getopt-long.scm
index c3939dc..5c73f9a 100644
--- a/module/ice-9/getopt-long.scm
+++ b/module/ice-9/getopt-long.scm
@@ -179,8 +179,6 @@
   option-spec?
   (name
option-spec-name set-option-spec-name!)
-  (value 
-   option-spec-value set-option-spec-value!)
   (required?
option-spec-required? set-option-spec-required?!)
   (option-spec-single-char
@@ -268,30 +266,20 @@
  (remove-if-not option-spec-single-char specs
 (let loop ((argument-ls argument-ls) (found '()) (etc '()))
   (define (eat! spec ls)
-(define (val!loop val n-ls n-found n-etc)
-  (set-option-spec-value!
-   spec
-   ;; handle multiple occurrences
-   (cond ((option-spec-value spec)
-  = (lambda (cur)
-   ((if (list? cur) cons list)
-val cur)))
- (else val)))
-  (loop n-ls n-found n-etc))
 (cond
  ((eq? 'optional (option-spec-value-policy spec))
   (if (or (null? ls)
   (looks-like-an-option (car ls)))
-  (val!loop #t ls (cons spec found) etc)
-  (val!loop (car ls) (cdr ls) (cons spec found) etc)))
+  (loop ls (acons spec #t found) etc)
+  (loop (cdr ls) (acons spec (car ls) found) etc)))
  ((eq? #t (option-spec-value-policy spec))
   (if (or (null? ls)
   (looks-like-an-option (car ls)))
   (fatal-error option must be specified with argument: --~a
(option-spec-name spec))
-  (val!loop (car ls) (cdr ls) (cons spec found) etc)))
+  (loop (cdr ls) (acons spec (car ls) found) etc)))
  (else
-  (val!loop #t ls (cons spec found) etc
+  (loop ls (acons spec #t found) etc
   
   (match argument-ls
 (()
@@ -363,37 +351,19 @@ to add a `single-char' clause to the option description.
(rest-ls (append (cdr found/etc) non-split-ls)))
   (for-each (lambda (spec)
   (let ((name (option-spec-name spec))
-(val (option-spec-value spec)))
+(val (assq-ref found spec)))
 (and (option-spec-required? spec)
- (or (memq spec found)
+ (or val
  (fatal-error option must be specified: --~a
   name)))
-(and (memq spec found)
- (eq? #t (option-spec-value-policy spec))
- (or val
- (fatal-error
-  option must be specified with argument: --~a
-  name)))
 (let ((pred (option-spec-predicate spec)))
   (and pred (pred name val)
 specifications)
-  (cons (cons '() rest-ls)
-(let ((multi-count (map (lambda (desc)
-  (cons (car desc) 0))
-option-desc-list)))
-  (map (lambda (spec)
- (let ((name (string-symbol (option-spec-name spec
-   (cons name
- ;; handle multiple occurrences
- (let ((maybe-ls (option-spec-value spec)))
-   (if (list? maybe-ls)
-   (let* ((look (assq name multi-count))
-  (idx (cdr look))
-  (val (list-ref maybe-ls idx)))
- (set-cdr! look (1+ idx)) ; ugh!
- val)
-   maybe-ls)
-   found))
+  (for-each (lambda (spec+val)
+  (set-car! spec+val
+(string-symbol (option-spec-name (car 
spec+val)
+found)
+  (cons (cons '() 

[PATCH 1/5] Fix occurrances typos in getopt-long code and test

[Neil Jerram]

* module/ice-9/getopt-long.scm (process-options, getopt-long): Change
  to occurrences.

* test-suite/tests/getopt-long.test (multiple occurrences): Same
  again.
---
 module/ice-9/getopt-long.scm  |4 ++--
 test-suite/tests/getopt-long.test |2 +-
 2 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/module/ice-9/getopt-long.scm b/module/ice-9/getopt-long.scm
index 1b170b4..c3939dc 100644
--- a/module/ice-9/getopt-long.scm
+++ b/module/ice-9/getopt-long.scm
@@ -271,7 +271,7 @@
 (define (val!loop val n-ls n-found n-etc)
   (set-option-spec-value!
spec
-   ;; handle multiple occurrances
+   ;; handle multiple occurrences
(cond ((option-spec-value spec)
   = (lambda (cur)
((if (list? cur) cons list)
@@ -384,7 +384,7 @@ to add a `single-char' clause to the option description.
   (map (lambda (spec)
  (let ((name (string-symbol (option-spec-name spec
(cons name
- ;; handle multiple occurrances
+ ;; handle multiple occurrences
  (let ((maybe-ls (option-spec-value spec)))
(if (list? maybe-ls)
(let* ((look (assq name multi-count))
diff --git a/test-suite/tests/getopt-long.test 
b/test-suite/tests/getopt-long.test
index d7f5184..682763c 100644
--- a/test-suite/tests/getopt-long.test
+++ b/test-suite/tests/getopt-long.test
@@ -252,7 +252,7 @@
 
   )
 
-(with-test-prefix multiple occurrances
+(with-test-prefix multiple occurrences
 
   (define (test9 . args)
 (equal? (getopt-long (cons foo args)
-- 
1.7.4.1

[PATCH 4/5] Implement #:stop-at-first-non-option option for getopt-long

[Neil Jerram]

(For use by guile-tools)

* module/ice-9/getopt-long.scm: Use (ice-9 optargs) so we can use
  define*.

  (process-options): Add stop-at-first-non-option parameter.  When
  this is true, stop processing when we hit a non-option (so long as
  that non-option isn't something that resulted from the unclumping of
  a short option group).

  (getopt-long): Add #:stop-at-first-non-option keyword; pass it on to
  process-options.

* test-suite/tests/getopt-long.test (stop-at-first-non-option): New
  test (for the above).
---
 module/ice-9/getopt-long.scm  |   12 +---
 test-suite/tests/getopt-long.test |   11 +++
 2 files changed, 20 insertions(+), 3 deletions(-)

diff --git a/module/ice-9/getopt-long.scm b/module/ice-9/getopt-long.scm
index 0c2d835..12f8c94 100644
--- a/module/ice-9/getopt-long.scm
+++ b/module/ice-9/getopt-long.scm
@@ -161,6 +161,7 @@
   #:use-module (srfi srfi-9)
   #:use-module (ice-9 match)
   #:use-module (ice-9 regex)
+  #:use-module (ice-9 optargs)
   #:export (getopt-long option-ref))
 
 (define %program-name (make-fluid))
@@ -231,7 +232,7 @@
   (regexp-exec long-opt-with-value-rx string)
   (regexp-exec long-opt-no-value-rx string)))
 
-(define (process-options specs argument-ls)
+(define (process-options specs argument-ls stop-at-first-non-option)
   ;; Use SPECS to scan ARGUMENT-LS; return (FOUND . ETC).
   ;; FOUND is an unordered list of option specs for found options, while ETC
   ;; is an order-maintained list of elements in ARGUMENT-LS that are neither
@@ -300,10 +301,14 @@
   (eat! spec (cons (match:substring match 2) rest))
   (fatal-error option does not support argument: --~a
opt)
+  ((and stop-at-first-non-option
+(= unclumped 0))
+   (cons found (append (reverse etc) argument-ls)))
   (else
(loop (- unclumped 1) rest found (cons opt etc)
 
-(define (getopt-long program-arguments option-desc-list)
+(define* (getopt-long program-arguments option-desc-list
+  #:key stop-at-first-non-option)
   Process options, handling both long and short options, similar to
 the glibc function 'getopt_long'.  PROGRAM-ARGUMENTS should be a value
 similar to what (program-arguments) returns.  OPTION-DESC-LIST is a
@@ -339,7 +344,8 @@ to add a `single-char' clause to the option description.
(pair (split-arg-list (cdr program-arguments)))
(split-ls (car pair))
(non-split-ls (cdr pair))
-   (found/etc (process-options specifications split-ls))
+   (found/etc (process-options specifications split-ls
+   stop-at-first-non-option))
(found (car found/etc))
(rest-ls (append (cdr found/etc) non-split-ls)))
   (for-each (lambda (spec)
diff --git a/test-suite/tests/getopt-long.test 
b/test-suite/tests/getopt-long.test
index 682763c..4ae6048 100644
--- a/test-suite/tests/getopt-long.test
+++ b/test-suite/tests/getopt-long.test
@@ -288,4 +288,15 @@
 
   )
 
+(with-test-prefix stop-at-first-non-option
+
+  (pass-if guile-tools compile example
+(equal? (getopt-long '(guile-tools compile -Wformat eval.scm -o 
eval.go)
+ '((help (single-char #\h))
+   (version (single-char #\v)))
+ #:stop-at-first-non-option #t)
+'((() compile -Wformat eval.scm -o eval.go
+
+  )
+
 ;;; getopt-long.test ends here
-- 
1.7.4.1

[PATCH 5/5] Reveal guile-tools's inner simplicity...

[Neil Jerram]

...by not using its own-rolled getopt, and moving the `list' function
to a separate script

* meta/guile-tools.in: Use (ice-9 getopt-long).

  (directory-files, strip-extensions, unique, find-submodules,
  list-scripts): Deleted (and moved to new `list' file).

  (getopt): Deleted.

  (main): Use getopt-long.  Default to calling the `list' script if no
  script is specified.

* module/scripts/list.scm: New script.
---
 meta/guile-tools.in |  160 +++
 module/scripts/list.scm |   83 
 2 files changed, 106 insertions(+), 137 deletions(-)
 create mode 100644 module/scripts/list.scm

diff --git a/meta/guile-tools.in b/meta/guile-tools.in
index 7f156ff..67d70f0 100755
--- a/meta/guile-tools.in
+++ b/meta/guile-tools.in
@@ -24,7 +24,7 @@ exec guile $GUILE_FLAGS -e '(@@ (guile-tools) main)' -s $0 
$@
  Boston, MA 02110-1301 USA
 
 (define-module (guile-tools)
-  #:use-module ((srfi srfi-1) #:select (fold append-map))
+  #:use-module (ice-9 getopt-long)
   #:autoload (ice-9 format) (format))
 
 ;; Hack to provide scripts with the bug-report address.
@@ -55,146 +55,32 @@ This is free software: you are free to change and 
redistribute it.
 There is NO WARRANTY, to the extent permitted by law.
  (version) (effective-version)))
 
-(define (directory-files dir)
-  (if (and (file-exists? dir) (file-is-directory? dir))
-  (let ((dir-stream (opendir dir)))
-(let loop ((new (readdir dir-stream))
-   (acc '()))
-  (if (eof-object? new)
-  (begin
-(closedir dir-stream)
-acc)
-  (loop (readdir dir-stream)
-(if (or (string=? .  new) ; ignore
-(string=? .. new)); ignore
-acc
-(cons new acc))
-  '()))
-
-(define (strip-extensions path)
-  (or-map (lambda (ext)
-(and
- (string-suffix? ext path)
- (substring path 0
-(- (string-length path) (string-length ext)
-  (append %load-compiled-extensions %load-extensions)))
-
-(define (unique l)
-  (cond ((null? l) l)
-((null? (cdr l)) l)
-((equal? (car l) (cadr l)) (unique (cdr l)))
-(else (cons (car l) (unique (cdr l))
-
-(define (find-submodules head)
-  (let ((shead (map symbol-string head)))
-(unique
- (sort
-  (append-map (lambda (path)
-(fold (lambda (x rest)
-(let ((stripped (strip-extensions x)))
-  (if stripped (cons stripped rest) rest)))
-  '()
-  (directory-files
-   (fold (lambda (x y) (in-vicinity y x)) path 
shead
-  %load-path)
-  string?
-
-(define (list-scripts)
-  (for-each (lambda (x)
-  ;; would be nice to show a summary.
-  (format #t ~A\n x))
-(find-submodules '(scripts
-
 (define (find-script s)
   (resolve-module (list 'scripts (string-symbol s)) #:ensure #f))
 
-(define (getopt args grammar)
-  (define (fail)
-(format (current-error-port)
-Try `guile-tools --help' for more information.~%)
-(exit 1))
-
-  (define (unrecognized-arg arg)
-(format (current-error-port)
-guile-tools: unrecognized option: `~a'~% arg)
-(fail))
-
-  (define (unexpected-value sym val)
-(format (current-error-port)
-guile-tools: option `--~a' does not take an argument (given ~s)~%
-sym val)
-(fail))
-
-  (define (single-char-table grammar)
-(cond
- ((null? grammar) '())
- ((assq 'single-char (cdar grammar))
-  = (lambda (form)
-   (acons (cadr form) (car grammar)
-  (single-char-table (cdr grammar)
- (else
-  (single-char-table (cdr grammar)
-  
-  (let ((single (single-char-table grammar)))
-(let lp ((args (cdr args)) (options '()))
-  (cond
-   ((or (null? args) (equal? (car args) -))
-(values (reverse options) args))
-   ((equal? (car args) --)
-(values (reverse options) (cdr args)))
-   ((string-prefix? -- (car args))
-(let* ((str (car args))
-   (eq (string-index str #\= 2))
-   (sym (string-symbol
- (substring str 2 (or eq (string-length str)
-   (val (and eq (substring str (1+ eq
-   (spec (assq sym grammar)))
-  (cond
-   ((not spec)
-(unrecognized-arg (substring str 0 (or eq (string-length str)
-   (val
-;; no values for now
-(unexpected-value sym val))
-   ((assq-ref (cdr spec) 'value)
-(error options with values not supported right now))
-   (else
-(lp (cdr args) (acons sym #f options))
-   ((string-prefix? - (car 

Re: Queries about while doc and (ice-9 command-line)

[Neil Jerram]

Andy Wingo wi...@pobox.com writes:

 Does this code mean that we load the script twice, in the -ds case?

 I think so, yes; unfortunately.  Fixed.  Would this merit a quick 2.0.2,
 you think?

I guess that would be better, if Ludo has time to make the release.

 Do we go interactive after seeing a -e option?  I don't see a setting of
 the interactive? variable that would prevent this?

 This appears to be the old behavior.  Am I mistaken?

No, sorry, I was.  This is fine then.

Regards,
Neil

Queries about while doc and (ice-9 command-line)

[Neil Jerram]

Hi there,

I was looking today at some recent commits, and noticed a few queries...

In
http://git.savannah.gnu.org/cgit/guile.git/commit/?h=stable-2.0id=91956a94fe6363cf69d574b56397962ec6ef4468:

+@example
+(while #f (error not reached)) @result{} #f
+(while #t (break)) @result{} #t
+(while #f (break 1 2 3)) @result{} 1 2 3
+@end example

I think the #f in the last while line should be #t.

In
http://git.savannah.gnu.org/cgit/guile.git/tree/module/ice-9/command-line.scm?h=stable-2.0id=90779ad9a1d8b2533ad8495753677aebf5626571:

(if (pair? do-script)
(set-car! do-script arg))
(set! arg0 arg)
(set! interactive? #f)
(finish args
(cons `(load ,arg) out)))

Does this code mean that we load the script twice, in the -ds case?

If that's right, I believe the -s block has the same issue.

   ((string=? arg -x) ; add to %load-extensions
(if (null? args)
(error missing argument to `-L' switch))
(set! user-extensions (cons (car args) user-extensions))
(parse (cdr args)
   out))

In the error message here, -L should be -x.

  ;; Handle the `-e' switch, if it was specified.
  ,@(if entry-point
`((,entry-point (command-line)))
'())

Do we go interactive after seeing a -e option?  I don't see a setting of
the interactive? variable that would prevent this?

Regards,
Neil

Re: Patch: New section Invoking Guile for chapter Programming in Scheme

[Neil Jerram]

l...@gnu.org (Ludovic Courtès) writes:

 It can be put in .dir-locals.el (info (emacs) Directory Variables).

 Yeah.  In fact it is there, in the root .dir-locals.el, as 72.  Is that
 sufficient?

 Oh right, should be enough, yes.

OK, that's fine then; that means we'll naturally asymptote towards a
situation where there aren't any more reflowing diffs.

Thanks!
  Neil

Re: Patch: New section Invoking Guile for chapter Programming in Scheme

[Neil Jerram]

Mark Harig idirect...@aim.com writes:

  +The @var{function} is most often a simple symbol that names a function
  +that is defined in the script.  It can also be of the form @code{(@@
  +@var{module-name} @var{symbol})}, and in that case, the symbol is
  +looked up in the module named @var{module-name}.

 You inserted a comma here before @var{symbol})}, and in that case.  I
 agree that a comma was needed, but would have put it as @var{symbol})}
 and, in that case, the   What do you think?


 Is the sentence of the form 1) A and B or of the form 2) A, and some
 supplemental information about A?  I think it is 2).  Then, you are
 left with the choice of how many commas:

 1) A, and, in that case, B
 2) A, and in that case, B
 3) A and, in that case, B

 Either choice 1) or 2) gets my vote.  Choice 3) is, I think, an error.

I'm not sure it's completely clearcut but yes, I see your point.  In
that case I might technically favour 1), but then that's a lot of
commas.  But, in any case, ...

 Another perspective: Re-write the sentence, replacing and in that
 case with in which case.  This should make it clearer that the
 sentence consists of a main clause and a sub-clause (preceded by a
 comma), not two main clauses.

... this is a much nicer idea than any of the above!

  +@table @env
  +@item GUILE_AUTO_COMPILE
  +@vindex GUILE_AUTO_COMPILE
  +This is a flag that can be used to tell Guile whether or not to compile
  +Scheme source files automatically.  Starting with Guile 2.0, Scheme
  +source files will be compiled automatically, by default.

 Is it useful to say Starting with Guile 2.0 in a post-2.0.0 version of
 the manual?  I think that expression could be deleted now.


 That's a consequence of the fact that I looked up what information I
 could find from the NEWS file, and then used that text as an initial
 version.

 I agree that it's not the best solution to the problem, but the
 problem is how does the manual convey to long-time Guile users this
 change in behavior?  I do not have a good solution to that in this
 brief patch.  For now, experienced users will and should rely on the
 NEWS file to inform them about changes in behavior.

Agreed.  I think it makes sense overall for the manual to describe the
status quo (plus the history section, for fun) and for NEWS to cover
changes.

(Notwithstanding that there are some occurrences in the manual source of
`@vnew{...}', which I guess was/is an attempt to codify such things
(when features changed, or were introduced) in the manual source.  As
far as I know this usage has never been sufficiently widespread to be
reliable.)

Regards,
Neil

Re: Patch: New section Invoking Guile for chapter Programming in Scheme

[Neil Jerram]

Hi Mark,

FWIW, these patches look great to me; I just have two minor comments,
inline below.  It's great to have someone looking at the manual material
with such a careful eye for detail.

Just one meta-thing that occurred to me: can we all agree on a value for
fill-column, so as to avoid spurious M-q diffs?  And, if we can
agree on that, is there a neat way of helping people to use it? - some
kind of local variables setup, I suppose.

Mark Harig idirect...@aim.com writes:

 From 80c6fd67b228ea8685def8ca4305bec9cdd98cd9 Mon Sep 17 00:00:00 2001
[...]
 +@item -e @var{function}
 +Make @var{function} the @dfn{entry point} of the script.  After loading
 +the script file (with @option{-s}) or evaluating the expression (with
 +@option{-c}), apply @var{function} to a list containing the program name
 +and the command-line arguments---the list provided by the
 +@code{command-line} function.
 +
 +A @option{-e} switch can appear anywhere in the argument list, but Guile
 +always invokes the @var{function} as the @emph{last} action it performs.
 +This is weird, but because of the way script invocation works under
 +POSIX, the @option{-s} option must always come last in the list.
 +
 +The @var{function} is most often a simple symbol that names a function
 +that is defined in the script.  It can also be of the form @code{(@@
 +@var{module-name} @var{symbol})}, and in that case, the symbol is
 +looked up in the module named @var{module-name}.

You inserted a comma here before @var{symbol})}, and in that case.  I
agree that a comma was needed, but would have put it as @var{symbol})}
and, in that case, the   What do you think?

 +@table @env
 +@item GUILE_AUTO_COMPILE
 +@vindex GUILE_AUTO_COMPILE
 +This is a flag that can be used to tell Guile whether or not to compile
 +Scheme source files automatically.  Starting with Guile 2.0, Scheme
 +source files will be compiled automatically, by default.

Is it useful to say Starting with Guile 2.0 in a post-2.0.0 version of
the manual?  I think that expression could be deleted now.

Regards,
Neil

Re: Broken Mail Transport Agent at stelco.com.mv

[Neil Jerram]

Hi guys

On 12 April 2011 10:55, Ludovic Courtès l...@gnu.org wrote:
 Hey!

 Andy Wingo wi...@pobox.com writes:

 On Sun 10 Apr 2011 00:09, Mark H Weaver m...@netris.org writes:

 postmas...@stelco.com.mv writes:
 This is an automatically generated Delivery Status Notification.

 Delivery to the following recipients failed.

        shi...@stelco.com.mv

 Can one of the guile-devel administrators please disable delivery to the
 address above, as would presumably have been done automatically if these
 bounces were being sent to the right address?

 I don't seem to have admin access to this list.  Ludo do you have
 access?

 I tried to log in at http://lists.gnu.org/mailman/admin/guile-devel
 with the latest password we received and it didn’t work.

 I never administered the lists, I think Neil used to.

Yes, it's correct that I did do that for a while.  But then the whole
job was passed to a group of mailing list administrators at GNU - as
suggested by the listhelper-moderateDELETEME at gnu.org address at
the bottom of, e.g.,
http://lists.gnu.org/mailman/listinfo/guile-devel.

So, I think that's the address to contact, if you want to help
administer the lists, or if you have particular requests.

Regards,
Neil

Re: Guile 2.0 eating memory on ARM

[Neil Jerram]

nalaginrut nalagin...@gmail.com writes:

 I think guile on embedded device would be interesting since it has VM
 now.

Also since it has the FFI - which means being able to access lots of
libraries, without needing to prepare and cross-compile glue code.

  What kernel version your freerunner running?

2.6.34

Regards,
  Neil

Re: Guile 2.0 eating memory on ARM

[Neil Jerram]

l...@gnu.org (Ludovic Courtès) writes:

 Hello Neil,

 Neil Jerram n...@ossau.uklinux.net writes:

 I think I've successfully cross-compiled Guile (stable-2.0, e309f3bf9e)
 for my Freerunner phone.  However, when I run it, it just keeps
 allocating memory until the OOM killer kills it:

 How much RAM does it have?

About 126Mb NAND, optionally plus 512Mb more SD card swap.  But I think
the behaviour was the same with and without the swap; with the swap it
just took longer before the OOM killer killed it.

  What is Guile doing when it gets killed?  Is
 it running a program or just trying to get to the REPL?

Well, I tried once with `guile -c 3', i.e. just trying to evaluate `3',
and once with `guile', i.e. getting to the REPL.  I don't think it got
as far as where those two possibilities fork.

 - Following the discussion about a cross version of `guile-tools
   compile', I realized that the Freerunner ARM platform is
   little-endian, and hence the .go files should be identical to those
   for x86.  Therefore, although I was going to look at adding a target
   type in the way that Ludo and Andy agreed, I don't actually need to do
   that yet.

   (Is that right?

 I think so.

Thanks.

   In any case, it definitely isn't relevant to the memory eating
   problem, because the strace shows that guile hasn't yet tried to
   open any .scm or .go files.)

 Woow, really?  Then can you start it directly under gdb and interrupt it
 quickly after to see what’s going on?

Yes, I'll do that.  I also should try with libgc CVS, instead of my
current 7.2alpha4.

 FWIW it runs on my GuruPlug, an ARM device, but that one has 512 MiB of RAM.

If it's easy for you to find out, (i) what version of libgc are you
using there, and (ii) how much memory does Guile use to execute `guile
-c 3' or `guile'?

Another possibility is that the problem is ARM version-dependent.  Mine
is armv4t, which I understand is now a bit old.

Thanks for your input!

 Neil

Re: module/ prefix in /usr/local/lib/guile/2.0/ccache/ice-9/*.go

[Neil Jerram]

Andy Wingo wi...@pobox.com writes:

 It does matter, yes: that suffix is used for looking for a file within
 the load path, and obviously having module/ on the beginning isn't going
 to work.  Good catch.  You'll have to rebuild everything to get the
 right paths residualized.

 Pushed a fix to git.

Great, thanks!

Neil

Re: on the importance of names

[Neil Jerram]

Andy Wingo wi...@pobox.com writes:

 So!  My new proposal is guild.

   guild update
   guild compile foo.scm
   guild install fmt

Yes, that's nice.

 Neil

Re: proposal: enhance and rename guile-tools

[Neil Jerram]

Andy Wingo wi...@pobox.com writes:

 On Mon 21 Mar 2011 22:50, Neil Jerram n...@ossau.uklinux.net writes:

 - gel is short; and it's the name of Guile before it was Guile; and
   suggests sticking things together; and AFAIK isn't already being used
   for anything else; and has similar key positions as gdo, so is
   equally easy to type.

 Gel is good!

But I agree that Guild is better!

 - I think I might find guile-tools (as is) less bothering if its
   built-in commands (help, version and list) were rewritten as scripts
   themselves.  Then it would be clearer that the remaining code in
   guile-tools was just implementing the main-invocation convention for
   scripts/*.

 Good idea also!

I'll do that - if you haven't already started it.

 Neil

Re: exit dynamic wind

[Neil Jerram]

Andy Wingo wi...@pobox.com writes:

 |   GENguile-procedures.texi
 | guile: uncaught throw to wrong-type-arg: (#f Wrong type (expecting ~A): 
 ~S (exact integer (#t #catch-closure 9916c10 #catch-closure 9916be0)) 
 ((#t #catch-closure 9916c10 #catch-closure 9916be0)))

 This, it turns out, was something more pernicious, fixed in
 572eef50c2d902d34427945dd504ba03af666e48.

Thanks for the fix.  I'm afraid I struggled to understand the change,
though - although I admit it may be largely my fault, as I'm not up to
speed with VM or prompt internals.  Nevertheless, would it perhaps be
worth a bit more commenting or a test, for future readers?

  Neil

[Neil Jerram] avoid running GC when SCM_I_CURRENT_THREAD is unset

[Neil Jerram]

[sorry, this should of course have been CC'd to the list too...]

Hi Andy,

I saw this change and couldn't fully understand it.  Given that you
ended up adding GC_disable() and GC_enable() around the GC_malloc()
call, couldn't you just have done that without all the other changes
from t- to t. ?

I'm probably missing something, but could you point it out?

Thanks,
Neil

Re: avoid running GC when SCM_I_CURRENT_THREAD is unset

[Neil Jerram]

Andy Wingo wi...@pobox.com writes:

 Hi Neil!

 Adding guile-devel; I'm wrong a lot lately, and folks should know ;-)

 On Wed 30 Mar 2011 21:11, Neil Jerram n...@ossau.uklinux.net writes:

 I saw this change and couldn't fully understand it.  Given that you
 ended up adding GC_disable() and GC_enable() around the GC_malloc()
 call, couldn't you just have done that without all the other changes
 from t- to t. ?

 I'm probably missing something, but could you point it out?

 Indeed, I probably could have just done a GC_disable before the whole
 thing, and an enable() afterwards.  That's probably clearer, no?

I doubt it's worth going back, now that the change is made.

I really just wanted to make sure I understood - because I'm seeing a
problem on ARM that looks GC-related, and so was reviewing recent
GC-area changes.  I'll post a bit more about that in a new thread.

  Neil

Re: Compilation error with stable-2.0 branch

[Neil Jerram]

Detlev Zundel d...@denx.de writes:

 Hi,

 compiling TOT of this branch (commit
 9dadfa47b07548ff5cf3604067910c8aece93c42 [fix prompt in fix in
 single-value context compilation]) fails like this:

 make[2]: Entering directory `/opt/src/git/guile/libguile'
 make  all-am
 make[3]: Entering directory `/opt/src/git/guile/libguile'
   CCLD   guile
 ./.libs/libguile-2.0.so: undefined reference to `GC_pthread_cancel'
 ./.libs/libguile-2.0.so: undefined reference to `GC_pthread_exit'
 collect2: ld returned 1 exit status
 make[3]: *** [guile] Error 1
 make[3]: Leaving directory `/opt/src/git/guile/libguile'
 make[2]: *** [all] Error 2
 make[2]: Leaving directory `/opt/src/git/guile/libguile'
 make[1]: *** [all-recursive] Error 1
 make[1]: Leaving directory `/opt/src/git/guile'
 make: *** [all] Error 2
 dzu@ohwell:guile[0]$

 Compilation of the tag v2.0.0 succeeds.  Installed locally is
 gc-7.2alpha4.

 Is this a known problem?

No, I don't think so; thanks for reporting it.  FWIW I see it too, also
with gc-7.2alpha4.

Regards,
Neil

Re: [Guile-commits] GNU Guile branch, stable-2.0, updated. v2.0.0-124-g5f0d295

[Neil Jerram]

l...@gnu.org (Ludovic Courtès) writes:

 Hello,

 A few more thoughts...

 Andy Wingo wi...@pobox.com writes:

 On Fri 25 Mar 2011 18:58, l...@gnu.org (Ludovic Courtès) writes:

 Andy Wingo wi...@pobox.com writes:

 bdw-gc 6.8 compatibility (hopefully)

 Aarrrgh.  The intent has always been to support 7.x only (bdw-gc.h has
 compatibility stuff for historical reasons), which is already enough
 work.  ;-)  The README and various responses we posted in the past are
 consistent.

 WDYT?

 I think we've been sending mixed messages.

 Again, I don’t think so.

What is the current best recommendation for libgc to use?

(Note in particular that Guile doesn't build with one of the most recent
releases, 7.2alpha4.  I guess it might make sense to try 7.2alpha5 too,
so I will do that and report back.)

Thanks,
Neil

Re: [Guile-commits] GNU Guile branch, stable-2.0, updated. v2.0.0-124-g5f0d295

[Neil Jerram]

l...@gnu.org (Ludovic Courtès) writes:

 7.x.  Best recommendation would be 7.2, which fixes several bugs, but it
 hasn’t been released yet, unfortunately.

 (Note in particular that Guile doesn't build with one of the most recent
 releases, 7.2alpha4.

 Really?  What’s the problem with this one?

Please see the current Compilation error with stable-2.0 branch
thread.  (Sorry, I meant to refer to it in my previous email.)

  Neil

Re: Some simple build simplification patches

[Neil Jerram]

Andy Wingo wi...@pobox.com writes:

 On Mon 21 Mar 2011 23:19, Neil Jerram n...@ossau.uklinux.net writes:

 Following are 4 simple (I believe) patches that simplify the build.
 Plus the one at the end (#5) that is only very loosely related to this,
 because of its mentioning of the $GUILE variable, but I think is a
 useful cleanup anyway.

 All sounds fine to me!

Thanks, I've pushed those then.

After doing that, I remembered that Jan had a query about
GUILE_FOR_BUILD, and we didn't yet reach a conclusion in that
conversation.  Jan, please do follow up to that, and I will be happy to
revert any GUILE_FOR_BUILD-related changes if we conclude that that's
the right thing.

Regards,
  Neil

Re: exit dynamic wind

[Neil Jerram]

Andy Wingo wi...@pobox.com writes:

 I have pushed something that causes the stack to be unwound before
 exiting.  Please let me know if you still see problems.

Unfortunately, yes.  Now when snarf-check-and-output-texi is run, I see:

|   GENguile-procedures.texi
| guile: uncaught throw to wrong-type-arg: (#f Wrong type (expecting ~A): ~S 
(exact integer (#t #catch-closure 9916c10 #catch-closure 9916be0)) ((#t 
#catch-closure 9916c10 #catch-closure 9916be0)))

Reverting ecba00af6501e082b86c8f2f7730081c733509d7 fixes this again.

Or, perhaps, hides the problem again.  It could be that there is a
real problem in snarf-check-and-output-texi that was being hidden by the
failure to unwind.

   Neil

module/ prefix in /usr/local/lib/guile/2.0/ccache/ice-9/*.go

[Neil Jerram]

I noticed that the filename properties in installed .go files always
begin with module/.  Is this correct and, if not, does it matter?

(For example, and-let-star.go has several occurrences of
module/ice-9/and-let-star.scm where I'd expect just
ice-9/and-let-star.scm.)

 Neil

Re: [PATCH 4/5] Inline the effect of am/pre-inst-guile

[Neil Jerram]

Jan Nieuwenhuizen janneke-l...@xs4all.nl writes:

[in rearranged order...]

 -$(preinstguile) -l $(srcdir)/$(snarf_doc).scm -c   
 \
 +$(top_builddir_absolute)/meta/guile -l $(srcdir)/$(snarf_doc).scm   
 \
 + -c
 \

 How do you suggest this works during cross compiling?

Because meta/guile itself uses $GUILE_FOR_BUILD when $cross_compiling is
yes.

 Ah, but in my cross build recipe, i have something like

preinstguile=$GUILE_FOR_BUILD

Is that because you're cross-building in a way that doesn't set
$cross_compiling to yes?

I can understand if you are, because I think I was doing that when last
working on mingw building, and using Wine and binfmt to run the built
executables.

 I know this isn't nice, I think preinstguile should go
 and we should use $GUILE_FOR_BUILD throughout.

 It's just one variable, but one that you can override,

I think the right thing might be to ensure that $cross_compiling is set
to yes for your build, even if the default ./configure mechanisms
(which I presume are based on the --target option) don't set it.  Could
you do a grep-find for cross_compiling, and see if any of the things
that depend on [ $cross_compiling = yes ] would _not_ be appropriate for
your kind of build?

(I think this would have worked for the mingw build that I was doing.
The difference would have been that the non-installed intermediate
executables, like guile_filter_doc_snarfage, were built (using
CC_FOR_BUILD) and run host-natively, instead of being target-built and
then Wine-run.)

Regards,
Neil

Re: proposal: enhance and rename guile-tools

[Neil Jerram]

On 21 March 2011 12:16, Barry Fishman barry_fish...@acm.org wrote:
 Andy Wingo wi...@pobox.com writes:

 On Mon 21 Mar 2011 00:16, l...@gnu.org (Ludovic Courtès) writes:
 FWIW I’m happy with the verbose name and I fear the joke wouldn’t be to
 everyone’s taste.  I’d also be happy with a shorter name, though.

 OK.  Anyone have any other good short names?

I wouldn't normally reply from work, but I'd like to stick an oar in
while the discussion's hot...

I rather like `guile' :-)

Seriously, in the mainline case where guile-tools executes a script,
it boils down to just:

(exit (apply (module-ref (resolve-module (list 'scripts
(string-symbol s)) #:ensure #f) 'main) (cdr args)))

I don't think we need a 198 line script to do that, and I think it
would be good for the main guile executable to have this function,
i.e. apply a named procedure, from a module that can be found in the
load path, to the remaining command line args.

Regarding the other 190 or so lines currently in guile-tools - I'm
sure they have some value, but I don't see why their domain should be
limited to the code in scripts/*.  This could evolve into a more
general tool for extracting and presenting meta-information about
Guile modules.

Regards,
   Neil

PS. Re guido I had a similar response as Ludo - I think that would
be perceived by many people as a bit odd.

Re: proposal: enhance and rename guile-tools

[Neil Jerram]

Andy Wingo wi...@pobox.com writes:

 This is fun :)

 Here are a few threads the PLT folk had:

http://thread.gmane.org/gmane.lisp.scheme.plt.devel/2540
http://thread.gmane.org/gmane.lisp.scheme.plt.devel/2693/focus=2715
http://thread.gmane.org/gmane.lisp.scheme.plt.devel/2775

Well indeed, that pretty much covers the problem space, including my
thought above.

Some further Guile-specific thoughts, in no particular order.

- gel is short; and it's the name of Guile before it was Guile; and
  suggests sticking things together; and AFAIK isn't already being used
  for anything else; and has similar key positions as gdo, so is
  equally easy to type.

- FWIW, the current differences between 'guile-tools THING . ARGS' and
  'guile -e (@@ (scripts THING) main) -- . ARGS appear to be that

  1. the guile command eventually does (main (cons guile ARGS)),
  whereas guile-tools does (main . ARGS) (aka (apply main ARGS))

  2. the guile command runs the REPL afterwards.

- I think I might find guile-tools (as is) less bothering if its
  built-in commands (help, version and list) were rewritten as scripts
  themselves.  Then it would be clearer that the remaining code in
  guile-tools was just implementing the main-invocation convention for
  scripts/*.

(Incidentally I have a patch pending for scripts/README, to remove some
of the statements about that convention that are no longer true.)

On the overall point, of having a separate name instead of just guile,
I think it just comes down to the observation that because the `git'
experience seems definitive.  And I agree that it's hard to argue with
that.

Best wishes for reaching a decision on this!

  Neil

[PATCH 2/5] GUILE_FOR_BUILD is only needed by meta/guile.in, not by Makefiles

[Neil Jerram]

* configure.ac: Use AM_SUBST_NOTMAKE for GUILE_FOR_BUILD instead of
  AC_SUBST.
---
 configure.ac |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/configure.ac b/configure.ac
index 423ae99..d033420 100644
--- a/configure.ac
+++ b/configure.ac
@@ -1496,7 +1496,7 @@ if test $cross_compiling = yes; then
AC_MSG_RESULT($GUILE_FOR_BUILD)
 fi
 AC_ARG_VAR(GUILE_FOR_BUILD,[guile for build system])
-AC_SUBST(GUILE_FOR_BUILD)
+AM_SUBST_NOTMAKE(GUILE_FOR_BUILD)

 ## If we're using GCC, ask for aggressive warnings.
 GCC_CFLAGS=
-- 
1.7.1

Some simple build simplification patches

[Neil Jerram]

Hi all,

Following are 4 simple (I believe) patches that simplify the build.
Plus the one at the end (#5) that is only very loosely related to this,
because of its mentioning of the $GUILE variable, but I think is a
useful cleanup anyway.

For me, these are part of working towards understanding and simplifying
cross-compilation, and the next step is seeing if we really need the
setting and using (in a few places only) of the $GUILE variable.

Any comments / objections?

Thanks,
Neil


PS. It's also my first try of using git send-email to send patches to
the Guile list, so here's hoping that that works out...

[PATCH 3/5] Make explicit that GUILE_FOR_BUILD is only used when cross-compiling

[Neil Jerram]

* configure.ac (GUILE_FOR_BUILD): Change normal build value to
  'this-value-will-never-be-used'.
---
 configure.ac |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/configure.ac b/configure.ac
index d033420..616bdda 100644
--- a/configure.ac
+++ b/configure.ac
@@ -1487,7 +1487,7 @@ if test $cross_compiling = yes; then
   AC_MSG_CHECKING(guile for build)
   GUILE_FOR_BUILD=${GUILE_FOR_BUILD-guile}
 else
-  GUILE_FOR_BUILD='$(preinstguile)'
+  GUILE_FOR_BUILD='this-value-will-never-be-used'
 fi   
 
 ## AC_MSG_CHECKING(if we are cross compiling)
-- 
1.7.1

[PATCH 1/5] Remove unused definition of preinstguiletool

[Neil Jerram]

* am/pre-inst-guile (preinstguiletool): Removed.
---
 am/pre-inst-guile |7 +++
 1 files changed, 3 insertions(+), 4 deletions(-)

diff --git a/am/pre-inst-guile b/am/pre-inst-guile
index 7993d15..b7b0d34 100644
--- a/am/pre-inst-guile
+++ b/am/pre-inst-guile
@@ -1,6 +1,6 @@
-## am/pre-inst-guile --- define preinstguile and preinstguiletool vars
+## am/pre-inst-guile --- define preinstguile
 
-## Copyright (C) 2002, 2006 Free Software Foundation
+## Copyright (C) 2002, 2006, 2011 Free Software Foundation
 ##
 ##   This file is part of GUILE.
 ##
@@ -21,7 +21,7 @@
 
 ## Commentary:
 
-## This fragment defines two variables: preinstguile, preinstguiletool.
+## This fragment defines the preinstguile variable
 ## It can be included in any Makefile.am by adding the line:
 ##   include $(top_srcdir)/am/pre-inst-guile
 ## See devel/build/pre-inst-guile.text (CVS only) for more info.
@@ -29,6 +29,5 @@
 ## Code:
 
 preinstguile = $(top_builddir_absolute)/meta/guile
-preinstguiletool = GUILE=$(preinstguile) $(top_srcdir)/scripts
 
 ## am/pre-inst-guile ends here
-- 
1.7.1

[PATCH 4/5] Inline the effect of am/pre-inst-guile

[Neil Jerram]

It's just one variable definition, and in my opinion it confuses,
rather than helps, the overall build picture to have two names
(preinstguile and meta/guile) for the same thing.

* am/Makefile.am (am_frags): Remove pre-inst-guile.

* am/pre-inst-guile: Deleted.

* doc/ref/Makefile.am: Don't include am/pre-inst-guile.
  ($(snarf_doc).am, $(snarf_doc).texi): Expand $(preinstguile).

* module/Makefile.am (ice-9/psyntax-pp.scm.gen): Don't include
  am/pre-inst-guile.
  (ice-9/psyntax-pp.scm.gen): Expand $(preinstguile).
---
 am/Makefile.am  |2 +-
 am/pre-inst-guile   |   33 -
 doc/ref/Makefile.am |7 +++
 module/Makefile.am  |3 +--
 4 files changed, 5 insertions(+), 40 deletions(-)
 delete mode 100644 am/pre-inst-guile

diff --git a/am/Makefile.am b/am/Makefile.am
index d1b7ecc..e2044d6 100644
--- a/am/Makefile.am
+++ b/am/Makefile.am
@@ -21,7 +21,7 @@
 
 AUTOMAKE_OPTIONS = gnu
 
-am_frags = pre-inst-guile maintainer-dirs guilec
+am_frags = maintainer-dirs guilec
 
 EXTRA_DIST = $(am_frags) ChangeLog-2008
 
diff --git a/am/pre-inst-guile b/am/pre-inst-guile
deleted file mode 100644
index b7b0d34..000
--- a/am/pre-inst-guile
+++ /dev/null
@@ -1,33 +0,0 @@
-## am/pre-inst-guile --- define preinstguile
-
-## Copyright (C) 2002, 2006, 2011 Free Software Foundation
-##
-##   This file is part of GUILE.
-##
-##   GUILE is free software; you can redistribute it and/or modify
-##   it under the terms of the GNU Lesser General Public License as
-##   published by the Free Software Foundation; either version 3, or
-##   (at your option) any later version.
-##
-##   GUILE is distributed in the hope that it will be useful, but
-##   WITHOUT ANY WARRANTY; without even the implied warranty of
-##   MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
-##   GNU Lesser General Public License for more details.
-##
-##   You should have received a copy of the GNU Lesser General Public
-##   License along with GUILE; see the file COPYING.LESSER.  If not, write
-##   to the Free Software Foundation, Inc., 51 Franklin Street, Fifth
-##   Floor, Boston, MA 02110-1301 USA
-
-## Commentary:
-
-## This fragment defines the preinstguile variable
-## It can be included in any Makefile.am by adding the line:
-##   include $(top_srcdir)/am/pre-inst-guile
-## See devel/build/pre-inst-guile.text (CVS only) for more info.
-
-## Code:
-
-preinstguile = $(top_builddir_absolute)/meta/guile
-
-## am/pre-inst-guile ends here
diff --git a/doc/ref/Makefile.am b/doc/ref/Makefile.am
index c154f42..0359380 100644
--- a/doc/ref/Makefile.am
+++ b/doc/ref/Makefile.am
@@ -111,8 +111,6 @@ noinst_DATA = $(PICTURES)
 
 EXTRA_DIST = ChangeLog-2008 $(PICTURES)
 
-include $(top_srcdir)/am/pre-inst-guile
-
 # Automated snarfing
 
 autoconf.texi: autoconf-macros.texi
@@ -129,7 +127,8 @@ snarf_doc = standard-library
 $(snarf_doc).am: $(snarf_doc).scm
GUILE_AUTO_COMPILE=0 ;  
\
variable=`echo $(snarf_doc) | tr - _`_scm_files ; 
\
-   $(preinstguile) -l $(srcdir)/$(snarf_doc).scm -c   
\
+   $(top_builddir_absolute)/meta/guile -l $(srcdir)/$(snarf_doc).scm   
\
+-c
\
 (format #t \# Automatically generated, do not edit.~%\)  
\
 (format #t \$$variable = \)  
\
 (for-each (lambda (m)  
\
@@ -143,7 +142,7 @@ include standard-library.am
 
 $(snarf_doc).texi: $(standard_library_scm_files)
GUILE_AUTO_COMPILE=0\
-   $(preinstguile) $(srcdir)/make-texinfo.scm  \
+   $(top_builddir_absolute)/meta/guile $(srcdir)/make-texinfo.scm  
\
  $(abs_srcdir)/$(snarf_doc).scm  $@.tmp
mv $@.tmp $@
 
diff --git a/module/Makefile.am b/module/Makefile.am
index 9940900..754bebf 100644
--- a/module/Makefile.am
+++ b/module/Makefile.am
@@ -73,9 +73,8 @@ ETAGS_ARGS += \
   ice-9/compile-psyntax.scm\
   ice-9/ChangeLog-2008
 
-include $(top_srcdir)/am/pre-inst-guile
 ice-9/psyntax-pp.scm.gen:
-   $(preinstguile) --no-auto-compile -s 
$(srcdir)/ice-9/compile-psyntax.scm \
+   $(top_builddir_absolute)/meta/guile --no-auto-compile -s 
$(srcdir)/ice-9/compile-psyntax.scm \
$(srcdir)/ice-9/psyntax.scm $(srcdir)/ice-9/psyntax-pp.scm
 
 .PHONY: ice-9/psyntax-pp.scm.gen
-- 
1.7.1

[PATCH 5/5] Remove statements about scripts/* that are no longer true

[Neil Jerram]

* doc/ref/tools.texi (Executable Modules): Say guile-tools modules
  instead of executable modules.  Remove obsolete statements about
  not ending in .scm, being executable, and beginning with shell
  script invocation sequence.

* module/scripts/README: Ditto.
---
 doc/ref/tools.texi|   33 +++--
 module/scripts/README |   23 +--
 2 files changed, 12 insertions(+), 44 deletions(-)

diff --git a/doc/ref/tools.texi b/doc/ref/tools.texi
index 2f4f59a..7a98884 100644
--- a/doc/ref/tools.texi
+++ b/doc/ref/tools.texi
@@ -303,14 +303,11 @@ is rather byzantine, so for now @emph{NO} doc snarfing 
programs are installed.
 @cindex executable modules
 @cindex scripts
 
-When Guile is installed, in addition to the @code{(ice-9 FOO)} modules,
-a set of @dfn{executable modules} @code{(scripts BAR)} is also installed.
-Each is a regular Scheme module that has some additional packaging so
-that it can be called as a program in its own right, from the shell.  For this
-reason, we sometimes use the term @dfn{script} in this context to mean the
-same thing.
-
-@c wow look at this hole^!  variable-width font users eat your heart out.
+When Guile is installed, in addition to the @code{(ice-9 FOO)} modules, a set
+of @dfn{guile-tools modules} @code{(scripts BAR)} is also installed.  Each is
+a regular Scheme module that has some additional packaging so that it can be
+used by guile-tools, from the shell.  For this reason, we sometimes use the
+term @dfn{script} in this context to mean the same thing.
 
 As a convenience, the @code{guile-tools} wrapper program is installed along w/
 @code{guile}; it knows where a particular module is installed and calls it
@@ -346,17 +343,11 @@ executable module.  Feel free to skip to the next chapter.
 
 See template file @code{PROGRAM} for a quick start.
 
-Programs must follow the @dfn{executable module} convention, documented here:
+Programs must follow the @dfn{guile-tools} convention, documented here:
 
 @itemize
 
 @item
-The file name must not end in .scm.
-
-@item
-The file must be executable (chmod +x).
-
-@item
 The module name must be (scripts PROGRAM).  A procedure named PROGRAM w/
 signature (PROGRAM . args) must be exported.  Basically, use some variant
 of the form:
@@ -377,20 +368,10 @@ There must be the alias:
 
 However, `main' must NOT be exported.
 
-@item
-The beginning of the file must use the following invocation sequence:
-
-@example
-#!/bin/sh
-main='(module-ref (resolve-module '\''(scripts PROGRAM)) '\'main')'
-exec $@{GUILE-guile@} -l $0 -c (apply $main (cdr (command-line))) $@@
-!#
-@end example
-
 @end itemize
 
 Following these conventions allows the program file to be used as module
-@code{(scripts PROGRAM)} in addition to as a standalone executable.  Please
+@code{(scripts PROGRAM)} in addition to being invoked by guile-tools.  Please
 also include a helpful Commentary section w/ some usage info.
 
 @c tools.texi ends here
diff --git a/module/scripts/README b/module/scripts/README
index 56dd286..cb397f5 100644
--- a/module/scripts/README
+++ b/module/scripts/README
@@ -4,9 +4,9 @@ Overview and Usage
 This directory contains Scheme programs, some useful in maintaining Guile.
 On make install, these programs are copied to PKGDATADIR/VERSION/scripts.
 
-You can invoke a program from the shell, or alternatively, load its file
-as a Guile Scheme module, and use its exported procedure(s) from Scheme code.
-Typically for any PROGRAM:
+You can use guile-tools to invoke a program from the shell, or alternatively,
+load its file as a Guile Scheme module, and use its exported procedure(s)
+from Scheme code.  Typically for any PROGRAM:
 
   (use-modules (scripts PROGRAM))
   (PROGRAM ARG1 ARG2 ...)
@@ -22,8 +22,6 @@ To see PROGRAM's commentary, which may or may not be helpful:
 
   (help (scripts PROGRAM))
 
-To see all commentaries and module dependencies, try: make overview.
-
 If you want to try the programs before installing Guile, you will probably
 need to set environment variable GUILE_LOAD_PATH to be the parent directory.
 This can be done in Bourne-compatible shells like so:
@@ -40,11 +38,7 @@ How to Contribute
 
 See template file PROGRAM for a quick start.
 
-Programs must follow the executable module convention, documented here:
-
-- The file name must not end in .scm.
-
-- The file must be executable (chmod +x).
+Programs must follow the guile-tools convention, documented here:
 
 - The module name must be (scripts PROGRAM).  A procedure named PROGRAM w/
   signature (PROGRAM . args) must be exported.  Basically, use some variant
@@ -61,15 +55,8 @@ Programs must follow the executable module convention, 
documented here:
 
   However, `main' must NOT be exported.
 
-- The beginning of the file must use the following invocation sequence:
-
-  #!/bin/sh
-  main='(module-ref (resolve-module '\''(scripts PROGRAM)) '\'main')'
-  exec ${GUILE-guile} -l $0 -c (apply $main (cdr (command-line))) $@
-  !#
-
 Following 

Re: Error in make check building guile-lib for guile 2.0. trap-enable unbound

[Neil Jerram]

l...@gnu.org (Ludovic Courtès) writes:

 Hi Neil,

 Neil Jerram n...@ossau.uklinux.net writes:

 I had a feeling that a lot (or even maybe all) of guile-lib got merged
 into the main Guile distribution.  So are you sure you still need
 separate guile-lib at all?

 Only (sxml ...), (texinfo ...), and (statprof) got merged, IIRC.  The
 other modules are still unique to Guile-Lib:

   http://www.nongnu.org/guile-lib/doc/ref/

Ah, thanks.

 I changed Guile-Lib in Git to not install those modules that come with
 2.0 when using 2.0.

Sounds good.  That may do the trick, if Dale's only problem was picking
up the wrong (old) version of statprof.scm.

 Neil

Re: Cross-compiling Guile 2.0

[Neil Jerram]

Andy Wingo wi...@pobox.com writes:

 On Sat 05 Mar 2011 20:47, Neil Jerram n...@ossau.uklinux.net writes:

 In principle, how should Guile 2.0 be cross-compiled?  I'm thinking
 mostly of the part of the build that compiles all the installed
 modules.

 I have never cross-compiled anything, so I really don't know.

 Ideally we could make a cross-compiling Guile that executed on the host,
 but produced .go files for the target.

 Humm.  Does that mean that for cross-compile builds, that we should
 not add the $builddir to the LOAD_COMPILED_PATH?  Probably so, right?  A
 cross-compiler probably doesn't autocompile either.  So then the
 cross-compiler receives as its inputs the source files from a project,
 then produces .go files for the target, but does not load .go files from
 the target.

 Does that sound right to you?

Thanks for your input on this.

Yes.  In principle I think the cross-compiler could simultaneously
auto-compile, for itself, and non-auto-compile for the target, but
that's a bit mind-blowing and would require careful handling of what's
being written and read from where.  Instead of that, we could do two
separate steps: one where the cross-compiler compiles for itself, and
one to compile for the target.

What architectural dependencies are there in the .go format?  If there
aren't too many, a cross-compiler is probably the nicest solution,
because the other two options (QEMU, and compiling after installation on
the target) are probably going to be ridiculously slow.

   Neil

Cross-compiling Guile 2.0

[Neil Jerram]

In principle, how should Guile 2.0 be cross-compiled?  I'm thinking
mostly of the part of the build that compiles all the installed modules.

I think target emulation is needed, using QEMU, and in particular that
it wouldn't work to set GUILE_FOR_BUILD to a build-system-native guile,
because that would generate .go files with the wrong architecture.

Alternatively, I suppose another approach would be to defer the module
compilation part of the build until after installation on the target.

Does that sound right?  Are there any other possibilities?

(The target is my Openmoko Freerunner phone.)

Thanks,
Neil

Re: Error in make check building guile-lib for guile 2.0. trap-enable unbound

[Neil Jerram]

dsm...@roadrunner.com writes:

 Howdy Guilers,

 As some of you know, I've been slowing bringing scwm back up to speed.
 I've gotten quite far but the next major hurdle is gtk+, so I am
 attempting to build and install that.  The first thing needed is
 guile-lib, which builds fine for me from git but has the following
 error output.

I had a feeling that a lot (or even maybe all) of guile-lib got merged
into the main Guile distribution.  So are you sure you still need
separate guile-lib at all?

 PASS: search.basic.scm
 Backtrace:
 In module/ice-9/boot-9.scm:
  170: 11 [catch #t #catch-closure 10ea2c0 ...]
 In unknown file:
?: 10 [catch-closure]
 In module/ice-9/boot-9.scm:
   62: 9 [call-with-prompt prompt0 ...]
 In module/ice-9/eval.scm:
  389: 8 [eval # #]
 In module/ice-9/boot-9.scm:
 1917: 7 [save-module-excursion #procedure 10f5840 at 
 module/ice-9/boot-9.scm:3339:3 ()]
 3346: 6 [#procedure 10f5840 at module/ice-9/boot-9.scm:3339:3 ()]
 1189: 5 [%start-stack load-stack ...]
 1194: 4 [#procedure 1105990 ()]
 In unknown file:
?: 3 [primitive-load 
 /home/dsmith/src/guile-lib/unit-tests/./statprof.scm]
 In module/ice-9/eval.scm:
  349: 2 [eval #memoized (trap-enable (quote traps)) ()]
  356: 1 [eval #memoized trap-enable ()]
 In unknown file:
?: 0 [memoize-variable-access! #memoized trap-enable #directory # 
 fea090]

There's certainly a statprof.scm in core Guile, which doesn't use
trap-enable.

Regards,
Neil