2 Jul 2012 11:29
2 Jul 2012 11:33
bug#11048: Trunk fails guardians.test (commit 01e909d90a130f4987b70edae2dbd5a2b33edae7)
Ludovic Courtès <ludo <at> gnu.org>
2012-07-02 09:33:36 GMT
2012-07-02 09:33:36 GMT
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)
2 Jul 2012 11:38
bug#10974: guile-user <at> gnu.org
Ludovic Courtès <ludo <at> gnu.org>
2012-07-02 09:38:27 GMT
2012-07-02 09:38:27 GMT
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’.
2 Jul 2012 12:15
bug#10974: guile-user <at> gnu.org
Alexei Matveev <alexei.matveev <at> gmail.com>
2012-07-02 10:15:46 GMT
2012-07-02 10:15:46 GMT
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)
2 Jul 2012 15:11
2 Jul 2012 20:36
bug#11845: guile-1.8.8 segfaults at build-time with gcc-4.6.3 and -O3
Cyprien Nicolas <c.nicolas <at> gmail.com>
2012-07-02 18:36:39 GMT
2012-07-02 18:36:39 GMT
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-(Continue reading)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"
2 Jul 2012 21:17
bug#10974: guile-user <at> gnu.org
Ludovic Courtès <ludo <at> gnu.org>
2012-07-02 19:17:59 GMT
2012-07-02 19:17:59 GMT
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’.
2 Jul 2012 23:45
bug#10974: guile-user <at> gnu.org
Andy Wingo <wingo <at> pobox.com>
2012-07-02 21:45:43 GMT
2012-07-02 21:45:43 GMT
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/
3 Jul 2012 00:35
bug#10974: guile-user <at> gnu.org
Ludovic Courtès <ludo <at> gnu.org>
2012-07-02 22:35:29 GMT
2012-07-02 22:35:29 GMT
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’.
3 Jul 2012 01:17
bug#10974: guile-user <at> gnu.org
Andy Wingo <wingo <at> pobox.com>
2012-07-02 23:17:54 GMT
2012-07-02 23:17:54 GMT
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/
RSS Feed