<erkin>Why doesn't guile respect the use-modules I put in ~/.guile? <erkin>It recognises the file inclusion and read/print option toggles but the modules don't get imported. <erkin>If the module imports get discarded after the file is loaded (so that eg (ice-9 readline) procedures don't clutter the repl), then how can I automatically import a module at startup? <dsmith>erkin: For an interactive session? <erkin>I've got a preamble file containing a bunch of quality-of-life macros. <dsmith>Hmm. I was going to mention that .guile isn't loaded for scripts, but that's not your issue. <dsmith>It sure would be nice to be able to tone down the compiler chattiness a bit. <daviid>erkin: are you sure? i use that feature, and it seems to work fine here <erkin>~/.guile contains (use-modules (mine)), preceded by the inclusion of its file. <erkin>,import doesn't list (mine) and sure enough I can't call anything exported from it. <erkin>But I can (use-modules (mine)) in the repl, meaning the file inclusion was successful. <daviid>erkin: not sure i unerstand 'preceeded by the inclusion', but here, i do <erkin>(include-from-path "/home/erkin/src/mine.sls") (use-modules (mine)) <daviid>erkin: i think the include should go in your mine module <erkin>But the mine module is the file that's getting included. <erkin>mine.sls contains (define-module (mine) ...) <daviid>anyway, i use that feature all the time and it works as expected <erkin>I'm trying to import (mine) into the interactive repl at startup. <daviid>erkin: then just do (use-modules (mine)) <erkin>No I want to import it automatically, without having to type use-modules in the repl every single time. <daviid>the (use-modules (mine)) from goes into your .guile file <erkin>It's there, but it doesn't get loaded at startup. <erkin>But I want it to get loaded at startup. <erkin>How will it know where the mine module is then? <daviid>you just need (use-modules (mine)) <erkin>Well "no code for module (mine)" <daviid>erkin: ok, that is because you miss the path and must add it <daviid>can do that in your .guile file as well <erkin>I assume include-from-path isn't the canonical way to do it then. <daviid>(add-to-load-path "the path of the ine module") <daviid>it has a totally different objective <erkin>Still "no code for module (mine)" <erkin>With (add-to-load-path "/home/erkin/src/guile.sls") <daviid>until the path of the mine module is there, guile won't find it <erkin>Oh it needs a folder, not a file. <erkin>I guess I need to put it in an empty folder then. <daviid>the parent mine dir must be i the load path <daviid>what is the full pathname of your mine module? <erkin>Okay, I made a specific folder for it. <str1ngs>hello wingo I have a small patch for guile-cairo. the patch adds a new procedure cairo-pointer->scm . this converts a SCM pointer with the value cairo_t to guile cairo SCM . mainly it's for use with g-golf. here is my proposed patch http://paste.debian.net/1127061. and this a g-golf use case http://paste.debian.net/1127062. if this is useful let me know and I'll mail to guile-user . <sneek>I last saw unknown_lamer on Jan 16 at 03:34 pm UTC, saying: basically working is a start after ten years of gathering dust :). <unknown_lamer>dsmith: hey, just been busy for a few days (work week is basically impossible for me to hack :-\), got your email and I'll merge it in at some point in the next few days <dsmith>unknown_lamer: I understand! btw, got some more changes too. <manumanumanu>Finally I have gotten myself into a problem with macro hygiene! <manumanumanu>it took 3 years of trying my hardest, but now I guess I'll have to concede at least one event to all those whining CLers. <ZombieChicken>there are arguments for both approaches, it's just one is less likely to shoot you in the foot <manumanumanu>Oh, I know, but now I have ended up with (let-syntax ((a (identifier-syntax (next-iter)))) (cons b a)) where I for the love of me can't get both "a" to be the same ones. <manumanumanu>the macro expands to about 40 lines of code generated and copied from all over the place <manumanumanu>It is the result of a macro generating a local let-syntax that gets the macro transformer from a procedure, so the different "a" are the same from the beginning, but not in the end. <manumanumanu>In racket I could use (syntax-local-introduce), but that is based on the scope theory of macro hygiene, so it isn't available. <manumanumanu>anyway, with gratious use of syntax->datum->syntax I can make it work, but that is icky. <ZombieChicken>manumanumanu: Might look at how Racket does it's thing and see if it's portable. You never know. <manumanumanu>ZombieChicken: it is not. I am pretty certain. syntax-local-introduce is quite tethered to macros as sets of scopes iirc. <ZombieChicken>Might fire off an email to the mailing list and see if some dev might think about picking it up <manumanumanu>ZombieChicken: I managed to make it work, but it aint pretty :) I managed to do it while being only moderately bad. I will have to think about this for some time though. I would love to not have to use datum->syntax, especially since I am doing it on an identifier passed to me by the user. <manumanumanu>my for loops now support non-tail-recursive (as in: you can build arbitrary long conses) loops, that way I can express for/list (working like built-in map) and for/stream without resorting to manually writing weird syntax. <manumanumanu>(for/list ((a (in-range 10))) a) becomes equivilent to (cons 0 (cons 1 (cons 2 (cons ... although through loops. <manumanumanu>expressed as a right fold, which now also has general support for lazy expansion. <mwette>manumanumanu: I've had issues with syntax calling syntax years ago. At that time, one of the developers thought it might be related to some modifications of psyntax in the Guile implementation to deal with identifier scope. <manumanumanu>mwette: that was not the case now. I was introducing syntax like this: (let-syntax ((my-internal-recur (procedure-returning-a-syntax-transformer (list (syntax id) ...)))) (stuff)).. Had I just defined procedure-returning-a-syntax-transformer as a macro directly I believe syntax information would have been intact. <manumanumanu>these are probably the hairiest macros I have ever made. something like 500 lines <jcowan>500 lines of macros makes a compiler <manumanumanu>I just finished porting a subset of racket's for/foldr which can be used to express not-TCO'd loops. That added a lot of complexity. <manumanumanu>jcowan: it is actually not that bad. Most of it is just syntactic versions of for/fold, which are added for comfort. <jcowan>every macro is to some degree a compiler <manumanumanu>I just watched the "inside racket: pattern matcher". I want to implement that for r6rs (or at least in easily portable guile). <manumanumanu>andy has a quote somewhere on the blog that every scheme programmer want't to be a compiler writer :D <jcowan>Not all. Some think that Lisp has been ruined for the sake of compiler writers and that its True Nature is expressible only in an interpreter. <jcowan>At the beginning of the R7RS-small process there was a bunch of noise about how fexprs should be standardized, even though humans can barely understand them, never mind compilers <str1ngs>does the F mean what I think it means? :P <jcowan>Because fexprs are first-class, a compiler can't optimize (foo (+ 1 2)) to (foo 3), because (+ 1 2) might be unevaluated data <jcowan>My best guess is that the F in fexpr stands for "special Form", as that's what it is for, defining new first-class special forms. Neither CL nor Scheme allows this. <dustyweb>ok I just also sent this to guile-user but <dustyweb>it was really easy to build zkeme80, was surprised <nckx>Someone's TI-84+ is going to go mysteriously missing after she's finished her exams. ***catonano_ is now known as catonano
***apteryx_ is now known as apteryx
<stis>Well, got python-on-guile and guile-log to run on guile-3.0 <ArneBab_>stis: does that mean you could run benchmarks vs. CPython? :-) <stis>PLease do try, but don't expect it to be fast. I've concentrated on good interoperability and semantics <stis>Some interations can be faster though if you produce some simple tal call function <stis>(and don't blow the stack) <ArneBab_>doesn’t the stack expand automatically in Guile 3? <stis>yes, but you may run out of memory still if you so sommething 10billion times and the allocation overhead will be high <stis>I think people there is trying to use it, so most likly there will be a version. probably not for guile-3.0 <ArneBab_>that’s always the danger when the distro uses the language you use: The distro must always stay working, so it’s likely that it’s a bit conservative with changing the language version. <ArneBab_>Though in guix that’s not as dangerous as in other distros, because users can have different versions than the system (and still be distro-managed). <ArneBab_>yes, but it took me a long time to switch to Guix, and now I have quite a few hacks to get it usable for work <ArneBab_>Stuff like calling a separately installed maven as LD_LIBRARY_PATH=$HOME/.guix-profile/lib mvn <stis>do not use it myself though ***drakonis1 is now known as drakonis