Problem compiling related to block-growth-factor fluid

Problem compiling related to block-growth-factor fluid

[rixed]

Hello list !

I'm using guile 2.0.2.4-17047 in production and noticed a strange
problem when my program try to compile some expression ; namely,
this exception:

In language/glil/spec.scm:
  32: 4 [compile-asm # # ()]
In language/glil/compile-assembly.scm:
 275: 3 [compile-assembly #]
In srfi/srfi-1.scm:
 445: 2 [fold #<procedure walk (x store)> #<vlist ()> ...]
 445: 1 [fold #<procedure walk (x store)> #<vlist ()> ...]
In ice-9/vlist.scm:
 422: 0 [vhash-cons 340277174624079928635746076935438991360 2 ...]

ice-9/vlist.scm:422:20: In procedure vhash-cons:
ice-9/vlist.scm:422:20: In procedure *: Wrong type argument in position 1: #f

It works alright when I compile the same expression from the REPL,
though, so there is probably something wrong with my program in the
first place. But on my dev machine (where I use a guile from the
stable-2 branch) it always worked.

This seams to be due to the block-growth-factor fluid in vlist.scm,
which for some reason has not been set (to 2 by default), for if I
change the guilty fluid-ref by:

(or (fluid-ref block-growth-factor) 2)

then all seams right.
block-cons being a macro I might need to import block-growth-factor
somewhere?

I looked in the git log of stable-2.0 for a bug regarding this but was
unable to find it. So I ask here in the hope that someone remember a
patch that might have fixed this issue, so that I might have a chance
to patch some scm files and get rid of the issue without the trouble
if packaging a more recent version of guile?

Also, after I changed vlist.scm, I noticed that whenever I try to
compile something I got this:

;;; note: source file /usr/share/guile/2.0/ice-9/vlist.scm
;;;       newer than compiled /usr/lib/guile/2.0/ccache/ice-9/vlist.go
;;; note: auto-compilation is enabled, set GUILE_AUTO_COMPILE=0
;;;       or pass the --no-auto-compile argument to disable.
;;; compiling /usr/share/guile/2.0/ice-9/vlist.scm
;;; WARNING: compilation of /usr/share/guile/2.0/ice-9/vlist.scm failed:
;;; ERROR: no such language tree-il

Google know about this particular problem [1], apparently related to the
fact that the compilation process requires the very file it's trying to
compile, but I couldn't find a solution to this.  But if I'm about to
patch stdlib scheme files I also need to deal with this problem, so any
idea about this would be welcome as well.


[1] http://lists.gnu.org/archive/html/guile-devel/2009-12/msg00033.html

Re: Problem compiling related to block-growth-factor fluid

[rixed]

-[ Mon, Nov 21, 2011 at 10:26:07AM +0100, rixed@happyleptic.org ]----
> But on my dev machine (where I use a guile from the
> stable-2 branch) it always worked.

Actually, it always worked because my setup was slightly different
and not because of the different version of guile, since it failed
as well with my recent guile when using the prod setup on my dev
host.

So the problem might not have already been fixed.

Re: Problem compiling related to block-growth-factor fluid

[rixed]

[-- Attachment #1: Type: text/plain, Size: 279 bytes --]

Here is a minimal example reproducing the problem.
Note that it only fails the first time (when scheme.scm is compiled).

Note: I put bug-guile on CC, hoping it will not trash the attachments,
because with this example I'm starting to believe there is something
wrong going on.


[-- Attachment #2: Makefile --]
[-- Type: text/plain, Size: 131 bytes --]

CFLAGS += $(shell guile-config compile) -std=c99
LDLIBS += $(shell guile-config link) -lpthread

all: main

clean:
	rm -f *.o main

[-- Attachment #3: scheme.scm --]
[-- Type: text/plain, Size: 162 bytes --]

(define-module (test))
(use-modules (system base compile))

(define prog '(lambda (a b c)
			    (+ a b c)))

(define (f)
  (compile prog)
  (display "done\n"))


[-- Attachment #4: main.c --]
[-- Type: text/x-csrc, Size: 690 bytes --]

#include <stdlib.h>
#include <pthread.h>
#include <libguile.h>

static void *eval_string(void *str)
{
	SCM module = scm_c_resolve_module("guile-user");
	(void)scm_c_eval_string_in_module(str, module);
	return NULL;
}

static void *do_call_f(void *name)
{
	SCM module = scm_c_resolve_module("test");
	SCM proc_var = scm_c_module_lookup(module, name);
	SCM proc = scm_variable_ref(proc_var);
	(void)scm_call_0(proc);
	return NULL;
}

void *thread(void *arg)
{
	(void)arg;
	scm_with_guile(do_call_f, "f");
	return NULL;
}

int main(void)
{
	pthread_t pt;

	scm_with_guile(eval_string, "(load \"scheme.scm\")");
	pthread_create(&pt, NULL, thread, NULL);
	pthread_join(pt, NULL);
	
	return 0;
}

Re: bug#10093: Problem compiling related to block-growth-factor fluid

[Andy Wingo]

On Mon 21 Nov 2011 14:35, rixed@happyleptic.org writes:

> Here is a minimal example reproducing the problem.
> Note that it only fails the first time (when scheme.scm is compiled).

Fixed in stable-2.0.  Thanks for the report!

Andy
-- 
http://wingolog.org/

Re: bug#10093: Problem compiling related to block-growth-factor fluid

[Ludovic Courtès]

Hello!

Andy Wingo <wingo@pobox.com> skribis:

> On Mon 21 Nov 2011 14:35, rixed@happyleptic.org writes:
>
>> Here is a minimal example reproducing the problem.
>> Note that it only fails the first time (when scheme.scm is compiled).
>
> Fixed in stable-2.0.  Thanks for the report!

So what was the deal?  One thread would see an uninitialized fluid,
right?

Thanks,
Ludo’.

Re: bug#10093: Problem compiling related to block-growth-factor fluid

[Andy Wingo]

Hi :)

On Wed 23 Nov 2011 15:06, ludo@gnu.org (Ludovic Courtès) writes:

> So what was the deal?  One thread would see an uninitialized fluid,
> right?

Yes, because threads that are not created by Guile do not share the
dynamic state with the threads that made (and set) the fluids, so they
get #f as the fluid value.

I fixed this by making it possible to create a fluid whose default
value, in all dynamic states, is something other than #f.

Regards,

Andy
-- 
http://wingolog.org/

Re: bug#10093: Problem compiling related to block-growth-factor fluid

[Ludovic Courtès]

Hi!

Andy Wingo <wingo@pobox.com> skribis:

> Yes, because threads that are not created by Guile do not share the
> dynamic state with the threads that made (and set) the fluids, so they
> get #f as the fluid value.

Oh, I see.

> I fixed this by making it possible to create a fluid whose default
> value, in all dynamic states, is something other than #f.

Yes, that’s a nice improvement!

Thanks,
Ludo’.