***darthlukan_ is now known as darthlukan
<felipebalbi>any chance we can get a letcc helper on guile mainline? It's simpler to write: (letcc foo ... then (call-with-current-continuation (lambda foo ... <felipebalbi>I have never done any define-syntax-rule before, but I *think* this is enough <wingo>if the only thing you need is an early return, consider let/ec from (ice-9 control) <wingo>your definition is good, but the begin is unnecessary; you can just do (lambda (k) e ...) <felipebalbi>wingo: thanks :-) having letcc just helps following "The Seasoned Schemer", really :-p <wingo>part of the fun in scheme is building up your own language, often with macros :) one of the corrolaries is that we can't provide the superset of all languages <wingo>in this specific case we'd probably name it let/cc which wouldn't be of use to you <felipebalbi>I must say, after so many years of C, Scheme is a lot of fun :-) <felipebalbi>wingo: btw, what is guile missing for full r6rs compliance? Is there any wiki page of some sorts tracking that? If possible, I'd like to help out. <wingo>if you find an incompatibility tho, patches to fix it are welcome :) <wingo>mail them to bug-guile@gnu.org <felipebalbi>wingo: I guess a better idea would be to implement some test cases for r6rs-defined functions? <wingo>there are also a number of open bugs about r6rs <felipebalbi>wingo: at least list-sort and vector sort are missing, for instance <wingo>they are certainly there; you have to write an r6rs program to use them (with proper import statements etc) <wingo>i.e. list-sort is in the (rnrs sorting) r6rs library <wingo>so do (import (rnrs sorting)) to get it <felipebalbi>oh, indeed. I must have forgotten to import (rnrs sorting) when I tested this <manumanumanu>I am very happy today. I got arximboldi's immer bindings for guile to work. Truly impressive stuff <manumanumanu>I don't know what to do with it yet, but those data structures is the only thing I miss from clojure <civodul>you should make a Guix package for it ;-) <manumanumanu>civodul: Haven't got guix up and running yet... that will be the next project <manumanumanu>they are a bit of a pain to install, and guix would simplify that a lot... <dustyweb>civodul: do you know what format import-x509-certificate expects? <dustyweb>(import-x509-certificate (string->utf8 "MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDCFENGw33yGihy92pDjZQhl0C36rPJj+CvfSC8+q28hxA161QFNUd13wuCTUcq0Qd2qsBe/2hFyc2DCJJg0h1L78+6Z4UMR7EOcpfdUE9Hf3m/hs+FUR45uBJeDK1HSFHD8bHKD6kv8FPGfJTotc+2xjJwoYi+1hqp1fIekaxsyQIDAQAB") x509-certificate-format/pem) <dustyweb>ERROR: Throw to key `gnutls-error' with args `(#<gnutls-error-enum Base64 unexpected header error.> import-x509-certificate)'. <civodul>dustyweb: there's a couple of examples in GnuTLS, under guile/tests <civodul>the thing should start with "-----BEGIN CERTIFICATE-----" <civodul>followed by a series of base64 lines, followed by "-----END CERTIFICATE-----" <amz3`>for some reason the x509-certificate.pem has two certificate in it <amz3`>I am talking bout gnutls tests too <dustyweb>civodul: seems like there's a distressingly large number of pem-like formats! <manumanumanu>why are the alist procedures named with a ! ?? They don't mutate <amz3`>manumanumanu: what alist procedure has a ! ?? <dustyweb>manumanumanu: they shouldn't have a ! if they don't mutate.. <amz3`>on my side, it mutated the original <amz3`>scheme@(guile-user)> (define a (acons 'a 'b '())) <amz3`>scheme@(guile-user)> (assoc-set! a 'a 'c) <manumanumanu>the manual talks about it. if the "key" is not present, it conses it to the beginning of the alist, and then the symbol pointing to the alist won't reflect that change <manumanumanu>doing (define a (acons 1 2 '()) and then (assoc-set! a 2 3) won't modify a <amz3`>fwiw I had only bad luck using set-car! and set-cdr! <amz3`>manumanumanu: that is alist-delete from srfi-1 <amz3`>that's helpers I wrote to work with alists <amz3`>in guile you would do differently but in pure scheme that's what it looks like <dustyweb>civodul: apparently the key format was in SubjectPublicKeyInfo format which I think is supported by gnutls but there's no guile bindings to import it maybe <dustyweb>> When I originally started working on GnuTLS I was envisioning a future where OpenPGP certificates will be used instead of X.509. My driver was the perceived simplicity of OpenPGP certificate format, and the fact that obtaining a certificate at the time required the intervention of costly CA, in contrast with OpenPGP where one had to generate a key and manage its web of trust. That never took off as a deployment nor idea, and today <dustyweb> none of the original driving factors are valid. OpenPGP certificates are not significantly simpler to parse than X.509, the web-of-trust proved to be a more difficult problem than Internet PKI, and the costly CAs verification issue is no longer relevant after letsencrypt.org. <amz3`>manumanumanu: for better or worse, I did no benchmarks, it works good enough project <manumanumanu>amz3`: I didn't use those, but what I threw together works the same <amz3`>dsmith-work: tx for bringing back sneek :) <dsmith-work>When we lose power, it doesn't seem to come up as automatically as it used to. <civodul>dustyweb: OpenPGP certs is also one of the things that drove me to GnuTLS back in the day <dustyweb>civodul: support for them? or frustration with them? <civodul>i was convinced by nmav's motivation <dustyweb>dammmmmmmmmn the world of encoding keys is hella complex <dustyweb>I was like, how hard could this be, it's just base64 encoded text right <dustyweb>makes me also feel even stronger empathy for rivest's canonical s-exps <stis_>yeah, I think I got my python loop macro to work. No you can use python generators in your loop and not litter the copde with set! which was the target <stis_>e.g. if you loop inside scheme that is <roelj>I get a "ERROR: Wrong type (expecting exact integer): #\\a", even though the C function that handles this uses scm_to_char (...), and not scm_to_int32_t (...).