<ijp>first half of a macro-by-example for elisp <ijp>other half will appear later today <artyom-poptsov>sneek: tell civodul Yes, my FTP server was down due to a NAT problem. Should be fixed now. BTW, thanks for pointing that out. <sneek>civodul, artyom-poptsov says: Yes, my FTP server was down due to a NAT problem. Should be fixed now. BTW, thanks for pointing that out. <nalaginrut>davexunit: what's the issue you mentioned? could you elaborate it? <ijp>bot abuse is serious business <artyom-poptsov>sneek: later tell civodul Yes, my FTP server was down due to a NAT problem. Should be fixed now. BTW, thanks for pointing that out. <nalaginrut>sneek is triggered by talking rather than knocking, so I should leave a message to davexunit, although he's online...so that he can see the message once he say a word... <nalaginrut>sneek: later tell davexunit could you elaborate the issue you mentioned about Artanis? <artyom-poptsov>Not only sneek, gnunet_bot too (although gnunet_bot seems to be not a very talkative person) <taylanub>when `error' puts me in the debugger, can I access its arguments? <taylanub>that displays them again, indicating that they're probably saved somewhere... <taylanub>(unless it just saved the display string) *taylanub looks into the REPL code <taylanub>well not "needlessly" -- it would need some convenience wrappers I guess <ArneBab>mark_weaver: I was in a small spanish village for 3 weeks. I remembered your comment that you would implement wisp differently: using the reader. This is the result: http://draketo.de/proj/wisp/wisp-scheme.html — almost halved number of lines of code, cleanly separated into whitespace parsing and indentation processing and generally much easier to reason about. Likely also actually correct ☺ In short: Thank you! <mark_weaver>ArneBab: cool! fwiw, I would recommend looking for a bare '.' yourself rather than having Guile's core 'read' read it. the problem with the latter approach is that it means you can't distinguish between a bare '.' and the quoted symbol |.| <mark_weaver>you already have to handle whitespace yourself, so I recommend looking for a bare '.' yourself as well. <mark_weaver>if it turns out that the '.' is the beginning of something else, you can 'unread-char' it and then proceed to guile's core reader. <mark_weaver>(frankly, I consider it a bug that (call-with-input-string "." read) returns |.|) <ArneBab>(call-with-input-string "#{.}#" read) does not return #{.}# by the way, but rather escape chars for #{ and } inside #{}#. <taylanub>probably #{}# should be deprecated in favor of ||, no? <ArneBab>(I also want to change it such that (. 1) no longer errors out from wisp. <ArneBab>because that’s actually valid syntax <mark_weaver>ArneBab: hmm. on my system, (call-with-input-string "#{.}#" read) => #{.}# (or |.| as it prints if the r7rs-symbols print option is enabled, which I now do in my .guile) <ArneBab>then I’ll *have to* fix it before the next guile release. <ArneBab>hm… it now does the same… I wonder how I got the other result? <mark_weaver>taylanub: there are backward compatibility issues, but fwiw in my .guile I enable the r7rs-symbols read and print options, so I generally agree. <ArneBab>I got #{\\escapechar\\escapechar.\\escapechar\\escapechar}# <mark_weaver>the problem is that there is existing guile code that assumes that | is a valid symbol character. <ArneBab>ok, so that’s clearly a wisp-bug. Thanks! <ArneBab>I’ll still have to use some temporary placeholder to rewrite the lists later, but it should then also be more compatible with other implementations. <ArneBab>the match-solution which DerGuteMoritz and nalaginrut suggested yesterday is awesome, by the way. <ArneBab>9 lines to solve a problem which took me hours to partially figure out on paper <mark_weaver>hmm, but doesn't that match solution presume that you are using 'read' and then seeing if it returned |.| ? <mark_weaver>btw, I should mention that (. 1) is not standard scheme syntax. it is a guile extension, and I'm not sure whether it was intentional or just an accident of how the reader is implemented. <mark_weaver>(not that I have any strong aversion to allowing it) <ArneBab>mario-goulart: yes, but I can change the match solution to check for other things, too. I could use any special symbol as placeholder. <ArneBab>mario-goulart: sorry, that was intended for mark_weaver (auto-complete got me) <sbidin`>Can I re-export all identifiers from a module? <civodul>there's no declarative way to do that, though <civodul>so you have to iterate over all the variables, using 'module-for-each' & co. <taylanub>the library system extensions proposal for R7RS-large seems pretty good; it has that feature <ijp>macro-by-example for elisp (needs cleanup) <taylanub>civodul: nope, it actually didn't. have to painfully list all the reexports under the one exports clause. even R7RS-small is a little better in that regard where one can at least `include-library-declarations' to yank in a list of identifiers from a standalone file (then the original library and the reexporting library can both just include that file) <davexunit>taylanub: you can't use the re-export procedure? <taylanub>civodul: nope, it actually didn't. have to painfully list all the reexports under the one exports clause. even R7RS-small is a little better in that regard where one can at least `include-library-declarations' to yank in a list of identifiers from a standalone file (then the original library and the reexporting library can both just include that file) <civodul>taylanub: oh ok, i thought R6 had something along those lines but no <civodul>glad R7 actually improves things ;-) <davexunit>taylanub: oh you don't want to use guile-specific things, got it. <taylanub>I keep sayin', R7 is not as bad as you make it out to be :P <davexunit>is it possible to use guile's http-get procedure with an https url? <davexunit>oh, cool. glad there's a library already available. thanks. <nalaginrut>guile-gnutls could do it too, but curl is easier <nalaginrut>davexunit: btw, can you elaborate the issue you mentioned about Artanis? <davexunit>nalaginrut: I used to do a bunch of rails stuff. rails did this content negotiation thing where, bsed upon the file extension given for a route (e.g. '/foo.json') it would know what format to use when rendering a response. <nalaginrut>there're many changes in wip-sql-mapping branch, it's better than master <davexunit>nalaginrut: I've been playing around with destructuring URIs into lists that can be pattern matched <davexunit>so you can have a route like ((GET "package" name) (render-json (find-package name))) <davexunit>let's say that for this route I want to be able to respond with JSON or HTML depending on what the user asks for. <davexunit>if they request /package/foo.html, they get html <davexunit>if they request /package/foo.json, they get json <davexunit>I could then have a macro like: (render response-format (json ...) (html ...)) <nalaginrut>oh, I think you need a better handle for bindings in route-rule <davexunit>rather than using that :foo syntax, I opted to build a list from the url components and pattern match <nalaginrut>I think you want to hide the details while fetching json files, right? <davexunit>I have a solution figured out, I was just curious if artanis already did it. :) <nalaginrut>ok, l thought (get "/package/foo.:format" ...) can work, let me try <nalaginrut>then you can use (params rc "format") to get the file format <davexunit>I guess really you'd want "/package/:name.:format", though <taylanub>sneek: later tell mark_weaver I remember you mentioning a psyntax rewrite; are there plans on what it will and won't support? I think immutable/sealed modules and the ability to "static import" them could be a huge help for performance-critical code. Shiro Kawai mentioned Gauche will be doing the same, which is otherwise like Guile in "all toplevels mutable"; I think it's the right solution. <davexunit>where do the guile bindings for gnutls get installed? <davexunit>I have gnutls installed on my system, and the guile bindings allegedly come with it. <davexunit>oh, debian has separated that into a separate package. <yngccc>hello... how do I export (define-record-type ...) in guile without export each setter getter manually? <ijp>there is no such form <ijp>it's not quite a trivial define-syntax-rule because of the nesting, but it is a very simple macro <ijp>(define-syntax-rule (define-public-record-type type (constructor fields ...) predicate (fieldname field-procs ...) ...) (begin (define-record-type type (constructor fields ...) predicate (fieldname field-procs ...)) (export type constructor predicate) (export field procs ...) ...)) <ijp>not tested, but I think it should cover it <ijp>s/field procs/fieldprocs/ <yngccc>ijp: ty, I will try it out, macro still new to me. <nalaginrut>because *.html is handled in the server-init, so html doesn't work for the case <ijp>yngccc: well, if you indent it properly, it should hopefully be self explanatory <nalaginrut>I'll write a helper function to let users choose what kind of file is handled by static file emitter in default <nalaginrut>davexunit: you have to use "/package/:name\\\\.:format" <ijp>backslash passing style ***jjmarin_ is now known as jjmarin
<davexunit>does anyone have recommendations for the best way to get guile bindings for gnutls to work? <davexunit>I installed the guile-gnutls package on a trisquel 6 machine. when I included the (gnutls) module from a guile 2.0.11 REPL it segfaulted. ***karswell` is now known as karswell