IRC channel logs

2014-12-20.log

back to list of logs

<mark_weaver>119 proposals, wow!!
*mark_weaver wonders how hard it would be to rewrite guix-daemon in guile
<tadni_>mark_weaver: I don't know, but davexunit and civodul already has discussed this eventual desire.
<tadni_>So assuming it's not amazingly difficult to do so, I see it happening in/by some faction eventually.
<mark_weaver>yes, it certainly will. just wondering how much complexity I'm failing to think about.
<mark_weaver>obviously it has to be very robust.
*tadni_ still doesn't understand what specifically the daemon does, just "a lot"...
<mark_weaver>that's perhaps the most important point.
<mark_weaver>anyway, going afk for a while...
<tadni_>Too, the fear of course that maybe Guile is still a bit too slow to be doing this heavy lifting until we get that native compilation going.
<civodul>it's fast enough for this kind of things
<tadni_>I've heard the reason Emerge is so slow, is more so due to Python and not Emerge's actual implementation. Not sure how true that claim is though...
*civodul -> zZz
<civodul>good night/day!
<mark_weaver>tadni_: guile is certainly fast enough for this. it's just a matter of using proper algorithms and data structures.
*davexunit attempts to hack on 'guix publish' a bit
<mark_weaver>cool! :)
<tadni_>davexunit: Short-hand desc?
<tadni_>mark_weaver: What is Guile, some factor of "too slow" for now then? Maybe more low-level stuff?
<tadni_>Like, could one write a decent performing hardware driver in Guile conceivably?
<mark_weaver>it's not about high-level or low-level, it's about the scale of the problems.
<davexunit>tadni_: it starts a web server that exposes a hydra-compatible http api for fetching substitutes.
*tadni_ may or may not be too tired to have parsed that correctly.
<mark_weaver>image or video processing, or example, involves millions of pixels and maybe a high frame rate, so that's something you'd need to squeeze every available bit of efficiency out of.
<davexunit>tadni_: basically, it will allow any guix user to start a server that another could use to fetch binaries from
<tadni_>mark_weaver: So say, if we wanted to rewite something like gstreamer in Guile?
<mark_weaver>whereas the kinds of jobs that hydra does involve working with graphs of thousands of packages. and frankly, with properly designed data structures and algorithms, guile could probably easily handle up to hundreds of thousands of packages and still be quite fast if the software is written well.
<tadni_>davexunit: Oh! Okay, /very/ neat.
<davexunit>I've been writing games with guile, and to get good performance I have to leave certain operations to efficient C libraries.
<mark_weaver>tadni_: right, writing video codecs is not a job for guile :)
<tadni_>davexunit: Only 30 years, till Sly can replace SDL with GDL. :^)
<tadni_>How long has SDL been in development? It has to been since the mid 90s.
<davexunit>something like that.
<davexunit>I really want to write SDL2 wrappers for Guile.
<davexunit>but that is a discussion for #guile :)
<tadni_>davexunit: Just not enough time, or? And okay, true.
*mark_weaver goes back to splitting this huge xorg-updates work into commits...
<davexunit>too many projects, not enough time, yeah.
<davexunit>help wanted. :)
<tadni_>davexunit: I probably will become a contributor to Sly eventually; My worry, is that I'm not well along in my math carrer to help in a lot of relevant places.
<davexunit>I need help with other projects, too. like guile-toxcore or guile-sdl2.
<davexunit>no linear algebra required. :)
*tadni_ has no idea how to write a wrapper ... should probably look into it.
<mark_weaver>there's no shortage of work that doesn't need any special knowledge of math.
<mark_weaver>very little of it does, actually
<ijp>$10 to the first person to apply the lessons of topology to guix
<tadni_>My hope, is to work real hard this year -- and become confident and competent in Scheme towards the end of 2015 to 2016, to be an assets beyond just very trivial work.
<tadni_>this coming year*
<davexunit>tadni_: like that fish from finding nemo said: just keep hacking.
<tadni_>davexunit: Welp, you made me verbally chuckle. :^)
<davexunit>I've been trying to implement this for guile, but it's hard stuff: http://infoscience.epfl.ch/record/169879/files/RMTrees.pdf?version=2
<davexunit>so I'm taking a break to hack on guix and feel productive
<mark_weaver>ijp: lol :)
<ijp>davexunit: if only there was someone you knew with an interest in immutable data structures who could be persuaded to take this one up
*ijp downloads paper
<davexunit>ijp: hehe :)
<mark_weaver>it's good to see you hanging out here, ijp :)
<davexunit>well, I wanted to do it for educational purposes!
<davexunit>if ijp solves all my purely functional data structure needs, I don't learn enough about how they work :)
<ijp>davexunit: I'm not sure what operations you need, but did you try something like my fectors library?
<ijp>davexunit: just learn how fingertrees work, then use them to implement everything
<davexunit>ijp: is that in pfds or is that separate?
<davexunit>basically, I want fast immutable arrays for Sly, so I can efficiently model grid based games in a purely functional way.
*davexunit looks up finger trees
<ijp>fectors are separate because they aren't technically purely functional
<davexunit>ah okay
<ijp>I could be prompted to special case (pfds sequences) to remove the extra layer of overhead
<davexunit>I need the purity aspect, because I intend to do what the Elm language does and allow for some time rewinding in Sly.
<ijp>davexunit: well, you can rewind, it just costs you
<ijp>fectors are more for "not usually functional except sometimes" vector uses
<davexunit>ah okay
<ijp>sequences are purely functional, but they have quite a bit of overhead at the oment
<davexunit>ijp: do you have any recommended literature for learning about finger trees?
<ijp>anyway, if you want to implement these RRB Trees, go ahead, but if you can't be assed, ping me
<davexunit>ijp: if I give up, I'll come to you.
<ijp>davexunit: http://apfelmus.nfshost.com/articles/monoid-fingertree.html will give you an overview, if you need more, read the paper
<davexunit>ideally I'd like something good enough to contribute to guile core.
<davexunit>ijp: thanks
<ijp>very few things in programming have made me as happy as fingertrees
<ijp>extensible effects looked good, but I still haven't finished that paper
<davexunit>they seem rather magical, given the amount of data structures you can implement with them.
<davexunit>gah, all these papers assume the reader knows haskell
<tadni_>sneek: help
<jxself>Poor sneek.
<tadni_>sneek: later tell zdavis Hey, any news on *.iso generation? :^)
<sneek>Will do.
<tadni_>jxself: Hm, why?
<jxself>You asked for help & sneek ignored you.
<jxself>Seems it doesn't understand help.
<tadni_>jxself: Nah, that command pms you, so it doesn't flood the channel.
<jxself>Ah, so the help should be sent via PM too?
<jxself>Because I thought sneek ignored you.
<jxself>Glad it didn't. :)
<tadni_>jxself: Yeah, go ahead and try it. :^)
<jxself>Hence, "poor sneek" because it was buggy.
<iyzsong>mark_weaver: it's great to have latest X stuff, thanks!
<gry>-seen civodul
<sneek>civodul is not here, sneek!
<jcca>Hi, some reason for this error "guix system: error: system locale lacks a definition"
<alezost>jcca: you are probably using "en_US.UTF-8" instead of "en_US.utf8"
<amirouche>sneek: tell later civodul are you aware of gnu emacs looking for another documentation format? did you propose skribillo? (ref: http://lwn.net/Articles/625072/)
<sneek>later, amirouche says: civodul are you aware of gnu emacs looking for another documentation format? did you propose skribillo? (ref: http://lwn.net/Articles/625072/)
<amirouche>x)
<jcca>alezost: Thanks!
***DusXMT_ is now known as DusXMT
***musicmatze1 is now known as musicmatze