IRC channel logs


back to list of logs

<iskarian>Hey all :) what is the difference between (a b) and (a . b)?
<iskarian>Most everything seems to treat the two as equivalent, but sometimes they aren't
<flatwhatson>iskarian: (cdr '(a b)) is (b) ;; (cdr '(a . b)) is b
<flatwhatson>you could also write (a b) as (a . (b))
<iskarian>Oh, thanks! That's more clearly stated than I've read, and I've been through a fair bit of the guile manual by now :) Would a pair typically be (a b) or (a . b)?
<iskarian>An alist seems to use (a . b) so I would think a pair is the same...
<flatwhatson>you can use either, but (a . b) uses less cons cells!
<iskarian>is there a way to compare (with equal? or match) that doesn't care about the difference?
<flatwhatson>the difference between (b) and b?
<iskarian>Yes, without flattening b if it's also a list
<iskarian>though I suppose when you put it like that I can see why it would be difficult :)
<flatwhatson>trying to support either structure transparently is a bit messy
<flatwhatson>i'd recommend using (a . b), where b might be a list
<flatwhatson>if you are using match to destructure your pairs, it's easy enough to destructure a single-element list and treat it the same as a lone atom
<iskarian>Yes, that sounds good. As you suggest, in practice it's not really an issue, as you should know what structure you're receiving
<iskarian>thanks for the help :)
<flatwhatson>happy to!
<rlb>iskarian: Anything "dotted" isn't a "proper list", i.e. won't satisfy proper-list?. If what you're doing is fundamentally list related, then you'll likely want a proper list, i.e. one terminated by the empty list as in (cons 1 (cons 2 (cons 3 '()))), but "dotted pairs" are idiomatic for alist key value pairs. And (cons 1 2) is also one of the less expensive things most lisps, including I think guile, can do.
<rlb>iskarian: But dotted lists are also very common syntax for expressing variable length argument lists, etc. e.g. (define (foo x y . others) (list x y others))
<rlb>s/very common/very common as/
<iskarian>rlb, that syntax was part of what made it confusing, though after the explanation I can see how it makes sense :)
<apteryx>daviid: it's this procedure at the bottom of the (guix utils) module:
<apteryx>if you have guix, it'll be exercised following 'guix package --list-installed' or 'guix package --list-available'
<apteryx>dsmith-work: Guix (it's some new code to align the columns of the tabularized 'guix package -A/-I' output)
<apteryx>rlb: yeah, improving format seems the way to go, although after enabling output buffering it brought it closer to Python performances. So Guile was about 5 s, Python 3 s, and the 'column -t' command about 2 s to format the 18000 something rows table.
<apteryx>(that's the current count of packages in Guix :-))
<rlb>Oh, well yeah, I'd expect it might well be terrible if you're not buffering output to some reasonable extent (i.e. dominated by syscall overhead or similar).
<rlb>apteryx: Might not matter, but I'd also suggest maybe testing a larger setvbuf buffer size, say 4096, 8192, or 16384. I think the default's 1024?
<rlb>wingo: was looking at bugs and I thought maybe that whole @deffn might be vestigial now? i.e. the @deffn including program-bindings to binding:end.
<rlb>Happy to handle that, but just wanted to make sure it was plausible.
<iskarian>is it possible (or advised) to fold with keyword arguments?
<leoprikler>wdym fold with keyword arguments?
<tohoyn>could somebody look at the error message I got when compiling a guile program with guild:
<tohoyn>I use guile 3.0.7 (pulled recently)
***sneek_ is now known as sneek
<dsmith-work>Happy Friday, Guilers!!
<dsmith-work>sneek: botsnack
***apteryx_ is now known as apteryx
<sneek>I've been running for 9 days
<sneek>This system has been up 2 weeks, 1 day, 2 hours, 42 minutes
<tohoyn>when I raise an exception of user-defined type theme-d-condition (a numerical overflow) it gets transformed in the following compound expression:
<tohoyn>what is happening
<tohoyn>I think I found the error
***bandali_ is now known as bandali
***lfam is now known as dstolfa1
***dstolfa1 is now known as lfam
<zap>hey guilers! Looks like broke my config or something... When I set GUILE_LOAD_* variables they have top priority for %load-path right?
<zap>I'm in a werid situation when (getenv "GUILE_LOAD_PATH") one thing but %load-path other, and I dont run any script that might fiddle with %load-path -- just invoke guile binary
<zap>* shows one thing but %load-path the other
<leoprikler>%load-path also has Guile internals, so GUILE_LOAD_PATH should be a subset of it
<zap>leoprikler: ah yes. But Im interested in presedence GUILE_LOAD_PATH should be in front?
<leoprikler>doing a quick check GUILE_LOAD_PATH should be first
<zap>This is so weird
<dsmith-work>$ GUILE_LOAD_PATH=/FOO guile -c '(display %load-path)';echo
<dsmith-work>(/FOO /usr/local/share/guile/3.0 /usr/local/share/guile/site/3.0 /usr/local/share/guile/site /usr/local/share/guile)
<dsmith-work>Looks anything like that?
<dsmith-work>That's a no-extra-argument ./configure
<zap>dsmith-work: ha! yes and no; it work with guile but doesnt work with guile from guix source tree seems like guix doing something tricky
<ss2>hello! Can I ask anything related to geiser here?
<dsmith-work>ss2: You can, but there *is* a #geiser channel.
<ss2>it is very small, and am hoping to find more geiser users here.
<dsmith-work>ss2: As usual in IRC, it's better to ask than to ask to ask.
<ss2>okay, then: I've run into an issue, that when I copy text from the REPL, Emacs will go in to a read-only state:
<ss2>It'd be good to know if this can be confirmed.
<dsmith-work>I've never seen that.
<dsmith-work>But I'm using 26.1 emacs.
<dsmith-work>And geiser-guile 20210508.1838
<ss2>That is from melpa, I assume?
<dsmith-work>And Guile 3.0.7
<ss2>haven't thought about this yet. Will fetch an older Emacs and see how it is from there.
<dsmith-work>ss2: Did you try C-x C-q ?
<dsmith-work>Which is also M-x read-only-mode
<ss2>yes, but all buffers are read-only, making it basically unresponsive.
<dsmith-work>That has got to be very frustrating
<ss2>This only happens when I select text in the REPL, otherwise it everything is fine.
<dsmith-work>Hmm. What happens if select something in a different application?
<ss2>okay, installing Emacs in Debian, and pulling the rest over melpa doesn't show this problem.
<ss2>nothing, that works as usual.
<dsmith-work>So an emacs 27 thing.
<dsmith-work>Does that emacs do that Weyland stuff? Or is it X11 ?
<dsmith-work>Very odd. I'd ask in #emacs
<ss2>oh, but this doesn't happen when I'm in a terminal!
<dsmith-work>Right, becuse the termial is doing the selection
<dsmith-work>And by "selection" I've been assuming you mean swiping with the mouse.
<ss2>what? no! :D
<ss2>I don't need a mouse in Emacs.
<dsmith-work>How are you making a selection.
<ss2>shift, arrow?
<ss2>hang on, gonna do the classic way with Mark set.
<dsmith-work>I usualy set the mark, move somewere, and then M-w
<dsmith-work>That loads the kill buffer/whatever it's called.
<dsmith-work>Ask in #emacs !
<ss2>will do! Thanks for helping still.
<dsmith-work>I've got my exterm wired up backwards to use the cut-buffer instead of the selection. Makes copy-paste to/from windows easier. (gotta run Debian in a VM)
<ss2>and after all those years I finally taught urxvt to select and copy text with a keyboard. I do have some old habbits on me. So there's the part where I'd still select and copy with a mouse.
<leoprikler>zap: Guix source guile has to ensure you find the local packages, so…
<zap>leoprikler: in my case it does the opposite :)
<leoprikler>I think Guix source Guile adds its own stuff on top of whatever you have specified as GUILE_LOAD_PATH
<leoprikler>whereas usually it'd be GUILE_LOAD_PATH expanded on top of %load-path
<leoprikler>I think that's mostly a potato potato thing, but okay