Guile with win32 cross compiling

[Volker Grabsch]

Hello Mike,

I just tried again to cross compile a win32 version of guile, using
the latest 2.0.0 release. My last attempt in April 2010 failed.

Much has been improved since then, but there are still fatal
errors, so I still can't support guile-2 in mingw-cross-env. [1]


1)

The first issue is the "#include " in gen-scmconfig,
which has already been discussed in the past and for which I
already provided a clean, working solution. I forward-ported
my patch to guile-2.0.0 and it seems to work. This patch is
attached to this email, please consider applying it.

Also attached is a build log created by mingw-cross-env showing
how far the cross build gets with this patch.


2)

The other open issue is also a known one: the missing mmap()
function under Windows. After some research, I found a promising
mmap()/munmap() implementation for Windows in a free software
project:

http://code.google.com/p/flvmeta/source/browse/trunk/src/mmap.h?r=74
http://code.google.com/p/flvmeta/source/browse/trunk/src/mmap.c?r=74

Maybe this is worth integrating into guile?



Greets,
Volker


[1] http://mingw-cross-env.nongnu.org/

-- 
Volker Grabsch
---<<(())>>---

Guile with win32 cross compiling

[Volker Grabsch]

Hello Mike,

I just tried again to cross compile a win32 version of guile, using
the latest 2.0.0 release. My last attempt in April 2010 failed.

Much has been improved since then, but there are still fatal
errors, so I still can't support guile-2 in mingw-cross-env. [1]


1)

The first issue is the "#include " in gen-scmconfig,
which has already been discussed in the past and for which I
already provided a clean, working solution. I forward-ported
my patch to guile-2.0.0 and it seems to work. This patch is
attached to this email, please consider applying it.

Also attached is a build log created by mingw-cross-env showing
how far the cross build gets with this patch.


2)

The other open issue is also a known one: the missing mmap()
function under Windows. After some research, I found a promising
mmap()/munmap() implementation for Windows in a free software
project:

http://code.google.com/p/flvmeta/source/browse/trunk/src/mmap.h?r=74
http://code.google.com/p/flvmeta/source/browse/trunk/src/mmap.c?r=74

Maybe this is worth integrating into guile?



Greets,
Volker


[1] http://mingw-cross-env.nongnu.org/

-- 
Volker Grabsch
---<<(())>>---
This file is part of mingw-cross-env.
See doc/index.html for further information.

--- a/libguile/Makefile.am
+++ b/libguile/Makefile.am
@@ -57,8 +57,8 @@ gen_scmconfig_SOURCES = gen-scmconfig.c
 gen-scmconfig.$(OBJEXT): gen-scmconfig.c
 	$(AM_V_GEN)			\
 	if [ "$(cross_compiling)" = "yes" ]; then			\
-		$(CC_FOR_BUILD) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES)	\
-		  $(AM_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS)	\
+		$(CC_FOR_BUILD) $(DEFS) $(DEFAULT_INCLUDES)		\
+	  -DBUILDING_LIBGUILE=1 -I$(top_srcdir) -I$(top_builddir)	\
 	  -c -o $@ $<;		\
 	else\
 		$(COMPILE) -c -o $@ $<;	\
--- a/libguile/gen-scmconfig.c
+++ b/libguile/gen-scmconfig.c
@@ -123,7 +123,6 @@
 
 #include 
 #include 
-#include 
 
 #define pf printf
 
@@ -143,6 +142,7 @@ main (int argc, char *argv[])
 pf ("#include \n");
   if (SCM_I_GSC_NEEDS_INTTYPES_H)
 pf ("#include \n");
+  pf ("#include \n");
 
 #ifdef HAVE_LIMITS_H
   pf ("#include \n");
@@ -379,11 +379,9 @@ main (int argc, char *argv[])
 
   pf ("\n");
   pf ("/* Constants from uniconv.h.  */\n");
-  pf ("#define SCM_ICONVEH_ERROR %d\n", (int) iconveh_error);
-  pf ("#define SCM_ICONVEH_QUESTION_MARK %d\n", 
-  (int) iconveh_question_mark);
-  pf ("#define SCM_ICONVEH_ESCAPE_SEQUENCE %d\n",
-  (int) iconveh_escape_sequence);  
+  pf ("#define SCM_ICONVEH_ERROR ((int) iconveh_error)\n");
+  pf ("#define SCM_ICONVEH_QUESTION_MARK ((int) iconveh_question_mark)\n");
+  pf ("#define SCM_ICONVEH_ESCAPE_SEQUENCE ((int) iconveh_escape_sequence)\n");
 
   printf ("#endif\n");
 
make[1]: Entering directory `/home/vog/mingw-cross-env'
rm -rf   '/home/vog/mingw-cross-env/tmp-guile'
mkdir -p '/home/vog/mingw-cross-env/tmp-guile'
cd '/home/vog/mingw-cross-env/tmp-guile' &&  tar xzf 
'/home/vog/mingw-cross-env/pkg/guile-2.0.0.tar.gz'
cd '/home/vog/mingw-cross-env/tmp-guile/guile-2.0.0'
(cd '/home/vog/mingw-cross-env/tmp-guile/guile-2.0.0' && patch -p1 -u) < 
./src/guile-1-fix-gen-scmconfig-for-cross-compiling.patch
patching file libguile/Makefile.am
patching file libguile/gen-scmconfig.c
cd '/home/vog/mingw-cross-env/tmp-guile/guile-2.0.0' && autoreconf
autoreconf: configure.ac: AM_GNU_GETTEXT is used, but not AM_GNU_GETTEXT_VERSION
cd '/home/vog/mingw-cross-env/tmp-guile/guile-2.0.0' && libtoolize --force
libtoolize: putting auxiliary files in AC_CONFIG_AUX_DIR, `build-aux'.
libtoolize: linking file `build-aux/ltmain.sh'
libtoolize: putting macros in AC_CONFIG_MACRO_DIR, `m4'.
libtoolize: linking file `m4/libtool.m4'
libtoolize: linking file `m4/ltoptions.m4'
libtoolize: linking file `m4/ltsugar.m4'
libtoolize: linking file `m4/ltversion.m4'
libtoolize: linking file `m4/lt~obsolete.m4'
cd '/home/vog/mingw-cross-env/tmp-guile/guile-2.0.0' && ./configure 
--host='i686-pc-mingw32' 
--prefix='/home/vog/mingw-cross-env/usr/i686-pc-mingw32' --disable-shared 
--without-threads
configure: WARNING: if you wanted to set the --build type, don't use --host.
If a cross compiler is detected then cross compile mode will be used
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for i686-pc-mingw32-strip... i686-pc-mingw32-strip
checking for a thread-safe mkdir -p... /bin/mkdir -p
checking for gawk... gawk
checking whether make sets $(MAKE)... yes
checking build system type... x86_64-unknown-linux-gnu
checking host system type... i686-pc-mingw32
checking for i686-pc-mingw32-as... i686-pc-mingw32-as
checking for i686-pc-mingw32-dlltool... i686-pc-mingw32-dlltool
checking for i686-pc-mingw32-objdump... i686-pc-mingw32-objdump
checking for i686-pc-mingw32-gcc... i686-pc-mingw32-gcc
checking whether the C compiler works... yes
checking for C compiler default output file name... a.exe
checking for suffix of executables... .exe
checking whether we are cross

Re: VM stack overflow while calling sxml-match within let* or car

[Andy Wingo]

On Sun 27 Mar 2011 13:30, Andy Wingo  writes:

>> (And Guile crashes upon ,bt.)
>
> I wonder if this indicates some compilation bug.

Indeed it does; it's a bug in Guile, not sxml-match.

The following expression exhibits this bug:

(car
 (letrec ((f (lambda ()
   (call-with-prompt
'p
(lambda () #t)
(lambda (k) #f)
   (f)))

Andy
-- 
http://wingolog.org/

Re: Fmt Module

[Andy Wingo]

On Mon 14 Mar 2011 18:35, Klaus Schilling  writes:

> From: l...@gnu.org (Ludovic Courtès)
> Subject: Re: Fmt Module
> Date: Mon, 14 Mar 2011 18:16:17 +0100
>> 
>> When we do include external libs, we should strive to leave upstream
>> files unmodified, as is done for (sxml ssax), (system base lalr),
>> (ice-9 match), and others.
>
> Why does htmlprag not get included?

Because it's not used by Guile itself, unlike the sxml stuff, statprof,
lalr, the matchers or the texinfo code.  Likewise, and more topically, I
would be inclined to include `fmt' iff we want to use it in Guile
itself.

You can install htmlprag from Guile-Lib; version 0.2.0 was released
yesterday.

I assume your broader point is that you would like it to be easier to
install htmlprag.  The CPAN for guile should fill that nice nicely.

Regards,

Andy
-- 
http://wingolog.org/

Re: ‘set-cdr!’ and weak-cdr pairs

[Andy Wingo]

On Sun 13 Mar 2011 16:25, l...@gnu.org (Ludovic Courtès) writes:

> The problem is that ‘hash-create-handle!’ above created a weak-cdr
> pair—i.e., a pair whose cdr is /not/ scanned for pointers—but ‘set-cdr!’
> did not register a disappearing link from O to K+V.  Consequently, O
> eventually gets collected, but K+V remains; the storage of O then gets
> reused, and the cdr of K+V ends up containing either an unrelated or >an
> invalid Scheme object.

Given that we don't expose weak-pair constructors or accessors to
Scheme, we should not expose weak pairs to Scheme.  What do you think
about making it an error to hash-create-handle! on a weak table?  That
way you never expose a weak pair to Scheme.  It does appear possible to
discriminate in C between calls to create-handle! that occur due to ref
/ set! and those that are called explicitly.

Also that would free up our implementation to use something other than
weak pairs for weak hash tables.  In particular, I think first-class
weak references are not a bad idea, as Chez Scheme does.

WDYT?

Andy
-- 
http://wingolog.org/

Re: The usage of -dtrace-scheme-coverage in Lilypond

[Andy Wingo]

Hello zhangxy,

On Fri 11 Mar 2011 14:31, Han-Wen Nienhuys  writes:

> On Fri, Mar 11, 2011 at 12:21 AM, zhangxy  wrote:
>> Now I want to analyze the test coverage of Lilypond.
>
> Apparently there is a new mechanism for finding coverage.  See
> https://www.gnu.org/software/guile/manual/html_node/Code-Coverage.html
> - perhaps you can work out a way with the guile folks to resurrect
> lilypond's test coverage code.

The code in Guile's `test-suite/guile-test' looks like this:

(let-values (((coverage-data _)
  (with-code-coverage (the-vm) run-tests)))
  (let ((out (open-output-file "guile.info")))
(coverage-data->lcov coverage-data out)
(close out)))

where `run-tests' is a thunk that runs the tests.

Andy
-- 
http://wingolog.org/

Re: SRFI-23

[Andy Wingo]

On Fri 11 Mar 2011 17:48, Noah Lavine  writes:

> Guile supports srfi-23 (the `error' procedure), and probably has
> forever, but it's not documented. This patch adds a note in the manual
> saying we support it, and also adds srfi-23 to our list of cond-expand
> features that we support.

Applied, thanks!

Andy
-- 
http://wingolog.org/

Re: Fmt Module

[Andy Wingo]

On Mon 14 Mar 2011 18:16, l...@gnu.org (Ludovic Courtès) writes:

> I think it would make sense to include ‘fmt’ in core Guile only if the
> API is reasonably stable and there are infrequent upstream releases, so
> we don’t quickly end up shipping an old incompatible version.

Agreed, and I don't know if this is the case or not.

I would add on another criteria, that we should avoid adding modules to
Guile unless they are to be used in Guile itself.  For everything else,
there is our CPAN that we need to make -- it will provide more freedom
both for module authors/packagers and for users.

Regards,

Andy
-- 
http://wingolog.org/

Re: VM stack overflow while calling sxml-match within let* or car

[Andy Wingo]

On Mon 14 Mar 2011 18:40, l...@gnu.org (Ludovic Courtès) writes:

> I can reproduce the problem:

Me too.  How weird.

scheme@(guile-user)> (sxml-match '(to "Trove") ((to ,cv) (list cv)) (,_ #f))
$5 = ("Trove")
scheme@(guile-user)> (define x (sxml-match '(to "Trove") ((to ,cv) (list cv)) 
(,_ #f)))
module/ice-9/boot-9.scm:1514:2: In procedure #:
module/ice-9/boot-9.scm:1514:2: Throw to key `vm-error' with args `(vm-run "VM: 
Stack overflow" ())'.

The second is the same as the first, only it's in a `define'.

> (And Guile crashes upon ,bt.)

Here too.  I wonder if this indicates some compilation bug.

Andy
-- 
http://wingolog.org/

Re: VM stack overflow while calling sxml-match within let* or car

[Andy Wingo]

On Sun 27 Mar 2011 13:56, Andy Wingo  writes:

> On Sun 27 Mar 2011 13:30, Andy Wingo  writes:
>
>>> (And Guile crashes upon ,bt.)
>>
>> I wonder if this indicates some compilation bug.
>
> Indeed it does; it's a bug in Guile, not sxml-match.
>
> The following expression exhibits this bug:
>
> (car
>  (letrec ((f (lambda ()
>(call-with-prompt
> 'p
> (lambda () #t)
> (lambda (k) #f)
>(f)))

Fixed in git.  Thanks for the amusing bug, Mr. Turing!

Andy
-- 
http://wingolog.org/

Re: ‘set-cdr!’ and weak-cdr pairs

[Ludovic Courtès]

Hello!

Andy Wingo  writes:

> On Sun 13 Mar 2011 16:25, l...@gnu.org (Ludovic Courtès) writes:
>
>> The problem is that ‘hash-create-handle!’ above created a weak-cdr
>> pair—i.e., a pair whose cdr is /not/ scanned for pointers—but ‘set-cdr!’
>> did not register a disappearing link from O to K+V.  Consequently, O
>> eventually gets collected, but K+V remains; the storage of O then gets
>> reused, and the cdr of K+V ends up containing either an unrelated or >an
>> invalid Scheme object.
>
> Given that we don't expose weak-pair constructors or accessors to
> Scheme, we should not expose weak pairs to Scheme.  What do you think
> about making it an error to hash-create-handle! on a weak table?  That
> way you never expose a weak pair to Scheme.  It does appear possible to
> discriminate in C between calls to create-handle! that occur due to ref
> / set! and those that are called explicitly.

Yes, sounds good.  Would you like to work on it?  :-)

Thanks,
Ludo’.

Re: Fmt Module

[Ludovic Courtès]

Hello,

Andreas Rottmann  writes:

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

[...]

>> Besides it’s still unclear (to me) what the future of Wak and similar
>> projects is.  I hope that it will take off, but I haven’t forgotten
>> Snow, ScmPkg, etc. either.
>>
> Well, there's a (IMHO) important difference in that Wak packages are
> based on R6RS, which specifies a module system.

But it doesn’t specify how modules are mapped to files.

And there’s R7RS, which specifies and slightly incompatible module
system, and there’s people who’ll always want to use their
implementation’s native module system, etc.

Let’s hope I’m overly pessimistic.  :-)

Thanks,
Ludo’.

Re: VM stack overflow while calling sxml-match within let* or car

[nalaginrut]

> On Sun 27 Mar 2011 13:56, Andy Wingo  writes:
> 
> > On Sun 27 Mar 2011 13:30, Andy Wingo  writes:
> >
> >>> (And Guile crashes upon ,bt.)
> >>
> >> I wonder if this indicates some compilation bug.
> >
> > Indeed it does; it's a bug in Guile, not sxml-match.
> >
> > The following expression exhibits this bug:
> >
> > (car
> >  (letrec ((f (lambda ()
> >(call-with-prompt
> > 'p
> > (lambda () #t)
> > (lambda (k) #f)
> >(f)))
> 
> Fixed in git.  Thanks for the amusing bug, Mr. Turing!
> 
> Andy

Well~it's a nice news. My code was modified to an more ugly style to
make it work because of this bug. But I think it's cure now. :-)

-- 
GNU Powered it
GPL Protected it
GOD Blessed it

HFG - NalaGinrut

Re: VM stack overflow while calling sxml-match within let* or car

[Ludovic Courtès]

Hi!

Andy Wingo  writes:

> On Sun 27 Mar 2011 13:56, Andy Wingo  writes:
>
>> On Sun 27 Mar 2011 13:30, Andy Wingo  writes:
>>
 (And Guile crashes upon ,bt.)
>>>
>>> I wonder if this indicates some compilation bug.
>>
>> Indeed it does; it's a bug in Guile, not sxml-match.
>>
>> The following expression exhibits this bug:
>>
>> (car
>>  (letrec ((f (lambda ()
>>(call-with-prompt
>> 'p
>> (lambda () #t)
>> (lambda (k) #f)
>>(f)))
>
> Fixed in git.  Thanks for the amusing bug, Mr. Turing!

Woow, interesting bug, good catch!

Thanks,
Ludo’.

Re: bdw-gc includes in libguile.h

[Ludovic Courtès]

Hello!

Andy Wingo  writes:

> On Fri 25 Mar 2011 19:06, l...@gnu.org (Ludovic Courtès) writes:
>
>> Andy Wingo  writes:

[...]

>>> I think that in 2.2 we should not expose libgc interfaces in libguile,
>>
>> That would be great, but then ‘scm_cell’, ‘SCM_NEWSMOB’, etc. would
>> need to do a function call, which we don’t want.  Even if we did want
>> it, the change would break the ABI.
>
> I realize this :)  That's why I am proposing it for 2.2, which will
> (presumably) be ABI-incompatible.

OK.

> I don't think inlining NEWSMOB et al actually buys us anything worth
> buying, so to speak.

Yes, I agree.

Internally we should still inline scm_cell & co., though; that can be
done without exposing  in public headers I guess.  (Actually,
we should inline scm_cons, too, internally.)

>> A meta-comment: can we agree to take more time to discuss this sort of
>> things?  I’ll try to be responsive, and the earth won’t stop spinning if
>> the fix waits a couple of days.  ;-)
>
> Sure.  Sorry for the precipitous action.  That said, this bug has been
> open since September:  https://savannah.gnu.org/bugs/?32436

Oh indeed, I hadn’t realized there’s a connection; still...

Thanks,
Ludo’.

Re: [PATCH] Take some lowhanging fruit to speed up R6RS fixnum operations

[Ludovic Courtès]

Hello,

Andreas Rottmann  writes:

> So, that's around 5% improvment (on the ZIP benchmark) for an IMHO
> significantly more hackish implementation.  I'm not sure that's worth
> it. WDYT?

Was it with ‘fixnum?’ inline, or with the ‘fixnum?’ instruction?

It’s ironic that while R6RS fixnums are a performance hack, they end up
being less efficient than unbounded integers in Guile.

Do you know how other implementations deal with that?

Thanks,
Ludo’.

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

[Ludovic Courtès]

Hello,

A few more thoughts...

Andy Wingo  writes:

> On Fri 25 Mar 2011 18:58, l...@gnu.org (Ludovic Courtès) writes:
>
>> "Andy Wingo"  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.

> Some people want to build on Debian stable, which has seemed to work
> fine.

That can only work with explicit hacks, because 6.8 doesn’t have a .pc
file whereas our configure.ac checks for that.

Thanks,
Ludo’.

Re: Fmt Module

[Noah Lavine]

Hello,

>> I think it would make sense to include ‘fmt’ in core Guile only if the
>> API is reasonably stable and there are infrequent upstream releases, so
>> we don’t quickly end up shipping an old incompatible version.
>
> Agreed, and I don't know if this is the case or not.
>
> I would add on another criteria, that we should avoid adding modules to
> Guile unless they are to be used in Guile itself.  For everything else,
> there is our CPAN that we need to make -- it will provide more freedom
> both for module authors/packagers and for users.

This makes sense, but I think there is an important distinction to
make that we do not currently make. We should have a clear idea of
what modules are used by Guile, so we can get a "minimal" Guile when
we want it, for instance for embedding into other applications.
However, it would be great if the standard install of Guile included
lots of modules, such as htmlprag, because it is nice to have the
batteries included when you are programming.

Noah

Re: [PATCH] Take some lowhanging fruit to speed up R6RS fixnum operations

[Andreas Rottmann]

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

> Hello,
>
> Andreas Rottmann  writes:
>
>> So, that's around 5% improvment (on the ZIP benchmark) for an IMHO
>> significantly more hackish implementation.  I'm not sure that's worth
>> it. WDYT?
>
> Was it with ‘fixnum?’ inline, or with the ‘fixnum?’ instruction?
>
The numbers from my previous mail were with the "clever" `fixnum?'
(i.e. the one that uses object-address and bit-twiddling), defined with
`define-inline'.  I have yet to produce numbers with `fixnum?' as VM
primitive and the more complicated, partially-inlinable fixnum
operators.  I'll keep you posted.

> It’s ironic that while R6RS fixnums are a performance hack, they end up
> being less efficient than unbounded integers in Guile.
>
Indeed.

> Do you know how other implementations deal with that?
>
I will do some research on that topic, investigating Racket, Ikarus and
Ypsilon -- these are the R6RS implementations, which I'm most familiar
with (besides Guile, obviously).

Regards, Rotty
-- 
Andreas Rottmann -- 

Re: Fmt Module

[Andreas Rottmann]

Noah Lavine  writes:

> Hello,
>
>>> I think it would make sense to include ‘fmt’ in core Guile only if the
>>> API is reasonably stable and there are infrequent upstream releases, so
>>> we don’t quickly end up shipping an old incompatible version.
>>
>> Agreed, and I don't know if this is the case or not.
>>
>> I would add on another criteria, that we should avoid adding modules to
>> Guile unless they are to be used in Guile itself.  For everything else,
>> there is our CPAN that we need to make -- it will provide more freedom
>> both for module authors/packagers and for users.
>
> This makes sense, but I think there is an important distinction to
> make that we do not currently make. We should have a clear idea of
> what modules are used by Guile, so we can get a "minimal" Guile when
> we want it, for instance for embedding into other applications.
>
+1!  Racket has acquired a problem with that over the years, and there
are now efforts to rectify it [0].

[0] http://www.mail-archive.com/dev@racket-lang.org/msg02376.html

> However, it would be great if the standard install of Guile included
> lots of modules, such as htmlprag, because it is nice to have the
> batteries included when you are programming.
>
My opinion on that is that if it's really easy to install additional
libraries (which is not yet the case, unfortunatly!), there would be no
need to bundle additional stuff not needed by the core into Guile
releases.

Regards, Rotty
-- 
Andreas Rottmann -- 

GSoC 2011

[Diogo F. S. Ramos]

Hello everybody,

I've been following some discussions about GSoC here and in the IRC and
I would like to say that I would love to work with you in this winter
;).

For those who are normally in the IRC, I'm didi. :D

As I can see, there are two main ideas:

  1. CPAN for Guile

  2. RoR for Guile

I've chatted a little with wingo at #guile about it but I would like to
know what the project is more interested in to be done.

I have my own ideas, like the Introspection branch that I forked from
zeenix, but I am not sure this is of the best interest for guile right
now.

-- 
Diogo F. S. Ramos