IRC channel logs


back to list of logs

<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>mark_weaver: oh, whoops
<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
<mark_weaver>*if we can 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>html format
<ozzloy>other than opening up the html and adding a <video> tag
<wingo>janneke: good morning :)
<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>wingo: hi!
<janneke>thanks for looking, let me know if I can help
<wingo>are you able to test the patches?
<janneke>yes, sure
<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
<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...
<janneke>reading your patch now
<wingo>yeah we don't do c99 unfortunately
<wingo>maybe we can use c99 now
<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?
<janneke>ACTION is building now
<wingo>janneke: i don't know. some of the patch is specific to the 2.2 series
<janneke>yes, i had that problem too
<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>with this patch in it too ;-)
<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>oh dear
<wingo>that's not good
<janneke>it's still running...
<janneke>eval.go file exists on disk
<janneke>ACTION goes afk for 15min or so
<wingo>janneke: i think you need to make clean then :/ if eval.go isn't loading up, your bootstrap will not go well
<wingo>maybe it is ok tho
<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>wingo: works fine!
<janneke>wingo: just one comment...
<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?
<galex-713>How do you do debugging with guile/geiser?
<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 :/
<janneke>i'm not sure
<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 agree
<janneke>i think ludo said the idea was nice, but too late
<wingo>well he said that but provided no reasons :)
<janneke>in that case...
<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>same for the other paths
<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
<janneke>no, same mess under debian
<wingo>why does the same mess exist in debian? :)
<wingo>ACTION genuinely curious
<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>because they are versioned
<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.
<janneke>ugh :-(
<wingo>ACTION out for a walk, biab
<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)
<civodul>i'm no expert though ;-)
<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?
<wingo>i want to release
<janneke>i built master on 64bit this afternoon...
<galex-713>wingo: me
<galex-713>As I said, thank you, it works here :p
<wingo>galex-713: tx for the report :)
<wingo>galex-713: you are on a 32-bit system right? :)
<holomorph>r-r-release? :3
<galex-713>Thinkpad X60T
<wingo>ACTION nod
<wingo>i wonder what is going on with
<galex-713>The first supported by libreboot \\o/ (and last one without ME)
<galex-713>What’s hydra ?
<wingo>it's a sort of continuous integration server
<wingo>that one builds guile any time it changes
<galex-713>ah ok
<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>Ah yeah right, guix has its own channel
<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>ok I see
<galex-713>pretty cool :)
<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.
<ewanas>I'm running configure this way
<ijp>wingo: I suspect that simple bootstrapping will be our guide on this issue
<wingo>i think i can discard because the backtrace indicates that there's an already-compiled .go files already
<wingo>ijp: indeed
<ewanas>Can anyone tell me what I'm missing?
<wingo>likewise i can discard
<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
<janneke>ewanas: what error do you get?
<ewanas>the last four lines:
<ewanas>checking whether to build shared libraries... yes
<ewanas>checking whether to build static libraries... yes
<ewanas>checking for libltdl... no
<ewanas>configure: error: GNU libltdl (Libtool) not found, see README.
<ewanas>sorry for the direct paste
<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
<janneke>ewanas: no
<ewanas>no, just static version
<ewanas>I actually *just* want to build guile for static linkage
<janneke>have you tried to configure with --disable-shared ?
<ewanas>I'll give that a try
<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
<ewanas>yup.. same result :p
<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>maybe i missed it
<wingo>ACTION looks
<wingo>ah tx i missed it
<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
<daviid>1 daviid is enough! :)
<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>that does sound better
<wingo>bah, i hate this path stuff
<janneke>plan 9!
<janneke>ACTION ducks
<wingo>i don't even know what plan 9 is ;)
<galex-713>You don’t know Plan9?
<galex-713>It’s like UNIX++
<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
<wingo>also ccache is a silly name
<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..
<janneke>go/2.2 ?
<daviid>people can make sym links until they slove, and most s/w do not install compiled files so far
<daviid>I's keep ccache for now
<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]
<janneke>ewanas: ok, nice. good luck.
<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 :)
<janneke>wingo: thank you
<wingo>ACTION zzz, night!
<daviid>good night wingo !