<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? <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 :) <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. <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>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. <mark_weaver>another option is to extract the common stuff into a macro instead. there's a precedent for that in the bytevector code. <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. <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. <mark_weaver>davexunit: I think scm_hash_fn_set_x is probably slower than the specialized hash set functions. <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. <mark_weaver>(sorry for the slow responses; I'm socializing with friends in real life :) <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 <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 <`enrythe`ermit>(xbindkey '(alt v) (system 'cliphist' (system 'xte "str $(xclip -o)"') <dje42>What does the % prompt mean? Is that a shell prompt? <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 <dje42>presumably the trailing ' on 'cliphist' shouldn't be there <dje42>But is the expression supposed to be a Scheme expression? <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, et.al. is always fun <dje42>You might try "cliphist && xte str\\ $(xclip -o)" [assuming the output of xclip has no spaces] <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 <antithesis>It pipes my clipboard history to dmenu, lets me select one from that, and puts that in my clipboard. :) ***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... <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>it's the tcsh shell prompt :) <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>[plus I read "guile and delimited continuations"] <mark_weaver>wingo: resumable partial continuations in RTL, yeah!! :) <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 <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 <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. <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>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 :) <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 <ijp>hmm, I don't see a permalink in the form, *edits* <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>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. <ijp>ponies are proprietary <ijp>if you can find a fully free pony with dna licensed under the gfdl, we'll consider it ;-)