<paroneayea>I'm hitting a bug that's happening only when I run the script from the command line <paroneayea>and not when I run it through the interpreter/geiser <paroneayea>curiously, if I use geiser-eval-region, it works fine <paroneayea>why would it be different for loading it as a file vs evaluating the reason <mark_weaver>paroneayea: subcommand-name ends up being a macro. you must define it before it is used. <mark_weaver>to be more precise, you must define macros before their uses are _expanded_. <paroneayea>I am a little bit surprised that (subcommand-name) is a macro rather than a function <mark_weaver>the record accessors are defined using 'define-inlinable' (well, a variant of it), and that works by defining a macro. <paroneayea>is it just to speed things up because records are used all over the place? <mark_weaver>some day we hope to have a cleaner solution for inlining top-level procedures. <paroneayea>thanks for your clear explainations, mark_weaver ! <mark_weaver>actually, I'm looking into detecting this exact kind of mistake, to issue warnings. <mark_weaver>my plan was to record in a table each time an identifier is looked up by the macro expander that is not yet defined, and thus assumed to later become a normal variable. then, whenever a macro is defined, look up the identifier in that table. <mark_weaver>when the macro expander sees (foo ...), if 'foo' is not yet defined, it assumes that it will later become a normal toplevel variable, so it makes that into a normal procedure call. <paroneayea>mark_weaver: is there anything similar I need to know when exporting those macros from the module? <mark_weaver>import the module using (use-modules ...) before using it. <mark_weaver>before using the macros exported by the module, that is <mark_weaver>'load' is not sufficient, because it doesn't take effect until run-time. <mark_weaver>one thought: use-modules is a no-op if the module has already been loaded, even if it's an old version. <mark_weaver>is this in the REPL, or running it with a fresh guile process? <paroneayea>well I also did a make distclean and I noticed that cli.scm fails to compile :) <paroneayea>because it fails to load one of the other modules, apparently <mark_weaver>one note: if module A uses a macro from module B, then you must manually recompile A when changing anything related to the macro in B. <mark_weaver>in other words, the auto-compilation logic does not look at the modification times of the *.scm files of imported modules. it only looks at the modification time of A.scm compared with A.go. <mark_weaver>so, if A.scm was compiled to A.go before B.scm exported the macro, then A.go will be compiled with the assumption that 'make-subcommand' is a normal procedure. <mark_weaver>but yeah, if cli.scm fails to compile, that can't be good. <paroneayea>I'm not sure that that's why, but it's something I should rule out <mark_weaver>when in doubt, try passing --fresh-auto-compile to guile <mark_weaver>it would be in /home/cwebber/.cache/guile/ccache/2.0-LE-8-2.0/home/cwebber/deploy/dustycloud/test_scripting.go <mark_weaver>yeah, sorry. it's like a .c file including a .h file and using a macro from it, but then failing to recompile the .c file when the .h file changes. *mark_weaver goes afk for a bit <rlb>I'm going to make an effort to get remaining upstream-relevant bugs forwarded soonish, but feel free to beat me to it... <mark_weaver>the bugs filed by zefram are also in our bug tracker. <rlb>mark_weaver: wrt the guile-snarf gcc invocation -- if you know offhand, how is that computed? <mark_weaver>734313 and 734314 look likely to be debian-specific, and worth looking into. <rlb>mark_weaver: (don't waste your time if you don't know -- I'll figure it out) <mark_weaver>rlb: guile-snarf is generated from libguile/guile-snarf.in and it's @CPP@ <mark_weaver>my autofoo is a bit weak, but autoconf is somehow coming up with that value of @CPP@ <rlb>mark_weaver: my /usr/bin/guile-snarf has no explicit -linux-gnu-... <mark_weaver>rlb: when building from source using a simple ./configure, @CPP@ ends up being just "gcc -E". same on GNU Guix. *rlb needs to investigate <rlb>i.e. my guile-snarf calls either CPP or "gcc -E", but if I invoke guile-snarf directly, who would be setting CPP? <rlb>maybe I/we fixed it? <rlb>i.e. the bug was 2.0.11+1-1, and I have -7 <mark_weaver>734178 is at best "wishlist", and arguably notabug and wontfix. He's complaining that the autocompile logic looks only at mtime, and might be confused by swapping in another file with an older mtime than the .go. You could make the same complaint about 'make'. <rlb>mark_weaver: yep -- I/we/someone fixed the CPP guile-snarf issue, so nevermind... <mark_weaver>I'm not sure 734009 warrants being 'important'. seems like wishlist to me, though I agree we should have it. <rlb>m68k is fine now too <rlb>(well, except for sparc) <rlb>And I suspect the sparc failure may be due to "not enough time allowed" <mark_weaver>interesting. I have my own sparc system running Debian (squeeze, I confess, need to upgrade), and I compiled guile-2.0.11 on it without problems. <rlb>mark_weaver: might be that gcc goes nuts now, but I'd guess that it's the .go compilation, i.e. psyntax, etc. that takes forever? <rlb>of course it might also just be stuck in INFLOOP <mark_weaver>hmm, 150 minutes of inactivity on the sparc build. sounds fishy indeed. <mark_weaver>and it wasn't during one of the early ones, but rather on compile-tree-il.go <rlb>I don't have a good idea if that's one of the slow ones... <mark_weaver>the first few files are *much* slower than any later ones, so if there was a timeout due to inactivity, it should have happened earlier. <rlb>right -- I'd be less wary if it was psyntax, etc. *rlb wonders if we have a sparc porter box... *rlb thinks mark_weaver should just upgrade ;> <mark_weaver>well, it's a pain because we're using uw-imapd, which is no longer in wheezy, and so first I have to migrate my users to dovecot, convert the mail files, yada yada. *rlb sympathizes -- dealing with a much less risky transition atm, himself <rlb>In the "chalk one up for debian" category, I was able to convert my oldest continually upgraded server from i386 to amd64 in-place without all that much fuss -- was kinda surprised it worked. <mark_weaver>this server of mine has been using debian since potato or hamm or something ancient. <rlb>that same machine (depending on how you feel about zeno's paradox) has been running fairly regularly upgraded debian since about 1996 I think? <rlb>it's certainly not the same hardware -- and after converting to amd64 a month or two ago, I finally added ram yesterday (to 12GB), which helped (with notmuch) tremendously. <mark_weaver>while debugging problems building guile using clang, just before the 2.0.11 release, I had bizarre problems where compile-tree-il.go was special in some way. I forget the details, but it was something along the lines that if that file was compiled before the others, it would work, and otherwise it would fail in a strange way. <rlb>(though still not enough -- currently switching to ssd, which should make me no longer care about the perf issues I've had -- *giant* Maildir) <rlb>mark_weaver: interesting <mark_weaver>I managed to get clang 3.4 working on x86_64 with guile 2.0.11 by hunting down cases of undefined behavior and fixing them. <mark_weaver>my gut feeling is that this is related to gcc 4.9 aggressively taking advantage of undefined behavior, similar to clang. <rlb>seems to be a lot of that going around these days <mark_weaver>you might try compiling guile on the sparc porter box with gcc-4.8. it would be interesting to see if it works, and if so, it could be an expedient workaround for now. <rlb>ok -- might try that <rlb>mark_weaver: sparc may be dropped from jessie iirc... <mark_weaver>keeping my server on a minority architecture has given me some comfort, worrying less about security issues, but it's probably time to move on. <mark_weaver>my sparc is pre-oracle, and I wouldn't want a post-oracle one. <rlb>mark_weaver: yeah, might buy an intel atom nuc for some fairly low-power work... <rlb>not very expensive, and good enough for what I need... <rlb>though only 8g max, so limited on that front <rlb>oh, right -- but I think it's similar(ish) <rlb>though probably faster <rlb>there are also i3/i5/i7 versions, but they're a lot spendier <rlb>I'd be perfectly happy with an arm equiv too, but most of the cheap small machines look likely to be a lot more hassle (and more non-free wrt firmware, etc.) <rlb>i.e. raspberry pi, etc. <mark_weaver>yeah, I've also been thinking of ARM, but I want RAID1 at the very least, and that rules out most of the reasonably-priced boards I'm aware of. <davexunit>mark_weaver: that board might be what we're using at the FSF. we have some serious stability issues we're working out of libreboot. <rlb>I'd just use software raid these days (at least with decent cpu), but I'm no expert. <rlb>mark_weaver: oh, right <mark_weaver>looks like Novena could be made to work with two drives, using an express PCI SATA card for the second drive, bt it's a bit pricey. <mark_weaver>davexunit: interesting, that's good to know. I hope they get the problems fixed. <rlb>mark_weaver: possibly difficult to get around a mini-itx case, and cheap intel (or other) board with a celeron/i3... <davexunit>mark_weaver: me too. our computers crash way too often. we also use diskless clients which may complicate things further. *rlb goes for simple/solid more often these days -- used to be more adventurous... <mark_weaver>my X60 has been quite stable, at least until it overheats (which is often a problem, but it's probably just that the fan isn't moving enough air) <rlb>fairly inexpensive too I think? <mark_weaver>sounds crazy, but I've even considered just running my server on a Libreboot X60, since I know it works well. *rlb just resurrected a t41p <rlb>(had been off for about 6 years?) <mark_weaver>more than anything, I'm constrained by my desire to avoid ME/AMT and run Libreboot if at all possible. <rlb>yeah, I haven't gotten that far yet <rlb>but I'd be happy about it <mark_weaver>I've been a long time getting there myself, but now that I'm running free BIOSes on my personal machines (YeeLoong and X60), I don't want to backslide. <mark_weaver>mtjm on #parabola, who seems quite knowledgable, says "I know only that no Intel CPU since at most Nehalem works without several megabytes of nonfree software (ME firmware) used also for AMT". <mark_weaver>and Peter Stuge, in a recent talk (at 30C3 iirc), spoke of a notable difference he found between the 945 and later chipsets: the 945 when running coreboot without the ME/AMT firmware seems to leave ME/AMT non-functional, but that with a 965, even without the ME/AMT firmware, he observes an IPv6 packet going out the ethernet port at boot time. *rlb wonders how the parallela systems will end up... <rlb>(don't know much about them yet) <rlb>guile clojure dialect, 64-cores, ... <pallagun>newbie guile scheme question: how do you organize your logical groups of code? Does something similar to a c++ namespace exist? Or do you just have verbose names for things? <mark_weaver>pallagun: we use modules. each module has its own namespace. <pallagun>mark_weaver: It dawns on me that I've used modules and yet I never thought to try and make one. Excellent, I'll poke around in that direction <mark_weaver>modules can import other modules, and can optionally add prefixes to the imported names, though we don't use that feature often. <mark_weaver>rlb: 734311 may be fixed upstream in commit 4a81f5b5d3800aafbc25452e50459c1ba6e29fea ***micro is now known as Guest62964
***mario-go` is now known as mario-goulart
***Guest62964 is now known as micro
<Ulrar>I get : ERROR: Throw to key `encoding-error' with args `("scm_to_stringn" "cannot convert wide string to output locale" 84 #f #f) <Ulrar>Could that mean that my string isn't actually utf8 ? <Ulrar>nvm, figured it out, needed to setlocale LC_ALL éé <rlb>mark_weaver: wrt 649718 likely, though I figured I'd wait a bit for the "more later". <mark_weaver>regarding all of those reports from Zefram that are also in our bug tracker (and I've replied to some of them), do you want to mark them as forwarded to us? I could compile a list of the ones we have, and the bug number mappings. <mark_weaver>right, I forgot about the fact that I can send control messages to Debian's own bug tracker. duh :) <mark_weaver>rlb: I am curious about bugs 734313 and 734314 though. does "guild list" show any commands on your system? does "guild help frisk" result in a backtrace? I've been nuable to reproduce these problems. <rlb>looks like guild list crashes here atm <rlb>nevermind -- can't type yet today <rlb>guild list prints help <mark_weaver>does it list commands, like "compile", "disassemble", etc? <rlb>talks about making things friskier <rlb>mark_weaver: seems fine <rlb>mark_weaver: suspect maybe we've fixed it since 2.0.9+1-1 <mark_weaver>okay, so maybe the problem has been fixed since he reported it. good :) <rlb>I should mark that closed... <rlb>mark_weaver: closed -- thanks for the help