<paroneayea>I worked a bit on the guile tutorial while on the plane <paroneayea>mostly just expanded on the basic (non-compound) types <paroneayea>xd1le: np! if you read it and have comments, happy to hear them (with the caveat that I'm mostly in the "writing a draft" rather than worrying too much about editing to nice refactored form right now) <xd1le>paroneayea: nws, i'm completely new to guile/scheme <paroneayea>xd1le: ah, I hope it becomes useful over time for you then! :) <wingo>paroneayea: starting to read your tutorial. looks lovely! <wingo>i also wonder for the nth time if we can turn on readline by default, somehow :P <ArneBab_>wingo: why can’t we do that — it’s just a REPL setting, right? <ArneBab_>so it should not spill into applications which use Guile <wingo>if you would like to make that argument in a careful way and send it to the list, that would be swell :) <wingo>probably you will want to search the archives too for previous discussions <ArneBab_>I just verified that I can simply wrap the call to readline into (catch …) to avoid problems when it’s not available <wingo>ACTION ready for a 2.1.2 release, whenever my guix manages to install texlive :) <wingo>davexunit gave me the tip to build from source and it is going much faster :) <wingo>slowing down package management with pre-built binaries : guix :: slowing down your program with types : gradual typing <civodul>right, each project has its own techniques to achieve slowdowns ;-) <wingo>mmm this prebuilt thing is satisfying <wingo>wtffffff i can't distcheck on guix without setting that damn impure library variable <civodul>and it happens during 'make install' right? <wingo>i have the var set in my /opt/guile/env script for building against local installations <wingo>but didn't realize i needed it in distcheck <wingo>anyway, at least distcheck doesn't take so long now :) <wingo>maybe wait a couple minutes :) <wingo>with the prebuilt files the tarball doubled to 10MB, oh well <wingo>ACTION waits for a report that the tarball builds correctly <taylan>well I can already see how fast it is compared to how it was; eval, psyntax, etc. all done already ^^ <taylan>ooh, guix does the timing for me anyway: phase `build' succeeded after 745.9 seconds <taylan>so yeah, together with configure, it took a little below 15 minutes <taylan>by the way Freenet permanently uses 70%-80% of one of my i5's cores, so that slows things down a bit <taylan>wingo: aaand check phase passed too <taylan>@ build-succeeded /gnu/store/q6x9dnrzllizdqkh07vyr69wybh0pmb1-guile-2.1.1.105-486b3.drv <wingo>i never remember, myself, but it's a common issue in grammars <ArneBab_>alltogether guile built in roughly 10 minutes on this machine <wingo>well, that's not too bad then <ArneBab_>so in these instances, the ecmascript implementation might stray from its definition <wingo>civodul: wdyt about a 2.1.2 release, any thoughts? :) <wingo>also mark_weaver, sorry, i just pinged ludo b/c we were talking about it last weekend <wingo>i would like a successful build report on a 32-bit machien <civodul>wingo: more testing sounds good, and there's the unboxing support that has been added since 2.1.1 <civodul>so it probably makes sense to have a 2.1.2 <wingo>yep, NEWS and everything is all ready <civodul>BTW you could try: guix build -s i686-linux guile-next --with-source=./guile-2.1.2.tar.xz <civodul>it simply uses personality(2) under the hood <wingo>so the wizard trope is problematic but that is some serious wizardry <civodul>and! you could try: guix build --target=armhf-linux-gnueabihf guile-next --with-source=./guile-2.1.2.tar.xz <taylan>civodul: BTW I had issues with guile-next and --with-source, it said the --with-source had no effect. worked with the regular guile package. <civodul>oh right, that's because the source needs to have the same name as the package <civodul>so you'd have to rename the tarball to 'guile-next-2.1.2.tar.xz' <mark_weaver>civodul: guile-2.1.x has been failing to build on both mips and arm on hydra <mark_weaver>on mips, it's because of the page size issue. on arm it might simply be the one-hour silent timeout, I don't know. <civodul>well this would just the cross-build procedure, not actually run tests <mark_weaver>also, does our guile package handle cross-building properly? <wingo>the builds should take not as long now, happily <wingo>i think 2.2 does, tough to tell tho <wingo>it can certainly cross-compile the .go files just fine <wingo>i had to fix that to make prebuilt/ work properly <civodul>--target should be a good way to test it <mark_weaver>civodul: really? I thought some special handling would be needed for that. <civodul>2.0.11 can definitely be cross-compiled, and i think it's a bit older than that <mark_weaver>I knew it could be done, but I thought it required first building a native copy of guile and then using it to cross-build with the GUILE_FOR_BUILD variable set, and I don't see anything about that in the guix package for guile. <mark_weaver>the "Cross building Guile" section in the README suggests that special handling is required. maybe that README needs updating? <civodul>mark_weaver: the recipe has the magical (self-native-input? #t) <wingo>bah, building with -s builds with i686-unknown-linux-gnu, not i686-pc-linux-gnu <civodul>it shouldn't make any difference no? <civodul>the "vendor" part is most often "unknown" nowadays, or something unrelated to the hardware vendor <mark_weaver>wingo: I would think that we shouldn't be sensitive to that vendor string. <wingo>mark_weaver: we could switch to use $host_cpu-$host-os instead, or add a symlink. <wingo>the plan is that while there are only 4 variations to just add a bunch of symlinks. <civodul>wingo: the bytecode format depends solely on $host_cpu, no? <wingo>does it? what about windows64 or mips with the n32 abi? <wingo>because i don't know i used the triple <civodul>there's no standard way to represent ABIs in GNU triplets <civodul>yeah you can't use full triplets in this Makefile.am <civodul>i think prebuild/$cpu/$word_size would work well <civodul>just like we do with the GOOF cookie <civodul>ACTION apologies for spoiling the party <mark_weaver>we can address the portability issues in a future prerelease. <wingo>civodul: you can use triplets <wingo>the current prebuilt/ setup will work when we have native compilation too <wingo>which is why it was done that way <wingo>i think it would be sufficient to add a bunch of symlinks <mark_weaver>wingo: the built libguile knows the endianness and word size. it would be better to make use of that knowledge than to add yet another independent repository of that knowledge, no? <mark_weaver>scmconfig.h might also know that knowledge in a form that is easy to extract <mark_weaver>anyway, it's not important to address this before the release. <wingo>my --target build didn't work unfortunately, it gave an elf error about a word size mismatch, but i couldn't tell from which guile. confusing <civodul>cross-builds are tricky because you can easily end up loading a .go for the wrong architecture ***Fuuzetsu_ is now known as Fuuzetsu
***Fuuzetsu is now known as Guest77311
***ozzloy_ is now known as ozzloy
<daviid>did the talk about guile on replicant occurred at fosdem? <daviid>paroneayea: where is your actor model git repo again? <paroneayea>daviid: oh I don't have an actor model git repo... though I do have an 8sync repo, which eventually should have an actor model one in it I hope :) <daviid>ah yes, that's what i as loking for thanks <daviid>paroneayea: yes, I got it already, tanks <wingo_>ACTION gives another go to a guile cross-build <wingo>the pun was made by some other person ***[csed] is now known as csed
***rntz^2_ is now known as rntz
<stis>Hmm persistance is not simple, variables point to a value and you typically want those to update, but that is not evident by the value <stis>I ended marking important variables values that is mutating containers with the varibale name and namespace <stis>That worked for guile-prolog <stis>but if the value is not a container you but an immediate you are smoked.