<davexunit>I don't have it on my machine, for instance. <davexunit>mgsk: does 'find /usr/lib -name "libGLU*.so"' return anything? ***linas_ is now known as linas
<LRz-Qphallic>So if you import some module and prefix all its bindings with foo: but also import srfi-88 (the keyword one) it basically then parses the (prefix (whatever) whatever:) as a keyword and throws an error. <wingo>LRz-Qphallic: good question... <wingo>it's consistent, somehow, but it's kinda crappy <LRz-Qphallic>wingo, well, is there a way to force verbatim symbols in the reader <LRz-Qphallic>I think racket has something like |3| to force 3 to be a symbol <wingo>LRz-Qphallic: yes; see "symbol read syntax" in the manual <LRz-Qphallic>wingo, another thing though, do you know how to add your own implementation of an srfi so that [srfi :number] can import it. <LRz-Qphallic>I have all my scheme libraries in ~/Documents/libs/Scheme and I'm not sure under what filename I should place it there for that ayntax to work <LRz-Qphallic>~/documents/libs/Scheme/srfi/srfi-number.scm does not seem to work <LRz-Qphallic>(also note these are written in the R6 library format, not guile's own one. <wingo>LRz-Qphallic: i think that what you have should work; probably if guile has one it is getting found first tho <wingo>guile's paths generally come first <wingo>you can override using GUILE_SYSTEM_LOAD_PATH <wingo>see the manual about library search orders (search for GUILE_LOAD_PATH and friends) <LRz-Qphallic>wingo, well, the srfi is not in the system path, that's why I made it myself. But it doesn't seem to find it at all, it says there's no code for that module. <LRz-Qphallic>I gather that if you type [srfi :n] what it searches for is srfi/srfi-n.scm right? <wingo>but if guile has a srfi/srfi-n.scm it might find guile's version first <wingo>or are you making a srfi version that guile doesn't have? <LRz-Qphallic>wingo, well it says 'ERROR: no code for module (srfi srfi-89) <LRz-Qphallic>I'm fairly certain that ~/Documents/libs/Scheme is in the GUILE_LOAD_ATH and that therein is a file srfi/srfi-89.scm <wingo>check the run-time %load-path ? <wingo>the scheme variable named %load-path <LRz-Qphallic>Well, the Documents/lib/Scheme folder is in the load-path and the srfi really isn't in any of the other ones. <LRz-Qphallic>It just says the srfi doesn't exist at all, it can't seem to find it at ~/Document/lib/Scheme/srfi/srfi-89.scm <LRz-Qphallic>Are you sure that's the path it's looking for with [srfi :89] as import? <LRz-Qphallic>wingo, in case you're wondering, changing [library [srfi :89] ....] to [library [srfi srfi-88. ...] fixed it and allowed it to be imported as [srfi :89] <LRz-Qphallic>wingo, well, it sort of makes sense doesn't it. All the [srfi :n] syntax is is a translation to [srfi srfi-n] <LRz-Qphallic>So I guess from the other end the library still wants to be called [srfi srfi-n] <wingo>ah, i guess that makes sense <wingo>probably that's a bug in guile then <wingo>we should read a name like [srfi :89] in a library form as meaning [srfi srfi-89] <wingo>can you send a mail to bug-guile with this information? <LRz-Qphallic>Truth be told, I can't speak, there's a small flaw in my implementation, it rejects (define* (f x (y 3) z)) <LRz-Qphallic>wingo, would you happen to know a debug function that basically applies the standard macro transformer on syntax objects? <wingo>LRz-Qphallic: macroexpand; but it's global, not lexical <wingo>that's usually not something you want to call :) <wingo>also it doesn't expand to syntax objects; anyway see the manual for more details <LRz-Qphallic>wingo, yeah, I know, I need something which translates syntax objects to syntax objects <LRz-Qphallic>I assume it's in there some-where since the intenral macro expander calls it. ***sneek_ is now known as sneek