***mark_otaris is now known as ColorfulBody
***ColorfulBody is now known as mark_otaris
<sneek>davexunit, you have 1 message. <davexunit>ACTION is going to try out civodul's repl service <davexunit>wish I had thought of that. civodul is a clever guy. <rekado_>got patches for blender, but I don't have enough disk space to build it on my laptop right now... <Steap>can't wait to use gerrit outside of work! <civodul>arrgh, Gerrit is actually a big pile of Java <Steap>that's why I was more thinking of a mail-based thingy for the CI <Steap>and the issue with Gerrit is that everybody has to use gerrit <Steap>you can't really use mails anymore <Steap>and using gerrit means having an account... <Steap>civodul: what kind of tool are you looking for, exactly ? <civodul>ideally, something that has both an emacs/email interface and a web interface (for work, and possibly for Guix) <civodul>QEMU's 'patches' thing is almost there <civodul>not much... but it depends on notmuch :-) <davexunit>just ran into a situation with dmd where I wish we had socket activation support. <davexunit>I have a service that provides an ssh tunnel <davexunit>and another service that provides a SOCKS proxy that depends on the tunnel <davexunit>if the tunnel service is stopped and I run 'deco start proxy', the tunnel is started and then the proxy, but there's a race condition: the tunnel port has to be opened quickly enough for the proxy service to be able to connect to it. this race is lost every time I've tried. <civodul>you could have code that waits for the port to be visibly open before returning from 'start' <davexunit>civodul: yes, I want to do something like that for the short-term. <davexunit>until we can get socket activation as a formal thing. <civodul>or you could use inetd, which has had socket activation since the 70's ;-) <civodul>seriously, i think it's not an unreasonable option <davexunit>civodul: could you explain a bit more? I'm pretty ignorant with this stuff. <civodul>davexunit: roughly inetd accept(2)s connections on behalf of whatever networking daemons are configured, and spawns those daemon upon connection, passing them an open file descriptor <davexunit>civodul: so, I'd have an inetd service, but would I still have my other services? <civodul>yes, things like sshd or guix-daemon could be managed by inetd, while other services would be managed by dmd <civodul>but obviously, it's better to have all managed by a single thing <civodul>i guess i'm just chatting without proposing any concrete solution ;-) <davexunit>yeah, I guess I want it all managed with dmd with all its schemey goodness. <davexunit>anyway, I have a couple of patches in mind to make REPLing a little friendlier that I will prepare sometime soon I hope. <davexunit>my userspace dmd config has some @@ usage to get at things that aren't exported. <civodul>that would be wonderful if you could look at the cooperative REPL thing <davexunit>civodul: I think we'd need to implement the file descriptor thing that you proposed. <civodul>if we have the file descriptor thing, then using the coop REPL server will be simple <davexunit>I haven't looked at the REPL server internals in awhile. I wonder how hard it would be to make it threadless. <davexunit>(system repl coop-server) already uses coroutines extensively (a construct that I think Guile should formalize at some point as an ice-9 module) <davexunit>surprise, surprise. more reports of failing container tests. <civodul>it means it's a good test suite, so this is good :-) <davexunit>good thing some of the container stuff made it into master. <wingo>ACTION adds a bunch of fields to <service> <wingo>whoa civodul you use syntax-local-binding in (guix monads) <wingo>didn't know anyone used that :P <wingo>civodul: should monads.scm:242 (the liftn fallback) have three arguments? <wingo>seems to me it should only have two <davexunit>ACTION wants to see the monad module make its way to core Guile <civodul>and yeah i ended up using syntax-local-binding <civodul>i'd have avoided it but couldn't find any other solution <wingo>civodul: i thought lift always took two arguments <wingo>ah indeed it was also missing #' <civodul>and lift is (lift proc monad) as well <wingo>civodul: yeah but not (lambda (liftn proc monad) ...) <wingo>on its own it is (lambda (proc monad) ...) no? <civodul>i'd like to add a template system in there <civodul>so we can build specialized versions of all the 'm' procedures <wingo>so in magit 2 how do i add a commit log for a staged hunk? <wingo>ah i have to enter the hunk and press C <wingo>can't just do it from the collapsed entry <wingo>must be a multi-mode thing or something <wingo>maybe the thing to fix guix environment speed is to finally release guile 2.2 <davexunit>would be interesting to prepare a package that builds guix with guile 2.2 <davexunit>but if it goes well, we can benchmark the 2. <Steap>guix env seems indeed a bit slow <paroneayea>might be nice to have a guile-bleeding-edge package in guix :) <davexunit>a dev snapshot would be nice so us early adopters can skip the long bootstrapping time. <paroneayea>i,i: I was once on a Blender forum like, over a decade ago? and someone was experiencing some serious bugs in svn trunk and was complaining about it, to which the response was: "sometimes when you're on the edge, you're bleeding!" <civodul>wingo: there might also be some higher-level optimization lurking in there <civodul>with 2.2 it'll be nice to have things like string literals mmapped instead of heap-allocated <davexunit>guile 2.2 really is a fine piece of work. thank you, wingo! <wingo>for 2.2 bootstrap times i think we can get away with building once with -O0 and then rebootstrap with optimizatoins <wingo>-O0 for scheme optimizations i mean <davexunit>can we see that our little language is meant for "real work" now? <Steap>"enterprise" will be the death of it. <Steap>"avoid success at all costs" <davexunit>but Guile, to me, seems to hold its own against the big languages. <Steap>They prbably have more users than Guile <Steap>but fewer than Python, for instance :) <davexunit>at work we're going to start using Docker more, and right now we're using this crappy lightweight init system called "runit". I want to replace it with dmd because despite it lacking features it's good enough to take the place of runit and is way more hackable. <paroneayea>though I think advancing Guile in terms of users might especially be an issue of having more compelling tooling for people to use in their everyday lives <civodul>i think adoption largely a non-technical problem <paroneayea>civodul: yeah Guile, and Scheme communities generally, are not really known for promoting themselves well. <civodul>paroneayea: they're too busy writing a new standard record API! <paroneayea>I think the GuixSD site redesign already makes Guix looks like more compelling software <davexunit>I want Guile to be more popular, but I also wouldn't want it to be a victim of success. :) <paroneayea>davexunit: I don't think we're at any risk of Guile becoming its own success-victim from having more users be excited by the software though <Steap>Maybe Guile shoudl break compatibility between versions <Steap>they did that, and they got tons of users ! <davexunit>(according to some people we've already done that) <paroneayea>Steap: being deep in the trenches of python and python 2->3 users <Steap>and people are busy fixing crazy bugs now. <paroneayea>I think I can say pretty well that didn't help python adoption <Steap>they had ltos of users before Python3 <Steap>well having code that works with Py2 and Py3 is a huge pain <paroneayea>Steap: it's more converting old code that's hard <Steap>paroneayea: I'm porting OpenStack to Py3 <civodul>paroneayea: Guile will prolly have its new web site within a few months <Steap>paroneayea: I can assure it is painful :) <Steap>paroneayea: I write new code with only Py3 in mind <paroneayea>Steap: well, we had an amazing developer in mediagoblin do all the crazy hard work to make GMG py3 compatible <paroneayea>Steap: but what I mean is, I've written some new libraries that *start out* at python 2 and python 3 compatible simultaneously <paroneayea>Steap: and that's a lot less hard than porting... <wingo>kindof a moot point, we don't need to break compat in any serious way right now <civodul>davexunit: our web site hero is ok to work on it eventually :-) <davexunit>wingo: I guess we have to find another way to be polarizing ;) <paroneayea>davexunit: we need two competing web frameworks! <paroneayea>that are both full stack and tightly integrated, thus *totally incompatible*. <paroneayea>davexunit: did you ever hear how Flask came to be? <davexunit>Guile has awesome modules for the basic web stuff, so that will somewhat help prevent that. <paroneayea>davexunit: it was originally a parody of a web framework called "Bottle" which claimed to be a micro web framework in a single file of python code and "under X lines" of code <paroneayea>davexunit: so initially, Flask was a parody of that released on april 1 which was also a 1 file of python as a microframework, and under X lines, but it had one huge base64 encoded line that contained a zipfile it read for the rest of the framework <paroneayea>and armin was like "oh shit I should take this seriously" <davexunit>shame that languages like Elm are taking off while Guile sits around mostly unnoticed. <wingo>how big of a problem is it that many things in gnu/system.scm compute the operating-system-services monadic value many times? <wingo>perhaps davexunit you know, as you have more experience with the store monad than i do <davexunit>wingo: do you spot something that should be memoized? <wingo>yes, the operating-system-services procedure <davexunit>if it involves RPCs to the daemon that build derivations, then the derivation will only be computed once, and subsequent calls will return the cached thing. <davexunit>(sequence %store-monad (operating-system-user-services os)) makes a monadic value of a list of monadic values <wingo>so making the monadic list from the list of monadic values.... i guess right, it doesn't rpc, but it does cons a lot <davexunit>it certainly doesn't seem like we should be repeating that work a lot <wingo>and it creates all the other services afresh <davexunit>which leads me to a common question I have about how to memoize effectively. of course you could just memoize the operating-system-services procedure outright, but now you've built yourself a global cache that never expires anything. <davexunit>for long running programs that would be terrible <wingo>you could invalidate the cache any time the os changes <wingo>any time you look up into the cache with a different os value i mean <davexunit>if you're only ever working with a single OS that could work <davexunit>container tests have been re-enabled on the guix package <lfam>What is the proper way to update a standalone installation of the package manager? I ran guix pull as root, and it worked. But how do I propagate the update to regular users? <lfam>davexunit: That's what I thought. I was just hoping that I had made a mistake that resulted in needing to recompile everything. <davexunit>lfam: 'guix pull' will only build guix once for that particular version <davexunit>if every user pulls the same version, the first user waits for the build and for the rest they get it almost instantaneously <lfam>That's what I expected to happen. I wonder what caused the divergence between the users' installations. <davexunit>a commit made in between those 2 moments in time <lfam>Me neither. I need to study the internals more. I don't fully understand how all the different profiles are mediated, or how my development tree affects things. I know the idea is that they don't affect each other but there have been times when I expected to be able to re-use some previously built binary but guix recompiled it anyways. The problem is probably with my knowledge ;) <davexunit>it's really very simple. I think people think there's more magic than there is. <davexunit>if a build you expected to be the same wasn't, then it means that either the version of guix you are using has changed or one of packages other dependencies has changed.