***cky944 is now known as cky
<wingo>i did a git push --tags and it pushed trash tags <wingo>serves me right for blindly following release.org ***aburgess_ is now known as aburgess
<lokli>davexunit, hi, you really saved my source to source compiler project. I have total clarity about it now, and actually got to the point of experimenting with type inference. Do you have any insights into the topic? <davexunit>lokli: glad to hear it! I don't know anything about type inference, though. that's a topic I need to do my homework on still. <davexunit>I know that, at a high level, I would want to associate each expression with its type. <davexunit>atoms (numbers, strings, etc.) are self-evident <davexunit>the type of a nested expression is the result of examining the types of all sub-expressions <lokli>i am mostly thinking of how to implement contexts and carry them around <davexunit>I need to read up on how other people actually implement this stuff, but my naive approach would be to tag every expression with a type or maybe a set of types that it could evaluate to. <davexunit>like, let's say that '+' is a primitive function in our language that may return an integer or a float, depending on arguments. <davexunit>we can use some simple proofs to narrow that down <davexunit>if both arguments to '+' are tagged as ints, then the '+' expression can be tagged as an int. <lokli>davexunit, so, tagging is happening in ast itself, or another, parallel ast is to be created? <lokli>for now i am thinking context trees, holding those rules, every added rule is checked to be non-conflicting <davexunit>this is all very... inexact. it might be totally silly. <davexunit>AST -> type tagged intermediate structure -> ? -> target language <lokli>thats a good enough start, prototyping will show if it is workable <davexunit>having a structure to hold the set of proofs sounds reasonable. <davexunit>I'm hoping that by reading more of "the little prover" I will be able to transfer what it teaches to this problem. <lokli>i am having some visions (again) i would like to try. when they fail, will go educate myself on the topic =) also ask people around <wingo>mark_weaver, civodul: should i upload .gz releases too for guile? at some point we should be good with just .xz i guess <wingo>i'll upload a .gz for this one i suppose ***peterbrett_work1 is now known as peterbrett_work
<wingo>peterbrett_work: yes, but this is 2.1.2 <peterbrett_work>The latter I had already guessed :) With the precompiled compiler, right? <peterbrett_work>Any thoughts on whether an architecture-independent .go format is a desirable thing? <wingo>pretty sure it's not desirable <wingo>the way that SCM objects are statically embedded in the ELF files depends on the architecture <wingo>any run-time swizzling would negate benefits of shareable read-only memory <wingo>and in the future these files will be natively compiled anyway <wingo>if you wanted some independent representation for other purposes like link-time optimization, you want the CPS, not the bytecode <wingo>so to me architecture-independent .go files is a non-goal <peterbrett_work>What about shipping the CPS in the tarball rather than the .go files? <wingo>cps->bytecode is not as cheap as you might thing :) <wingo>it involves register allocation at least <peterbrett_work>There must be a solution here that doesn't require all non Linux/x86{,-64} users to spend an hour bootstrapping <peterbrett_work>An hour of churning the CPU doing something completely duplicative is a waste of CO2 emissions <wingo>peterbrett_work: see the Makefile.am. you can symlink an architecture to prebuilt iles <wingo>feel very free to submit patches adding symlinks <wingo>and feel free to symlink yourself :) <davexunit>peterbrett_work: it serves a real purpose: not having to trust pre-built binaries, which is a very desirable thing. <davexunit>I am thankful that Guile doesn't force me to trust a pre-built compiler. <wingo>how to trust the c compiler is a different question :) <davexunit>peterbrett_work: sure, I know where you're going, but do you think that adding an *additional* compiler to the trust chain improves the situation? <peterbrett_work>If I'm happy to trust Fedora's C compiler, then I'm happy to trust the FSF's Guile Scheme compiler <davexunit>the reproducible-builds project is actually looking for ways to bootstrap a C compiler without trusting another pre-built C compiler. <davexunit>but there's also an approach that can be taken by finding a fixed point. <civodul>wingo: i prefer to upload both .tar.gz and .tar.xz, it doesn't cost much <peterbrett_work>That reminds me that I need to test mark_weaver's LLP64 support patch <davexunit>civodul: how do we disable the use of pre-built binaries in our guix package for guile 2.1? <wingo>ACTION tries to remember how to use CVS <civodul>davexunit: yeah, we could remove stuff in a snippet <wingo>davexunit: make -C prebuild clean before building <wingo>you could of course nuke any .go in the tarball ***karswell` is now known as karswell
<wingo>i am thinking it is useless to list md5 or sha1 sums, we should just do sha256 sums <wingo>savannah has allows you to log in over http, weird <roelj>I'm going to check out the 2.1.2 release :D <roelj>Hmm, I saw the the 2.1.2 tag when pulling. Now built and installed it, but 'guile --version' says: 2.1.1.105-486b3-dirty <mark_weaver>roelj: you need to run ./configure again to fix the version number <wingo>looking forward to seeing it in guix :) <wingo>how should guix work with guile prereleases? just -next or should we have a guile-2.2 package or what? <wingo>s/prereleases/eventual 2.2 release/ <mark_weaver>wingo: we have a 'guile-next' package. I guess it should be updated :) <civodul>wingo: yeah it has a different name so that --upgrade don't switch to 2.1 inadvertently <mark_weaver>and also so --install doesn't choose it over guile-2.0 <peterbrett>Even though I've barely got gschem users even using 2.0 yet ;) <amz3>congrats for the new release :) <paroneayea>I'll promote it when I reboot back into debian and have access to my package manager again :) <wilo_>I'm a python programmer who wants to learn Guile, a good book that can recommend me apart from the official documentation <paroneayea>wilo_: I'm also working on a tutorial, but it isn't really ready! <wilo_>paroneayea: cool!, could see your tutorial <paroneayea>wilo_: happy to hear feedback though (with the caveat that I am mostly just "writing ahead" at the moment)