IRC channel logs


back to list of logs

***mark_otaris is now known as ColorfulBody
***ColorfulBody is now known as mark_otaris
<davexunit>codemac: nice :)
<sneek>davexunit, you have 1 message.
<sneek>davexunit, codemac says: my baby config. I'd love to fully replace/replicate the systemd user unit files I have:
<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...
<civodul>has anyone used this?
<civodul>looks pretty cool
<Steap>can't wait to use gerrit outside of work!
<civodul>arrgh, Gerrit is actually a big pile of Java
<civodul>with a custom build system
<civodul>ok, next one
<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
<Steap>what is missing ?
<Steap>from the QEMU thing, I mean
<civodul>not much... but it depends on notmuch :-)
<civodul>dunno, i should just give it a try
<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'
<civodul>we do that for udev
<civodul>(not terribly elegant)
<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.
<davexunit>eager to learn more. :)
<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?
<davexunit>in dmd, that is.
<davexunit>I also this "xinetd" thing
<davexunit>I also see*
<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.
<davexunit>and additionally, a threadless REPL server?
<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>needs non-blocking I/O.
<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>since 2013 even
<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
<davexunit>for all to enjoy
<civodul>wingo: no, but it lacks a #'
<civodul>and yeah i ended up using syntax-local-binding
<civodul>i'd have avoided it but couldn't find any other solution
<civodul>and it's been handy :-)
<wingo>civodul: i thought lift always took two arguments
<civodul>liftN is (liftN proc monad)
<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>aaah i see
<civodul>yes, indeed!
<civodul>well feel free to push a fix
<civodul>davexunit: someday!
<civodul>i'd like to add a template system in there
<civodul>so we can build specialized versions of all the 'm' procedures
<civodul>but that's trickier than in C++ ;-)
<davexunit>oh boy
<davexunit>what's the use-case there?
<wingo>so in magit 2 how do i add a commit log for a staged hunk?
<wingo>C doesn't seem to work
<davexunit>c c ?
<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
<civodul>that's a bit annoying IMO
<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>I haven't tried, no idea what will break.
<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!"
<paroneayea>I still like that sentence
<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
<civodul>for the package modules
<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>heh tx ;)
<wingo>-O0 for scheme optimizations i mean
<davexunit>can we see that our little language is meant for "real work" now?
<davexunit>"production-ready", "enterprise"? ;)
<wingo>hmmm :)
<wingo>if you like :)
<Steap>"enterprise" will be the death of it.
<davexunit>I'm half-joking.
<Steap>Haskell has a slogan
<Steap>"avoid success at all costs"
<civodul>they've been failing, i'm afraid
<Steap>civodul: lolz
<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>especially with the new compiler and VM
<paroneayea>would be interesting to see some new benchmarks
<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
<davexunit>I want to sneak in Guile wherever possible.
<civodul>i think adoption largely a non-technical problem
<davexunit>yeah, lots of marketing.
<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 we can do better!
<civodul>better record APIs?
<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>like Python
<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.
<davexunit>paroneayea: yes, indeed not.
<paroneayea>I think I can say pretty well that didn't help python adoption
<Steap>paroneayea: yeah :)
<paroneayea>I also think Python did it pretty well
<davexunit>Guix is a "killer app"
<paroneayea>for 2->3
<Steap>they had ltos of users before Python3
<paroneayea>it wasn't a world-changing design like perl 6
<Steap>well having code that works with Py2 and Py3 is a huge pain
<paroneayea>Steap: less and less hard now though
<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
<paroneayea>Steap: ah yeah, I hear your pain then :)
<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
<davexunit>civodul: oh, really? that's exciting.
<paroneayea>Steap: it was a dedicated project though
<paroneayea>Steap: and tons of work, so yeah :)
<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 :-)
<paroneayea>civodul: oooooh
<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>that'll solve it.
<paroneayea>solve becoming polarized that is!
<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.
<davexunit>paroneayea: no.
<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>so it was a joke
<paroneayea>but then people started using it
<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.
<wingo>but you still RPC right?
<wingo>that's going to be p slow
<davexunit>looks like this doesn't RPC
<davexunit>but not 100%
<wingo>services are monadic values
<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>looks like we need memoization
<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
<wingo>ok, /me -> bar. ttyl :)
<davexunit>if you're only ever working with a single OS that could work
<davexunit>okay later
<davexunit>good catch
<davexunit>have fun
<davexunit>container tests have been re-enabled on the guix package
<paroneayea>davexunit: that sounds promising
<davexunit>I fixed them awhile ago :)
<davexunit>but only now re-enabled them.
<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?
<davexunit>lfam: run 'guix pull' as that user
<davexunit>each user may use their own version of guix
<davexunit>rekado_: in which I plead with the RubyGems maintainers to reconsider the consequences of discouraging test suites in gem archives
<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
<davexunit>not sure
<davexunit>I made the last commit an hour ago
<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.