IRC channel logs
2017-04-06.log
back to list of logs
<hezzob>hi.. noob question.. how do you set the search path for the (load "file.scm") command? i've tried (add-to-load-path "./dir") and setting environment variable GUILE_LOAD_PATH="./dir", but in both cases the path is not searched for file.scm <hezzob>still using Guile 2.0 if that changes anything. <davexunit>hezzob: the load path is for finding modules, it's not used for 'load' <davexunit>load is very simple, it just evaluates the scheme file you pass in <davexunit>if you use a relative file name, it's relative to the current working directory <hezzob>daveexunit, that's weird, because i'm loading someone elses library, and it itself uses "load" for further files and fails even if i give the full path to my "load" <hezzob>okay.. i think it is meant to be a cross-scheme library.. it has load instructions for chicken and a bunch of others too.. so i dunno.. <hezzob>of course the first thing i ever try with guile is more complex than hello world ;-) <hezzob>on another note.. how do i squelch all the auto-compile messages? <davexunit>you probably want to compile those things in advance. <davexunit>guile can handle libraries that use the portable r6rs style module definitions <davexunit>but it sounds like you are using code that is doing odd things <davexunit>things that might not be compatible with guile at all <hezzob>davexunit, yeah, i just used the first lib from github that I googled for. A bit too wild a swing apparently. I'll step back and take a few baby steps. <manumanumanu>So... if I run, "chez test.scm -- --argument 1" shouldn't anything after -- be passed as commandline args to test.scm? <davexunit>wingo: I'm still having some allocation problems after switching to u32vectors because I have a loop counter that can't be proven to be in the u64 range so it gets boxed. <davexunit>I have a u32vector of indices pointing to elements of an f32vector and I loop over the u32vector elements using a counter 'i'. I thought about using a u32 or u64vector of a single element to store the loop counter in, but that will just introduce boxing when I go to increment it. <davexunit>I feel like I might be up a creek at this point. <ArneBab_>how come that string-append is so fast? it seems to be factor 20 faster than vector-append and factor 100 faster than append. <taylan>'append' being slower than the others makes sense as it has to copy potentially many small spread apart objects, but I'd have thought string-append and vector-append to be roughly the same speed... <taylan>ArneBab_: is this vector-append from SRFI 43? <taylan>because that's implemented in Scheme, whereas string-append is written in C <lloda>but it's just a shell, it still uses C functions internally, vector-move-left! is C <lloda>probably string-append! uses memcpy etc while vector-move-left! goes index by index or some such <lloda>I mean there's fast and slow C <lloda>libguile/vectors.c still deals with vectors as if they were general arrays, but in 2.2, they aren't. So all those routines could be sped up. <paroneayea>a new blogpost about the "language" I've been working on for genetic programming <paroneayea>"Gush: A stack based language eventually for genetic programming" <daviid>i did not know/remember that nongnu projects can't define a bug-...@nongnu.org mailing list, so no debbug 'facility' for nongnu I guess <civodul`>paroneayea: looks fun, reminds me of my HP48! ;-) <paroneayea>civodul: you're right, both of them are reverse polish notation using a stack <paroneayea>I became familiar with that initially thanks to Emacs Calc <paroneayea>(Emacs Calc is super great, though I think probably baffles most newcomers who were expecting a "regular" calculator... sure baffled me)