<jsierles>my goal here is to know for a given manifest, what the associated profile will be. because in the cluster, i'm just setting the appropriate environment variables, not linking or using the guix command line.
<rekado_>I can’t check this now, but I’ll try to find some time today to see if we can do this easily
<jsierles>so what i want to do is build from a manifest, then grab that profile hash so the clients (docker containers) start up with the right paths
<jsierles>i guess one way is just to check what my current link is after the 'guix package'?
<davidl>rekado_ a nice feature to have when using GuixSD would be to be able to apply a system configuration that automatically resorts to a version which has a successful build available on hydra so you can avoid the time it takes building from source.
<davidl>rekado_ exporting the cert paths seem to work.
<rekado_>what do you think about adding different manifest formats?
<rekado_>it’s trivial to read different file formats with Guile, so if all a user wants is to describe an environment, why not give them ways that don’t involve writing Scheme?
<rekado_>I think we might be able to reduce complexity for some users by removing most syntax from manifests
<civodul>rekado: re manifest formats, why not, sounds like a good idea
<rain1>but implementing a language is harder.. the runtime for scheme is quite large
<cbaines>Does anyone know of a way to take a file like /tmp/guix/gnu/packages/../.. and turn it in to /tmp/guix ?
<rain1>so I am wondering maybe a lower level language but still something above assembly would be a good help to do
<rain1>forth for example has a very small runtime compared to scheme, but i've not coded in that much
<janneke>rain1: i was hoping to find a middle way between hex2 and hex3 with OriansJ, now your hex86 also plays :-)
<janneke>rain1: i fear things get too slow with an extra indirection between assembly and scheme
<janneke>but, who knows -- OriansJ's stage2 LISP is also nice
<rain1>yes we must be careful not to stack interpreters
<rain1>but as long as long as things are being compiled down they should stay fast
<rain1>that is why i have been rewriting my scheme compiler, to avoid nested interpretation
<janneke>otoh, as soon as stage0 can assemble+link mes'c hex2, we somewhat (with only a bit of cheating) closed the bootstrap loop on the lower end, if we can get mescc to compile a compiler that can compile gcc...done
<janneke>yeah, we should move to compilation some time soon
<janneke>rain1: it will get real fun as soon as we can somehow combine or build on all of our efforts
<rain1>I wonder what I should do to help most just now? if there's more info/testing needing done regarding C compilers I can look into it
<janneke>quigonjin, rain1: yeah, beautiful metaphor for the bootstrap problem
<janneke>rain1: i'm personally looking for two things: 1. some insights/decisive arguments on how to close the gap between hex2 and hex3 (hex86 might be it) ... but in a way that OriansJ is happy to produce an ELF from that
<rain1>so I think OriansJ plan was building on top of this portable virtual machine, all the hex codes are programmed to this particular engine (maybe we can call it the Knight VM)
<janneke>and 2.: the simplest C compiler to compile with mescc, hopefully simpler than tcc
<rain1>on top of Knight VM he has a lisp interpreter, forth interpreter, some toolls like cat and such - it's a great way
<janneke>or, otherwise: help to simplify tcc and help to compile it using mescc :-)
<rain1>but how to implement the VM interpreter? that's why I was trying to follow his idea but directly to x86 instead of to a virtual ISC
<rain1>so it could be used to build up towards implementing the knight VM, then on top of that we may have a basic set of assemblers, linkers etc. enough to get the mes scheme implementation going
<rain1>just throwing one possible path/idea out though
<rain1>simpler than tcc <- this is a difficult one, I don't think there is a older commit in the tcc repo of a "one-file tcc" that can be used
<rain1>pcc can build tcc, but it quite a considerable codebase
<rain1>maybe I should check out these ultra minimal c compilers like 8cc and see if any of them have a chance at building an early tcc
<reepca>cbaines: (canonicalize-path "/home/reepca/.././././reepca") => "/home/reepca". It appears to be a guile builtin that isn't documented in the reference.
<ng0>jsierles, I'd rather use pagure instead of gitlab. well at least that's where I am moving personally and project related. Developed around fedora this one looks the most promising.
<ng0>it's tough to get it working but of all the version control web systems I want this myself.. the package builds, just need to get the service definition right. gnunet-service and pagure, that'll be the work focus now.
<ng0>I think you all are quicker in response than the fsfe licensing team (I don't expect them to be fast and responsive): there was a deriviate license of the GPL2 way before GPL3 was made public, had a different name. I'm not sure if I am allowed to do the same with AGPL3. There's just one clause I want to add, the result of past discussions and chats. I'm not sure what the implication of a derivate license is.
<ng0>All I want is AGPL3 plus this new paragraph in it. I think I would have to rename the license.. I don't know any software lawyers, but some other people who could help with proof reading the section