| --- Log opened Sun Mar 31 00:00:07 2013 |
| --- Day changed Sun Mar 31 2013 |
| 00:00 | <&McMartin> | It looks like you can grab 1.6 from clojure.org. |
| 00:00 | | mac [mac@Nightstar-fe8a1f12.il.comcast.net] has joined #code |
| 00:00 | <&ToxicFrog> | I'm still on 1.4 @.@ |
| 00:00 | <&McMartin> | So was I until this morning |
| 00:00 | <&McMartin> | (And I still am, on Osmium, it looks like) |
| 00:01 | < RichyB> | They've skipped over 1.5.0 because of a late-breaking bug and immediately pushed 1.5.1 |
| 00:01 | <&McMartin> | Aha |
| 00:01 | < RichyB> | The entire changelog for 1.5.1 is "fix for leak caused by ddc65a96fdb1163b" |
| 00:01 | <&McMartin> | Where are the changelogs? |
| 00:02 | < RichyB> | They maintain one in the repo because they're good people. https://github.com/clojure/clojure/blob/master/changes.md |
| 00:02 | | Turaiel is now known as Turaiel[Offline] |
| 00:07 | < RichyB> | So they've got, in 1.5, some kind of efficient catamorphism thing, nicer literals, friendlier threads, better EDSL support, easier Java compat, support for 0-method protocols, closer Emacs support, more consistent behaviour around strings and some collections, and a "safe" version of the reader that isn't just immediately equivalent to eval'ing untrusted streams. |
| 00:11 | <&McMartin> | "some kind of efficient catamorphism thing" |
| 00:11 | <&McMartin> | That's a nearly-transparently parallelizing compiler |
| 00:13 | <&McMartin> | So that's pretty exciting for handling massive datasets. |
| 00:13 | | * RichyB shrug. |
| 00:14 | < RichyB> | I'm used to the same thing being available in GHC as "parMap" instead of "map". |
| 00:14 | < RichyB> | It's more of a sensible equivalent of "#pragma omp parallel for", TBH. |
| 00:15 | <&McMartin> | I can't parse that~ |
| 00:15 | < RichyB> | I'm referring to OpenMP. |
| 00:16 | < RichyB> | If you write C programs with "gcc -fopenmp" then "#pragma omp parralel for \n for (i=0; i<n; i++) { do_stuff(i); }" will cause do_stuff() to get parallelised across all of the available SMP cores. |
| 00:17 | < RichyB> | So it's an annotation on an iteration that all of the iterations could be performed in parallel. |
| 00:17 | <&McMartin> | Ah |
| 00:18 | < RichyB> | It's massively useful because it's just a one-line annotation instead of half a kLOC of farting around with pthread_create() and pthread_fork() |
| 00:18 | <&McMartin> | Quite |
| 00:19 | < RichyB> | it's nowhere near an automatic parallellising compiler - and it doesn't come with the drawbacks of one, because you still have to|get to make your own judgements as to which loops are worth splitting across threads. |
| 00:19 | < RichyB> | Even GHC's `par` function, which is the lowest-overhead parallel split that I know of, still has some overhead. |
| 00:20 | <&McMartin> | Yeah, I'm firmly in the "get to" there >_> |
| 00:22 | | VirusJTG_ [VirusJTG@Nightstar-09c31e7a.sta.comporium.net] has quit [[NS] Quit: Program Shutting down] |
| 00:36 | | himi [fow035@Nightstar-5d05bada.internode.on.net] has quit [Ping timeout: 121 seconds] |
| 00:43 | | VirusJTG [VirusJTG@Nightstar-09c31e7a.sta.comporium.net] has joined #code |
| 00:48 | | celticminstrel [celticminst@Nightstar-e83b3651.cable.rogers.com] has quit [[NS] Quit: KABOOM! It seems that I have exploded. Please wait while I reinstall the universe.] |
| 00:48 | | celticminstrel [celticminst@Nightstar-e83b3651.cable.rogers.com] has joined #code |
| 00:48 | | mode/#code [+o celticminstrel] by ChanServ |
| 00:50 | | himi [fow035@Nightstar-5d05bada.internode.on.net] has joined #code |
| 00:50 | | mode/#code [+o himi] by ChanServ |
| 02:46 | | mac [mac@Nightstar-fe8a1f12.il.comcast.net] has quit [Ping timeout: 121 seconds] |
| 02:47 | | mac [mac@Nightstar-fe8a1f12.il.comcast.net] has joined #code |
| 03:16 | | mac [mac@Nightstar-fe8a1f12.il.comcast.net] has quit [Ping timeout: 121 seconds] |
| 03:17 | | mac [mac@Nightstar-fe8a1f12.il.comcast.net] has joined #code |
| 03:25 | | Kindamoody[zZz] is now known as Kindamoody |
| 03:26 | | thalass [thalass@Nightstar-f97b970e.bigpond.net.au] has quit [Ping timeout: 121 seconds] |
| 03:40 | <&McMartin> | OK, I think I've got all the data collection working for listfile dumping in Ophis. |
| 03:40 | <&McMartin> | Now I just need to format it and then consider refactoring it all. |
| 03:40 | <&McMartin> | Before refactoring it I guess I also need a corpus to check against. |
| 03:44 | <&McMartin> | Mmm. I'm not actually sure it's worth the refactor, even though the current version has typeswitches. |
| 03:50 | | Derakon[AFK] is now known as Derakon |
| 04:09 | | VirusJTG [VirusJTG@Nightstar-09c31e7a.sta.comporium.net] has quit [[NS] Quit: Program Shutting down] |
| 04:18 | | RichyB [richardb@Nightstar-86656b6c.cable.virginmedia.com] has quit [Ping timeout: 121 seconds] |
| 04:40 | | Nemu [NeophoxProd@Nightstar-5e16937e.asahi-net.or.jp] has joined #code |
| 04:42 | | Kindamoody [Kindamoody@Nightstar-05577424.tbcn.telia.com] has quit [[NS] Quit: This network from hell can go back to where it came from, I'm switching to mobile internet!!!] |
| 04:44 | | Syka [the@Nightstar-31d49847.iinet.net.au] has joined #code |
| 04:44 | | Kindamoody|autojoin [Kindamoody@Nightstar-9ddf46a7.cust.tele2.se] has joined #code |
| 04:44 | | mode/#code [+o Kindamoody|autojoin] by ChanServ |
| 04:45 | | Kindamoody|autojoin is now known as Kindamoody |
| 04:49 | | harlow [mac@Nightstar-fe8a1f12.il.comcast.net] has joined #code |
| 04:50 | | mac [mac@Nightstar-fe8a1f12.il.comcast.net] has quit [Ping timeout: 121 seconds] |
| 04:55 | | someoneis [mac@Nightstar-fe8a1f12.il.comcast.net] has joined #code |
| 04:56 | | harlow [mac@Nightstar-fe8a1f12.il.comcast.net] has quit [Ping timeout: 121 seconds] |
| 05:18 | | someoneis [mac@Nightstar-fe8a1f12.il.comcast.net] has left #code ["Leaving"] |
| 05:39 | | jeroud [uid10043@Nightstar-1d9743e5.irccloud.com] has quit [Connection closed] |
| 05:46 | | celticminstrel [celticminst@Nightstar-e83b3651.cable.rogers.com] has quit [[NS] Quit: And lo! The computer falls into a deep sleep, to awake again some other day!] |
| 06:20 | | Derakon is now known as Derakon[AFK] |
| 07:12 | <&McMartin> | Argh |
| 07:12 | | * McMartin appears to have bent MSVS to his will, finally |
| 07:12 | <&McMartin> | I wish there were build systems that weren't made entirely of infinitely recursive spiders |
| 07:13 | < Syka> | write your own one |
| 07:13 | < Syka> | at least the spiders will then be the ones you know |
| 07:13 | <&McMartin> | I am well-versed in the ways of many spider. |
| 07:13 | <&McMartin> | s |
| 07:13 | <&McMartin> | But yeah, it works on MSVS, soon I will need to make it work with Makefiles for the other platforms |
| 07:13 | <&McMartin> | Which are full of Makefile Madness |
| 07:14 | < Syka> | McMartin: just look at pictures of owls and keep in your happy zone |
| 07:14 | < Syka> | here's one to start http://25.media.tumblr.com/00f439b783f5cd6ac7ad150dd5b5fbb3/tumblr_mj3uvcsm6l1r2 wrwho4_r1_250.gif |
| 07:15 | <&McMartin> | D'aww. |
| 07:16 | | * McMartin also applies bunnies. https://cuteoverload.files.wordpress.com/2013/03/8006988311_f955b31ee5_b.jpg |
| 07:16 | <&McMartin> | Sadly, my next stumbling block appears to be an issue with C itself. |
| 07:18 | <&McMartin> | ... |
| 07:18 | <&McMartin> | o_O |
| 07:18 | <&McMartin> | -_- |
| 07:18 | <~Vornicus> | Uh oh. |
| 07:19 | <~Vornicus> | What happened? |
| 07:19 | <&McMartin> | The problem: I want to embed rather a lot of UTF-8 strings in this code. |
| 07:20 | <&McMartin> | The further problem: Unlike in sane languages like, say, Python, \x will take any number of hexits and then bitch when the result is over 255, which is to say, ALL THE TIME IT WAS MORE THAN TWO. |
| 07:20 | <&McMartin> | The solution: Octal. |
| 07:21 | < Syka> | realistic solution: cry |
| 07:21 | <~Vornicus> | I think I don't understand |
| 07:21 | <&McMartin> | OK, so, you know how Python has \unnnn? |
| 07:21 | <&McMartin> | For unicode strings? |
| 07:21 | <~Vornicus> | Right right right. |
| 07:22 | <&McMartin> | And how it also has \xnn, for octets? |
| 07:22 | <~Vornicus> | But in what situation are you putting more than two hexits? |
| 07:22 | <&McMartin> | Oh |
| 07:22 | <&McMartin> | One moment while I make an example that works~ |
| 07:23 | <&McMartin> | Let us say you wished to write out "(C)2013 McMartin" |
| 07:23 | <&McMartin> | That would be "\xc2\xa92013 McMartin" |
| 07:24 | <&McMartin> | Python's cool with that, and does the right thing. |
| 07:24 | <&McMartin> | C tries to jam 0xa920 into a byte and whines. |
| 07:24 | <~Vornicus> | wtf |
| 07:24 | <&McMartin> | The solution is to use \nnn, which is Always An Octet but also always in octal~ |
| 07:26 | <~Vornicus> | Still, wtf at C |
| 07:26 | <&McMartin> | Anyway, the embedder is actually generating C from an XML file, so I by "I have to use octal" I mean that I have r"\%03o" % ord(c) where before I had r"\x%02x" % ord(c) |
| 07:26 | <&McMartin> | Wide strings weren't part of the original, and they're allergic to adding new escape characters =P |
| 07:41 | <&McMartin> | -_- |
| 07:41 | <&McMartin> | Protip: commits work better when the VPN is running |
| 07:44 | <&McMartin> | Success! |
| 07:45 | <&McMartin> | Now I may Bat all the Mans. |
| 07:58 | | thalass [thalass@Nightstar-f97b970e.bigpond.net.au] has joined #code |
| 08:01 | | Orthia [orthianz@3CF3A5.E1CD01.B089B9.1E14D1] has quit [Ping timeout: 121 seconds] |
| 08:08 | | Vornotron [vorn@Nightstar-221158c7.sd.cox.net] has joined #code |
| 08:09 | | Vornicus [vorn@ServerAdministrator.Nightstar.Net] has quit [Ping timeout: 121 seconds] |
| 08:10 | | Vornicus [vorn@Nightstar-221158c7.sd.cox.net] has joined #code |
| 08:10 | | mode/#code [+qo Vornicus Vornicus] by ChanServ |
| 08:12 | | Vornotron [vorn@Nightstar-221158c7.sd.cox.net] has quit [Ping timeout: 121 seconds] |
| 08:34 | | Kindamoody [Kindamoody@Nightstar-9ddf46a7.cust.tele2.se] has quit [Connection reset by peer] |
| 08:34 | | KiMo|autorejoin [Kindamoody@Nightstar-9ddf46a7.cust.tele2.se] has joined #code |
| 08:34 | | mode/#code [+o KiMo|autorejoin] by ChanServ |
| 08:35 | | Orthia [orthianz@3CF3A5.E1CD01.B089B9.1E14D1] has joined #code |
| 08:35 | | mode/#code [+o Orthia] by ChanServ |
| 08:35 | | Nemu [NeophoxProd@Nightstar-5e16937e.asahi-net.or.jp] has quit [Ping timeout: 121 seconds] |
| 08:36 | | KiMo|autorejoin is now known as Kindamoody |
| 08:42 | | thalass [thalass@Nightstar-f97b970e.bigpond.net.au] has quit [Ping timeout: 121 seconds] |
| 09:01 | | Kindamoody is now known as Kindamoody|afk |
| 09:06 | | Kindamoody|afk [Kindamoody@Nightstar-9ddf46a7.cust.tele2.se] has quit [Connection reset by peer] |
| 09:06 | | KiMo|autorejoin [Kindamoody@Nightstar-9ddf46a7.cust.tele2.se] has joined #code |
| 09:06 | | mode/#code [+o KiMo|autorejoin] by ChanServ |
| 09:11 | | KiMo|autorejoin [Kindamoody@Nightstar-9ddf46a7.cust.tele2.se] has quit [Connection reset by peer] |
| 09:13 | | KiMo|autorejoin [Kindamoody@Nightstar-9ddf46a7.cust.tele2.se] has joined #code |
| 09:13 | | mode/#code [+o KiMo|autorejoin] by ChanServ |
| 09:17 | | KiMo|autorejoin [Kindamoody@Nightstar-9ddf46a7.cust.tele2.se] has quit [Connection reset by peer] |
| 09:18 | | KiMo|autorejoin [Kindamoody@Nightstar-9ddf46a7.cust.tele2.se] has joined #code |
| 09:19 | | mode/#code [+o KiMo|autorejoin] by ChanServ |
| 09:20 | | KiMo|autorejoin [Kindamoody@Nightstar-9ddf46a7.cust.tele2.se] has quit [Connection reset by peer] |
| 09:20 | | thalass [thalass@Nightstar-f97b970e.bigpond.net.au] has joined #code |
| 09:22 | | KiMo|autorejoin [Kindamoody@Nightstar-9ddf46a7.cust.tele2.se] has joined #code |
| 09:22 | | mode/#code [+o KiMo|autorejoin] by ChanServ |
| 09:29 | <@froztbyte> | <McMartin> Protip: commits work better when the VPN is running |
| 09:29 | <@froztbyte> | why do your commits need remote access to work? ;p |
| 09:56 | <&McMartin> | Because we use SVN. |
| 09:56 | <&McMartin> | If we were using git, then that sentence would have been "pushes to buildbot" |
| 09:57 | <@froztbyte> | SVN really is a terrible blight |
| 09:57 | <&McMartin> | I seriously do not understand what you folks are smoking. |
| 09:57 | <&McMartin> | Does your memory not go back more than two years or what |
| 09:59 | | KiMo|autorejoin is now known as Kindamoody |
| 09:59 | <~Vornicus> | more like two weeks, considering how often you seem to need to explain this |
| 09:59 | | * Vornicus kimogreets |
| 09:59 | <@Kindamoody> | Hi Vorn. ^^ |
| 10:01 | <~Vornicus> | (though why you say two years, I'm curious about) |
| 10:02 | <&McMartin> | (Because while DVCSes go back quite aways, they haven't been the default expectation until quite recently.) |
| 10:02 | <&McMartin> | (And it has to be recent enough that they can't have ever even heard of CVS, much less the two additional generations of VCSes that CVS was a gigantic step ahead of) |
| 10:02 | <&McMartin> | (...and which I had to actually use as an undergrad) |
| 10:04 | <&jerith> | I can understand why SVN is still widely used, but that doesn't make it less terrible. |
| 10:04 | <&jerith> | Of course, git, hg, etc. are also terrible. |
| 10:05 | | Kindamoody [Kindamoody@Nightstar-9ddf46a7.cust.tele2.se] has quit [[NS] Quit: My client derps, I can hear someone pm-ing me but I can't see who. brb] |
| 10:06 | | Kindamoody|autojoin [Kindamoody@Nightstar-9ddf46a7.cust.tele2.se] has joined #code |
| 10:06 | | mode/#code [+o Kindamoody|autojoin] by ChanServ |
| 10:06 | | Kindamoody|autojoin is now known as Kindamoody |
| 10:09 | <&McMartin> | I still think it's great that a sizable community took the acceleration of SVN development post-1.5 (which is to say, making branches actually work right, centralizing the local repository information, etc.) as a personal affront |
| 10:09 | < AnnoDomini> | Is there anything particularly worthwhile that I should back up outside of ~ if I want to upgrade Debian by installing over the previous one? |
| 10:09 | <&McMartin> | Not a Debian expert, but have you mucked around with anything in /etc? |
| 10:10 | < AnnoDomini> | Probably, but I'm not sure anything in there is particularly needful to me. I know I left the normal setup for disk mounting this time around. |
| 10:11 | <&McMartin> | I can't think of anything obvious, then. |
| 10:11 | <&McMartin> | But I don't run Debian, I just ignore bug reports from people running stable~ |
| 10:11 | < AnnoDomini> | I'll back /etc/ up just in case. |
| 10:15 | | * AnnoDomini is currently running a safe-upgraded stable/testing, which sort of works, but not quite. |
| 10:15 | <&McMartin> | I hear they've gotten better since I set my policy, but I still have seen no reason to change it. |
| 10:16 | <&McMartin> | There was stuff something like nine releases out of date |
| 10:16 | <&McMartin> | How dare I rely on unstable new features that were introduced a mere seven releases ago |
| 10:24 | <@froztbyte> | McMartin: no, I've never asked you about this before |
| 10:24 | <&McMartin> | froztbyte: I didn't mean what Vorn did |
| 10:24 | <@froztbyte> | McMartin: and I'm fully aware of the fact that there are hysterical raisins why you find svn everywhere |
| 10:24 | <@froztbyte> | but yeah |
| 10:25 | <@froztbyte> | all things are terribad |
| 10:25 | <&McMartin> | I meant "seriously have ever actually seen CVS" |
| 10:25 | <@froztbyte> | let's burn a planet |
| 10:25 | <@froztbyte> | McMartin: oh, well, yeah |
| 10:25 | <@froztbyte> | I have :( |
| 10:25 | <@froztbyte> | in fact, I had to use it for a while |
| 10:25 | <&McMartin> | Here's the thing |
| 10:25 | <&McMartin> | CVS was huge steps ahead of what came before |
| 10:25 | <&McMartin> | In that it actually had the idea of merging changes |
| 10:25 | <&McMartin> | Instead of *remotely locking the edited file for all users during the entire duration of the programmer doing the editing* |
| 10:26 | <&McMartin> | Which was the old hotness because you could actually not trash each other's changes~ |
| 10:26 | <&McMartin> | But more seriously, it seems like Kids These Days have largely actually *never used non-DVCS* |
| 10:27 | <&McMartin> | (And actually, the work repository is structured in a way that DVCS happens to be bad at) |
| 10:28 | <&McMartin> | (Which is also why UQM is still SVN.) |
| 10:29 | <&McMartin> | (Clearly, we need to shift everything over to Maven >_>) |
| 10:29 | <&McMartin> | (By which I mean "nope") |
| 10:32 | <&McMartin> | All that said |
| 10:32 | <&McMartin> | 02:23 <@froztbyte> all things are terribad |
| 10:33 | <&McMartin> | I disagree. |
| 10:33 | <&McMartin> | SVN and Git are both good enough at what they do that neither provides much friction. |
| 10:34 | <&McMartin> | (This statement has only been true since Git started shipping with enough of MSYS to actually run out of the box on Windows, and SVN since 1.6 when they finally managed to get enough of Perforce cloned to get branching and merging reliable) |
| 10:34 | <@froztbyte> | the thing about git that makes me rage is that it has no internal consistency |
| 10:34 | <@froztbyte> | you don't so much understand how git works as to learn how to use git to achieve a collection of tasks |
| 10:34 | <@froztbyte> | and that strikes me as a bit dumb |
| 10:34 | <&McMartin> | Git is a functional nested map object that you can manipulate in various ways~ |
| 10:35 | <&McMartin> | Seriously, this is how I think of it |
| 10:35 | <&McMartin> | Trees are maps, Blobs are leaf values |
| 10:35 | < AnnoDomini> | As a Dwarf Fortress player, I find git's interface perfectly logical and consistent. |
| 10:35 | <&McMartin> | "Take all the SVN commands and make them do destructive things for spite" |
| 10:36 | | * McMartin is however noticably more offended by git checkout than git revert |
| 10:36 | <&McMartin> | Git revert makes perfect sense if you think "functional map"~ |
| 10:36 | <@froztbyte> | haha |
| 10:37 | <@froztbyte> | also, omnomnom noodles :> |
| 10:37 | <@froztbyte> | <McMartin> Instead of *remotely locking the edited file for all users during the entire duration of the programmer doing the editing* |
| 10:37 | <@froztbyte> | it's kinda strange to me that editor locking behaviour is still roughly that |
| 10:38 | <&McMartin> | RCS strikes again~ |
| 10:38 | <@froztbyte> | teehee |
| 10:38 | <@froztbyte> | but think about it |
| 10:38 | <&McMartin> | Well, more seriously, a lot of OSes let you open a file exclusively |
| 10:38 | <@froztbyte> | Sublime Text is in python, right? and difflib's in python |
| 10:39 | <&jerith> | froztbyte: ST2 isn't in Python. |
| 10:39 | <@froztbyte> | so the fact that it doesn't have any sort of mediated locking functionality or so is just kinda dumb |
| 10:39 | <&jerith> | It just has a Python API. |
| 10:39 | <@froztbyte> | jerith: oh |
| 10:39 | <@froztbyte> | well, close enough ;p |
| 10:39 | <@froztbyte> | but same for vim |
| 10:39 | <@froztbyte> | in fact, vim is a pretty damn good example |
| 10:39 | <@froztbyte> | because it already supports some sort of session shit |
| 10:39 | <@froztbyte> | where you can connect up to a different process |
| 10:40 | <&jerith> | McMartin: git makes sense if you treat it as a revision tree manipulation system rather than a revision control system. |
| 10:40 | <&jerith> | Which is similar to what you're saying but not quite the same. |
| 10:40 | <&McMartin> | jerith: Less so, becuase one could imagine that a revision tree manipulator might allow, you know, mutation. |
| 10:41 | <&jerith> | It was designed specifically to throw patches around between different trees. |
| 10:41 | | Nemu [NeophoxProd@Nightstar-5e16937e.asahi-net.or.jp] has joined #code |
| 10:41 | <&jerith> | McMartin: You can mutate in the sense that you can create new changesets out of old ones. |
| 10:43 | <&jerith> | You can arbitrarily change the state of the tree as well, but then you can't push nondestructively to other clones of the tree. |
| 10:43 | <&McMartin> | Well, that part is "and it's content-addressed", which has extremely far-reaching implications. |
| 10:48 | | * McMartin goes back to unleashing a standalone Mad Refactoring Bot against the codebase. |
| 10:48 | <&jerith> | That's either awesome or horrible. |
| 10:48 | <&jerith> | What does the MRB do? |
| 10:48 | | Kindamoody [Kindamoody@Nightstar-9ddf46a7.cust.tele2.se] has quit [[NS] Quit: Changing connections, brb] |
| 10:49 | <&McMartin> | I'm splitting one rather large library a lot of this code depends on into two smaller ones. That part is now working. |
| 10:49 | <&McMartin> | What I now need to do is change a piece of the API in the smaller one, and its use in the old and bad way is pervasive. |
| 10:49 | <&McMartin> | So I've thrown together a custom lexer to do what needs to be done to the rest of the code. |
| 10:49 | <&jerith> | C code? |
| 10:49 | <&McMartin> | A dry run that is Just The Analyzer indicates that this will end up touching about 200 files. |
| 10:49 | <&McMartin> | C++. |
| 10:50 | <&jerith> | Ah. |
| 10:50 | <@froztbyte> | that sounds pretty cool |
| 10:50 | | Kindamoody|autojoin [Kindamoody@Nightstar-e9aa495d.tbcn.telia.com] has joined #code |
| 10:50 | | mode/#code [+o Kindamoody|autojoin] by ChanServ |
| 10:50 | <&McMartin> | If it weren't for the library change part I could do this with sed. |
| 10:50 | | Kindamoody|autojoin is now known as Kindamoody |
| 10:50 | <&jerith> | How extensive is the API change? |
| 10:51 | <&McMartin> | However, in doing that I believe I will be turning the Mad Refactoring Bot into a report generator once it's done; shifting what it looks for to look for the new form instead of the old and ensure all data is consistent |
| 10:51 | <&McMartin> | Turning several thousand field references into a method call. One method, old field value now informs the argument but is not identical to it. |
| 10:51 | <&jerith> | Not just a reordering of function parameters or something, I take it. |
| 10:52 | <&McMartin> | The thing is, because they used to be field references, the compiler could check various useful correctness properties for us; the refactorer will eventually itself be refactored into a lint-like tool to do those checks. |
| 10:53 | <&jerith> | How likely is this to accidentally modify things that are unrelated to this API? |
| 10:53 | <&McMartin> | And it's not particularly nasty. It's about a hundred lines of Python including the prettyprinting code |
| 10:53 | <&McMartin> | After studying the dry run results I believe that will not happen |
| 10:53 | <&McMartin> | But, um, I'll be checking the diff before it goes in, yes~ |
| 10:53 | <&jerith> | I suppose the compiler will catch places where it's a problem. |
| 10:54 | <&jerith> | Because static typing. |
| 10:54 | <&McMartin> | Quite so. |
| 10:54 | <&McMartin> | Also, linkage. |
| 10:54 | <&McMartin> | The field-to-method shift is exceedingly unlikely to have false positives. |
| 10:54 | <&McMartin> | Due to the strings involved (as I said, that part I could arguably do with sed if I didn't want a report generator to go with it) |
| 10:55 | <&McMartin> | (...and if the part that makes sure that what it is doing is sane didn't involve pulling the relevant data out of about 2000 lines of XML which is the Single Point Of Truth) |
| 10:56 | <&jerith> | Are you using etree for the XML? |
| 10:56 | <&McMartin> | xml.dom.minidom |
| 10:56 | <&jerith> | Ah. |
| 10:56 | <&jerith> | That's a more painful API, but less prone to silliness. |
| 10:56 | <&McMartin> | Which is directly referenced in exactly two lines of code, both of which are list comprehensions. |
| 10:57 | | * McMartin is pretty good at making sure that when he uses XML it is Only For Good. |
| 10:57 | <&jerith> | I have a pure-Python XPath engine if you need something more horrible.~ |
| 10:57 | <&jerith> | (Although it still has a bunch of rough edges.) |
| 10:57 | <&McMartin> | I'd change the schema first~ |
| 10:57 | <@froztbyte> | jerith: did you ever finish making that a thing on parsely? |
| 10:57 | <&McMartin> | (The XML format here is completely under my control.) |
| 10:57 | <@froztbyte> | (is it parsley these days?) |
| 10:58 | | Nemu_ [NeophoxProd@Nightstar-5c549f6e.asahi-net.or.jp] has joined #code |
| 10:58 | <&jerith> | froztbyte: I have both PLY and parsley versions. The parsley version is much nicer, but it's also much slower. |
| 10:59 | <&jerith> | (Due almost entirely to the fact that it has to generate a new parser every time instead of caching it.) |
| 10:59 | <&jerith> | And it has always been "parsley". |
| 11:01 | | Vornicus [vorn@Nightstar-221158c7.sd.cox.net] has quit [[NS] Quit: ] |
| 11:01 | | Nemu [NeophoxProd@Nightstar-5e16937e.asahi-net.or.jp] has quit [Ping timeout: 121 seconds] |
| 11:14 | | thalass [thalass@Nightstar-f97b970e.bigpond.net.au] has quit [Ping timeout: 121 seconds] |
| 11:22 | | * McMartin readies... a machine for pigs |
| 11:23 | | * jerith prepares... the bacon plate |
| 11:23 | <@froztbyte> | jerith: oh, no solution to the cache issue yet? :s |
| 11:23 | <@froztbyte> | then again, having read that conversation at the time, I'm also not really sure how one would go around doing so |
| 11:25 | <&jerith> | froztbyte: The build system already does that, because parsley's parser is implemented in parsley. |
| 11:25 | <&jerith> | It's just a matter of generalising it, etc. |
| 11:56 | < AnnoDomini> | This backup is taking more time than anticipated. |
| 12:00 | <&McMartin> | Woo |
| 12:00 | <&McMartin> | Many hundreds of compilation errors |
| 12:04 | < Syka> | whoooo |
| 12:08 | <&jerith> | McMartin: Your army of robots not quite trained well enough yet? |
| 12:10 | <&McMartin> | More foes than I expected, more like. |
| 12:10 | <&McMartin> | There are places that expect char * and that are now getting std::string. |
| 12:10 | <&McMartin> | I feel the correct approach here is to Start Accepting std::string. |
| 12:11 | <&jerith> | Isn't that a bug? |
| 12:11 | <&jerith> | In the existing code, I mean. |
| 12:11 | <&McMartin> | Yes~ |
| 12:11 | <&McMartin> | But it compiled before. Now it doesn't. |
| 12:11 | < Syka> | WELCOME TO C |
| 12:11 | <&McMartin> | Training the robots would thus be solving the wrong problem. |
| 12:15 | <&jerith> | That depends on what you're training them to do.~ |
| 12:17 | <&McMartin> | True enough |
| 12:17 | <&McMartin> | I think the bits I *can't* warp will fall to manual correction or simple one-off regexes. |
| 12:19 | <&McMartin> | And we are now down from 700 errors to 16. |
| 12:20 | < Syka> | related http://reddrgn.net/cplusplus.jpg :P |
| 12:21 | <&McMartin> | Errors gone. |
| 12:23 | <&jerith> | Do the tests pass? |
| 12:25 | <&McMartin> | It doesn't compile yet. |
| 12:25 | <&McMartin> | So no. |
| 12:25 | <&McMartin> | "Do the tests pass" is a question that requires deploying it alongside at least four other programs on at least two other machines. |
| 12:25 | <&McMartin> | I can't do that while dicking around over the weekend, much less pre-upload. |
| 12:26 | <&jerith> | Ah. I thought "errors gone" meant "now compiles". |
| 12:26 | <&McMartin> | Yeah |
| 12:26 | <&McMartin> | That's one module out of... 180 or so. |
| 12:26 | <&jerith> | Ah. |
| 12:26 | <&McMartin> | But yes, we've learned long ago to our costs that "unit tests" on the client component of this system mean precisely dick |
| 12:27 | <&McMartin> | *Every* interesting failure mode it has comes out in systemic. |
| 12:28 | <&jerith> | What's the interface between the client component and the rest of the system? |
| 12:28 | <&McMartin> | HTTP, mostly. |
| 12:28 | <&McMartin> | To the tune of many gigabytes from encrypted datastores that you negotiate authentication for independently, etc, and then do things with. |
| 12:29 | <&McMartin> | To grossly oversimplify, the client application is iTunes for centrally-managed VMs. |
| 12:30 | <&McMartin> | As far as network traffic, the client is not *too* hard to fake, so the servers have a variety of mock harnesses that can put them through their paces. |
| 12:30 | <&McMartin> | But we have yet to get anything remotely resembling a mock server that behaves appropriately |
| 12:30 | <&McMartin> | Which means the unit tests for the client component are stuff like "are you correctly parsing your configuration files" |
| 12:30 | | thalass [thalass@Nightstar-f97b970e.bigpond.net.au] has joined #code |
| 12:30 | <&McMartin> | "Can you make net connections, generally" |
| 12:31 | <&McMartin> | But once you get past "can you start getting the data you need" and into "... and then actually do anything actually useful with it" you're out of potted-inputs land. |
| 12:32 | <&jerith> | What about recording traffic between the client and the server for assert/replay in tests? |
| 12:32 | <&McMartin> | That would mean we'd be vulnerable to replay attacks, would it not~ |
| 12:32 | <&McMartin> | One can often cache the results of previous successful runs and keep them around, if one *only* wishes to test the post-download operations. |
| 12:32 | <&jerith> | The server has to be robust against them, certainly. |
| 12:33 | < Syka> | you're never going to get testable code if nothing is static |
| 12:33 | < Syka> | or if nothing is repeatable, rather |
| 12:33 | <&McMartin> | Syka: Basically, the simple test here is (to go to iTunes again), "When I hit play, does music come out" |
| 12:34 | <&McMartin> | Actually running the full test suite of all components of the software takes 2-3 man-weeks. |
| 12:35 | <&McMartin> | But the kinds of things you can build into unit tests don't tell you shit for the kinds of things we find that go wrong. |
| 12:35 | <&McMartin> | (Arguably by definition, since things that do go wrong at that level don't make it to QA.) |
| 12:36 | <&McMartin> | So you can start with a music library pre-loaded. |
| 12:36 | <&McMartin> | I will need to confirm that I haven't introduced systemic regressions, but none of the tests here will show that the stuff I'm working on here "worked" because what I'm actually changing here is aspects of the UI. |
| 12:36 | <&McMartin> | So the test is "get it running, and run it through every display it can make to the user and ensure that it looks right with respect to the design". |
| 12:40 | <&jerith> | McMartin: The thing I wrote made calls to domain registrars and recorded the requests and responses. |
| 12:41 | <&McMartin> | Sure, that part is fine. |
| 12:41 | <&McMartin> | It's not too difficult to mock the server for that... |
| 12:41 | <&McMartin> | But that doesn't get you your "music files" |
| 12:41 | <&McMartin> | Which are 4-10GB for a test that's likely to be representative of anything. |
| 12:41 | <&McMartin> | Again, depending on which component you're modifying. |
| 12:41 | <&jerith> | I had some basic template substitution in it, so the client would generate a random domain name to register (necessary against a stateful registrar sandbox) and that would be extracted from the request and subbed into a response. |
| 12:42 | <&jerith> | Do you actually need all of that for most of the tests? |
| 12:42 | <&McMartin> | Yes. |
| 12:42 | <&McMartin> | Part of the system is a series of daemons that run on a Windows OS inside the VM controlled by the box. |
| 12:43 | <&McMartin> | Then there is the client box, and the server that controls policy for our product, and the image server that gets you the VM. |
| 12:43 | <&McMartin> | You can cache that latter stuff locally |
| 12:43 | <&McMartin> | But again |
| 12:43 | <&McMartin> | The changes I'm making are UI |
| 12:44 | <&McMartin> | Even if you've divided up the software so that automation has its hooks into all the core facilities and can work them arbitrarily... |
| 12:44 | <&McMartin> | ... the only way to prove that the UI controls are correctly hooked up is to have something push the buttons and make sure it does too. |
| 12:44 | <&McMartin> | (Also, given our product, you also have to do this on about five different computers because Xp and Win7 don't work the same way, nor do OS X 10.6, 10.7, or 10.8) |
| 12:44 | | Kindamoody is now known as Kindamoody|out |
| 12:45 | <&McMartin> | And past a certain point, it's much easier to point it at a known-good non-mock server in your test lab. |
| 12:46 | <&jerith> | Yeah. |
| 12:46 | <&McMartin> | We *never* - after what I'd estimate to be about a man-year of effort - got any of our mock servers to get an error rate low enough that the automated tests failing were the fault of the product more often than the fault of the tests. |
| 12:47 | <&McMartin> | Beyond the most basic "simulate authentication" stuff. |
| 12:47 | <&McMartin> | (That said, our server is also trivially easy to mass-deploy on stock hardware, which is one of the selling points, so~) |
| 12:48 | <&McMartin> | There are still aspects of our product that I don't think we properly test enough in-house, but I'm not sure at what point our responsibility ends. |
| 12:48 | <&McMartin> | ("If the admin on your domain sets GPO thus-and-so, your product stops working") |
| 12:49 | <&McMartin> | (For which the response can be either "Well, of course it does, don't do that" through "this appears to be due to an only-partially-documented anomaly in Windows's registry reading priority that varies across releases.") |
| 12:50 | <&McMartin> | Part of the joy of being a small company that mostly sells to extremely large companies, a situation that is (a) AFAICT not supposed to be even theoretically possible and (b) basically the norm |
| 12:53 | <&McMartin> | Now that I have a certain greater degree of authority I plan on trying to formalize more of this. |
| 12:54 | <&McMartin> | The strongest institutional block against me being able to do this retired a few months ago, so woo, Klingon promotion >_> |
| 13:05 | <&jerith> | \o/ |
| 13:07 | <&McMartin> | OK, I think that's all the linker dependencies for Windows sorted out. |
| 13:07 | <&McMartin> | For once, the stock MS tools beat Makefiles~ |
| 13:14 | <&jerith> | Makefiles are so very horrible. |
| 13:15 | | thalass [thalass@Nightstar-f97b970e.bigpond.net.au] has quit [Ping timeout: 121 seconds] |
| 13:16 | <&McMartin> | And recursive makefiles are worse |
| 13:16 | <&McMartin> | To fix all the linking breakage in MSVS it was opening two context menus, picking an item off each, and then checking a single checkbox in the resulting dialog. |
| 13:40 | | RichyB [richardb@Nightstar-86656b6c.cable.virginmedia.com] has joined #code |
| 13:48 | <&McMartin> | Ugh |
| 13:49 | | * McMartin puts another ancient design decision onto the Kill List. |
| 13:59 | | * McMartin also queues up the Whetfahrt Cheesefunk |
| 14:20 | | thalass [thalass@Nightstar-f97b970e.bigpond.net.au] has joined #code |
| 14:21 | <&McMartin> | ??????? |
| 14:21 | <&McMartin> | ?????? even |
| 14:21 | | Nemu_ [NeophoxProd@Nightstar-5c549f6e.asahi-net.or.jp] has quit [Ping timeout: 121 seconds] |
| 14:24 | | celticminstrel [celticminst@Nightstar-e83b3651.cable.rogers.com] has joined #code |
| 14:24 | | mode/#code [+o celticminstrel] by ChanServ |
| 14:36 | | Orthia [orthianz@3CF3A5.E1CD01.B089B9.1E14D1] has quit [Ping timeout: 121 seconds] |
| 14:39 | <&McMartin> | aaaand now we're up to 910 errors |
| 14:39 | <&McMartin> | This needs one human pass and then I can send a couple more waves of robots. |
| 14:51 | <@froztbyte> | McMartin: that's not really a klingon promotion, unless you missed a 'was' before retired |
| 15:16 | | jeroud [uid10043@Nightstar-13dfc6f9.irccloud.com] has joined #code |
| 15:16 | | * sshine has problems building a GCC cross-compiler. |
| 15:18 | <@Tamber> | The problem is, of course, you're building a GCC cross-compiler. |
| 15:19 | <@sshine> | configure:4457: /home/simon/Downloads/build-gcc/./gcc/xgcc -B/home/simon/Downloads/build-gcc/./gcc/ -B/opt/osm/mips-elf/bin/ -B/opt/osm/mips-elf/lib/ -isystem /opt/osm/mips-elf/include -isystem /opt/osm/mips-elf/sys-include -c -g -O2 conftest.c >&5 |
| 15:19 | <@sshine> | conftest.c:12:19: fatal error: stdio.h: No such file or directory |
| 15:19 | <@sshine> | #include <stdio.h> |
| 15:19 | <@Tamber> | ... |
| 15:20 | <@Tamber> | I'm sure I've seen that before when I tried to get a mips crosscompiler working, but for the life of me I can't remember *why* it happened, or how I fixed it. One moment. |
| 15:20 | <@sshine> | the problem seems to be that for this one library, libssp, it looks for stdio.h in the wrong place. I'm compiling my cross-compiler with --prefix=/opt/osm |
| 15:20 | <@sshine> | I'm using the configure parameters recommended by those who build the toy operating system I intend to compile. |
| 15:21 | <@sshine> | ../gcc-4.0.2/configure --with-gnu-ld --with-gnu-as --without-nls --enable-languages=c --disable-multilib --target=mips-elf --prefix=$PREFIX (where I'm using GCC 4.8.0 instead) |
| 15:21 | <@Tamber> | Hmmmm. |
| 15:23 | <@sshine> | http://paste.roguecoders.com/p/1c98301d05785d5390d28158ed647a2a.txt are my errors |
| 15:23 | <@sshine> | but checking mips-elf/libssp/config.log, it said the thing above... |
| 15:24 | <@sshine> | which corresponds well to its inability at recognizing basic things like size_t, strlen(), etc. |
| 15:24 | <@Tamber> | Missing libc? |
| 15:24 | <@Tamber> | Or, at least, libc headers? |
| 15:24 | <@sshine> | ummm |
| 15:24 | <@sshine> | core/gcc 4.7.2-4 (base-devel) [installed] |
| 15:24 | <@sshine> | core/gcc-libs 4.7.2-4 (base) [installed] |
| 15:24 | <@sshine> | multilib/lib32-gcc-libs 4.7.2-4 [installed] |
| 15:25 | <@sshine> | I don't know if I should need more. |
| 15:26 | <@Tamber> | Er, let me try again with that. Are you missing the libc/libc headers for the *cross-compiler*? |
| 15:27 | <@sshine> | well, I'm hoping I don't need the headers for the cross-compiler in order to install it... |
| 15:27 | <@Tamber> | http://www.gentoo.org/doc/en/draft/bootstrapping-guide.xml |
| 15:27 | <@Tamber> | See ?2.4 |
| 15:29 | <@Tamber> | You need the cross binutils and glibc headers before you can build the cross-compiler, then building glibc itself. (...then re-building the cross-compiler, etc.) |
| 15:29 | <@Tamber> | At least, as far as I understand/remember it. |
| 15:30 | <@sshine> | ok. I do have the cross binutils |
| 15:30 | <@sshine> | and they're in my path. but maybe they're not in my includepath or something |
| 15:30 | <@Tamber> | And the glibc headers? |
| 15:30 | <@sshine> | no, I didn't make an effort to get those first. |
| 15:30 | <@sshine> | so I'll get the cross-compiler glibc going first. thanks! |
| 15:31 | <@Tamber> | It's all a horrible, tangled mess. :D |
| 15:31 | <@sshine> | doesn't it come with gcc-4.8.0? |
| 15:32 | <@Tamber> | What, glibc? Not that I know of. |
| 15:32 | <@sshine> | oh. |
| 15:32 | <@Tamber> | http://www.gnu.org/software/libc/libc.html |
| 15:33 | <@sshine> | the guide at http://www.niksula.hut.fi/~buenos/cross-compiler.html doesn't mention building glibc for my cross-compiler before... |
| 15:33 | <@sshine> | (only that binutils for my cross-compiler should be in my path) |
| 15:33 | <@sshine> | well, it does say "some tools, like binutils"... maybe that involves glibc. ;) |
| 15:33 | <@Tamber> | Perhaps. :p |
| 15:34 | <@Tamber> | Well, at least just the glibc headers. |
| 15:34 | <@Tamber> | cross compiling is Fun. |
| 15:35 | <@sshine> | hehe |
| 15:35 | | thalass [thalass@Nightstar-f97b970e.bigpond.net.au] has quit [Operation timed out] |
| 15:35 | <@sshine> | GCC is complex. |
| 15:36 | <@Tamber> | Hrm. It doesn't seem to mention glibc at all on that page. |
| 15:38 | | * sshine checks out an Arch AUR package named "aur/cross-mipsel-linux-gnu-gcc" |
| 15:42 | <@sshine> | ah yeah, I found another howto that does recommend installing glibc. I'll see if the AUR package works out and build a better tutorial that mentions glibc if not. :) |
| 15:44 | <@sshine> | I wonder what the difference is between "mips-gnu-as" and "mipsel-linux-gnu-as". |
| 15:44 | <@sshine> | ah, just the name it seems. |
| 15:46 | <@sshine> | "Crosscompiling GNU libc is always only the second best solution as certain parts of it will not be compiled when crosscompiling. A proper solution will be documented here as soon as it is available and believed to be stable." -- from http://linuxdocs.org/HOWTOs/MIPS-HOWTO-9.html |
| 15:47 | <@Tamber> | Ahehehehehe |
| 15:47 | <@Tamber> | So, never, then. |
| 15:48 | <@Tamber> | A "second best solution" is better than a "best solution" that doesn't exist. |
| 15:54 | <@sshine> | yeah :) |
| 16:09 | <@sshine> | haha, I'm an idiot. |
| 16:10 | <@sshine> | I can just disable the library that's bugging me. |
| 16:10 | <@sshine> | apparently, whatever libssp is, it isn't very important for my needs. |
| 16:10 | <@sshine> | it's a library for inserting stack-overflow protection canaries. |
| 16:10 | <@sshine> | "canaries" |
| 16:11 | <@Tamber> | Ahh |
| 16:11 | <@Tamber> | Well, that's helpful. |
| 16:11 | <@sshine> | it is. |
| 16:11 | <@sshine> | but apparently not essential. I suppose it might help debugging in some cases... |
| 16:12 | <@sshine> | but debugging this operating system at run-time is kind of difficult either way |
| 16:13 | <@sshine> | i.e. the memory management is pretty tight, so stack-overflow protection would probably only be useful in debugging user-land programs and not the kernel itself. |
| 16:13 | <@Tamber> | *nods* |
| 16:13 | <@Tamber> | I meant being able to disable it is helpful, but yes; that point stands too. :) |
| 16:14 | <@sshine> | ah, right :) so my current strategy is just to disable anything that errors. ;-) |
| 16:14 | <@Tamber> | :D |
| 16:15 | <@Azash> | 17:10 <@sshine> it's a library for inserting stack-overflow protection canaries. < doesn't this sound more like a task for the OS? |
| 16:15 | <@sshine> | sheesh. I'm a TA, and getting this darned thing to work has been bugging me all day. I can't imagine that a lot of people actually get this working by themselves. |
| 16:15 | <@sshine> | Azash, it's hard for the OS to check when a boundary is crossed in userland. |
| 16:16 | <@sshine> | Azash, I'm not sure how you'd accomplish that. |
| 16:16 | <@sshine> | Azash, either you use a programming language that isn't as insane as C and doesn't allow arbitrary addressing, or you add some run-time checking to your binaries that checks if certain memory areas between stack-frames are ever crossed by means of overwriting. |
| 16:16 | <@Azash> | Doesn't the OS manage the stack and heap? |
| 16:17 | <@sshine> | Azash, it manages the allocation of the stack and the heap, but not the use of it, which purely happens in userland. |
| 16:17 | <@Azash> | Yes, I'm aware of that |
| 16:18 | <@sshine> | I'd like to know what other kind of protection you could add from the operating system's side... |
| 16:18 | <@Azash> | But why couldn't the OS place a one-byte canary between, say, two allocated heap areas? |
| 16:18 | <@Azash> | Or between stack frames? |
| 16:18 | <@sshine> | you'd have to make one function's stack-frame inaccessible to its recursive calls by means of the operating system... |
| 16:19 | <@sshine> | which means that recursive calls essentially become system calls. I think that might be too expensive. |
| 16:19 | <@sshine> | unless you invent some inexpensive syscalls. |
| 16:20 | <@Azash> | Wouldn't recursive calls just add stack frames rather than access an existing one? (if I understood you correctly, for which there are no guarantees) |
| 16:30 | | VirusJTG [VirusJTG@Nightstar-09c31e7a.sta.comporium.net] has joined #code |
| 16:47 | < RichyB> | Azash: noo, the OS does not manage the stack and heap for you. (*) |
| 16:50 | < RichyB> | On a modern Unix, all the OS does for you (w.r.t memory layout) is gives you an interface to allocate&free pages and sets you up with your initial mappings and stack. |
| 16:50 | <@sshine> | Azash, recursive calls would add stack frames, but the call might try to illegally access existing ones. there is no operating system code running between recursive calls that checks if this happened. |
| 16:50 | < RichyB> | The heap is entirely managed in userland, the stack can be. |
| 16:51 | < RichyB> | Er, the stack can be? The stack is. |
| 16:51 | < RichyB> | It's your programming language's run-time that has the duty of managing the size of the call stack & heap. |
| 16:52 | < RichyB> | For convenience, most OSes will hand you an initial stack with ~2MB of pages already set up so that C programs don't usually need stack extension anyway. |
| 16:52 | <@sshine> | some run-times don't need stack-frame protection because they're not possible, and so adding mandatory operating system support for it would limit efficiency. |
| 16:53 | < RichyB> | Right. You could quite happily write a virtual machine that doesn't even use a call stack. |
| 16:53 | <@Azash> | RichyB: Alright, thanks |
| 16:53 | < RichyB> | You also never want to have the OS manage anything that it doesn't have to, because going into and out of the kernel is really expensive. |
| 16:54 | < RichyB> | AIUI this situation is a bit different on Windows |
| 16:54 | <@Azash> | Well, yeah, the idea would've been to check canaries just before resuming execution |
| 16:54 | < RichyB> | AIUI on Windows the deal is that every process manages its own stack and heap in userland, so that's just the same, but there are a bunch of things external to your process that will make assumptions about how you lay out and use memory and if you violate those assumptions then you get undefined behaviour. |
| 16:55 | < RichyB> | Azash: note that "2MB of pages allocated" isn't the same thing as "2MB of RAM allocated". ? |
| 16:56 | < RichyB> | Just because 2MB of my process-local address space is marked out doesn't mean that there's 2MB of physical RAM backing it yet. ? |
| 16:57 | <@Azash> | Aye, I know |
| 16:57 | <@sshine> | RichyB, I wonder if, since Linux doesn't actually give you the memory before you use it, if you address something five pages into your virtual address space, does it only allocate that page? that is, do you think modern Unices are even lazy towards the individual pages? |
| 16:58 | < RichyB> | sshine: yep, they're lazy down to individual pages. |
| 16:58 | < RichyB> | Don't *have* to be, because whether they are or aren't isn't visible to you. |
| 16:59 | <@sshine> | I just realized that that'd be both cheaper and easier to optimize towards. |
| 16:59 | <@sshine> | I wonder what datastructure is being used to keep the actually allocated pages. |
| 17:00 | <@sshine> | woohoo, my GCC cross-compiler compiled! |
| 17:00 | <@sshine> | (without compiling glibc first, simply disabling LibSSP.) |
| 17:00 | <@Tamber> | \o/ |
| 17:00 | <@sshine> | I suppose this only works because my current non-cross glibc is recent enough. |
| 17:01 | <@sshine> | maybe. |
| 17:28 | | Syka is now known as syksleep |
| 17:32 | | d4de [olorin@687AAB.418D22.69C423.728303] has quit [Ping timeout: 121 seconds] |
| 17:36 | | Derakon[AFK] is now known as Derakon |
| 17:39 | < RichyB> | Okay, so, don't use OpenMP in real-time applications that have deadlines under 10ms. |
| 17:39 | <@Tamber> | How badly did it end? |
| 17:42 | < RichyB> | https://github.com/RichardBarrell/snippets/blob/master/openmp_frequency.c |
| 17:42 | < RichyB> | With OpenMP turned on, every ten-thousandth loop iteration has a ~1ms delay. |
| 17:43 | < RichyB> | Every fifty-thousandth has a ~4ms delay. |
| 17:43 | < RichyB> | One in a million idles for ~8ms. |
| 17:44 | <@Tamber> | Ouch. |
| 17:45 | < RichyB> | I suppose that maybe a large part of that is that the benchmark runs for long enough for the OS to interrupt it a few times. |
| 17:47 | | gnolam is now known as gehirnfiltrator |
| 17:48 | < RichyB> | Prolly that, it does about twice as well when I stop VLC playing in the background. |
| 17:49 | < RichyB> | I would be very unsurprised if the delays here were due to the OS blocking one of either threads for a moment to do something and the others waiting for it. |
| 17:49 | < RichyB> | If I could get this to switch from barriers to work-stealing I bet the drama would go away. |
| 17:50 | < RichyB> | Oh, I mis-spoke, it only does about 20% better with zero competition for CPU. |
| 17:51 | < RichyB> | Haha, but if I start two instances simultaneously then it utterly eats dirt. ? |
| 18:42 | | d4de [olorin@687AAB.418D22.C1A6F3.80EB68] has joined #code |
| 18:42 | | gehirnfiltrator is now known as gnolam |
| 18:49 | | Turaiel[Offline] is now known as Turaiel |
| 18:58 | <@celticminstrel> | What is the definition of a grapheme in Unicode, in terms of characters/codepoints? Would it be "any non-combining character followed by zero or more combining characters"? |
| 19:14 | < RichyB> | Hrmn. OpenMP is somewhat faster than using pthreads and pthread_barrier_wait() manually. |
| 19:18 | < RichyB> | TIL: using SMP doesn't make anything any faster at all if you're running a program with a small enough inner loop. :| |
| 19:20 | | Kindamoody|out is now known as Kindamoody |
| 20:03 | | Vornicus [vorn@ServerAdministrator.Nightstar.Net] has joined #code |
| 20:03 | | mode/#code [+qo Vornicus Vornicus] by ChanServ |
| 20:21 | | Kindamoody is now known as Kindamoody[zZz] |
| 20:34 | < AnnoDomini> | Man, the upgrade is going on and on. |
| 20:34 | | * AnnoDomini has mistakenly installed a fresh 6.0 instead of 7.0, but that can actually be upgraded out of the box, unlike the previous mess I had. |
| 20:55 | | Turaiel is now known as Turaiel[Offline] |
| 20:56 | < AnnoDomini> | Oh god what the fuck. |
| 20:56 | < AnnoDomini> | Where has my perfectly usable interface gone? |
| 20:57 | < AnnoDomini> | What the fuck is this new shite? |
| 20:57 | < AnnoDomini> | I don't want this new shite. I want my old, familiar interface back. |
| 20:58 | <@Tamber> | "But look, new shiny!" "...it's missing 90% of the functionality. And the 10% that is there doesn't work." "But it's shiny!" |
| 20:59 | < RichyB> | AnnoDomini: what did you set up? |
| 21:01 | < AnnoDomini> | I installed a debian stable, which had the old interface, and dist-upgraded it into debian testing. |
| 21:01 | < AnnoDomini> | I set up nothing that I was aware of. |
| 21:02 | < AnnoDomini> | The task bar is gone, the four desktops are gone, the desktop itself is gone. |
| 21:02 | < AnnoDomini> | The menus are gone. |
| 21:03 | <@Tamber> | o.0 |
| 21:04 | | Turaiel[Offline] is now known as Turaiel |
| 21:05 | <@celticminstrel> | I hate it when that sort of fake upgrade occurs... |
| 21:06 | <@celticminstrel> | Though I can't remember any specifics of where I've seen it occur. |
| 21:11 | < AnnoDomini> | Okay, according to the What's New, I should use the Gnome Classic option an login. |
| 21:11 | < AnnoDomini> | However, when I select that at login, I am sent to "Oh no! Something has gone wrong" screen and must log out immediately. |
| 21:16 | | Turaiel is now known as Turaiel[Offline] |
| 21:17 | | Turaiel[Offline] is now known as Turaiel |
| 21:33 | < Turaiel> | Well that was fun. I just accidentally deleted a progam I've been writing for the last few days. |
| 21:33 | < Turaiel> | I has just finished it... |
| 21:33 | | jeroud [uid10043@Nightstar-13dfc6f9.irccloud.com] has quit [Connection closed] |
| 21:33 | <@celticminstrel> | ... |
| 21:33 | < Turaiel> | had* |
| 21:34 | < Turaiel> | Hopefully extundelete will work. I shut the machine down a few minutes ago. |
| 21:36 | | jeroud [uid10043@Nightstar-1d9743e5.irccloud.com] has joined #code |
| 21:37 | | jeroud_ [uid10043@Nightstar-13dfc6f9.irccloud.com] has joined #code |
| 21:38 | <@gnolam> | ... and that is why you use source control. |
| 21:41 | < Turaiel> | Oh. No wonder |
| 21:42 | < Turaiel> | I didn't delete it. gzip removed it when I compressed it. |
| 21:42 | < Turaiel> | And since the gz files were for testing purposes, I deleted them when I was done with them |
| 21:43 | <@Tamber> | Oops. |
| 21:43 | < Turaiel> | That's strange, considering tar doesn't do that. :/ |
| 21:44 | <&ToxicFrog> | gzip/bzip2, on their own, default to replacing the target file with its compressed version. |
| 21:47 | < Turaiel> | I saw that when I read the man page |
| 21:47 | < Turaiel> | At the very least, if the original files are unrecoverable, the compressed ones should still be recoverable |
| 21:47 | < Turaiel> | I shut the machine down immediately after I deleted them |
| 21:48 | <&ToxicFrog> | Wait, so it seriously wasn't version controlled? |
| 21:48 | | * AnnoDomini posts on the Debian help forums to hopefully receive aid. |
| 21:50 | < Turaiel> | I don't use version control on small projects like this. it was a class assignment |
| 21:50 | < Turaiel> | I don't usually version control anything |
| 21:55 | < RichyB> | Ouch. |
| 21:55 | < RichyB> | Seriously, use version control. |
| 21:55 | < Turaiel> | But why bother creating a repo for 4 files? |
| 21:55 | < RichyB> | Setting up a new git repo is literally, "git init; git add *; git commit -m 'my stuff'" |
| 21:55 | < Turaiel> | I know. |
| 21:56 | < RichyB> | 'cuz setting up a repo is almost no work, and having one lets me track the contents of the files over time. |
| 21:56 | <&ToxicFrog> | Because it's trivial and saves you from stuff like this, as well as being useful in general when e.g. you have it all working and then break it while trying to implement the bonus features. |
| 21:56 | < RichyB> | If I spend a week working on a program, I will probably commit its in-progress states many times in that period. |
| 21:57 | < RichyB> | The ability to browse history also saves you from having any reason to do stupid things like keep old code around but commented out. |
| 21:58 | < RichyB> | (Anyway, you can use less than one repo per project for tiny things.) |
| 21:58 | < RichyB> | (I keep a single repo in ~/snippets for miscellaneous stuff that pops into my head.) |
| 21:58 | <&ToxicFrog> | (but why bother? it's easier to initialize a new repo) |
| 21:59 | <&ToxicFrog> | aah |
| 21:59 | < RichyB> | https://github.com/RichardBarrell/snippets/ <- is effectively a backup of it, from my perspective, and also makes it very easy to hyperlink people to these things. |
| 22:02 | < RichyB> | Oh god this is hilarious: https://twitter.com/mattskala/status/318467847288414209 |
| 22:11 | <&ToxicFrog> | ..what's the context there? |
| 22:11 | | celticminstrel [celticminst@Nightstar-e83b3651.cable.rogers.com] has quit [[NS] Quit: And lo! The computer falls into a deep sleep, to awake again some other day!] |
| 22:23 | < RichyB> | The context is that there's a bug in fontforge's support for tooltips, and the discussion on the bug itself has gone so wildly wrong that it's eligible for a drinking game. |
| 22:26 | | cpux [cpux@Nightstar-98762b0f.dyn.optonline.net] has joined #code |
| 22:26 | | mode/#code [+o cpux] by ChanServ |
| 22:29 | | cpux|2 [cpux@Nightstar-98762b0f.dyn.optonline.net] has quit [Ping timeout: 121 seconds] |
| 22:39 | | jeroud_ [uid10043@Nightstar-13dfc6f9.irccloud.com] has quit [Connection closed] |
| 22:39 | | jeroud [uid10043@Nightstar-1d9743e5.irccloud.com] has quit [Connection closed] |
| 22:50 | | Turaiel is now known as Turaiel[Offline] |
| 22:58 | | Orthia [orthianz@3CF3A5.E1CD01.B089B9.1E14D1] has joined #code |
| 22:58 | | mode/#code [+o Orthia] by ChanServ |
| 23:02 | <&ToxicFrog> | Hmm. |
| 23:02 | <&ToxicFrog> | I have encountered one of the Two Hard Problems. |
| 23:03 | <&ToxicFrog> | I need a project name for Spellcast by Web. |
| 23:03 | <~Vornicus> | Webcast, clearly |
| 23:04 | <~Vornicus> | Idunno, "spellcast by web" is a pretty good project name, honestly |
| 23:04 | <&ToxicFrog> | Takes a while to type and is an awkward repo name, though. |
| 23:04 | <&ToxicFrog> | This isn't the display name, it's the repo/namespace name. |
| 23:04 | <@Tamber> | spellweb? |
| 23:04 | <@Namegduf> | spellcast-web? |
| 23:04 | <~Vornicus> | look-ma-two-hands |
| 23:05 | <~Vornicus> | :P |
| 23:18 | < AnnoDomini> | Transnetwork Violence Protocol. |
| 23:45 | <&McMartin> | Burnination over Ethernet |
| 23:46 | <&McMartin> | mod_spellcast |
| 23:47 | < JustBob> | Packet-Oriented Protocol for Devastation and Destruction. |
| 23:47 | < JustBob> | POP4DAD. :p |
| 23:47 | <&McMartin> | spell-bind9-er |
| 23:47 | <&McMartin> | (spellcast-web is the best suggestion so far) |
| 23:50 | | * AnnoDomini gets gnome issue helped with by the forums people. |
| 23:51 | < AnnoDomini> | It turns out I had to uncheck "disable touchpad while typing", because that broke theming and by consequence gnome. |
| 23:51 | | * AnnoDomini applies sacred machine oil and chants the litany of maintenance. |
| --- Log closed Mon Apr 01 00:00:11 2013 |