| --- Log opened Mon Dec 05 00:00:38 2016 |
| 00:01 | <@celticminstrel> | (Or rather, not dividing them by ten. But it also doesn't work if I pre-divide them by 10...) |
| 00:11 | | * celticminstrel found it; missed one place, basically. (And apparently it doesn't like values <1.) |
| 00:12 | <@celticminstrel> | (Which doesn't really make sense but whatever.) |
| 00:28 | | Kindamoody is now known as Kindamoody[zZz] |
| 01:29 | | Vornicus [Vorn@ServerAdministrator.Nightstar.Net] has joined #code |
| 01:29 | | mode/#code [+qo Vornicus Vornicus] by ChanServ |
| 01:37 | | Vash [Vash@Nightstar-uhn82m.ct.comcast.net] has joined #code |
| 02:30 | | Vornicus [Vorn@ServerAdministrator.Nightstar.Net] has quit [Connection reset by peer] |
| 02:37 | | Vornicus [Vorn@ServerAdministrator.Nightstar.Net] has joined #code |
| 02:37 | | mode/#code [+qo Vornicus Vornicus] by ChanServ |
| 03:00 | | ion [Owner@Nightstar-i1r.42k.119.199.IP] has quit [Ping timeout: 121 seconds] |
| 03:02 | | ion [Owner@Nightstar-6grqph.vs.shawcable.net] has joined #code |
| 03:02 | | mode/#code [+o ion] by ChanServ |
| 04:08 | | Vash [Vash@Nightstar-uhn82m.ct.comcast.net] has quit [[NS] Quit: Quit] |
| 05:10 | | macdjord [macdjord@Nightstar-cd2k4t.mc.videotron.ca] has joined #code |
| 05:10 | | mode/#code [+o macdjord] by ChanServ |
| 05:40 | | gnolam [lenin@Nightstar-t1tbf0.cust.bahnhof.se] has quit [[NS] Quit: Gone] |
| 06:16 | | celticminstrel is now known as celmin|ZZzzzzz |
| 06:19 | | gnolam [quassel@Nightstar-lhk.n94.131.88.IP] has joined #code |
| 06:19 | | mode/#code [+o gnolam] by ChanServ |
| 06:38 | | gnolam_ [quassel@Nightstar-lhk.n94.131.88.IP] has joined #code |
| 06:41 | | gnolam [quassel@Nightstar-lhk.n94.131.88.IP] has quit [Ping timeout: 121 seconds] |
| 06:48 | | gnolam [quassel@Nightstar-lhk.n94.131.88.IP] has joined #code |
| 06:48 | | mode/#code [+o gnolam] by ChanServ |
| 06:52 | | gnolam_ [quassel@Nightstar-lhk.n94.131.88.IP] has quit [Ping timeout: 121 seconds] |
| 06:59 | | gnolam_ [quassel@Nightstar-lhk.n94.131.88.IP] has joined #code |
| 07:02 | | gnolam [quassel@Nightstar-lhk.n94.131.88.IP] has quit [Ping timeout: 121 seconds] |
| 07:25 | | Kindamoody[zZz] is now known as Kindamoody |
| 08:20 | | Kindamoody is now known as Kindamoody|afk |
| 09:52 | | gnolam_ [quassel@Nightstar-lhk.n94.131.88.IP] has quit [[NS] Quit: Gone] |
| 11:20 | | ASCII [user1@Nightstar-g7hdo5.dyn.optonline.net] has quit [Ping timeout: 121 seconds] |
| --- Log closed Mon Dec 05 13:53:33 2016 |
| --- Log opened Mon Dec 05 13:53:42 2016 |
| 13:53 | | TheWatcher [chris@GlobalOperator.Nightstar.Net] has joined #code |
| 13:53 | | Irssi: #code: Total of 36 nicks [35 ops, 0 halfops, 0 voices, 1 normal] |
| 13:53 | | mode/#code [+o TheWatcher] by ChanServ |
| 13:54 | | * TheWatcher ponders this part of this project |
| 13:54 | | Irssi: Join to #code was synced in 63 secs |
| 13:55 | <@TheWatcher> | Users are supposed to have a PIN they need to enter in certain places |
| 13:55 | <@TheWatcher> | They can, of course, set this. |
| 13:59 | <@TheWatcher> | I'm pondering making it so that if they try setting their PIN to '12345' it returns an error linking them to https://youtu.be/a6iW-8xPw3k?t=12s |
| 14:16 | <&[R]> | Is it a serious professional project? |
| 14:37 | <@TheWatcher> | Vaguely |
| 14:41 | | Vornotron [Vorn@ServerAdministrator.Nightstar.Net] has joined #code |
| 14:44 | | Vornicus [Vorn@ServerAdministrator.Nightstar.Net] has quit [Ping timeout: 121 seconds] |
| 14:46 | <@TheWatcher> | Bah, fine. I'll use "%(code)s is not allowed (this isn't your luggage)" |
| 14:49 | <@Tamber> | hee |
| 15:44 | | macdjord is now known as macdjord|slep |
| 15:44 | | macdjord|slep is now known as macdjord|wurk |
| 16:35 | | celmin|ZZzzzzz is now known as celticminstrel |
| 17:25 | <&jerith> | So, who wants to hear about some terribleness in docker that surpassed my most jaded expectations about it? |
| 17:26 | <@Tamber> | Sure! |
| 17:26 | <&jerith> | Docker has this API, which is the way to talk to the daemon that does all the work. |
| 17:27 | <&jerith> | The `docker` command line tool, among other things, uses this API. |
| 17:29 | <&jerith> | Docker also supports volume driver plugins, wherein docker makes API calls to registered plugins to tell them to mount or unmount volumes. |
| 17:31 | <&jerith> | Sometimes when you use the docker API (usually through the command line tool), you have to wait some annoying amount of time before you get a response. |
| 17:31 | <&jerith> | If you use the docker API from inside your volume driver plugin, you never get a response. |
| 17:32 | <&jerith> | And neither does any other API call to docker. |
| 17:32 | <@Tamber> | Ick. |
| 17:33 | <&jerith> | This is the point at which I should explain why my volume driver API (which is supposed to deal only with external things related to filesystems and such) needs to call back into docker. |
| 17:34 | <&jerith> | The volume driver API protocol is very simple. |
| 17:34 | <&jerith> | Whenever you start a container that uses a volume, docker makes a VolumeDriver.Mount call and waits for you to give it a path to the mounted volume. |
| 17:35 | <&jerith> | Whenever you stop a container that uses a volume, docker makes a VolumeDriver.Unmount call and waits for you to return. |
| 17:35 | <&jerith> | (There are a few more things, but they're not relevant here.) |
| 17:36 | <&jerith> | "But jerith," I hear you ask, "what if more than one container wants to use the same volume?" |
| 17:36 | <&jerith> | Excellent question. |
| 17:37 | <&jerith> | You get a VolumeDriver.Mount call for each when it starts and a VolumeDriver.Unmount call for each when it stops. |
| 17:37 | <&jerith> | It's up to you to figure out which unmount is the last and should result in the volume actually being unmounted. |
| 17:38 | <&jerith> | This means you need to know how many container are still using the volume. |
| 17:39 | <&jerith> | Docker doesn't tell you this through the API. |
| 17:40 | <&jerith> | You can count mount and unmount calls per volume, but it's possible for containers to go away without the unmount (`kill -9 <docker's pid>`, for example) and it's possible for your volume driver process to restart or something. |
| 17:41 | <&jerith> | So pure refcounting is unreliable. |
| 17:41 | <&jerith> | All that's left is to ask docker for all the information it has about all the containers, and grovel through that to find the ones using the volume you've just been asked to unmount. |
| 17:42 | <&jerith> | Except you can't do that, because the docker API isn't reentrant even for read-only queries and the whole fucking thing deadlocks if you try. |
| 17:44 | <&jerith> | So now the only thing I can thing to do is have my unmount handler not actually unmount, but instead schedule an asynchronous task to run later and check if it's safe to unmount the volume. |
| 17:46 | <&jerith> | Except that now leaves us open to all sorts of exciting race conditions, the most obvious of which is that something could ask for the volume between the cleanup task checking if it's used and actually unmounting it. |
| 17:46 | <&jerith> | So doing that would require adding a bunch of nontriivial locking to *my* code. |
| 17:46 | <@Tamber> | That sounds *hilarious*(!) |
| 17:50 | <&jerith> | If it weren't a problem that is actively harmful to my production environment, I might agree. |
| 17:52 | <&jerith> | This is a production environment that runs stuff millions of people (literally, more than two million) rely on for information relevant to their health and wellbeing. |
| 17:53 | <&jerith> | On the bright side, nothing else in the stack is anywhere near as bad as docker. |
| 17:54 | <@Tamber> | *nods* |
| 17:57 | | * celticminstrel wonders if executing bytecode is inherently faster than executing a syntax tree. |
| 17:58 | <&jerith> | celticminstrel: A syntax tree is generally more cumbersome to operate on. |
| 17:59 | <&jerith> | Also, it's bigger and *mumblemumble* CPU cache. |
| 18:00 | <@celticminstrel> | I see. |
| 18:01 | <&jerith> | So while it's definitely possible to build slow bytecode interpreters, my guess is that all else being equal the bytecode is probably a bit faster. |
| 18:02 | | * celticminstrel every so often feels the urge to design a new programming language. Never gets very far, mind you. |
| 18:03 | <&jerith> | The real win is that you'd have to build the syntax tree before you can act on it. Bytecode can be executed directly without all that. |
| 18:03 | <@celticminstrel> | Latest idea was something like, "what if you took all the best things from JavaScript and Lua". |
| 18:04 | <@celticminstrel> | Right, but if you're starting from the source code, that win doesn't really exist, right? |
| 18:04 | <&jerith> | Sure. How often are you executing code that will never be exectued again? |
| 18:04 | <&jerith> | +spelling |
| 18:04 | <@celticminstrel> | No idea! |
| 18:05 | <@celticminstrel> | If I actually made a scripting language it'd probably end up being used in a game. |
| 18:07 | <&jerith> | It's not actually all that hard to turn a thing that executes a syntax tree into a thing that emits bytecode and a thing that executes that bytecode. |
| 18:08 | <@celticminstrel> | I see, so it might be cost-efficient to first write the thing that executes a syntax tree and then, if I end up using it a lot, move it to bytecode. |
| 18:08 | <&jerith> | And you get the benefit of a clean separation between "here be dragons (and dragon books) of text stuff" and "this is where the program runs". |
| 18:08 | <@celticminstrel> | ...heh, what. |
| 18:09 | <&jerith> | And that somewhat clumsy phrasing was nothing more than an excuse to reference the Dragon Book. |
| 18:09 | | gnolam [quassel@Nightstar-t2vo1j.tbcn.telia.com] has joined #code |
| 18:09 | | mode/#code [+o gnolam] by ChanServ |
| 18:09 | <&jerith> | Which I've never read, but which was (and maybe still is) the canonical tome about compilers. |
| 18:44 | | catalyst [catalyst@Nightstar-bt5k4h.81.in-addr.arpa] has joined #code |
| 19:19 | <&ToxicFrog> | celticminstrel: isn't that just "lua, but with 0-indexing"?~ |
| 19:19 | <&ToxicFrog> | jerith: it still was when I took my compilers course in university, at least |
| 19:19 | <&ToxicFrog> | Which was...2007? 2008? |
| 19:20 | <&ToxicFrog> | And yeah, write the thing that executes the syntax tree first, and then if it's useful, evaluate whether you want to write your own bytecode interpreter or emit bytecode for an existing VM. |
| 19:21 | <@celticminstrel> | ToxicFrog: Not really, no. |
| 19:21 | | * ToxicFrog suddenly has an overwhelming but probably not actually useful desire to write a lisp that compiles to lua |
| 19:22 | <@celticminstrel> | I don't know of any good existing VMs besides Java... and I guess .NET. |
| 19:25 | <&ToxicFrog> | LuaJIT is actually really good, and if you favour portability over speed, PUC Lua runs on basically anything that has a C compiler and ~200k of program memory. |
| 19:25 | <&ToxicFrog> | I understand that V8 is pretty good these days, too |
| 19:27 | <@simon_> | celticminstrel, LLVM? |
| 19:27 | <@simon_> | celticminstrel, Parrot? |
| 19:27 | <@simon_> | celticminstrel, (I assume Parrot isn't actually *good*, but it's there!) |
| 19:28 | <@simon_> | ToxicFrog, why compile to Lua and not C? |
| 19:29 | <@simon_> | ToxicFrog, oh, JIT. |
| 19:30 | <@celticminstrel> | ...LLVM? Huh? |
| 19:30 | <@celticminstrel> | V8 is a bytecode interpreter? |
| 19:31 | <&ToxicFrog> | celticminstrel: for JS, yes |
| 19:31 | <&ToxicFrog> | simon_: LLVM is for emitting native code, I thought, not runtime bytecode execution? |
| 19:32 | <&ToxicFrog> | Like, you emit LLVM bytecode and then feed that to an arch-specific backend that emits object code. |
| 19:32 | <&ToxicFrog> | And I'd want to compile to Lua and not C because then I get high performance (via luajit) without needing a separate compile step and without the portability woes of emitting object code. |
| 19:33 | <&jeroud> | Isn't there a pypy lisp?~ |
| 19:38 | <@simon_> | ToxicFrog, right, and ok. |
| 19:40 | <&ToxicFrog> | jeroud: probably, but neither love2d nor te4 speak python |
| 21:48 | | Pink [user1@Nightstar-g7hdo5.dyn.optonline.net] has joined #code |
| 22:05 | | Pink [user1@Nightstar-g7hdo5.dyn.optonline.net] has quit [Ping timeout: 121 seconds] |
| 22:05 | <&jerith> | ToxicFrog: I should have said "rpython", not "pypy". |
| 22:06 | <&McMartin> | ToxicFrog: Did you ever get a chance to look at that FreeDOS image, while we're at it |
| 22:06 | <&jerith> | The language runtime is implemented in rpython (which is basically a statically typed subset of python) and gets the benefit of pypy's meta-tracing JIT for very little extra effort. |
| 22:11 | <&McMartin> | https://imgur.com/gallery/WrMJi |
| 22:16 | | Kindamoody|afk is now known as Kindamoody |
| 22:17 | | Alek [Alek@Nightstar-cltq0r.il.comcast.net] has quit [Ping timeout: 121 seconds] |
| 22:21 | | Alek [Alek@Nightstar-cltq0r.il.comcast.net] has joined #code |
| 22:21 | | mode/#code [+o Alek] by ChanServ |
| 22:25 | | Alek [Alek@Nightstar-cltq0r.il.comcast.net] has quit [Ping timeout: 121 seconds] |
| 22:28 | | Alek [Alek@Nightstar-cltq0r.il.comcast.net] has joined #code |
| 22:28 | | mode/#code [+o Alek] by ChanServ |
| 22:31 | | himi [sjjf@Nightstar-v37cpe.internode.on.net] has quit [Connection closed] |
| 22:39 | | Kindamoody is now known as Kindamoody[zZz] |
| --- Log closed Mon Dec 05 22:56:57 2016 |
| --- Log opened Mon Dec 05 23:05:51 2016 |
| 23:05 | | TheWatcher [chris@GlobalOperator.Nightstar.Net] has joined #code |
| 23:05 | | Irssi: #code: Total of 37 nicks [34 ops, 0 halfops, 0 voices, 3 normal] |
| 23:05 | | mode/#code [+o TheWatcher] by ChanServ |
| 23:06 | | Irssi: Join to #code was synced in 55 secs |
| 23:47 | | catalyst [catalyst@Nightstar-bt5k4h.81.in-addr.arpa] has quit [[NS] Quit: Leaving] |
| 23:54 | | himi [sjjf@Nightstar-dm0.2ni.203.150.IP] has joined #code |
| 23:54 | | mode/#code [+o himi] by ChanServ |
| --- Log closed Tue Dec 06 00:00:45 2016 |