Ludovic Courtès | 2 Jul 11:29 2012
Picon

bug#11500: GC_PTR redeclaration when building against libgc 7.2

Hi,

Fixed in commit e862ae1cebe006f0bac967c016f259c13d314387, which will be
in 2.0.6.  Thanks!

Ludo’.

Ludovic Courtès | 2 Jul 11:33 2012
Picon

bug#11048: Trunk fails guardians.test (commit 01e909d90a130f4987b70edae2dbd5a2b33edae7)

Hi,

Sorry for the very late reply.

adamsonj <at> ninthfloor.org (Joel J. Adamson) skribis:

> Compiling from git, I got this after 'make -k check' (full output follows):
>
> Running guardians.test
> /bin/sh: line 5: 20304 Segmentation fault      CHARSETALIASDIR="/home/joel/Public/src/guile/lib" ${dir}$tst
> FAIL: check-guile
> ==================================
> 1 of 1 test failed
> Please report to bug-guile <at> gnu.org
> ==================================
> make[3]: *** [check-TESTS] Error 1
>
> git log shows:
>
>    commit 01e909d90a130f4987b70edae2dbd5a2b33edae7

Can you check whether this still happens?  Apparently, this was with
‘master’, right?

Note that the stable development branch is ‘stable-2.0’.

Thanks,
Ludo’.

(Continue reading)

Ludovic Courtès | 2 Jul 11:38 2012
Picon

bug#10974: guile-user <at> gnu.org

Hi,

Sorry for the late reply.

Alexei Matveev <alexei.matveev <at> gmail.com> skribis:

> For use from a Fortran program I am collecting API fixes for libguile.so
> as wrapper functions for what is provided to C-programs as macros.
> I noted that some of the macros are function-macros some are symbol
> macros. An example of the latter is
>
>   #define scm_to_int scm_to_int23

The macros in numbers.h that are “symbol macros”, such as
‘scm_from_int’, allow users to write code like:

  &scm_from_int

This wouldn’t be possible if these were function macros.

Thus, I think things will have to remain this way.

What do you think?

Thanks,
Ludo’.

Alexei Matveev | 2 Jul 12:15 2012
Picon

bug#10974: guile-user <at> gnu.org

On Mon, Jul 2, 2012 at 11:38 AM, Ludovic Courtès <ludo <at> gnu.org> wrote:
>
>> For use from a Fortran program I am collecting API fixes for libguile.so
>> as wrapper functions for what is provided to C-programs as macros.
>> I noted that some of the macros are function-macros some are symbol
>> macros. An example of the latter is
>>
>>   #define scm_to_int scm_to_int23
>
> The macros in numbers.h that are “symbol macros”, such as
> ‘scm_from_int’, allow users to write code like:
>
>   &scm_from_int
>
> This wouldn’t be possible if these were function macros.
>
> Thus, I think things will have to remain this way.

Hi,

It's ok. You may close it.

I still think it could be less confusing if the libguile.so implemented/provided
functions as advertised in Guile API docs for the sake of interfacing to
languages other than C. And &scm_from_int wold also work if it were a real
function.

But there are many more macros, so such a link-time interface would be a
lot of work, I realize by now.

(Continue reading)

Ludovic Courtès | 2 Jul 15:11 2012
Picon

bug#10938: patch

Hi Stefan,

Thanks, fixed differently in a8215aedad433a15abf87c2310a41c684dfcef97.

In the future, could you please provide a patch with a log and test case
similar to what’s in the above commit?

Ludo’.

Cyprien Nicolas | 2 Jul 20:36 2012
Picon

bug#11845: guile-1.8.8 segfaults at build-time with gcc-4.6.3 and -O3

Hello guilers,

Origin: https://bugs.gentoo.org/show_bug.cgi?id=424475

- CONFIGURATION -
-----------------

# emerge --info --ignore-default-opts
Portage 2.2.0_alpha113 (default/linux/x86/10.0/desktop, gcc-4.6.3,
glibc-2.15-r2, 3.2.1-gentoo-r2 x86_64)
=================================================================
System uname:
Linux-3.2.1-gentoo-r2-x86_64-Intel-R-_Xeon-R-_CPU_5120_ <at> _1.86GHz-with-gentoo-2.1
app-shells/bash:          4.2_p29
dev-util/pkgconfig:       0.26
sys-apps/baselayout:      2.1-r1
sys-apps/openrc:          0.10.3
sys-apps/sandbox:         2.5
sys-devel/autoconf:       2.13, 2.69
sys-devel/automake:       1.11.5, 1.12.1
sys-devel/binutils:       2.22-r1
sys-devel/gcc:            4.5.3-r2, 4.6.3, 4.7.1
sys-devel/gcc-config:     1.7.3
sys-devel/libtool:        2.4.2
sys-devel/make:           3.82-r3
sys-kernel/linux-headers: 3.4 (virtual/os-headers)
sys-libs/glibc:           2.15-r2

CFLAGS="-O2 -march=i686 -pipe -finline-functions -ggdb"

(Continue reading)

Ludovic Courtès | 2 Jul 21:17 2012
Picon

bug#10974: guile-user <at> gnu.org

Hi,

Alexei Matveev <alexei.matveev <at> gmail.com> skribis:

> It's ok. You may close it.

Thanks.

> I still think it could be less confusing if the libguile.so implemented/provided
> functions as advertised in Guile API docs for the sake of interfacing to
> languages other than C. And &scm_from_int wold also work if it were a real
> function.
>
> But there are many more macros, so such a link-time interface would be a
> lot of work, I realize by now.

Yeah.  Though here, you could still write bindings for ‘scm_from_int32’
(the real function) instead of ‘scm_from_int’, for instance, no?

Thanks,
Ludo’.

Andy Wingo | 2 Jul 23:45 2012
Picon

bug#10974: guile-user <at> gnu.org

On Mon 02 Jul 2012 11:38, ludo <at> gnu.org (Ludovic Courtès) writes:

> The macros in numbers.h that are “symbol macros”, such as
> ‘scm_from_int’, allow users to write code like:
>
>   &scm_from_int
>
> This wouldn’t be possible if these were function macros.

Interesting, I hadn't thought of that.

> Thus, I think things will have to remain this way.

Would this be "fixed" if we changed these to be implemented as inline
functions?

Dunno, just thinking out loud.

Andy
--

-- 
http://wingolog.org/

Ludovic Courtès | 3 Jul 00:35 2012
Picon

bug#10974: guile-user <at> gnu.org

Hi,

Andy Wingo <wingo <at> pobox.com> skribis:

> Would this be "fixed" if we changed these to be implemented as inline
> functions?

In some way, though their address could still not be taken.

Thanks,
Ludo’.

Andy Wingo | 3 Jul 01:17 2012
Picon

bug#10974: guile-user <at> gnu.org

On Tue 03 Jul 2012 00:35, ludo <at> gnu.org (Ludovic Courtès) writes:

> Andy Wingo <wingo <at> pobox.com> skribis:
>
>> Would this be "fixed" if we changed these to be implemented as inline
>> functions?
>
> In some way, though their address could still not be taken.

Sorry to be obtuse, but with our inline functions, we also residualize a
concrete instantiation (via the inline.c madness).  Does that not work?

A
--

-- 
http://wingolog.org/


Gmane