***cluck` is now known as cluck
<please_help>Suppose I have (in pseudo-form): (begin (define A (generate-array-of-int64)) (define B (apply make-typed-array 'f32 *unspecified* (array-dimensions A))) (array-copy! A B) B) <davexunit>if B held a reference to A, then A would never be GC'd until B was. <davexunit>the other question I can't really answer, because of my unfamiliarity with the array API. <lloda`>please_help: what davexunit says, but even if A was collected, B wouldn't be affected, because B is independent storage, it doesn't have any reference to A. <lloda`>as to well-defined, it should give the same result always if that's what you mean, but an 'f32 can't hold an arbitrary 's64 or 'u64 without loss of precision (if that's what the array-of-int64 is), so when you copy to B, B won't have the same values (numerically) that A did. <please_help>more specifically, I wanted to know if that was a bit-copy or if there was type conversion going on (including downcasting if necessary) <lloda`>there is type conversion if you use array-copy! <lloda`>or array-map! or any other function in that set <please_help>why do I get nan+(pi)i on (what look like) overflows, rather than just nan? <lloda`>please_help: when operating with complex numbers, you may get a nan independently on the real or imag part <lloda`>it's a pain that nan? doesn't work on complex numbers though <lloda`>but you can easily define it so that it does <lloda`>there are other ways to get complex from real <lloda`>say acos(2), just off the top of my head <please_help>it's only matrix mults/adds/subs/scales, and the matrices aren't toeplitz <lloda`>there can always be a bug, but you'll have to look closer *wingo grumbles at srfi-41 not being documented in the manual <mark_weaver>wingo: huh? SRFI-41 is fully documented in our manual <wingo>mark_weaver: is it! i didn't see it in the srfi index <wingo>somehow i ended up opening the wrong .info file <wingo>too many versions of guile on this machine! <wingo>i have a patch to expose the frame filter interface to scheme in gdb <please_help>how can I get the amount of milliseconds since the program started (or since an arbitrary point during execution)? <taylanub>please_help: section 7.2.5 Time of the manual should help <taylanub>oh, "whether true microsecond resolution is available depends on the operating system" ... <wingo>get-internal-run-time or get-internal-real-time <wingo>get-internal-real-time uses the highest-precision clock available to guile <wingo>tough to know :) even when the api offers nanoseconds you don't always have a nanosecond timer <wingo>but see internal-time-units-per-second, and again, the manual :) <paroneayea>ArneBab: while waking up from sleep I had a thought about wisp <paroneayea>ArneBab: if it were pretty easy to figure out where the parens belong in wisp, it might be neat in an emacs wisp-mode to have a keystroke that toggles in some display of where the parens *would* be <please_help>I have something weird happening: I have some_file.scm and run guile -l some_file.scm. It's compiled and all is well. I then modify this file and run again. The file is compiled, but the old version is used! <please_help>in fact, how does the old version persist in existing? <please_help>if I remove the cache and let it compile again, it works <paroneayea>please_help: it gets compiled somewhere else too... let me see <daviid>wingo: I'm trying to compile g-wrap against 2.2 [which is here: /opt2] and ... export PATH=/opt2/bin:$PATH; export ACLOCAL_FLAGS="-I /opt2/share/aclocal"; ./autogen.sh --prefix=/opt2 PKG_CONFIG_PATH=/opt2/lib/pkgconfig LD_LIBRARY_PATH=/opt2/lib -> + passing --prefix=/opt2 to configure \\ - ignoring unknown autogen.sh argument PKG_CONFIG_PATH=/opt2/lib/pkgconfig \\ - ignoring unknown autogen.sh argument LD_LIBRARY_PATH=/opt2/lib <daviid>of course it finds guile 2.0 instead, which is not good :) I wonder what would be the best here, updating autogen-support.sh for these 2 argts or something else? <joolean>has anyone built Guile on Ubuntu recently? I'm getting a funny error that I suspect is my fault, not Guile's, but I'm not sure what to do about it. <joolean>It manifests as a bunch of incompatibilities between snarfed files and headers. <joolean>In file included from alist.c:377:0: <joolean>../libguile/alist.x: In function 'scm_init_alist': <joolean>../libguile/alist.x:2:5628: error: conflicting types for 'scm_array_get_handle' <daviid>wingo: wrt g-wrap autogen/configure, i wonder if the best would not be: (a) copy autogen.sh from guile-clutter [which 'just' runs 'autoreconf -vif' and (b) adapt g-wrap's configure.ac, wdyt? <mark_weaver>joolean: we've been having issues with guile-snarf. just before the 2.0.10/11 releases, we learned that our guile-snarf didn't work with clang's preprocessor, so I fixed that problem. then we learned that it somehow broke the compile on windows, and I haven't had a chance to investigate further. <mark_weaver>but of course lots of people compile guile on debian/ubuntu, and 2.0.11 is in debian jessie, so I'd be surprised if somehow we failed to build there. <joolean>Tentatively, it looks like doing a massive purge of everything may have worked. <mark_weaver>please_help: one issue that might be biting you is this: if you modify a macro, we have no mechanism to automatically recompile modules that used that macro. <mark_weaver>to make an analogy with C: it's as if, after changing a .h file, the .c that include that .h weren't recompiled automatically. <please_help>so when I remove the previous version of the module that contains the macro, the other files get "linked" to the fresh version, updating their defs? <mark_weaver>please_help: it's not a matter of linking. it's analogous to C preprocessor macros. the macros are expanded when the other modules are compiled. <mark_weaver>a .o file from a .c file that included a .h file doesn't "link" to the old .h file. it just made use of the .h file during compilation, and the macros essentially get incorporated into the .o file, as you probably know. with guile it is similar. <mark_weaver>macros are expanded as the first pass of compilation. <mark_weaver>please_help: so, to be clear: if macros.scm contains a macro that is used by user.scm, then if you change a macro in macros.scm, you need to recompile both user.go and macros.go <mark_weaver>daviid: it's the -Werror that's turning those warnings into errors. <daviid>mark_weaver: i forgot what it should be and where it is 'declared' <mark_weaver>daviid: do you see how it says "[-Werror=deprecated-declarations]" ? <mark_weaver>that means that you can disable errors on those particular warnings by adding -Wno-error=deprecated-declarations to CFLAGS <daviid>ok, where is CFLAGS defined [usually, because g-wrap has its own autogen.sh code, that should evolve but... 1 thing at a time :)] <mark_weaver>daviid: just pass CFLAGS=-Wno-error=deprecated-declarations to configure <mark_weaver>daviid: well, you can always rerun configure again manually after running autogen <mark_weaver>or you could pass CONFIGURE_EXT_OPT as an environment variable to autogen, like this: CONFIGURE_EXT_OPT=CFLAGS=-Wno-error=deprecated-declarations ./autogen.sh <daviid>yes, that's what i did now, but if i was a good guy, i'd study autotool and rewrite the g-wrap ... <mark_weaver>and fyi, the place where -Werror is added to CFLAGS by default is in configure.ac <mark_weaver>you could change that to CFLAGS="$CFLAGS -Werror -Wno-error=deprecated-declarations" <mark_weaver>although really g-wrap should obviously be updated to avoid these deprecated interfaces, of course. <daviid>of course! but the all autotool files should be updated as well <daviid>anyway many thanks, right now i'd like to check guile-gnome and guile-clutrter against guile-2.2 as you understoiod :) <daviid>i wish i'd be a good autool guy :) <mark_weaver>although those deprecated interfaces have been completely removed in 2.2, so I'm not sure how you can avoid fixing g-wrap properly if you want to use 2.2 <mark_weaver>if it's working at all, maybe you are compiling against the wrong header files. <daviid>are there removed in 2.1 as well then ? [sorry if it sounds stupid, but i dont know, could last chance to get rid of deprecated...] <mark_weaver>I see that these are warnings for things deprecated in 2.2. <mark_weaver>it's reasonably clear from the warnings/errors that you are using 2.2 headers. <daviid>ok, but now that i add the flag i got another error <daviid>mark_weaver: i complied guile with the "-2.2" --program-tranformation [or whatever it'1s called], i though about "-2.1" but finally decided "-2.2" <mark_weaver>daviid: sure, seems reasonable. we're testing how things would work if current master were 2.2 <mark_weaver>just as long as we all remember that it's not 2.2 yet <daviid>now i get this error, it seems g-wrap calls 'guile' [and not the 'guile script/command' configure found which in my case is guile-2.2 <mark_weaver>daviid: guile/g-wrap/gw/Makefile.am assumes that the command is called 'guile'. it should probably be made into a variable reference, with a way to set it from configure or something. <daviid>mark_weaver: i changed the g-wrap 'looking for guile' based on how guile-clutter... here is configure.ac extract: http://paste.lisp.org/+34H2/2 so i guess I can now refer to $GUILE_EFFECTIVE_VERSION in this Makefile.am ? <daviid>mark_weaver: it worked, g-wrap compiled fine, but make check fails for 4 tests. in the mean time here is the updated Makefile.am, comments welcome: http://paste.lisp.org/+34H2/3 <mark_weaver>well, you're assuming that guile was configured with --program-suffix=-$(GUILE_EFFECTIVE_VERSION) <daviid>ah of course, or guile or guile-x.x ... how is this weritten in a makefile? <mark_weaver>daviid: use the GUILE_PROGS autoconf macro (defined in guile.m4), which sets the GUILE variable. <mark_weaver>or at least that's my guess. I confess I'm quite weak at autotools myself. <daviid>i'm weaker :) so in Makefile.am i can use GUILE_PROGS [why is it with 's' at the end?] <mark_weaver>then leave Makefile.am as you had it, but remove the definition of GUILE at the top that you added. <mark_weaver>the configure script should, I suspect, arrange to set GUILE itself <mark_weaver>daviid: the reason it has 'S' at the end is because it also finds the names of the other programs GUILD, GUILE_CONFIG and GUILE_TOOLS <mark_weaver>although GUILE_TOOLS is the old name for GUILD, which supercedes GUILE_CONFIG :) <mark_weaver>but at least one of those other programs is still relevant :) (GUILD) <mark_weaver>sorry, I made a mistake there. it's pkg-config that supercedes guile-config <daviid>mark_weaver: wrt GUILE, here is what i did earlier, http://paste.lisp.org/+34H2/4 copying from guile-clutter: (a) I thought PKG_CHECK_MODULES(GUILE, guile-$v, [GUILE_EFFECTIVE_VERSION=$v], [true]) would define GUILER, but it does not [?] and (b) if i add 3 lines, with "GUILE_PKG([2.2 2.0])\\nGUILE_PROGS\\nGUILE_FLAGS" just before GUILE_EFFECTIVE_VERSION=no, then configure fails with hecking for guile... no, configure: error: guile <daviid>it actually says "configure: checking for guile 2.2, configure: found guile 2.2, hecking for guile... no, onfigure: error: guile required but not found" which is rather funny