<jenia>hello. Does the Guile interpreter use a GIL? <wleslie>no, it has full support for free threading ***_zxq9_ is now known as zxq9
<wingo>it's to include prebuilt .go files in $top_srcdir/prebuilt/ on release <wingo>DIST_SUBDIRS will descent there and create .go files for the 4 variants we currently have (big/little endian, 32/64 bit) <wingo>$top_srcdir/prebuilt will be added to GUILE_LOAD_COMPILED_PATH when building <wingo>so that if you build from a tarball you will pick up those prebuilt .go files. <wingo>we only build the .go files for the compiler (the things built in bootstrap/) <wingo>and if you nuke that directory, then you bootstrap from C via the interpreter, as it is now. in that way guix people can be happy <wingo>(we add the appropriate target-specific subdir of $top_srcdir/prebuilt to GUILE_LOAD_COMPILED_PATH) <wingo>i was hesitant before to do this because hey, we're headed towards native compilation eventualyl <wingo>but this strategy can work just as well in that case. a "make dist" tarball can include the equivalent of .go files for the architectures we're interested in <wingo>it would be possible to check these files into git but probably that's not necessary <wingo>and anyway if a git user wanted prebuilt files, they could copy them from a tarball <peterbrett_work>wingo: Even though "hey, we're headed towards native compilation eventually!" the compiled compiler is still going to be *way* faster than the interpreted compiler — possibly even more significantly <peterbrett_work>wingo: With the compiler bytecode already present, getting a native compiler is a matter of converting bytecode->native. I think having the compiler's .go files in the dist tarball would be a win for native compilation as well, overall <peterbrett_work>There's an environmentalist aspect here too — sounds like including the .go files in the source tarball would save quite a lot of otherwise-unnecessary CO2 emissions by people building Guile (1 hr at max CPU is quite energy costly) <wingo>it also frees us up a bit in the compiler, that we can rely on the presence of optimizations <wingo>for example right now i'd be hesitant to use a u64vector as a bitvector because loading a u64 value in the interpreter is going to be a bignum on any platform <wingo>whereas loading it with the compiler, it will be unboxed on any platform <wleslie>been really enjoying your blog posts lately, too <wleslie>are you still thinking to build a compiler -O0 as an intermediate step? <wingo>that's what the bootstrap/ dir is <wingo>i think it uses -O1 actually, which is all optimizations off except for peval and other tree-il optimizations <wingo>still need to make it use a different, cheaper slot allocation strategy tho <wleslie>is slot allocation a kind of register allocation? <civodul>wingo: as long as prebuilt/ is just a cache, why not <civodul>it might be enough to put a handful of .go files in there, like eval, psyntax, vlists <daviid>I finally got ftp-upload authorization processed and uploaded guile-gnome[clutter] latest releases, great. but I need to clean a wrong upload attempt [I used a wrong location in my first guile-gnome release upload], how do I do that? I can't se nothing in the 'Information for Maintainers' web page <daviid>civodul: ^^ [good news, thanks for your help wrt this...] <daviid>wingo, civodul: how do we manage, clean, reorganize gnu projects upload dirs? do we have sftp access [I tried but that failed] <wingo>we do not have sftp access, i think there is no provision for removing files. but see "info maintain" <daviid>wingo: ah! too bad, no way to clean reorganize then [the info maintain is a copy [or vis e versa] of the maintainers web page]. I wanted to create an 'old' subdir with all the old releases and only have 1 release in the top guile-gnome-platform, guile-clutter ... <daviid>wrt to the wrong attempt leading to /pub/gnu/guile-gnome/platform I'll file a savannah non urgent request to delete it <daviid>wingo: wrt distributing some .go files I also think it is a good idea. I actually am in favor to check these in git as well, because most of us use git, and I'd rather have to use an optional --rebuild-go to have to and if no option benefit from the exiting ones... my 2c <peterbrett_work>daviid: Unfortunately checking in derived files to git is a big no-no <daviid>peterbrett_work: ah, wingo suggested to check these in git along his irc msg so I thought it was possible <daviid>if it is, and 100% reliable, then we should do it, imo <peterbrett_work>In my experience, checking in binary, derived objects is a cause of massive maintenance pain (if only because of the merge conflicts (oh boy, the merge conflicts)). So no, not a good idea IME. <davexunit>binaries should *not* be checked into version control <davexunit>daviid: it's important that existing source tarball URLs are stable (immutable), because changing them gives downstream users (such as distribution package maintainers) headaches <davexunit>civodul recently started a thread on a GNU mailing list about treating the FTP archive as an append-only data structure for these kinds of reasons. <peterbrett_work>davexunit: Maybe it needs to have some sort of "are you sure you want to commit this file to the FTP archive, irrefutably, forever?!" intermediate staging step <daviid>davexunit: I was not refering to tarballs, but if wingo goes ahead with the idea, they will contain essential .go files and still be immutable right? a specific version of guile has 'its' .go files, and a new tarball would mean a new guile version, as it's right now.... <wingo>merge conflicts is a good point. no .go files in git. <wingo>if a git user wants .go files they can get then from a corresponding release, if such a thing exists <daviid>I thought git had a specific set of commands for binaries <taylan>wingo: BTW I wonder if something similar to what we did in Guix could be done in Guile, loading many modules into memory at once then compiling their files in one process? <wingo>taylan: i think it's less interesting for guile because in guile you want to benefit from the newly compiled .go files <taylan>wingo: hmm, after bootstrap is done, aren't modules auto-compiled in memory when loaded? <wingo>the win for guix-style compilation is when you have to expand a large number of files to build. in guile the point at which expansion dominates runtime is the point at which fewest parts of the compiler are compiled -- the time when you really want to switch to running compiled code instead of interpreted code. <wingo>ACTION not sure what you mean <taylan>I thought 'load'ing an .scm basically compiles it transparently, just doesn't write the compilation result anywhere (or does so in $XDG_CACHE_HOME) <taylan>similar to how the REPL compiles the lines typed into it... <taylan>maybe my understanding of that is wrong <taylan>anyway, have to catch a bus now, TTYL :) <daviid>ACTION updated both guile-gnome and guile-clutter, so latest tarballs and sigs URLs are back to 'normal' gnu [and not the temporary grip nongnu savannah URLs], and removed the pending authorization request 'special notes', great, much cleaner! <ArneBab_>daviid: AFAIK the git thing for binaries is for large binary source files — like gimp files. <daviid>ArneBab_: whether big or snmall doesn't make diff imo. derived is a human iterpretation, git doesn't have to know that, it just have to provide developers with the tool to handle binaries, if they wish to, again imo. the more I think about it, the more I think it should, and we should use it when/if we think we should ... <davexunit>I think the thing to keep in mind is that version control systems are for source code, the stuff that can't be generated by a computer. anything that is some kind of build artifact shouldn't be kept in version control. <davexunit>a lot of reproducibility and trust issues arise when projects violate this rule. <daviid>davexunit: I understand, but if .go files land in tarballs, then it already breaks the rule, so imo, it better be with some control, precisely... anyway I understand we have diff opinion here, no big deal but I still think what I wrote is the right way, if,again, .go files land in tarballs, they should be under git control, special binary files control... <davexunit>daviid: tarballs already include files that aren't in version control <davexunit>for example, they include a configure script <davexunit>the entire build system has been bootstrapped <daviid>davexunit: sure. I made these comments because wingo said, earlier, that he would maintain a directory [not checked] with these 'speedymycompiletime' .go files. But if he generates these as part of the 'make dist', which the is case of the configure script you're refering too, which is always rewritten by make dist, then ok. but i guess he won't do that [the way he wrote let me think he will decide when and which .go files versions <daviid>... which makes perfect sence by the way, then the need for a tool to control ... imo ***eilert is now known as outworlder
<davexunit>paron_remote: haha I was about to post about Sussman <paron_remote>I thought that blogpost was interesting in that it sounded like sussman was saying programming used to be more about spending much time thinking about hard problems and writing code to prove those general problems and now it's more about sewing together libraries <davexunit>though I wish Sussman expounded a bit more on if he thought that Scheme could fufill the role that Python serves now. <paron_remote>python is probably a better library sewing kit, namely because of the number of available libraries but not because of general capability of filling that role <davexunit>because from my perspective, there are fewer libraries available to sew together, but it's more than capable for the task. <davexunit>it seems that he doesn't think highly of the committee that did the choosing, or committees in general. <davexunit>paron_remote: this talk is more of the same that he's been talking about for years, but he always slips in something new and interesting. <paron_remote>davexunit: now that I know what days I'm in Boston, we should schedule that office visit :) <paron_remote>davexunit: note that the two big properties he's advocating <paron_remote>are the very kind of direction that people who claim that the "unix philosophy is the holy grail and that's why emacs sucks" dislike <davexunit>paron_remote: and also the static typing folks. <davexunit>I imagine the Haskell folks aren't too into Sussman's notion of computing <davexunit>paron_remote: "the inspiration for this is Emacs" <paron_remote>I do think it ties in with his other ~recent talks but is also a bit different <davexunit>paron_remote: "the insides of automobile software are disastrous" <davexunit>haha "the code I'm writing is terribly risky... on purpose." <davexunit>paron_remote: "don't shoot yourself in the foot with a magic bullet" <davexunit>just after a funny dig at Haskell programmers. <davexunit>paron_remote: Sussman gets asked "Why did MIT switch from Scheme to Python?" towards the end <paron_remote>davexunit: he also seems to be advocating GOOPS/CLOS style generic methods <davexunit>(gonna read SICP chapter 4+5 later as a precursor to writing a Lisp->GLSL shader compiler)