***petercom1and is now known as petercommand
<stis>evening to all other letters as well :) ***haroldwu_ is now known as haroldwu
<davexunit>how does guile's dynamic-link procedure search for libraries on gnu/linux? <davexunit>I have the LIBRARY_PATH env var set, but it doesn't seem to search the directories there. <daviid>davexunit: i perso add path, when necessary, in /etc/ld.so.conf.d/ [i'm on debian] and run ldconfig [as root of course], but i know there are more then 1 way... <davexunit>okay, that's what I thought. I'm using guix and currently having trouble with that method. <mark_weaver>davexunit: LTDL_LIBRARY_PATH is also consulted by libltdl on GNU/Linux. <davexunit>on #guix, civodul suggested that I could use AC_SUBST to get the absolute path to the library at configure time. <mark_weaver>also, iirc, you can pass an absolute pathname to dynamic-link. <mark_weaver>(though with the library extension omitted, I think) <davexunit>mark_weaver: yeah, the issue is determining that absolute path name. need to figure out the autoconf macros to use, I guess. <mark_weaver>davexunit: well, if you use the absolute path method, that would be done by the Guix recipe, I think. <davexunit>mark_weaver: yeah, I've done that sort of patching for guile-opengl <mark_weaver>it's also possible to make calls into libltdl that augment the search path local to that process. <davexunit>however, this is for guix environment. there's no build recipe to run. I want things to work as-is. <mark_weaver>ah, okay. LTDL_LIBRARY_PATH sounds like a good solution here then :) <davexunit>yes, I think I will use that. thanks a lot. augmenting LD_LIBRARY_PATH was causing a segfault. <mark_weaver>sethalves, taylanub: it's a shame that R7RS doesn't have a reader directive #!r7rs analogous to #!r6rs which is present in R6RS. it would allow me to put the reader into an R7RS-compliant mode when reading R7RS source files. <cky>mark_weaver: Hey, what do you think of the idea of adding a (srfi srfi-28) module? It'd basically be: (define (format format-string . args) (apply simple-format #f format-string args)). <cky>(or even (define format (cut simple-format #f <> <...>)) if we're willing to have a srfi-26 dependency) <taylanub>mark_weaver: the .sld file extension might be useful for that, though it won't be useful for R7RS programs (as opposed to libraries) <mark_weaver>cky: sure, sounds good. it's not worth depending on srfi-26 for this. you should use #:replace instead of #:export when exporting it. also, put (cond-expand-provide (current-module) '(srfi-26)) in the module. would you like to post a porposed patch to guile-devel? <taylanub>mark_weaver: for programs, testing ARGV[0] = "scheme" might be a good idea, so if the user uses a symlink named "scheme" to launch Guile, it operates in R7RS mode (e.g. executing the file in ARGV[1] as an R7RS program) <mark_weaver>taylanub: unfortunately, adding support for more file extensions will slow down our module lookup mechanism, the way its currently implemented. <cky>mark_weaver: I can do so later today, if I find the time. I'm about to have some house stuff to move around. :-) <mark_weaver>taylanub: for R7RS programs/REPL, I would rather add a command-line argument. <taylanub>mark_weaver: searching for .sld could be limited for R7RS import declarations perhaps? <mark_weaver>that would be intolerably ugly to implement, because the module loading is done at a low level in the system, and 'import' is just a macro. <mark_weaver>it's a drag that the R7RS folks were so intent on pretending R6RS didn't exist :-( <taylanub>well, I recently noticed that the R7RS library syntax is essentially SRFI-7, just with clearer identifiers. the situation with R6/7RS is sad indeed, but R7RS at least returned to making good use of existing SRFIs <mark_weaver>there's also the fact that you should be able to manually open a file and 'read' from it. the #!r6rs solution allows that kind of thing to work, whereas making assumptions about filenames and putting the reader into a different mode based on the name doesn't. <mark_weaver>still, you may be right that it's the best solution available to us. <mark_weaver>maybe it's time for me to rewrite the module searching code to read the directories instead of trying 'stat' for every dir/ext combination. <taylanub>other than that I can imagine testing whether the first form in a file is either of (import ...) or (define-library ...), since a program must start with the former (else there are *no* bindings in the program's environment), and a library with the latter. <taylanub>but that's probably a bad idea; if the next standard allows either to start with something else... <mark_weaver>I suppose we'll need to do the file extension thing to support non-scheme modules anyway. <taylanub>hm, I think it's a little unfair to say that R7RS ignored R6RS. they certainly prioritized SRFIs over R6RS (in response to R6RS getting criticized for ignoring SRFIs), but otherwise useful things were taken from R6RS insofar they were in the scope of R7RS-small at all <mark_weaver>R7RS is gratuitously incompatible with R6RS. It would have been easy to make it *possible* to write a simple library that's a subset of both R6RS and R7RS. <mark_weaver>R6RS libraries, or at least a subset thereof, were certainly in the scope of R7RS-small. <mark_weaver>instead, we have a situation where every library author has to choose between the two. <mark_weaver>I can understand that there were some things about R6RS that they didn't like. they could have removed some controversial things without making it impossible to write even the simplest library that works with both. <mark_weaver>and I don't buy the claim thta R7RS was so respectful of SRFIs either. Take a look at SRFI-45. R7RS took the exact semantics of SRFI-45, but decided to rename two of its identifiers. Why? <mark_weaver>the (scheme lazy) module is *identical* to SRFI-45 except that 'eager' is called 'make-promise' and 'lazy' is called 'delay-force' (a misleading name). <mark_weaver>other examples: R7RS 'vector-map' and 'vector-for-each' are incompatible with procedures of the same names from SRFI-43. R7RS 'string-map' and 'string-for-each' are incompatible with SRFI-13. <mark_weaver>in those cases at least, I can understand why they did it, but if you're going to criticize R6RS for not always following the applicable SRFIs, it should be noted that R7RS did the same. <taylanub>I wasn't aware of all of those differences :( <mark_weaver>So, the R7RS folks made it impossible to write code that works with both R6RS and R7RS. Every code author must choose between R6RS and R7RS. I've made my choice: R6RS. There are some things I don't like about R6RS, and some things I like better about R7RS, but on the whole I think that R6RS was much more competently designed. <davexunit>as an outsider, the scheme standards process seems awful. *davexunit wants to write a sexp -> sql macro <mark_weaver>davexunit: why a macro and not a procedure? I'd think that something vaguely analogous to sxml would be nice, but admittedly I haven't looked closely. <davexunit>I was thinking of some sugar to automatically escape unquoted expressions. <mark_weaver>looks nice, although the docs are so minimal that it's hard to say. <daviid>i think there has been better attempts by lispers, if you really want to develop somnething well designed, might be worth searching [but i don't have links to offer right now though, sorry] <davexunit>and it got me interested in what guile has to offer for database things <daviid>guile-sqlite, but in both case [I think] the sql query or sql command is a string, then you call an sql prep [there api...], exec, and receive the results as an array of strings <davexunit>I liked how the above article demonstrated the advantages of not using an ORM <davexunit>rail's ActiveRecord is cool, but it definitely feels limiting at times <mark_weaver>even if sometimes a higher-level interface is desired, I still think we should have a lower-level layer that represents SQL queries as S-expressions, like sxml. <mark_weaver>then we could (optionally) build something on top of that.