IRC channel logs


back to list of logs

<mark_weaver>paroneayea: ?
<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>I have it paired down a bit to show:
<paroneayea> result in interpreter
<paroneayea> result in the command line
<paroneayea>curiously, if I use geiser-eval-region, it works fine
<paroneayea>but if I use
<paroneayea>and run (main '("foo" "-h")) as above
<paroneayea>it borks out
<paroneayea>same way as via command line
<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.
<paroneayea>mark_weaver: gotcha :)
<mark_weaver>(it's defined by the 'define-record-type' form)
<paroneayea>The More You Know
<paroneayea>that works!
<paroneayea>thanks mark_weaver
<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
<paroneayea>why is that?
<paroneayea>it seems like it could just be a function...
<mark_weaver>it's an efficiency hack, basically
<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.
<mark_weaver>yes, exactly.
<paroneayea>gotcha, okay
<paroneayea>thanks for your clear explainations, mark_weaver !
<paroneayea>very helpful
<mark_weaver>glad to help!
<mark_weaver>actually, I'm looking into detecting this exact kind of mistake, to issue warnings.
<paroneayea>mark_weaver: very cool
<paroneayea>how are you going to do that, out of curiosity?
<paroneayea>some kind of static code analysis?
<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
<paroneayea>hm, I did that...
<mark_weaver>'load' is not sufficient, because it doesn't take effect until run-time.
<mark_weaver>and you exported the macro?
<paroneayea> and imported to
<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?
<mark_weaver>oh, nevermind, I see it's a fresh session. hmm.
<paroneayea>ohhhh, I think I see what happened
<paroneayea>wait, hm, no
<paroneayea>well I also did a make distclean and I noticed that cli.scm fails to compile :)
<paroneayea>so that's probably relevant
<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> indicates that cli.scm was freshly compiled, but maybe test-scripting.scm itself needs to be recompiled.
<paroneayea>fixed the compilation issue, same error
<paroneayea>and recompiled everything.
<mark_weaver>did you recompile test-scripting.scm ?
<paroneayea>well, there's no .go file anyway :)
<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>delete the file and try again please
<paroneayea>.scm.go, but yes
<paroneayea>that worked!
<paroneayea>tricky tricky :)
<paroneayea>mark_weaver: thanks for all your help :)
<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.
*paroneayea nods
<paroneayea>this is great, thanks mark_weaver !
<mark_weaver>you're welcome!
*mark_weaver goes afk for a bit
<rlb>btw, anyone who wants to browse:;archive=0;src=guile-2.0;dist=unstable;repeatmerged=0
<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.
<mark_weaver>734323 is fixed in stable-2.0
<mark_weaver>734157 and 734108 are notabug IMO
<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/ 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>437158 is also notabug
<mark_weaver>rlb: when building from source using a simple ./configure, @CPP@ ends up being just "gcc -E". same on GNU Guix.
<mark_weaver>so I guess it's somehow debian-specific.
*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'.
<mark_weaver>he filed all these bugs in our bug tracker as well.
<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.
<mark_weaver>what's the status of 742834? (missing on armhf)
<rlb>m68k is fine now too
<rlb>(we're good)
<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
<rlb>but guile-2.0 beats guile-1.8 now:
<rlb>so that's something
<rlb>and for the ports:
<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>it's not
<mark_weaver>not 150 minutes anyway
<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.
<mark_weaver>so that might be a bona-fide bug
<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 ;>
<rlb>ahh -- we do:
<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>I wouldn't be surprised if an earlier gcc works.
<rlb>(used multiarch)
<mark_weaver>ooh, nice!
<mark_weaver>this server of mine has been using debian since potato or hamm or something ancient.
<mark_weaver>(although it wasn't sparc at that time)
<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 forgest
<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>okay, good to know.
<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.
<mark_weaver>a very old box, but my needs are modest.
<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>(in this case)
<rlb>~ $130 + ram/drive?
<rlb>that one:
<rlb>though only 8g max, so limited on that front
<mark_weaver>looks like a celeron, not atom
<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
<mark_weaver>I might try this: since it's supported by coreboot
<mark_weaver>and maybe libreboot soon.
<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.
<mark_weaver>oh yes, I always use software raid.
<mark_weaver>but I need two fast drive interfaces
<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>This looked plausible if you don't need a lot of drives or a 5":
<rlb>it's small
<mark_weaver>yeah, looks okay to me
<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.
<mark_weaver>hmm, though I want two drives. oops.
*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.
<mark_weaver>or some free BIOS, anyway.
<rlb>yeah, I haven't gotten that far yet
<mark_weaver>(I consider the Novena to qualify here)
<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.
<mark_weaver>the video for that talk is here:
*rlb wonders how the parallela systems will end up...
<rlb>(don't know much about them yet)
<mark_weaver>looks interesting!
<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: looks like 649718 is resolved, no?
<mark_weaver>rlb: 734311 may be fixed upstream in commit 4a81f5b5d3800aafbc25452e50459c1ba6e29fea
<mark_weaver>(but I'm not sure)
<civodul>Hello Guilers!
<artyom-poptsov>Hi civodul
<janneke>Hi civodul!
***micro is now known as Guest62964
***mario-go` is now known as mario-goulart
***Guest62964 is now known as micro
<dsmith-work>Morning Greetings, Guilers
<davexunit>hello dsmith-work
<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>rlb: ^^
<rlb>mark_weaver: if you're up for it -- feel free to just mark them forwarded yourself: (but don't feel obliged)
<mark_weaver>okay, thanks
<rlb>you can also handle multiple ones at once via
<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
<mark_weaver>heh :)
<rlb>guild list prints help
<rlb>"Usage: guild ..."
<mark_weaver>does it list commands, like "compile", "disassemble", etc?
<mark_weaver>okay, what about "guild help frisk" ?
<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...
<mark_weaver>both 734313 and 734314
<rlb>mark_weaver: closed -- thanks for the help