<void_pointer>Got a bit of a question. Often, when I resync back to master, one of the Makefile.am's is changed and thus it seems I need to reconfigure and essentially do a make clean, configure, make all over again. This is not directly the issue. The issue is that I have been having trouble figuring out how to speed up the bootstrapping process. I feel like I've heard that one can use an existing guile-2.1.x to do it (say, a previous compilat <void_pointer>figure out if that is true or not, and if it is how to do it. <nalaginrut>ArneBab_: I think I found the reason why it faster than Chez 3s, it could be GC cache(?), each time I enter guile-tjit, it's 15s, but the second time run it without quit, the time in GC saved 3s, always <nalaginrut>maybe a guile-tjit docker image will be better, but I'm not familiar with docker... <ecraven>wingo: on the way, still running.. seems I turned up the timeout to 5 minutes, and a few schemes run into that a lot, so it now takes forever <ecraven>I'll tune it down to 2 minutes for the next run ;) <wingo>i think i have a hack that will give prebuilt binaries to everyone <wingo>i was going to ask people for a bunch of triplets but that's silly <wingo>gosh, getting pretty excited <wingo>wow that gc bug fix fixed fibers scaling!!!! <wingo>with 9 cores, crossing a numa node boundary; starting from 12.5K reqs/s on one core <wingo>5x speedup for 6 cores on same numa node; reliable now too, which it wasn't before <wingo>currently open bug is just goops slot design issue i think <wingo>there are probably some more but that deserves some thought <wingo>i think git is ready to go for 2.2.0. <wingo>i'm sure there are additional platform-specific fixes we will make for a 2.2.1 but i am happy with things as they are. <davexunit>paroneayea: +1 on making a big deal about 2.2 <davexunit>I think this is the release where we can say definitively that Guile is a serious programming language for serious software. <civodul>did you have a chance to look at 'guix pack'? <wingo>civodul: did you see my mail reply? <wingo>i did, just had a couple questions <wingo>basically it looks great and i just wanted to make sure that it was safe for unthinking users :) <wingo>or users without the guix mental model <wingo>civodul: i was thinking maybe we should cut a tarball today or tomorrow, and release it on thursday <civodul>the only question is how we'd distribute the binary tarballs <civodul>whether we need to document it in the manual (prolly not) <wingo>i think probably no need to document in guile manual; i don't even know that we should agree to do it in the future <wingo>much less release for other architectures <wingo>wdyt there? also i guess cuirass in the future should be able to build this <wingo>probably just on-demand tho; dunno <wingo>you wouldn't want to fill disk up with tarballs <wingo>it is a hard question and i don't think you or me want to adopt that puppy right now :) <civodul>so i agree, i think it would be just for 2.2.0 <civodul>and probably just for x86_64 and i686 <davexunit>will it require user namespaces in order to "just work" on most distros? <wingo>it will have /gnu/store/...., the user unpacks as root in / <wingo>i think it won't have /var/guix but i dunno, that's the question <wingo>anyway when you distribute the tarball you also tell users the name of the profile in the store <wingo>not terribly convenient but it doesn't conflict with anything, anyway :) <davexunit>could maybe add /usr/local/bin/guile-2.2 or something? <wingo>yeah i dunno, i guess exposing the profile on /opt/gnu would be ok too <wingo>then if the user installs multiple packages it augments the profile there, or overrides previous links <civodul>BTW, for 728MiB only (uncompressed), we'd have guile + emacs + geiser :-) <wingo>i think i wouldn't mutate /usr/local, or anything in /usr <wingo>i guess this is a use case for that force-directory-creation thing for union-directories :) <ArneBab>ecraven: how do you run both guile-2.0 and guile-2.2? <ArneBab>(in your benchmarks, which I like, by the way :)) <civodul>wingo: BTW could you reinstate dist-lzip? <ecraven>Arnebab: right now by passing proper env vars <ecraven>I'll try to add proper support for guile git later <ArneBab>ecraven: so you create a second benchmark and rename it? <ecraven>Unless it crashes, it should be fine, the scheme implementation names are different, they contain the exact version ***dje__ is now known as xdje
<webshinra>hey guilers, I'm working on integrating guile with an engine of my own, and y have naïve question about loadpath I can't find answer to <webshinra>I'm trying to use guile to do some hight level initialisation stuff, and to do so I'm defining a guile module to represent the high level logic <webshinra>and then call a scheme procedure put inside that module <webshinra>but I can't see how I'm suppose to inform guile that a given directory in my c program data is supposed to be looked at like a module? <webshinra>what would be the recomanded approach to do such a thing? <wingo>see "Environment Variables" in the manual <wingo>for GUILE_LOAD_PATH / GUILE_LOAD_COMPILED_PATH etc <wingo>also search the manual for %load-path / %load-compiled-path <lloda>I do scm_eval_string("(append! %load-path "+ etc + ")") from C... <webshinra>wingo: thank you to, I've allready read that sections, but I have not a really clear idea on «when environement variable are taken account of» by guile <webshinra>(and I didnt thought of calling inline scheme code from c, which seem to be a logical solution if their are not costly downside to it) <wingo>yeah, no downsides to calling scheme <wingo>env variables have to be set before scm_init_guile <wingo>otherwise you can mutate %load-path / %load-compiled-path at run-time <civodul>wingo: how would you get a VM backtrace upon a segfault due to set-car! on a literal pair? :-) <webshinra>hum, do you know how I could import a procedure defined with scm_c_define_gsubr inside a module? <webshinra>when I'm calling it from a (define-module …) file, I qet a «guile: uncaught throw to unbound-variable: (module-lookup Unbound variable: ~S (create-tile) #f)» error <webshinra>but calling it from toplevel (ie from eval_string) it work as expected <webshinra>hum, it seems that the only way is to define subr inside an extention and use load-extension <dsmith-work>Wow. ISTR some C function that called one of it's arguments in the context of a module. <dsmith-work>But I can't remember now. Maybe that has gone away since 1.8 ? <webshinra>this particular function seem to call scheme code from c <webshinra>my goal is to call c code from a scheme module <remi`bd>hey webshinra, you might want to try Guile’s FFI (-> info guile ffi) <dsmith-work>Ah. Yeah, that's usualy what's done with extensions. <dsmith-work>webshinra: Check out examples/box-dynamic-module/ in the guile source tree. <dsmith-work>webshinra: Also take a look at the guile-cairo project. <dsmith-work>webshinra: But the current hotness is to use the ffi instead of a C extension. <dsmith-work>Which is great, because you don't need to leave Scheme. <dsmith-work>But sometimes, you need access to things that are #define'd and #ifdef'ed and it's just plain easier to do it from C. <webshinra>well I'm not sure I can use it in this precise case, but'll keep it in the back of my head <webshinra>(the idea is that scheme interact with a heavely multithreaded context and share state with it) <webshinra>(as far as I know it seem hard map it with ffi, but that's not my speciality) <civodul>wingo: in 2.2, fport_close no longer ignores EBADF <civodul>EBADF handling disappeared in 5a771d5f51