<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 <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? <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 <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>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>Happy to handle that, but just wanted to make sure it was plausible. <iskarian>is it possible (or advised) to fold with keyword arguments? <tohoyn>I use guile 3.0.7 (pulled recently) ***sneek_ is now known as sneek
***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 ***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 <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) <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? <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>It'd be good to know if this can be confirmed. <ss2>That is from melpa, I assume? <ss2>haven't thought about this yet. Will fetch an older Emacs and see how it is from there. <ss2>yes, but all buffers are read-only, making it basically unresponsive. <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>Does that emacs do that Weyland stuff? Or is it X11 ? <ss2>oh, but this doesn't happen when I'm in a terminal! <dsmith-work>And by "selection" I've been assuming you mean swiping with the mouse. <ss2>I don't need a mouse in Emacs. <ss2>hang on, gonna do the classic way with Mark set. <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