On Tuesday 14 May 2013 08:15:45 William S Fulton wrote:

> Thanks for doing the class example. Re the port example, I'd be tempted

> to delete it except it tests some typemaps shipped with SWIG, sigh. I'm

> not sure what to do, I'll try and debug it myself. Do you know where it

> abouts it goes wrong? Which line of the Guile code or inside the FILE *

> typemap?

>

> William

 

When running the ports example in a guile 2 context, you will see this output:

314159

(wrong-type-arg "$name" "Wrong type argument in position ~A: ~S" (1 #<output: string 90071e0>) (#<output: string 90071e0>))

read_int: error reading from file

read_int: Success

1075290112

 

On 1.8 you will get this:

314159

(wrong-type-arg "$name" "Wrong type argument in position ~A: ~S" (1 #<output: string 8f3a5d0>) (#<output: string 8f3a5d0>))

4711

 

The wrong-type-arg error is expected. It is an illustration in the example of what doesn't work.

 

The difference is in the read_int error.

 

The runme script first writes a number to stdout (314159). Then it writes a number to a file called output.txt (4711). You don't see this in the output above, but it happens just before the wrong-type-arg illustration is run.

 

After the wrong-type-arg error, the runme script goes on to read the number that was written to output.txt and prints what it found. On 1.8 it correctly prints 4711 again, on 2.0 it gives an error and then a wrong number.

 

The error is generated when executing line 13 in example.c (fscanf ...). The function is called from port_wrap.c, line 1370, which is inside the wrapper code for the read_int function.

 

I did step through the wrapper function in gdb, both in guile 1.8 and 2.0 environments, but I couldn't find any difference in behaviour between the two. Yet one results in a read error eventually, the other doesn't.

 

That's all I have found so far. I hope you can spot the issue. Otherwise it will be something for a guile expert.

 

Geert