IRC channel logs
2017-03-07.log
back to list of logs
<paroneayea>so django has this nice thing where during the test suite, you can look at what arguments were passed into each template <paroneayea>now in my guile webapps' example, templates are just procedures that render sexps <paroneayea>generalized to any procedure, but realistically just used by templates <paroneayea>one option would be to wrap calls in something like <paroneayea>where snoopply is snooped apply, which records argument calls in some structure held by some parameter <paroneayea>where there's a mapping of eq? procedure -> args <paroneayea>however, it struck me... I could use vm traps for that <paroneayea>but, vm traps seem a lot gnarlier, for some reason <paroneayea>using them for tests instead of debugging seems like a huge hack, but then again so does calling procedures with (snoopply foo ...) <paroneayea>wingo: do you think the move to an AOT based version of Guile's VM will mean that the trap infrastructure may disappear or change dramatically? <paroneayea>I guess if anything gets inlined, that means that a trap won't continue to work there <paroneayea>which would make sense, not against that, just trying to figure out what I can expect to survive :) <CharlieBrown>davexunit: I found a random Lisper on a reddit thread when I was thinking about sucklessifying my system. To my surprise, it was you. <nalaginrut>lloda: interesting, I never encounter such issue <nalaginrut>lloda: have you enabled lightning during configuration? <lloda>it's weird, if I run GUILE_AUTO_COMPILE=0 ../meta/build-env guild compile --target="x86_64-unknown-linux-gnu" -O1 -L "/home/danielo/sys/guile-git/obj-tjit/../src-tjit/module" -L "/home/danielo/sys/guile-git/obj-tjit/../src-tjit/guile-readline" -o "ice-9/eval.go" "../../src-tjit/module/ice-9/eval.scm" <lloda>but from the Makefile, it crashes <lloda>probably something in the environment? <lloda>although master, stable-2.0, all work w/o problems <nalaginrut>lloda: I'm still tweaking Makefile, it doesn't work for me again. Anyway, it seems not stable, I'll do more check <lloda>nalaginrut: I'll test when you have something up :-) <nalaginrut>lloda: the problem is that I can't reproduce your coredump, I just fixed another bug to mkdir before copy compat-x86_64-linux.scm which breaks the compilation occasionally <nalaginrut>lloda: maybe the problem you encountered is related to the version of GCC <wingo>paroneayea: does adding a rest argument not do it for you? <wingo>the rest argument gets all keyword arguments <wingo>paroneayea: regarding traps. i don't think things will change significantly. i think the cost of a trap invocation will be similar to a GOT lookup on i386 -- a call to a known address that doesn't clobber any registers <wingo>so we just emit calls where the traps would run, and usually they do nothing <wingo>we could have a compile option that emits the trap calls; not sure how important that is tho <wingo>dunno how much traps and asyncs can share infrastructure, but we'll see i guess <wingo>i guess traps have to be per-thread so i guess they will be part of scm_i_thread... <wingo>anyway, i think we can keep them in by default <wingo>otherwise you have to implement a full debugger like gdb and that's hard to do with threads <wingo>yeah indeed, i always forget how to use it <wingo>and the manual doesn't really help <civodul>ACTION just realized there's been a lot of activity on guile-user <wingo>civodul: so you probably are just swamped with mail and stuff, a guile detail tho: possibly-last-2.1.x prerel this thursday, 2.2.0 next thursday maybe! <civodul>wingo: yes, i just saw that, exciting! <civodul>i replied regaring the foreign object API <civodul>i've not been involved but i feel the excitement like in the 1.9 days :-) <wingo>do use them for making debugging tools but i advise against using them for core program functionality :) <paroneayea>wingo: regarding *args and **kwargs in python, the things I miss aren't critical, and I don't always miss them... I miss sometimes that **kwargs will only grab the keywords that haven't been "fulfilled" by ones actually specified. Yeah I know I can filter those out manually <paroneayea>also when I want keyword-heavy interfaces that might change I often want #:allow-other-keys but it's kinda long ;) <paroneayea>that said, I do like that define* is "just an abstraction" and you can write your own snowflake thing if you reeeeeeaally want to, but probably don't need to :) <paroneayea>the ability to refer to the previous arguments in constructing the "defaults" is pretty great <paroneayea><wingo> do use them for making debugging tools but i advise against using them for core program functionality :) <paroneayea>wingo: what about for snooping on your code in a test suite? ;) <wingo>depends on what you do with them :) <wingo>the compiler could do weird things to your code and so the runtime might trap in different places <wingo>if the compiler changes and your code breaks, you can keep both pieces :) <paroneayea>wingo: mainly snoop on what arguments are passed into an sxml-generating template procedure. I'm trying to emulate django's "see what arguments are passed into your template" thing they use in unit tests, which turns out to be pretty nice for writing tests where you want to make sure the right things are being passed in to "render" <paroneayea>with something I wrote called snooply, which, depending on your dynamic environment, is a snoopy apply which also records the arguments passed into any procedure called through it. Pretty hacky. I figured, maybe VM traps would be a different kind of hacky ;) <wingo>better to use hacks that have more stable semantics and aren't vulnerable to weird compiler things :) <paroneayea>it's kludgy, but unit testing html-generating views can be pretty hard otherwise. sifting through the response by processing the returned html isn't very nice, and is even more brittle than trying to spy on what arguments are passed into the templates since the visual presentation could always change <paroneayea>so I think django probably does the right thing by letting you check what arguments are passed into the template procedures <efraim>wingo: I saw 2.2.0 might be around the corner. If you need me to test an RC or something on aarch64 let me know <wingo>efraim: what is your config.guess? <wingo>i mean the triple/tuple/whatever <efraim>It should be aarch64-linux-gnu. I'm on my phone ATM <wingo>cool, i need to make sure the prebuilt/ links work nicely on all common architectures <wingo>efraim: do you know the page size? <efraim>that's a good question. It might be 16 instead of 8 <efraim>civodul had a good patch for the guix-daemon that made the daemon work on aarch64 <efraim>OK looks like I'm not answering the question you asked, I'm not really sure <wingo>yeah guile 2.2 right now has a problem if page size > 4096 bytes <wingo>fixing it is a little gnarly <civodul>wingo: does that fail with huge pages? <andijh92>hello. if i have a file with multiple srfi-64 tests. is there a simple way to run only 1 test from the commandline? every test should be skipped except the specified one. <wingo>sneek: later tell civodul you don't get huge pages unless you ask for them, so i think there is no problem <wingo>i would help andijh92 but i don't know anything about srfi 64, sorry <wingo>i think i have a solution to the dynamic-state + exception handler problem... <wingo>make-thread-local-fluid, a fluid kind that doesn't get captured by make-dynamic-state <amz3>I am the one who asked about sat solver <amz3>stis: héllo I am reading through your blog <amz3>you seem to use minikanren and not the new microkanren, is there a reason for that? <amz3>stis: there is a typo I think in the article <amz3>No you can pass extra information → Now* you can pass <amz3>stis: why do you continuation passing style instead of call/cc for instance? <amz3>stis: i am trying to solve the package manager dependency problem, I made a sat solution but maybe it could be solved using minikanren or guile log?