<RhodiumToad>(apply-individually-aux (list 'quote f) (reverse args))) <sviteri>I was trying 'f! (which made no sense for the clear reason) <sviteri>great -- getting $38 = ((((quote S) X) Y) Z) <RhodiumToad>this is assuming the first arg to apply-individually is always a symbol that you want to match literally <RhodiumToad>that's correct - always remember that 'S is just a reader shorthand for (quote S) <sviteri>I might want to use (apply-individually '(S I) '(X Y Z)) <sviteri>I can put a recursive quote mechanism in the same spot I guess <RhodiumToad>does the first arg there contain only literal symbols, not anything else? <sviteri> `(,(rec-quote (car x)) ,(rec-quote (cadr x))))) <sviteri>scheme@(guile-user)> (rec-quote '(S I)) <RhodiumToad>style question, wouldn't apply-individually-aux be better as a named-let? *RhodiumToad not an authority on scheme style <sviteri>scheme@(guile-user)> (program-to-reduction-rule 'I) <sviteri>scheme@(guile-user)> (program-to-reduction-rule '(S I)) <sviteri>$43 = (((((quote S) (quote I)) v0) v1) (v1 (v0 v1))) <sviteri>Or are we? I think I need to unquote the right side <sviteri>A huge letdown -- scheme@(guile-user)> (match '(I X) (program-to-reduction-rule 'I)) <sviteri>but (program-to-reduction-rule 'I) contains both my pattern and expression <RhodiumToad>remember that match is a macro, it doesn't evaluate its args <RhodiumToad>(match '(I X) (program-to-reduction-rule 'I)) binds the value (I X) to the symbol program-to-reduction-rule and then returns the result of evaluating 'I <sviteri>(let ((rule (program-to-reduction-rule 'I))) (match '(I X) rule)) <daviid>mwette: did not answer your message about configure.ac, but fwiw, in my projects (guile-cv, g-golf, foliot ... in guile-lib to) i implemented an option '--with-guile-site' and still honour $prefix (for doc, examples ...) if passed - just look at the configure.ac of g-golf for example, if you are interested of course (and m4/guil-ext.m4, am/guile.mk) <RhodiumToad>sviteri: you either need a non-macro version of match, or you need to use (compile) <sviteri>Ah so that's why you used compile earlier <sviteri>So the example by stis earlier -- is this a non-macro version of match <daviid>mwette: g-golf is guile version 'agnostic', so code modules are installed in the GUILE_GLOBAL_SITE dir (as oppoed to the GUILE_SITE dir) <sviteri>(define m2 (append-imatch '(?a 2) (lambda (?a) (list 'b ?a)) m1)) <rotty>is `flush-output-port` (aka `force-output`) supposed to work with R6RS `transcoded-port`? I think this used to work, but am pretty confident it is broken now (i.e. may fail to actually force output) <rotty>dsmith-work: request noted, I will put it on my lengthy and very unreliable mental list of "things to look into" <rotty>weinholt: this is where dorodango is stuck when running under Guile 3.0, FWIW *rotty writes a bug report, this seems to be a regression introduced with Guile 2.2 (the linked code works as expected on 2.0) <sviteri>RhodiumToad: and Stis: it works now, thank you <sviteri>scheme@(guile-user)> (program-to-reduction-rule 'I) <sviteri>$78 = (((quote I) v0) (quasiquote (unquote v0))) <sviteri>scheme@(guile-user)> (define lang `(,(program-to-reduction-rule 'I))) <sviteri>$79 = ((((quote I) v0) (quasiquote (unquote v0)))) <sviteri>scheme@(guile-user)> (define v (compile `(lambda (prog) (match prog ,@lang)) #:env ***wxie1 is now known as wxie
***daviid` is now known as daviid
<daviid>str1ngs: wc! cool to see nomad progresses <daviid>str1ngs: i am working on the 'inout args problem, then the missing array types ... <str1ngs> daviid no rush for functions/methods that g-golf I just use some custom typelib functions of my owne. <rlb>...found the problem with pfds -- it did end up being a bug there, not with guile. I'll report it and close the guile bug tomorrow. ***wxie1 is now known as wxie
<rotty>is it possible that debbugs swallows mails stemming from `mail@<domain>` addresses? I think this has happened to me with Debian's instance before, and seems to be happening to me with the GNU instance as well. if i'd know it, I could work around it, but it's seriously misterious -- the mail has been accepted almost an hour ago by the debbugs MTA, but does not show up in the web interface. <rotty>(issue 39610, which i originally posted via gmane, and sent an update directly via mail: from=<mail@r0tty.org> to=<39610@debbugs.gnu.org> stat="250 OK id=1j2xdC-0000us-0n", Feb 15 13:37:14 UTC) <jackhill>Hi, how would I try to build all the packages reported by guix refresh -l, if I wanted to check that my change didn't break dependent packages? <weinholt>i'm surprised that it hasn't bitten anyone earlier <stis>people tend to code around <rlb>...guile doesn't support srfi-7 and racket doesn't support srfi-0... <rlb>Anyone happen to know of a reasonable way to detect racket vs guile right now, so that you can selectively say (require 'srfi/64) vs (use-modules (srfi srfi-64))? <rlb>all the rest of the code can be rnrs, but need to handle loading the srfis differently (it seems). <weinholt>why not (import (srfi :64))? works with guile and plt-r6rs <rlb>weinholt: had no idea that was a thing -- but possibly perfect. Is that part of the rnrs spec, or just happens be implemented by both, or...? (I still don't know r6+rs very well.) <rlb>weinholt: ok, thanks much. <rlb>(oops ...missed my C-x b there...) <rlb>...looks like the pfds' test library may just be "gone" from the internet, i.e. (wak trc-testing). <rlb>I thought I tried that earlier and got a 404 (i.e. gitlab, but maybe the link I was following was just broken)... And none of my subsequent searches found it. Might be time to step away from the keyboard for a bit :) (And thanks.) <lispmacs>when I run statprof I get messages like ;;; (what! #<stack 7f96eb0d2660>) ***janneke_ is now known as janneke
<rlb>scheme@(guile-user)> (use-modules (srfi srfi-69)) <rlb>scheme@(guile-user)> (hash #:foo) <rlb>$1 = 16939754213367027 <rlb>scheme@(guile-user)> (hash #:bar) <rlb>$2 = 16939754213367027 <rlb>I think that may have been a contributor to the pfds crash I was seeing. i.e. I'd assumed that keywords would not all have equal hashes. Though there may still be a bug in pfds, i.e. why wouldn't it just have terrible performance due to universal collisions? <mwette>this boils down to (w/o srfi-69) (hash #:foo most-positive-fixnum) <mwette>... to scm_raw_ihashq (SCM_UNPACK (obj))) % n ... so I wonder if there is something to do with encoding keywords <rlb>First off, do we think that might be a bug, or what was intended? (i.e. happy to investigate and see if I can fix it, if it's something that needs fixing...) <mwette>I can't see how this could be indended behavior. <mwette>I'd guess some optimization of keywords w/o realizing this outcome. <dsmith>scheme@(guile-user)> (hash 'foo) <dsmith>scheme@(guile-user)> (hash 'bar) <dsmith>scheme@(guile-user)> (hash #:foo) <dsmith>scheme@(guile-user)> (hash #:bar) <dsmith>scheme@(guile-user)> (hash #:baz) <dsmith>scheme@(guile-user)> (hash #:zork) <dsmith>scheme@(guile-user)> (hash #:something-else-anything-else) <rlb>Maybe it's not hashing the content. <rlb>i.e. it's hashing the common type-object or something... <mwette>I think SCM_UNPACK(obj) where obj is a keyword need to be unraveled <dsmith>'foo and "foo" hash to the same value <rlb>Or at least, not what I want from a general purpose hasher... <dsmith>scheme@(guile-user)> (eq? (hash 'foo) (hash "foo")) <rlb>It turns out that hash integer for all keywords was relevant to the pfds hamts crash -- i.e. if it's 0, no crash, but that value perturbs things such that it hits the broken code path. <rlb>And looks like there's another pr there (merged by ironscheme) that fixed the bug I found -- wish I'd seen that earlier. <rlb>Wonder if ironscheme might be the preferred pfds upstream now, or if there is one... <weinholt>rlb, it's quite useful software, thinking about packaging it? <mwette>so odd: if I code in C, hashes are different <rlb>Hah, not yet -- first think we should figure out a somewhat active upstream, i.e. with those fixes, readme update, etc. <rlb>Was trying to decide if I should fork it for myself for now (and of course others could use it), rely on ironscheme's fork (and see if they want to be the upstream for now), or... *rlb doesn't know anything about ironscheme... <rlb>oh, that's the clr thing <weinholt>rlb, i've got an ITP for chez-srfi and have been sketching out some general ideas for packaging R6RS and R7RS libraries, would be good to hear your views at some point <rlb>Ahh, ok -- well currently have no opinion :) (Hadn't thought about it at all yet.) <rlb>I hope what we need will be simpler than emacsen-common has been :) <rlb>Any idea if it might be more like just needing to put the files in a well specified location and then have some policy so that each of the maintainers can adapt guile/chez/racket/whatever to find them? <rlb>I guess we might need more than that if we want install-time compilation triggered, etc. <weinholt>i'm hoping to get away with just dropping the files in the right place initially <weinholt>but the full picture is more complicated... i'll send you an email <rlb>I'd need to read up again, but if triggers *could* do what we want, then adding a trigger call to the postinst or whatever might be handy, then maintainers can opt-in as they like. But might want to sit down first and come up with something like debian-emacs-policy if feasible. <rlb>Though as mentioned, certainly hope it can be simpler than that... <weinholt>the more people desire, the more complicated it gets :) <lispmacs>hi, I'm running guile-3.0 from Guix guile-next package. When I use statprof I get the "error" <lispmacs>in source code it says this is not supposed to happen if statprof.scm is compiled <lispmacs>the guile-next package does have a statprof.go installed, so I'm wondering what is amiss 