<kori>mark_weaver: if you haven't seen the msg, I got guix to work <kori>not sure what changed, except I didn't include xmonad when installing now <mark_weaver>kori: I'm glad to hear it. this is #guile, not #guix, though :) <mark_weaver>I would be *very* surprised if the presence of 'xmonad' in packages would have interfered with the early boot. probably something else was different. <kori>my current irc configuration got me confused <mejja>LLP64 more or less equates Mickey Soft, right? <mark_weaver>mejja: 64-bit Windows is the only system I know of that uses the LLP64 data model <mark_weaver>but on the other hand, it would be good to avoid writing code that makes non-portable assumptions if we avoid it <taylan>aren't such things usually resolved by using preprocessor macros for types? so there would be e.g. SCM_LONG and it would expand to 'long' or 'long long' depending on the platform <ozzloy>is there a way to add an ogv to skribilo generated doc? <ozzloy>other than opening up the html and adding a <video> tag <wingo>i was looking at your skip-invalid-go-files patch <wingo>i want to implement it in a different way if you do not mind <janneke>thanks for looking, let me know if I can help <wingo>are you able to test the patches? <janneke>it's nice to let me know you are rewriting/reimplementing <wingo>np, sorry for taking so long <janneke>of course i'm fine with that, i very much trust you know what you're doing :) <wingo>i just pushed my patch to master <wingo>would you mind pulling and testing? <janneke>i was a bit frustrated with that, until i pulled guile master since march and read what you've been doing...wow <wingo>yeah your patch was good and most importantly it addressed the issue ;) but i have to spend more time in this code and the complexity is daunting to me, i really wanted to avoid extra branches in loader.c <janneke>it seemed to me that much of this code hasn't been touched since before c99 and i was unsure what to do with all that... <wingo>yeah we don't do c99 unfortunately <madsy_>mark_weaver: Thanks! I'll test the patch as soon as possible <janneke>wingo: do you intend to backport this to stable-2.0 too? <wingo>janneke: i don't know. some of the patch is specific to the 2.2 series <wingo>someone certainly should! the reason i wanted to reimplement is because the loader is part of code i work with all the time and i have many feels about it ;) but for 2.0 i don't care as much. (of course it's important! but i don't have strong feelings.) <janneke>i'm not sure if it's "needed", i would be able to use 2.0 and 2.2 nicely alongside each other <wingo>i think ideally we would have had a 2.0.12 release many moons ago <wingo>but i am doing 2.2 and don't have much bandwidth for 2.0, and civodul and mark_weaver seem to be on guix right now... <janneke>wingo: while building now I get (didn't clean my tree since last 2.2 build) <janneke> BOOTSTRAP GUILEC ice-9/psyntax-pp.go <janneke>;;; WARNING: loading compiled file /home/janneke/src/guile/build/module/ice-9/eval.go failed: <janneke>;;; Throw to key system-error with args ("load-thunk-from-memory" "~A" ("No such file or directory") (2)) <wingo>janneke: i think you need to make clean then :/ if eval.go isn't loading up, your bootstrap will not go well <wingo>manybe the eval.go from bootstrap/ will be loaded <wingo>since that error was from module/ <wingo>but the error is strange, i don't see how load-thunk-from-memory would be called there ***Mayor_Adam_West is now known as Mayor_Stanislav_
<janneke>wingo: after make clean now warning-free past psyntax-pp.go ***heroux_ is now known as heroux
<janneke>when i prepend the 2.0 ccache to GUILE_LOAD_COMPILED_PATH, ie: <janneke>export GUILE_LOAD_COMPILED_PATH=/run/current-system/profile/lib/guile/2.0/ccache:$HOME/pkg/lib/guile/2.2/ccache/ <janneke>warning messages are printed for each 2.0 .go file: <janneke>;;; note: source file /home/janneke/pkg/share/guile/2.2/ice-9/r5rs.scm <janneke>;;; newer than compiled /run/current-system/profile/lib/guile/2.0/ccache/ice-9/r5rs.go <janneke>;;; found fresh compiled file at /home/janneke/pkg/lib/guile/2.2/ccache/ice-9/r5rs.go <alchemizt>is there an eta for when 2.2 will be released? <wingo>janneke: humm, i wonder what to do about that. <wingo>i guess we could remove the warning entirely <janneke>wingo: i'm not sure what the feature of those messages is anyway... <janneke>either that or behind a debug/verbosity flag <wingo>the warnings are there to detect incorrect environments somehow <wingo>they shouldn't print unless something is wrong <wingo>and having multiple ice-9/r5rs.go in your path is wrong in a way <wingo>i guess the 2.0 vs 2.2 thing isn't really something to warn about; dunno. i think having multiple versions in your path is not great -- it increases startup cost for example <janneke>true...but in a 2.0/2.2 you will have multiple say guile-library .go's in GUILE_LOAD_COMPILED_PATH? <wingo>but as you and ludo argue it might be the right thing :/ <wingo>it makes me unhappy though because i want to provide the fastest system possible <wingo>and people want to use it in a way that it will be slow, and then don't want warnings about the fact that it's slower than it could be <janneke>my first attempt at combining 2.0 and 2.2 was to have guile add a /2.2 or /2.0 suffix onto GUILE_LOAD_COMPILED_PATH <janneke>i think ludo said the idea was nice, but too late <wingo>well he said that but provided no reasons :) <wingo>we could for example preferentially take GUILE_2_2_LOAD_COMPILED_PATH if it's there <wingo>instead of GUILE_LOAD_COMPILED_PATH <wingo>and then Guix could have a more tightly trimmed set of compiled paths <janneke>if we would change the layout from /run/current-system/profile/lib/guile/2.0/ccache to /run/current-system/profile/lib/guile/ccache/2.0/ and ccache/2.2 ... <wingo>AFAIU this is essentially a Guix problem, no? <wingo>like, I don't know of other situations where you would have multiple Guile versions in your LOAD_COMPILED_PATH <wingo>why does the same mess exist in debian? :) <janneke>the problem is more prominent in guix, because system tools (guix, ld) use guile, but that seems to be handled now <wingo>you can install guile 2.0 and 2.2 in parallel in /usr and debian will never set GUILE_LOAD_COMPILED_PATH on behalf of the user, AFAIU <wingo>the guile 2.0 and 2.2 have their own internal default paths that are disjoint <janneke>maybe mess is a big word, but if you want guile-2.0 and guile-2.2 in parallel, esp. from one emacs session... ugh <wingo>ACTION pings civodul for thoughts on whether GUILE_2_2_LOAD_COMPILED_PATH would work <wingo>i.e. first try GUILE_2_2_LOAD_COMPILED_PATH and then if it's unset fall back to GUILE_LOAD_COMPILE_PATH <wingo>same with the system load compiled path and the extensions dir <janneke>yes, for system libraries that works, but if you install anything in $HOME that needs a GUILE_LOAD_COMPILE_PATH, you're foobared <janneke>so yes, problem is more prominent with guix <wingo>actually the more i think about it the better (optionally-)versioned paths for compiled files is sounding <wingo>b/c it would also fix the gdb problem (on guix, meta/gdb-uninstalled-guile doesn't work) <wingo>bah, that does not fix the gdb problem. <wingo>the uninstalled environment sets its vars in such a way that the guile that gdb itself uses tries to load boot-9 from guile 2.2; badness. <civodul>wingo: i already wrote about it, but i think there are two solutions to me: 1) GUILE_LOAD_COMPILED_PATH for all Guiles, and skip invalid .go files, 2) GUILE_LOAD_COMPILED_PATH for all Guiles, and append MAJOR.MINOR to each search path entry <civodul>(1) is the least we can do, it's also fairly natural <civodul>(2) is an "optimization", as it reduces the number of stats; it's also a convenience because one could set GUILE_LOAD_COMPILED_PATH=/foo/bar without having to worry which major.minor pair matters <civodul>for GUIX_LOCPATH, we followed (2); same pattern <civodul>i *think* PERL5LIB follows (2), but PYTHONPATH follows (1) <wingo>has anyone made a successful build of guile since the 32-bit fix? <wingo>locally i have done so with a guix env but hydra is reporting errors <wingo>mark_weaver: have you been able to give it a try? <janneke>i built master on 64bit this afternoon... <wingo>galex-713: tx for the report :) <wingo>galex-713: you are on a 32-bit system right? :) <galex-713>The first supported by libreboot \\o/ (and last one without ME) <wingo>it's a sort of continuous integration server <wingo>that one builds guile any time it changes <galex-713>wingo: oh btw, any info of why gnunet p2p share of deterministly built binaries were abandoned? <wingo>galex-713: no idea :) i think that might be a guix thing <galex-713>wingo: and how is native compilation? somewhat far from being implemented or far far far from it? ^^ <wingo>hard to say :) i think native compilation is for next year probably. i need some mental space for that. <galex-713>can’t wait for a GHM2017 talk explaining how guile optimize itself running on metal :D <galex-713>I wonder about something, if maybe that’s already clear to you: when that will be done, will libguile be kept only written in C or will there a rewrite in scheme? <wingo>scheme code will need less and less support from libguile over time. however we still have compatibility obligations <wingo>i don't know how the two will play out. <ewanas>hi all. I'm trying to cross-compile guile for Android and I'm getting complaints about libtool missing. <ijp>wingo: I suspect that simple bootstrapping will be our guide on this issue <ewanas>Can anyone tell me what I'm missing? <wingo>ewanas: i have no time to help right now :/ good luck tho! <ewanas>Thanks for letting me know. I'll stick around just in case someone has cross compiled it before <ewanas>checking whether to build shared libraries... yes <ewanas>checking whether to build static libraries... yes <ewanas>configure: error: GNU libltdl (Libtool) not found, see README. <ewanas>libltdl.a exists in that -L folder I'm providing <ewanas>ACTION trying against master branch. Just an FYI <wingo>you probably would do better against the 2.0.11 tarball fwiw; master is the unstable dev branch <ewanas>I actually *just* want to build guile for static linkage <janneke>have you tried to configure with --disable-shared ? <wingo>civodul: any thoughts re: GUILE_2_2_LOAD_COMPILED_PATH ? <janneke>ACTION ponders what a statically linked dynamic load library actually means <wingo>i can release with or without it <wingo>i think it would solve the guix use case nicely <wingo>though you might want versioned GUILE_LOAD_PATH as well, dunno <wingo>maybe it just confuses things too much :P <wingo>you'll have downstream packages setting GUILE_LOAD_PATH for various things and wondering why it's not working, if GUILE_2_2_LOAD_PATH is also set... <daviid>wingo: did you read the log [yesterday or the day before], civodul answered you I think ... <wingo>civodul: so i implemented the bit where GUILE_LOAD_COMPILED_PATH skips invalid .go files, on master, based on a patch from janneke; but it has downsides <wingo>it throws a stat party, basically, if you have two guiles installed; and it's almost impossible to make it give warnings/messages that are as useful as guile 2.0 gives (re: out of date compiled files for example) <janneke>ewanas: have you looked in config.log, why it's not happy with your libltdl.a? <wingo>because you can see that foo.go is out of date relative to foo.scm, but until you load it, you don't know if it is valid or not; so when do you give a warning? <wingo>those warnings are helpful for making sure your load-path etc are all correct and not bogus, i find; but perhaps i am in a minority <daviid>ACTION daviid crosses his fingers so wingo find some time to look at and fix bug#20093 before next release <janneke>fwiw, i still like what civodul refers to as the 2) option abovev: GUILE_LOAD_COMPILED_PATH for all Guiles, and append <janneke> MAJOR.MINOR to each search path entry <wingo>i don't even know what plan 9 is ;) <galex-713>Applying all the UNIX concepts, but coherently and cleanly and consistently <janneke>and then you shadow-mount any bin directory there <daviid>FWIW, I really do like that solution (2) as well <janneke>most notably your big WORM device, clean-out your local disk every day <daviid>because then you can install scm modules that are compatible with multiple guile versions in share/guile/site, and imo that is what people should do wrt these modules <wingo>maybe that is the thing then <wingo>the problem is that people's build systems will have to change to install the .go files into the /2.2 directory <wingo>i guess we change from VERSION/ccache to ccache/VERSION <daviid>wingo: that's fine I guess, but is it not the case alreay that guile installs in ccache of its verion? <daviid>ah ok, yes, ccache/VERSION sounds even better ino <janneke>yes...i of course would be happy to make such a change, esp. because it already enables using one path setting for both guile-2.0 and 2.2; i have no idea how big the impact is for others <daviid>ye Ive always asked myself why, but then I thought it's just a name.. <daviid>people can make sym links until they slove, and most s/w do not install compiled files so far <wingo>eventually these files will have a ".so" ending <wingo>as they are dynamically-linked ELF shared objects <daviid>for me, just Grip and Gnu Foliot, I can change that very easily, don't for others but g-wrap and guile-gnome do not install compiled files so all go in the user ccache, can't remember about about guile-cairo but i kind of remember it does install compiled file either <daviid>wingo: for all my projects, I use GUILE_SITE_CCACHE set by guile.m4 ... <wingo>well, no release tonight then :/ <ewanas>janneke: I saw it's complaining about ltdl.h I guess that should do it. Thought to let you know. Thanks for the help <daviid>good to remember to make the changes there as well [guile.m4] <mejja>wingo: maybe give her some flowers one in a while <wingo>i guess for compiled files we follow a (2)-like strategy in the future. will need more work. i will pick it up on wednesday or so <mejja>ACTION blames the keyboarddrivers for eating random chars.. <wingo>mejja: sexual jokes are not welcome here; tx in advance :)