IRC channel logs


back to list of logs

<ijp>just the man I wanted :)
<ijp>mark_weaver: I was just away to push dak's fix for the docs of unfold-right, but the wording is slightly different from that of srfi 1
<ijp>I think it's a little better, but should I prefer the srfi 1 version?
*mark_weaver looks
<ijp>anyway, I have filled in the commit message, since he didn't give a proper patch, and my finger is now hovering over the push button :)
<mark_weaver>I don't think it matters much either way. use your best judgment :)
<mark_weaver>I also slightly prefer dak's wording.
<jmd>I wonder if there is a guile based backup tool out in the wild somewhere?
<mark_weaver>jmd: civodul developed a cooperative backup system using Guile for his PhD. it's called libchop.
<mark_weaver>more generally, it's a distributed storage system.
<jmd>Oh Thanks.
<davexunit>I have a function that wants to use SCM_VALIDATE_LIST, but it seems to want FUNC_NAME defined.
<davexunit>will FUNC_NAME be exposed to the user upon error
<davexunit>because this function is just a helper, it does not have a scheme binding.
<mark_weaver>well, you can #define FUNC_NAME before the function and #undef it after, but I'm not sure it makes sense to have a helper here.
<mark_weaver>the function is so small already
<mark_weaver>it's fairly common to #define FUNC_NAME in helpers to be the name of the scheme procedure that uses the helper.
<mark_weaver>I suppose you could pass in the name of the scheme procedure to the helper, as an extra argument, and then #define FUNC_NAME to refer to that argument name.
<davexunit>hmm. I figured that since I now have 4 functions doing almost the same thing, I would extract the common stuff out into a function.
<davexunit>I guess I can just pull out the list validation bit, though.
<davexunit>and problem solved.
<mark_weaver>another option is to extract the common stuff into a macro instead. there's a precedent for that in the bytevector code.
<davexunit>oh yeah. that's a good point.
<mark_weaver>I don't know which is better here; use your best judgment :)
<mark_weaver>but if you use a function, make sure it's "static". that makes a big difference.
<davexunit>yeah, to keep it local to that module.
<mark_weaver>if it's not 'static', then calls to it cannot be inlined and must go through the shared library PLT, which is much slower.
<mark_weaver>in a shared library, calls to 'static' functions are dramatically cheaper.
<davexunit>good to know.
<davexunit>I tried the macro approach. here's what I have so far:
<mark_weaver>davexunit: I think scm_hash_fn_set_x is probably slower than the specialized hash set functions.
<davexunit>hmm, alright then. I can change it.
<davexunit>the thing that's tripping me up right now is hashx since it requires 2 additional procedures to be passed.
<mark_weaver>davexunit: well, you could use the macro only for the other three, but not for the hashx one.
<mark_weaver>or, if you wanted to be fancy, you could probably make it work with higher-order macros: macros that take macros as arguments.
<mark_weaver>but I'm not sure it's worth the complexity in this case.
<davexunit>yeah I guess I can just treat hashx special.
<davexunit>mark_weaver: now I have this
<mark_weaver>looks good to me!
<mark_weaver>we'll also need docs and tests.
<mark_weaver>(sorry for the slow responses; I'm socializing with friends in real life :)
<mark_weaver>thanks for working on this!
<davexunit>thanks for the help mark_weaver
<mark_weaver>going offline for a bit. bbl!
<antithesis>Part of a command needs to be put inside "double quotes", but the whole command is inside the "double quotes" as well
<antithesis>So I need them to behave like regular quotes. But it gets confused if I do that
<antithesis>(xbindkey '(alt v) "cliphist && xte "str $(xclip -o)"") is what I'm trying to do
<dje42>\\" ?
<antithesis>dje42 I don't need to print the character. The command xte just requires double quotes in order to interpret the command correctly.
<dje42>could be misunderstanding of course, but "cliphist && xte \\"str $(xclip -o)\\"" is what I was thinking of
<antithesis>lsal@b00n ~ % xte \\"str abc\\"
<antithesis>Unknown command '"str'
<antithesis>Unknown command 'abc"'
<antithesis>Whereas xte "str abc" will do what I want
<`enrythe`ermit>(xbindkey '(alt v) (system 'cliphist' (system 'xte "str $(xclip -o)"')
<`enrythe`ermit>with (delay or macro around system
<dje42>What does the % prompt mean? Is that a shell prompt?
<antithesis>dje42 that's zsh
<dje42>[if so, no wonder "str and abc" were interpreted as separate args :-)]
<dje42>So which program is parsing (xbindkey ...) ?
<antithesis>`enrythe`ermit you forgot a few parenthesis but even after fixing that, it isn't working
<antithesis>Vim shows a red highlight at 'cliphist', thinking something's wrong with it. I don't know what.
<dje42>presumably the trailing ' on 'cliphist' shouldn't be there
<antithesis>dje42 it's parsed by xbindkeys
<dje42>But is the expression supposed to be a Scheme expression?
<antithesis>dje42 that doesn't work either
<antithesis>The program just offers to use Guile for the configuration
<dje42>And what is the second argument? Something that is passed to a shell?
<dje42>I guess I still don't understand why my original suggestion doesn't work. Guile will turn it into the string: cliphist && xte "str $(xclip -o)"
<dje42>Obviously missing something I guess.
<dje42>passing spaces through various levels of shell, is always fun
<dje42>You might try "cliphist && xte str\\ $(xclip -o)" [assuming the output of xclip has no spaces]
<dje42>xte str\\\\ $(xclip -o)
<antithesis>It works!
<antithesis>Thanks dje42
<dje42>Which one? :) The xte str\\\\ $(xclip -o) ?
<antithesis>Sorry about that. I dismissed your initial suggestion without actually trying it. I typed in xte \\"str $(xclip -o)\\" in the shell and it didn't work, so I didn't bother to even put it in my configuration file
<dje42>Ah. np.
<antithesis>Do you want to see the cliphist script? :)
<dje42>naaaa. :)
<antithesis>It pipes my clipboard history to dmenu, lets me select one from that, and puts that in my clipboard. :)
<stis>wingo: morning!
<davexunit>good morning guilers
<davexunit>how do I run a single test file?
<stis>good morning davexunit:
***wingo_ is now known as wingo
<wingo>davexunit: ./check-guile foo.test
<davexunit>wingo: thanks. that's almost what I tried first, but I messed up and specified the path to the test file like test-suite/tests/foo.test.
<wingo>davexunit: yep; undocumented test suite lib is undocumented :(
<wingo>whee, resumable partial continuations in the new vm...
<davexunit>is that what prompts are?
<wingo>they might be resumable or not depending on whether they include C code
<wingo>and depending on whether their handler accesses their continuation or not
<wingo>non-resumable continuations were working, now resumable continuations are too
<wingo>which means i just have a couple miscompilation issues and some bootstrap issues and i'll be able to compile all of guile with rtl
<dje42>where/how did the word "prompt" get chosen to describe these?
<dje42>Huh. Thanks. Hopefully I can find a mnemonic to keep it in cache. (the one in the paper went in one eye and out the other :) )
<wingo>% doesn't work for you?
<wingo>it's the tcsh shell prompt :)
<wingo>dje42: here's another try:
<mark_weaver>ijp: did you get the impression that there might never be a 2.0.10 ?
<mark_weaver>even if 2.2 was released tomorrow, we'd still want to support 2.0.x for a while. I'd do it if no one else wanted to.
<dje42>wingo: that helps.
<wingo>mark_weaver: agreed, fwiw
<dje42>[plus I read "guile and delimited continuations"]
<mark_weaver>wingo: resumable partial continuations in RTL, yeah!! :)
<wingo>mark_weaver: :)
<wingo>that's in the wip-rtl-prompts branch
<wingo>i probably shouldn't merge it until we are closer to switching over -- it makes stack vm partial continuations not resumable
<mark_weaver>ah, okay. makes sense.
<wingo>but we are close :) maybe by next week or so.
<ijp>mark_weaver: the funny thing about that procedure is that it has been broken for 4 years, and deprecated for 4.5
<mark_weaver>heh, well, it's certainly true that ttn will have to work around the problem.
<mark_weaver>still, 2.0.x will be around for a while, and so I think it should be fixed. if you don't want to do it, I will.
<ijp>fixing it is not a problem; I just take exception to his notion that I'm coercing him
<mark_weaver>I agree that you wouldn't be coercing him, but that's not quite what he wrote.
<mark_weaver>I think that some projects are frustrated at the amount of work they've needed to do to continue working with the latest version of Guile. I think some of them feel coerced into doing work that they'd rather not do. It's not an unreasonable thing to feel. I guess ttn was giving voice to that feeling.
<ijp>the code has been literally broken since Jan 20 2010
<mark_weaver>yeah, so we screwed up, and that's embarrassing.
<ijp>that's a mid 1.9.x problem
<mark_weaver>it's true that it's been broken for so long that all projects using that procedure will have to work around the problem.
<mark_weaver>but I still think we should fix it.
<ijp>I think we should fix it because fixing bugs is the right thing to do; I'm not fixing it because I think this procedure has been used before he reported it in september
<mark_weaver>well, you never know. a lot of people don't report bugs. many simply work around the problem in silence.
<mark_weaver>(while they're opinion of Guile goes down)
<mark_weaver>I'm embarrassed to admit that in most of my time using GNU (about 20 years), I've tended to work around problems in silence and not report bugs properly.
<mark_weaver>that's just one data point, but I suspect it's fairly common.
<dsmith>mark_weaver, Part of it is that there is a huge lag between finding/fixing something locally and getting it merged into upstream and then getting THAT into your distros packages.
<dsmith>While building stuff locally us usually not that much of an effort, I'd much rather be lazy and use packages. Especially if I am managing lots of systems.
<mark_weaver>dsmith: yeah, the huge lag time is a major demotivator.
<mark_weaver>(one of the reasons I'm looking forward to Guix as my primary system :)
<ijp>mark_weaver: any comment on it?
<mark_weaver>ijp: the commit message should reference the bug number and reporter. other than that, looks good!
<ijp>whoops, I did actually mean to do that
<mark_weaver>the bug numbers are important. without them, compiling the NEWS will be a PITA :)
<ijp>would you prefer the number or the url?
<ijp>looks like the url is pretty common
<mark_weaver>I like to put the URL in the form:
<mark_weaver>(that number is made up)
<ijp>hmm, I don't see a permalink in the form, *edits*
*ijp pushes
<mark_weaver>cool, thanks!
<ijp>how can I get usable output from trace
<mark_weaver>ijp: can you be more specific about the problem you'd like to see fixed?
<ijp>I don't really know, some kind of filtering
<ijp>but I just got 15000 lines for tracing one form, and I know I don't want that :)
<mark_weaver>15000? ouch. I've never seen it that bad. I wonder if it has to do with the R6RS layer.
<ijp>no, this one is because the code happens to parse a file (which I hadn't known beforehand)
<ijp>the r6rs records do make the traces very unpleasant at times, though
<mark_weaver>I think this is a question for wingo
<mark_weaver>I confess I usually just sprinkle 'pk' around :)
<mark_weaver>but it would be nice to have better debugging support. ideas welcome!
<ijp>this is probably a job for breakpoints
<ijp>(well, now that I have something to go on)
<mark_weaver>ijp: btw, did wingo suggest that a 2.2.0 release might happen soon?
<mark_weaver>if so, I'll probably encourage holding off on that for a while.
<mark_weaver>(given that the x.x.0 releases are the only times when we can introduce ABI incompatibilities, we should take the opporunity to fix some other things that would require incompatible changes)
<ijp>mark_weaver: I recall him saying he wanted the new vm released before the end of the year. which I believed was a major number change
<mark_weaver>okay. I better get my ass in gear on some of my TODO list items.
<ijp>from the TODO email "Obviously it would be nice to get a lot of other things into 2.2 but this is the necessary bit. I think we should shoot for a 2.1.0 release around 1 December; dunno."
<mark_weaver>among other things, I'd like to change the string repr to UTF-8, source tracking for bare symbols, secure sandboxing, more numeric VM ops, and probably some other things I'm forgetting.
<mark_weaver>also, an efficient 'define-values' implementation, which in turn requires fixing-letrec-reloaded.
<mark_weaver>I also think we should import irregex (or better yet, the draft SRFI based on it), and maybe foof-loop too.
<dsmith>mark_weaver, wow. That's a lot.
<dje42>Can we have a pony too? :)
<ijp>ponies are proprietary
<ijp>if you can find a fully free pony with dna licensed under the gfdl, we'll consider it ;-)