<sirgazil>paroneayea: Hi :) I sent you an email with Guile logo SVG. Hope is not too late. <taylanub>sneek: later tell wlhlm I can reproduce your exact issue on Yosemite with Guile 2.0.11 from MacPorts <ArneBab>sneek: later tell davexunit: Can I ask shroud to encrypt to multiple GPG keys? I don’t have my private GPG accounts at work, but I need the passwords in both places. <zacts>I want to visit Denmark one day <taylanub>what does it mean when I get (vm-run "Unrewindable partial continuation" (#<vm-continuation 2c67280>)) ? there was some kind of continuation barrier in the place I captured the continuation? <taylanub> (lambda () (hash-for-each (lambda (k v) (abort-to-prompt ht-iter k v)) ht)) <taylanub> (lambda (cont k v) (make-cursor cont k v))) <sneek>Welcome back davexunit, you have 1 message. <sneek>davexunit, ArneBab says: Can I ask shroud to encrypt to multiple GPG keys? I don’t have my private GPG accounts at work, but I need the passwords in both places. <davexunit>if you ever feel motivated, you'll find that the shroud source code is very small. <ArneBab>I just started using diceware (and building a better german equivalent), so I will have more passwords… <davexunit>I use shroud every day, most notably in my offlineimap config <ArneBab>I normally rely on kwallet, but that’s bound to a single machine <davexunit>I added a python function that spawns a subprocess to fetch my email passwords from shroud's db <davexunit>working with numbers in Scheme is so pleasant. lots of other languages require special hackery to get around the fixed size of the integer type and such. <ArneBab>why do you call the initial autoconf-calling script ./bootstrap? <davexunit>ArneBab: copied from elsewhere. it bootstraps the build system. <ArneBab>/bin/mkdir: cannot create directory '/usr/local/lib': File exists <ArneBab>that’s what I get on sudo make install <ArneBab>davexunit: do I have to adjust the GUILE_LOAD_PATH? <davexunit>ArneBab: depends on how your system is setup <davexunit>but yes, GUILE_LOAD_PATH and GUILE_LOAD_COMPILED_PATH should include the directory where the modules were installed. <ArneBab>GUILE_LOAD_PATH=/usr/local/share/guile/site/2.0/ scripts/shroud --help # this works <ArneBab>davexunit: does shroud install the script for you? <ArneBab>“nothing to do for install-exec-am”? <ArneBab>did you really not do it or is my system just borked worse than I thought? <davexunit>I definitely tested this but I guess my PATH was setup to use the scripts directory in my repo <ArneBab>don’t worry, that’s what real-world testing is for :) <ArneBab>that I stumble over it while we’re both in IRC is close to the best case :) <davexunit>well thank you for spotting this. I have to test my releases more carefully. <davexunit>I uploaded a tarball but haven't pushed the relevant commits yet <davexunit>if you confirm that it works now, I'll send an email about the issue and update the guix package. <davexunit>same deal for any other guile modules that aren't installed to the default prefix <ArneBab>^ patch to add setup info to the readme. <ArneBab>maybe that should be /etc/bash/bashrc in there <davexunit>note that this wouldn't be an issue if you set the appropriate prefix <ArneBab>that’s not in the instructions, also that would clobber my distros installations <davexunit>of course, some people, perhaps you, don't like putting stuff there because that's where their distro puts stuff, but that's the directory that would "just work" <davexunit>it's not in the instructions because --prefix is a standard GNU build system option. <ArneBab>I think that for documentation, you either need to add the prefix or add the GUILE_LOAD_PATH <ArneBab>it’s normal to have /usr/local/bin in PATH (or rather: if you google that, stackoverflow tells you what to do ☺) <davexunit>then you need to configure Guile accordingly <davexunit>but I can make a note in the README about it. <ArneBab>you should be able to simply import them with git <ArneBab>yikes… encrypting to my other GPG key yields the expected result ☺ <davexunit>ArneBab: how does one import this mercurial patch thing? <ArneBab>davexunit: just like you import any other patch (as created with diff -u) <davexunit>I use 'git am' typically, but that only works for patches in mbox fomat <ArneBab>luckily there’s an option for that in the email extension ☺ $ hg email -r 21 -r 26 -m readme-patches.mbox <davexunit>I'll just copy the diff and credit you in the commit log. <ArneBab>I didn’t rebase the first onto your new push <ArneBab>^ I’d like to know whether this workflow is seamless now <davexunit>ArneBab: thanks, but I've already done it the old-fashioned way. <davexunit>I honestly just copied the text out of the patch file, removed the + signs and reformatted it. <ArneBab>I’m trying to find out where to add multiple encrypt-target IDs <ArneBab>I’d guess ui.scm, and then loop it through to secret.scm (save-…) <davexunit>ArneBab: call-with-encrypted-output-file in (shroud utils) would need to be adapted. <ArneBab>(let ((user-id-string (if (pair? user-id) (string-join user-id ",") user-id))) <davexunit>use (ice-9 match) to match a single string or a list of strings <please_help>where's the source for the typed-array code (especially the virtual array ops) located? <lloda>I expect to have it reviewed and merged at some point <ArneBab>davexunit: can git read from base64 encoded emails in an mbox? <ArneBab>do you want to try it or do you want a plain diff? <ArneBab>allow setting multiple recipients in ~/.shroud <ArneBab>Just use ("user@host" "user@host") instead of "user@host". <ArneBab>'((user-id . ("me@here" "you@there"))) <lloda>please_help: a couple bug fixes and some low-level functions to take slices <ArneBab>davexunit: multi-recipient code written ☺ <davexunit>ArneBab: awesome! I will take a look shortly <ArneBab>it was my first play with fold and ,@ (unquote-splicing) ☺ <ArneBab>the first match clause might benefit from a linebreak… <ArneBab>otherwise I’m happy with how small this patch turned out :) <lloda>please_help: array_ref is in generalized-arrays <davexunit>ArneBab: cool, the change is in the right place. I will tweak this code a bit and apply it soon. <lloda>please_help: are you using git? you can just git grep <davexunit>ArneBab: what email address do you want to use to link you to this commit? <davexunit>I guess through your full name in with it: Foo Bar <foo@example.com> <davexunit>that way I can add a copyright line for you and mark you as co-author of the commit. <please_help>I actually can't find the guile source files anywhere on my system so I'm using savanah. <lloda>please_help: just git clone it on your system somewhere <mark_weaver>taylanub: the reason is because 'hash-for-each' is implemented in C <taylanub>ah, ok. I posted about that on the user ML by the way. <amz3`>there is a potluck like previous years for guile? when is it? <amz3`>mark_weaver: I saw you message about lazy & guile. I need to study guile stream more closely <davexunit>amz3`: my parser combinator module uses streams, might serve as a decent example. <amz3`>I have a questio regarding that, but I don't recall right now <amz3`>davexunit: how do you parse using combinator parens? like aaabbb <davexunit>I didn't test this, but it would look something like: <davexunit>(define parens (parse-seq (parse-char #\\() (parse-any (parse-char #\\)) parens))) <davexunit>I don't have my library in front of me to test <davexunit>(define parens (parse-seq (parse-char #\\() (parse-any (parse-char #\\)) (parse-seq parens #\\))))) <davexunit>perhaps like this. I won't spit any more code out without testing, but I hope you see the rough idea. <davexunit>translated: to parse nested parens, you parse an opening paren, and then either a closing paren *or* nested parens followed by a closing paren. <davexunit>parser combinators, at least my implementation, can handle what's known as "right recursive grammars", as seen here. <davexunit>but they cannot handle "left recursive grammars" <davexunit>I tried to handle left recursive grammars but the added complexity was not worth it. <davexunit>and furthermore I don't have a good example of a language with a left recursive grammar. <amz3`>something like (define parser-thing (parse-seq parse-thing (parse-char #\\))) ? <mark_weaver>davexunit: the most simple infix language with only a left-associative '+' operator is left-recursive when expressed naturally. <mark_weaver>(although it is well known how to hack the grammar to not be left-recursive) <davexunit>amz3`: yeah, that would be an example of a parser that would never complete. <zacts>^ found out about this today via the gnu homepage <davexunit>mark_weaver: when you say 'infix language', do you mean a language for doing arithmetic? <davexunit>I read chicken scheme's "comparse" library implementation, and it too does not do left recursive grammars AFAICT. <mark_weaver>of course, it can be fairly easily worked around, with some loss of elegance <davexunit>I read an article that walked through a GLL parser combinator implementation in Racket that can handle such things, but the complexity quickly got out of control for me. <davexunit>the nice pure functions became a continuation passing style mess. <mark_weaver>hmm, yeah, I haven't looked at the state of the art in parser combinators lately. I don't know how elegantly it can be done. <mark_weaver>I suppose I ought to find some time to investigate this soon. <amz3`>zacts: it hase a good reputation too :) <mark_weaver>if/when I find time to look into this, I'll definitely look at what you've done <daviid>amz3`: what has a good reputation? <amz3`>kawa was the first time I did scheme, I did kawa drivers for rexster datbase. integration between scheme and java code is easy compared to jython <zacts>also it looks like they now support R7RS (I'm assuming small) <zacts>although, I'm lately trying to avoid any JVM based languages due to political reasons <zacts>and also the fact that iirc they were trying to make their API copyrightable in the USA ***amz3` is now known as amz3
<amz3>seems like you can never trust a big company to do the right things(tm) <daviid>wrt Kawa: I recently started to use it for 1 of my customer [which among other things does advanced digital image processing lab] and here is my conclusion: it is by far, order of magnitude, inferior to guile, due to the underlying java limitations. unless you have to play with a pura java library, which my situation wrt to imagej, I'd rather stick to Guile, Racket, .. any scheme impleentation that is not built on top of java <daviid>the Kawa people are very nice and very helpfull, but the limitations I'm talkng about hit immediately. then of course goops is an order of magnitude superior to the java oo system <davexunit>and those poor Clojurians, forced to use 'recur' instead of having tail-calls. <zacts>also, sly > java graphics kits (in terms of coolness) <daviid>and this said, I will use it for thisimagej deal I have to ... and I'm on #kawa, join me there [there is nobody :)] <davexunit>that's one of the really good java game programming libraries <zacts>it was Ok, but I really don't like the clojure seq over the scheme list <zacts>I liked clojure better than pure java though (orders of magnitude better) <zacts>but I haven't done much java at all ever <daviid>davexunit: yes, jawa implements proper tail-call, thanks god <davexunit>daviid: but it does so at a great cost, IIRC. <daviid>but for the recur religion, i has an option -no-tail-call :) <mark_weaver>daviid: are proper tails calls enabled by default in the general case? <davexunit>from what I've read, the JVM doesn't have the necessary instructions to implement tail calls. <mark_weaver>last I checked (a couple of years ago, iirc), they were disabled by default, except that some special cases (e.g. simple loops) were handled regardless. <mark_weaver>but I thought that handling them in the general case on JVM requires trampolines, or similar methods with high overhead. <daviid>mark_weaver: I think so, because the '-no-tail-call' is an option and not the default, but my steps with kawa are a couple days old :) <daviid>but wether default or not, using tail call [which I much prefer then recur or even loop] will cost a fortune there [jvm based scheme implementations] <daviid>mark_weaver: actually the option is this one, and I don't know the default [would have to check in the manual, no time now]: --[no-]full-tailcalls (Don't) use full tail-calls <daviid>so it might be no full tail call per default, don't knw yet <daviid>anyway, for a guiler, kawa is a small nightmare :) [sorry Per, wonderful work you do, but java is a planetarian disaster] <mark_weaver>so, it doesn't really have proper tail calls by default, but the compiler tries hard to turn common cases (e.g. simple loops) into tail calls. <mark_weaver>so it's an optimization, not semantically guaranteed as Scheme requires <mark_weaver>and I can't fault Per for this, since I guess there's no better solution for JVM. <mark_weaver>but proper tail calls are quite fundamental to the design of scheme <zacts>that's why sussman and aebelson wear wizard hats <paroneayea>sirgazino worries, I didn't see it but the guile with black background looked nice <zacts>huh, so I may post my music compositions to LibreFM <paroneayea>sneek: later tell sirgazil no worries, I didn't see it but the guile with black background looked nice, thanks for sending! I'll use it in future presentations <daviid>I would like to remove some directories within the guile-gnome documentation tree, which are on savannah, [under cvs: I don't think I can do that remotely [since there is no cvs dir remove command, it has to be 'rm -rf ...' on the server itself] so I need to fill a savannah ticket right? anyone here can confirm this? <mark_weaver>daviid: my CVS knowledge is rusty, but I think removing the directories would also remove all of the older revisions of the files in that directory, no? <mark_weaver>is there a practical reason why the directories need to be removed? <daviid>mark_weaver: there are empty already [content moved 1 level up] it's just a cleaning op really <daviid>and clutter becomes a separate project, so I can remove the doc from guile-gnome ... <mark_weaver>right, but CVS has no version control of directory trees, instead each individual file is version controlled. <mark_weaver>so, if you delete a directory, won't you lose all the history of the files that were in that directory before? <daviid>unless I have access to a server, I can't keep the server sync with the local copy <daviid>mark_weaver: good point. i'll leave them, just wanted to be clean and imo, the only important history there is in the news page, which is preserved, from 2004 till now <daviid>ACTION is almost ready with Guile-Clutter web-pages! <taylanub>mark_weaver: were there any specific problems with supporting integers in module names? I made an attempt and seem to have gotten it basically working (can define and import a module with integers in its name) with a fairly small patch. <taylanub>I also rebased r7rs-wip onto stable-2.0. there was one nontrivial conflict but it wasn't hard to solve. (new functions in stable-2.0/read.c needed the "option" -> "context" transformation that was done on r7rs-wip.) <taylanub>oh, 'import' doesn't accept the integers yet, though 'use-modules' does... <mark_weaver>taylanub: mainly it's just a matter of deciding on the best strategy for (1) how to map module names to file names in the presence of integers, (2) how to map the R6RS :N names to this, (3) how to best ensure that (srfi srfi-1) and (srfi 1) and (srfi :1) all resolve to the same module, etc. <mark_weaver>and dealing with backward compatibility on all of these things <mark_weaver>since SRFIs seem to be the most common use for integers-in-module-names in practice, it seemed almost pointless to allow such modules without solving the SRFI problem. <taylanub>I see. most R7RS implementations will look at $load_path/srfi/n.sld upon (import (srfi n)), but I guess we want to fall back to (srfi srfi-n) <mark_weaver>however, the biggest *technical* blockers to merging r7rs-wip are: (1) supporting cyclic data in 'write' by default without severely impacting its efficiency, and (2) gaining a more comprehensive test suite, to convince myself that all of this new code that I wrote for R7RS support isn't buggy. <mark_weaver>the main problem with (1) turns out to be doing it in such a way that doesn't break binary compatibility in the 2.0 series. it would be much easier to make the changes on the 'master' branch. <mark_weaver>someone apparently thought it would be a good idea for the scm_print_state struct to be part of our public API/ABI :-( <mark_weaver>and so I had to resort to really gross hacks to somehow store the information I needed in there. <mark_weaver>same problem I had with ports, since our port structure is also public. <taylanub>ouch, ok... I really appreciate the work you've put into it by the way, and think it would be a shame to let it go to waste :-) I'm still not very experienced especially in C, but I'll see what I can do. <amz3>taylanub: hey, what do you want to do with a cursor over a hashmap?