| --- Log opened Sat Apr 26 00:00:06 2014 |
| 00:00 | <~Vornicus> | (jerith was aiming mostly to depixelize fonts, so assumed that there would be no places where three different colors would meet; see for instance the many places in http://research.microsoft.com/en-us/um/people/kopf/pixelart/images/teaser_ours_s mall.png where black, blue, and white meet; one of the splines that meet there always ends. He doesn't have any methods for splines that end.) |
| 00:03 | <~Vornicus> | (--or, for that matter, adjusting splines so they land in the right place) |
| 00:11 | <~Vornicus> | (which I haven't figured out either!) |
| 00:30 | | Omega [omegaboot@Nightstar-qa936g.il.comcast.net] has joined #code |
| 00:30 | | Alek [omegaboot@Nightstar-qa936g.il.comcast.net] has quit [Ping timeout: 121 seconds] |
| 00:37 | | Turaiel is now known as Turaiel[Offline] |
| 01:06 | | JackKnife [Z@Nightstar-484uip.cust.comxnet.dk] has joined #code |
| 01:06 | | mode/#code [+o JackKnife] by ChanServ |
| 01:06 | | Serah [Z@Nightstar-484uip.cust.comxnet.dk] has quit [Connection closed] |
| 01:30 | | Turaiel[Offline] is now known as Turaiel |
| 02:03 | <&Derakon> | So hey, guess what sucks in Java? |
| 02:03 | <&Derakon> | Reflection. |
| 02:03 | <&Derakon> | (I'm sure there are many other candidates; that's just what I've been dealing with at work lately) |
| 02:08 | <&ToxicFrog> | I would guess "sockets" because that's what I've been poking at lately |
| 02:15 | <&Derakon> | Well, as an example, to get a function pointer in Java, you have to do something like "this.class.getDeclaredMethod(funcName, paramsList)" where paramsList is a list of the types of the parameters (which may be more or less easy to construct!). |
| 02:15 | <&Derakon> | And of course, since it's Java, you are required to explicitly catch or throw all exceptions that this can cause. |
| 02:15 | <&Derakon> | Oh, yes. |
| 02:15 | <&Derakon> | Fun fact: Java's sleep function can throw an InterruptedException. |
| 02:15 | <&Derakon> | So any time you want to sleep you have to wrap it in a try/catch! |
| 02:16 | | HotShot[ipad] [HotShot@Nightstar-ecje17.mi.comcast.net] has joined #code |
| 02:17 | <@Azash> | It's a reasonable thing though |
| 02:17 | <&Derakon> | What, having to explicitly catch exceptions? |
| 02:18 | <&Derakon> | Meh, IMO failure to catch an exception should just cause the current execution thread to exit with an error message. |
| 02:18 | <&Derakon> | That's what it does in most languages. |
| 02:18 | <@Azash> | ¯\_(ã)_/¯ |
| 02:18 | <&Derakon> | It's pretty rare in the code I'm working on for an exception to be recoverable. I recognize such situations exist, but that's why you can catch exceptions, not why you should be required to do so. |
| 02:19 | <&ToxicFrog> | Derakon: hey, you could also declare your function as throwing it and just kick the problem up the call stack until you reach code you aren't responsible for~ |
| 02:20 | <~Vornicus> | I am unsure why anyone codes in java any more |
| 02:20 | <@Azash> | I'm prone to thinking that when the language has a convention of explicitly handling and requiring things, requiring exceptions to be handled is pretty natural |
| 02:21 | <@Azash> | Vornicus: Our company has a fair bit of it |
| 02:21 | <@Azash> | It seems to be a mix of customer preference and tool selection |
| 02:21 | <&Derakon> | TF: such code doesn't exist :( |
| 02:22 | <&Derakon> | Vorn: our program is in Java because it was started as an ImageJ plugin. |
| 02:23 | <&ToxicFrog> | Vornicus: in my case, because I'm programming in clojure, and I want to do stuff with sockets at a level that no-one has written a clojure library for |
| 02:24 | <@Azash> | http://chr13.com/2014/04/20/using-facebook-notes-to-ddos-any-website/ |
| 02:35 | <@celticminstrel> | It's reasonable for sleep to be able to throw an InterruptedException. |
| 02:35 | <@Namegduf> | I tend to like Java's mechanic. |
| 02:35 | <@celticminstrel> | However, InterruptedException should be a subclass of RuntimeException so that you don't need to catch it. |
| 02:36 | <@Namegduf> | I like to be able to know all the errors something can give and handle them. |
| 02:36 | <@Namegduf> | Most stuff I write is not one-off scripts. |
| 02:36 | <@celticminstrel> | I like to be able to know all the errors something can give. I don't like to be forced to have giant try-catch blocks to handle all of them. Java 7 helps a bit with that, though. |
| 02:36 | <@Namegduf> | And is servers or APIs or other user-facing things which do not respond to errors by terminating entirely. |
| 02:37 | <@Namegduf> | I don't use Java much, but I direly miss that feature when working in C#, which removed it. |
| 02:37 | <@Namegduf> | Especially because MS's approach to API design is to have things throw the most bizarre exceptions. |
| 02:37 | <&Derakon> | Namegduf: NB I said the thread terminates, not the entire program. |
| 02:37 | <@Namegduf> | Same thing. |
| 02:37 | <&Derakon> | Ehh. |
| 02:38 | <&Derakon> | There's a big difference between "you clicked on this button / sent this service request and the program couldn't cope" and "you clicked etc. and the entire program crashed." |
| 02:38 | <@celticminstrel> | It seems a bit odd for an exception in a thread to crash only that thread, honestly. |
| 02:39 | <@Namegduf> | You're going to corrupt program state. |
| 02:39 | <@Namegduf> | In that particular case, the program gets stuck in a loading state forever. |
| 02:39 | <&Derakon> | That depends entirely on how shittily you implemented your threads, Namegduf~ |
| 02:39 | <@Namegduf> | No? |
| 02:39 | <@Namegduf> | Not really, no. |
| 02:40 | <&Derakon> | If your event handler is modifying "global" program state (i.e. stuff that can be referred to by other threads) and can thus leave the program in a bad state, then you've messed up. |
| 02:40 | <@Namegduf> | Threads are not generally transactional in their interactions with other threads or shared state such that they can terminate and all the state accessible to everything else is fine. |
| 02:40 | <@Namegduf> | Doubly so given you don't even get notification you can use to rollback stuff. |
| 02:40 | <&Derakon> | Why not? |
| 02:40 | <&Derakon> | Remember I never said you shouldn't be allowed to catch exceptions. |
| 02:41 | <&Derakon> | Just that you shouldn't be required to do so. |
| 02:41 | <@Namegduf> | Making it so you're not required to do so, in practice makes it impossible for you to choose to guarantee you have done so. |
| 02:41 | <@Namegduf> | Checked exceptions are a thing. |
| 02:41 | <@Namegduf> | A toggleable switch for checked exceptions is not a thing. |
| 02:41 | <@celticminstrel> | I'd assume that, if a thread can terminate without warning due to an exception, then the thread object would have a way to determine that this happened. |
| 02:42 | <@Namegduf> | What thread object? |
| 02:42 | <@Namegduf> | Held by who, and what's listening on it? |
| 02:42 | <@Azash> | What Namegduf said, plus, the options are either "die violently" in which case even the barest handling is better, or "soldier on" which is absolutely terrible and I hope nobody handles exceptions like that ever |
| 02:42 | <@celticminstrel> | So, you could get a notification if you wanted it. |
| 02:42 | <@celticminstrel> | I still don't think it makes much sense though. |
| 02:42 | <@Namegduf> | How do you receive this notification and which thread gets it? |
| 02:42 | | * Vornicus gives Azash On Error Resume Next, runs the hell away |
| 02:42 | <@Namegduf> | It seems kind of like what you want is Eiffel. |
| 02:43 | <@Namegduf> | Was that the one? |
| 02:43 | <@celticminstrel> | The main thread (for example) constructs the thread object and then splits off the thread. So, the main thread could periodically check to see if it crashed. |
| 02:43 | <@Namegduf> | Not sure. |
| 02:43 | <@Namegduf> | No it can't. |
| 02:43 | <@Namegduf> | Your main thread is busy dispatching UI events. |
| 02:43 | <&Derakon> | Note that I'm thinking here in terms of stuff like GUI event handlers. |
| 02:43 | <&Derakon> | "You clicked on a button, so I am going to do some things related to that." |
| 02:43 | <@Azash> | Vornicus: Hnnggg |
| 02:43 | <@celticminstrel> | Whichever thread launched the subthread, then. |
| 02:43 | <@Namegduf> | The main thread launched it. |
| 02:43 | <@Namegduf> | It then went back to dispatching UI events. |
| 02:43 | <@celticminstrel> | Then it can do what I said. |
| 02:44 | <@Namegduf> | How? |
| 02:44 | <&Derakon> | If the event handler blows up, e.g. because I forgot to check that a form input isn't empty, say, then oh well! |
| 02:44 | <@celticminstrel> | It can keep track of the thread object somehow. |
| 02:44 | <&Derakon> | If it's that important that it not blow up, then I can check for exceptions around the form handling logic. |
| 02:44 | <@Namegduf> | It shoves it in a class member. |
| 02:44 | <@Namegduf> | Now what? |
| 02:44 | <&Derakon> | But usually it's not that important. |
| 02:44 | <@Namegduf> | Polling is not a nice thing to try to integrate into most software. |
| 02:44 | <@celticminstrel> | Polling threads? |
| 02:44 | <@Namegduf> | Yes. |
| 02:45 | <~Vornicus> | reminds me I should redo my power grid exception thing, so I can tell when I've thrown an error. |
| 02:45 | <~Vornicus> | as opposed to when something bigger has gone wrong,. |
| 02:45 | <@Namegduf> | It's an ugly approach. Normally you invoke back in some framework or application specific fashion. |
| 02:45 | <@Namegduf> | I think what you would end up doing in most programs is handing the thread object off to a third thread where a timer slept and polled it occasionally. |
| 02:45 | <@celticminstrel> | I'm pretty sure my main thread isn't the one that's dispatching UI events. It's the one that's polling for UI events. |
| 02:46 | <@Namegduf> | It is unlikely to be polling. |
| 02:46 | <@Namegduf> | Polling means either high latency or ridiculous CPU usage. |
| 02:46 | <@Namegduf> | It is probably *blocked* on UI events. |
| 02:46 | <@celticminstrel> | Namegduf, I never said it was a good approach, merely that it was a possible approach. |
| 02:46 | <@celticminstrel> | Yeah, blocked would be better than polling. |
| 02:46 | <@Namegduf> | And I said that it was architecturally a poor fit with most software. Polling doesn't integrate well. |
| 02:47 | <@Namegduf> | You need to feed into whatever the normal blocking waiting is. |
| 02:47 | <@celticminstrel> | If it needs to run animations though, polling might make more sense. |
| 02:48 | <@Namegduf> | If you can tune your application to go to sleep for an appropriate length of time between checks, yes, based on the needs of your animation. |
| 02:49 | <@Namegduf> | But typically you don't write your own event loop, you get one from your toolkit/framework. |
| 02:49 | <@Namegduf> | So animation is dealt with differently. |
| 02:49 | <@Namegduf> | Possibly with timers. |
| 02:50 | <&Derakon> | Ah, yes, when I needed animations in a prior GUI program they were done by making the window in question get woken up 10 times per second by a timer so it could redraw. |
| 02:50 | <&Derakon> | I wouldn't want to implement a game this way. |
| 02:50 | <&Derakon> | But it was a simple and effective method for what was needed. |
| 02:51 | <@Namegduf> | Yeah. Games I think tend to have dedicated toolsets which are smarter and can try to render up to N times a second, polling for things to react to before each frame or similar, and use sleeps when able to draw excessively. |
| 02:51 | <@Namegduf> | Or just 100% the CPU. |
| 02:51 | | celmin [celticminst@Nightstar-ha4ihv.dsl.bell.ca] has joined #code |
| 02:51 | | mode/#code [+o celmin] by ChanServ |
| 02:51 | <@Namegduf> | Games can get away with that in a way other programs can't. |
| 02:51 | | celticminstrel [celticminst@Nightstar-57p13c.dsl.bell.ca] has quit [Ping timeout: 121 seconds] |
| 02:51 | | celmin is now known as celticminstrel |
| 02:52 | <@Namegduf> | Well, smarter for a game's usecase. |
| 02:52 | <@Namegduf> | You wouldn't want most software to act like that. |
| 02:52 | <@celticminstrel> | Did I miss anything? |
| 02:53 | <@Namegduf> | Hang on. |
| 02:53 | <@Namegduf> | http://pastebin.com/f9RgeqJs |
| 02:54 | <@celticminstrel> | This line didn't get through, which is interesting because you mentioned games anyway. |
| 02:54 | <@celticminstrel> | [Apr 25@9:48:32pm] celticminstrel: To be fair, I have games in mind rather than normal applications, so it's a bit different. |
| 02:54 | <&Derakon> | I mentioned games mostly because having a timer wake up your thread so it can repaint is obviously inefficient. |
| 02:55 | <@celticminstrel> | Is it? |
| 02:55 | <@Namegduf> | Yeah. |
| 02:55 | <@celticminstrel> | Good thing I'm not doing that, I guess. |
| 02:56 | <&ToxicFrog> | IIRC, the typical game approach is to calculate your updates, optionally sleep until the next VBLANK, then render your stuff |
| 02:56 | <&ToxicFrog> | Or possibly that but in a different order |
| 02:56 | <&Derakon> | Ideally your physics and your display are somewhat decoupled, but yeah. |
| 02:57 | <&Derakon> | For example, Jetblade ran physics at IIRC 20FPS, and interpolated extra drawing frames in-between, up to the limit of the CPU. |
| 02:57 | <@celticminstrel> | I think they're decoupled in my own project, but in BoE there's calls to redraw all or part of the screen scattered throughout the code. |
| 02:58 | <@celticminstrel> | Though, I don't think it's interleaved much with actual game rules... |
| 02:59 | <&Derakon> | BoE? Blades of Exile? |
| 02:59 | <@celticminstrel> | More with UI handling. |
| 02:59 | <@celticminstrel> | Yes. |
| 02:59 | <&Derakon> | Yeah, that's pretty oldschool. |
| 02:59 | <&Derakon> | And doesn't really have...animations. |
| 02:59 | <@celticminstrel> | It does, actually. |
| 02:59 | <@celticminstrel> | A few terrains (like underground water) animate through four frames. |
| 02:59 | <@celticminstrel> | Then there's missile animations and explosions. |
| 02:59 | <@celticminstrel> | (Which currently don't work.) |
| 03:00 | <&ToxicFrog> | Derakon: I was deliberately vague about "calculate your updates"; it may involve, e.g., reading control input state and fetching the current physics state from a separate thread |
| 03:00 | <&Derakon> | The latter are modal, though, so don't count~ |
| 03:00 | <@celticminstrel> | (No idea if the terrain animations work.) |
| 03:00 | <&Derakon> | I wasn't aware there were terrain animations though. |
| 03:00 | <@celticminstrel> | Yeah, you could say that. |
| 03:00 | <@celticminstrel> | I suspect the reason they don't work is related to that "modality". |
| 03:01 | <@celticminstrel> | Unless I forgot to load a texture somewhere, I suppose. |
| 03:01 | <&Derakon> | As a shot in the dark, I'd guess that the game has a timer that tells it to redraw animated terrains. |
| 03:01 | <@celticminstrel> | Pretty much. |
| 03:01 | <&Derakon> | IIRC the missile/explosion animations simply drew as fast as possible. |
| 03:02 | <@celticminstrel> | I haven't looked at that part of the code yet, but I think there might be some deliberate pauses inserted. |
| 03:03 | <&Derakon> | Again, at a guess, if your animations aren't working then the redraw logic isn't being engaged correctly in timers. Perhaps it's being called from the wrong thread? |
| 03:04 | <&Derakon> | Depending on what library you're using, there may be a "call this function later in the main thread" function you can use. |
| 03:05 | <@celticminstrel> | Well, I recall seeing a missile animation, but it didn't look right, which is why I wondered about forgetting to load a texture. I don't think I saw any explosions, so yeah, maybe the redraw logic isn't engaged correctly. This wouldn't be surprising since I already completely rearranged and simplified the redraw logic. |
| 03:05 | <@celticminstrel> | The function call tree was a little crazy, with some redundant calls. |
| 03:06 | < [R]> | <celticminstrel> I like to be able to know all the errors something can give. I don't like to be forced to have giant try-catch blocks to handle all of them. Java 7 helps a bit with that, though. <-- What's J7 do specifically on that end? |
| 03:06 | <@celticminstrel> | Multi-catch. |
| 03:06 | <@celticminstrel> | Making the try-catch blocks significantly less giant. |
| 03:07 | <&Derakon> | Ah, yes. |
| 03:07 | <&Derakon> | We're only using Java 6 at work. |
| 03:07 | <&Derakon> | So we can't do "catch (FooException | BarException | BazException ex) {do the same thing regardless}" |
| 03:07 | <&Derakon> | Gotta do them one at a time or catch a superclass. |
| 03:21 | <@Namegduf> | It could be a library difference. |
| 03:21 | <@Namegduf> | I don't think I ever needed to handle more than about three, two of which actually needed different handling on average. |
| 03:21 | <@Namegduf> | I could believe some poorly designed Java APIs throw stupid numbers of exceptions. |
| 03:22 | <@Namegduf> | There are very few tolerable Java APIs. |
| 03:31 | | HotShot[ipad] [HotShot@Nightstar-ecje17.mi.comcast.net] has quit [Ping timeout: 121 seconds] |
| 03:35 | | Typherix [Typherix@Nightstar-n91qrf.lnngmi.sbcglobal.net] has quit [Ping timeout: 121 seconds] |
| 03:41 | | Typherix [Typherix@Nightstar-n91qrf.lnngmi.sbcglobal.net] has joined #code |
| 03:42 | <@celticminstrel> | The reflection API throws about five or six different exceptions. |
| 03:43 | <@Namegduf> | Ew. Just counting the non-Runtime ones? |
| 03:43 | <@celticminstrel> | Think so. |
| 03:43 | <@celticminstrel> | Not every reflection method throws all of them, but if you're doing several reflective things in a row, you'll need a minimum of three catch blocks, and quite likely a few more. |
| 03:43 | <@Namegduf> | I like the Runtime/Non-Runtime split. If it can happen and not be a programmer error, I want to know it can happen and I probably want it to do something about it. |
| 03:44 | <@celticminstrel> | That might be including some that don't need to be caught, depending on whether Eclipse adds those for you. |
| 03:44 | <@Namegduf> | Being forced to handle FileNotFound is not really a pain because I want to handle it anyway to be doing it rihgt. |
| 03:44 | <@Namegduf> | That kind of thing. |
| 03:45 | <@celticminstrel> | Actually, the file i/o stuff is sligtly annoying, perhaps because it has the common superclass... |
| 03:46 | <@Namegduf> | More often than not, when converting a string to an integer, I want to at least consider "what if the string isn't a number", and being made to at least acknowledge that I've considered that in the source isn't annoying. |
| 03:46 | <@celticminstrel> | It's annoying to me. |
| 03:47 | <@celticminstrel> | I suppose it's nice that, if I rely on exceptions, it can point out that I've forgotten to consider if the string is a number. |
| 03:47 | <@Namegduf> | I don't see how I'd remember "I explicitly considered that error case and decided it was okay" without an empty exception block or a rethrow or something. |
| 03:47 | <@celticminstrel> | But sometimes I know the string is a number, so I don't want to be forced to catch an exception that is impossible to be thrown. |
| 03:48 | <@Namegduf> | I don't think I often parse strings to numbers where it is a programmer error for the string to not be a number. |
| 03:48 | <@celticminstrel> | For example if I'm in a 'if(string.matches("/d+"))' block. |
| 03:48 | <@Namegduf> | I don't know if that could fail or not. |
| 03:48 | <@celticminstrel> | ^\d |
| 03:48 | <@Namegduf> | I guess it could be too big. |
| 03:49 | <@celticminstrel> | ? |
| 03:49 | <@Namegduf> | It could overflow int. |
| 03:49 | <@celticminstrel> | Huh? |
| 03:49 | <@Namegduf> | If the number is too large to convert to Integer and you are parsing it to Integer, Java will throw an exception. |
| 03:49 | <~Vornicus> | converting a string into a number could fail because the number is too large. |
| 03:50 | <@celticminstrel> | Oh. |
| 03:50 | <@Namegduf> | This could happen if your input is actually just a long string of digits rather than an actually sensible numerical input. |
| 03:50 | <@Namegduf> | I am quite slow to decide I "know" inputs are valid in that kind of way... for that kind of reason. |
| 03:50 | <@Namegduf> | I "know" it's a string of digits. To know that it won't error would require sitting down with the documentation for the method, and if I'm relying on that I will want to drop a comment in about it. |
| 03:52 | <@Namegduf> | I don't begrudge exceptions for making me look at the cases where the thing can fail due to things outside my program and making me mark off each as dealt with, because I guess that's my normal workflow anyway. A method which has too many separate things like that is kind of badly designed. |
| 03:53 | <@Namegduf> | I guess if you use a try { ... } finally { ... } model and ensure that anything you've done is rolled back in the finally you can avoid that. |
| 03:54 | | Omega is now known as Alek |
| 03:54 | | mode/#code [+o Alek] by ChanServ |
| 03:54 | | Kindamoody[zZz] is now known as Kindamoody |
| 03:54 | <@Namegduf> | Or if everything you talk to is separately transactional and your whole handler can die completely and automatic rollbacks will take care of it all, ala App Engine. |
| 03:55 | <@Namegduf> | (Or SQL) |
| 03:55 | <@celticminstrel> | I don't think it's good in general to be relying on exceptions for normal program flow, since that'll cause XCode to stop at an exception that's expected and will be caught; but that principle might not apply to Java. That is, Java might be an exception. |
| 03:55 | <@Namegduf> | A sensible IDE will let you get rid of that behaviour. |
| 03:55 | <@Namegduf> | I doubt Eclipse does it, for example. |
| 03:56 | <@Namegduf> | (Not that Eclipse is a sensible IDE) |
| 03:56 | <&Derakon> | CM: stylistically, you should never expect to throw an exception. |
| 03:56 | <&Derakon> | They are exceptional. |
| 03:56 | <&Derakon> | And they fuck over CPU pipelining something fierce. |
| 03:56 | <@celticminstrel> | Yeah. |
| 03:56 | <@Namegduf> | You shouldn't be using it for "normal program flow", although a lot of things like to do things like try to open files and just handle failure rather than try to detect presence. |
| 03:57 | <@Namegduf> | Since the latter has race conditions and whatnot. |
| 03:57 | <&Derakon> | I am reminded of some code I inherited in my previous job. |
| 03:57 | <@Namegduf> | That happens for, say, cache or settings files, fairly often. |
| 03:58 | <&Derakon> | try: foo; except: foo = some default value |
| 03:58 | <@Namegduf> | And can make programs which throw exceptions on first startup consistently. |
| 03:58 | <&Derakon> | Because apparently it was too fucking hard to declare foo in advance to be, say, None, and then check if foo was None. |
| 03:58 | <@Namegduf> | This isn't "normal program flow" and isn't performance sensitive, though. |
| 03:59 | <@Namegduf> | It is a case where your IDE erroring on every exception will give you no end of grief, though. |
| 03:59 | <@Namegduf> | Also, sockets in any language which really uses exceptions will throw them like monkeys throw shit. |
| 04:00 | <@Namegduf> | Thinking about it more I'd be quite surprised if XCode couldn't ignore at least some handled exceptions, unless the languages it supports have very different behaviour. |
| 04:00 | <@Namegduf> | Because that would quickly become obnoxious for anything dealing with sockets. |
| 04:01 | <@celticminstrel> | C++ streams don't throw any exceptions by default, and C doesn't have exceptions at all. |
| 04:01 | <@celticminstrel> | (C++ streams can be configured to throw exceptions; I don't know if that's common.) |
| 04:01 | <@celticminstrel> | ^+ly done |
| 04:02 | <@Namegduf> | C++ isn't a language I'd think of as "really using" exceptions, because while it supports them, a lot of stuff doesn't use or handle them. |
| 04:02 | <@celticminstrel> | I'm not sure about Objective-C; it does have exceptions, but I'm guessing its IO functions probably don't throw. |
| 04:02 | <@celticminstrel> | And I think that more or less covers the languages XCode is intended to support. |
| 04:03 | <@celticminstrel> | You actually need to explicitly enable breaking on exceptions. |
| 04:03 | <@Namegduf> | Ah. |
| 04:03 | <@celticminstrel> | And can tell it to only break on C++ exceptions, or only on Objective-C exceptions. |
| 04:04 | <@Namegduf> | Makes sense. |
| 04:05 | <@celticminstrel> | It can also break when it's thrown or when it's caught (I don't see the latter as being terribly useful though). |
| 04:05 | <@celticminstrel> | But yeah, there'll certainly be less exceptions occurring in an XCode project than in a Java project. |
| 04:06 | <@Namegduf> | Yeah. |
| 04:06 | <@Namegduf> | Or Python, for that matter. |
| 04:06 | <@celticminstrel> | Probably, yeah. |
| 04:08 | <@Alek> | ahah |
| 04:09 | <@Alek> | "10% of Americans think that HTML is a sexually transmitted disease." |
| 04:12 | | VirusJTG [VirusJTG@Nightstar-6i5vf7.sta.comporium.net] has quit [[NS] Quit: Program Shutting down] |
| 04:39 | | orth_ [orthianz@Nightstar-dsapgd.xtra.co.nz] has joined #code |
| 04:52 | | orth__ [orthianz@Nightstar-dsapgd.xtra.co.nz] has joined #code |
| 04:52 | | orth_ [orthianz@Nightstar-dsapgd.xtra.co.nz] has quit [Connection closed] |
| 05:12 | | Derakon is now known as Derakon[AFK2] |
| 05:12 | | JackKnife [Z@Nightstar-484uip.cust.comxnet.dk] has quit [Ping timeout: 121 seconds] |
| 05:20 | | macdjord|wurk is now known as macdjord |
| 05:41 | | RchrdB [RichardB@Nightstar-c6u.vd5.170.83.IP] has quit [[NS] Quit: Gone.] |
| 05:44 | | RchrdB [RichardB@Nightstar-c6u.vd5.170.83.IP] has joined #code |
| 06:09 | | celticminstrel [celticminst@Nightstar-ha4ihv.dsl.bell.ca] has quit [[NS] Quit: And lo! The computer falls into a deep sleep, to awake again some other day!] |
| 06:25 | | * Vornicus explodes in a shower of bling. |
| 06:31 | | * macdjord distirbutes Vornicus amoung rappers and pimps |
| 06:34 | | macdjord is now known as Warning-Macdjord |
| 06:38 | | Warning-Macdjord is now known as macdjord |
| 07:05 | | Turaiel is now known as Turaiel[Offline] |
| 07:15 | | Kindamoody [Kindamoody@Nightstar-180u8i.tbcn.telia.com] has quit [Client exited] |
| 07:15 | | Kindamoody|autojoin [Kindamoody@Nightstar-180u8i.tbcn.telia.com] has joined #code |
| 07:15 | | mode/#code [+o Kindamoody|autojoin] by ChanServ |
| 07:16 | | Kindamoody|autojoin is now known as Kindamoody |
| 07:18 | | Kindamoody is now known as Kindamoody|afk |
| 07:36 | | himi [fow035@Nightstar-v37cpe.internode.on.net] has quit [Ping timeout: 121 seconds] |
| 07:45 | | Kindamoody|afk is now known as Kindamoody |
| 08:05 | | orth__ [orthianz@Nightstar-dsapgd.xtra.co.nz] has quit [Connection closed] |
| 08:05 | | orth_ [orthianz@Nightstar-dsapgd.xtra.co.nz] has joined #code |
| 08:15 | <&jeroud> | Vornicus: Also, I was getting the easy case right before moving on to the less easy case, except I never got the easy case right. |
| 08:16 | <~Vornicus> | A truth. |
| 08:19 | | Kindamoody is now known as Kindamoody|out |
| 08:26 | <&jeroud> | A sad truth. |
| 08:26 | <&jeroud> | A sad truth worth getting out bed for. |
| 08:27 | <&jeroud> | (Or worth using as an excuse for the getting out of bed I'm about to do anyway.) |
| 08:27 | <~Vornicus> | well, when I manufacture enough spoons to get smoothing working, I'll see what I can come up with. |
| 08:27 | <~Vornicus> | god I need dried frog pills. |
| 08:29 | <&jeroud> | Can't you get some? |
| 08:30 | <~Vornicus> | jobless american, remember |
| 08:35 | <&jeroud> | Oh, right. :-( |
| 08:41 | | Vornicus [Vorn@ServerAdministrator.Nightstar.Net] has quit [Connection reset by peer] |
| 08:41 | | Vornicus [Vorn@ServerAdministrator.Nightstar.Net] has joined #code |
| 08:41 | | mode/#code [+qo Vornicus Vornicus] by ChanServ |
| 09:02 | | * macdjord lends Vornicus some spare dried frog pills. Or possibly some Temptations Cat Treats in a pill bottle. |
| 09:04 | <@macdjord> | (I actually do have a bunch of Temptations here, and they are indeed in an old pill bottle from my Ritalin prescription. Unlike the platic bag they came in, it is sturdy enough that the kitty can't shred it to get the treats out~) |
| 09:12 | | macdjord is now known as macdjord|slep |
| 10:25 | | AverageJoe [evil1@Nightstar-fb1kt4.ph.cox.net] has joined #code |
| 10:51 | | AverageJoe [evil1@Nightstar-fb1kt4.ph.cox.net] has quit [[NS] Quit: Leaving] |
| 11:15 | | Syka [the@Nightstar-6ps.np9.126.1.IP] has joined #code |
| 11:15 | | orth_ [orthianz@Nightstar-dsapgd.xtra.co.nz] has quit [Connection closed] |
| 11:15 | | orth_ [orthianz@Nightstar-dsapgd.xtra.co.nz] has joined #code |
| 11:16 | | Syka is now known as NSGuest212 |
| 12:02 | | JackKnife [Z@Nightstar-484uip.cust.comxnet.dk] has joined #code |
| 12:02 | | mode/#code [+o JackKnife] by ChanServ |
| 12:08 | | VirusJTG [VirusJTG@Nightstar-6i5vf7.sta.comporium.net] has joined #code |
| 12:31 | | himi [fow035@Nightstar-v37cpe.internode.on.net] has joined #code |
| 12:31 | | mode/#code [+o himi] by ChanServ |
| 12:45 | | NSGuest212 is now known as Syk |
| 12:45 | | Vornicus [Vorn@ServerAdministrator.Nightstar.Net] has quit [Connection closed] |
| 12:47 | | orth_ [orthianz@Nightstar-dsapgd.xtra.co.nz] has quit [Ping timeout: 121 seconds] |
| 13:04 | <@Tarinaky> | http://gfycat.com/SpanishDownrightHedgehog << Kerbal Space Qwop |
| 13:06 | <@Tamber> | Qwopbal. |
| 13:28 | <@Tarinaky> | https://www.youtube.com/watch?v=Sus6X0w1Zow&feature=youtu.be Full video |
| 13:29 | <@Tarinaky> | Given the observation that Mun walking is easier than qwop-walking in normal Kerbin gravity... |
| 13:29 | <@Tarinaky> | Does that imply bipedal locomotion in low-gravity is computationally easier as well as mechanically? |
| 15:43 | | Syk [the@Nightstar-6ps.np9.126.1.IP] has quit [[NS] Quit: leaving] |
| 15:46 | | * ErikMesoy WTFs and curses at the guy who decided to select a number between N and M by means of N+((M-N)*rand()*rand()). |
| 15:46 | <@TheWatcher> | #code, I desire links to what you consider to be the best, clearest, and easily used protocol or file format specifications. |
| 15:49 | <@gnolam> | OOXML. ;) |
| 15:53 | | * TheWatcher fires gnolam into space |
| 15:56 | <@gnolam> | What is this for? |
| 15:57 | <&ToxicFrog> | TheWatcher: for what purpose, and in what languages? |
| 15:57 | <@TheWatcher> | To throw at someone as examples of good practice, and preferably language agnostic, c/c++ if not |
| 15:59 | <&ToxicFrog> | ...also, by file format specifications, do you mean serialization formats, or any well designed file format? |
| 15:59 | <@TheWatcher> | anything |
| 15:59 | <@TheWatcher> | anything that is a well-written spec, really |
| 16:06 | <&ToxicFrog> | Aah, ok. So it's not the format that you're interested in but the specification itself. |
| 16:06 | <&ToxicFrog> | First thing that comes to mind is the Lua reference manual, which also serves as the specification for the language and its implementation and is quite readable. |
| 16:15 | | celticminstrel [celticminst@Nightstar-ha4ihv.dsl.bell.ca] has joined #code |
| 16:15 | | mode/#code [+o celticminstrel] by ChanServ |
| 18:18 | | Serah [Z@Nightstar-484uip.cust.comxnet.dk] has joined #code |
| 18:18 | | mode/#code [+o Serah] by ChanServ |
| 18:21 | | JackKnife [Z@Nightstar-484uip.cust.comxnet.dk] has quit [Ping timeout: 121 seconds] |
| 18:28 | | AverageJoe [evil1@Nightstar-fb1kt4.ph.cox.net] has joined #code |
| 19:02 | <&jerith> | So. logging.info and logging.INFO are very different things. |
| 19:03 | <&jerith> | And the former can apparently be used in place of the latter. |
| 19:03 | <&jerith> | Except some stuff interprets it weirdly. |
| 19:04 | <&jerith> | I now have code that works perfectly and has processed several thousand messages, but has emailed me an error log for each. |
| 19:06 | <@Tamber> | Oh dear. |
| 19:09 | <&jerith> | Actually, I only have several hundred emailed errors. |
| 19:09 | <&jerith> | The error emailing thing fell over. |
| 19:10 | <@Tamber> | Ah, so you've tested something that you didn't expect to, and it's failed :p |
| 19:11 | <&jerith> | We know the error emailing thing gets sad when you hit it with a hundred requests per second. |
| 19:18 | <@TheWatcher> | Which is understandble, really |
| 19:18 | | * TheWatcher would suggest a digesting queue system for the emails, but what does he know |
| 19:20 | <&jerith> | TheWatcher: There are a bunch of crappy things in this setup, some of which are responsible for me deploying bugs on a Saturday evening in the first place. |
| 19:21 | <&jerith> | Sadly, our current workload is such that stuff hasn't been getting fixed unless it's actually on fire, because too much of our time is being spent fighting the fires we already have. :-/ |
| 19:22 | <@TheWatcher> | :(( |
| 19:23 | <&jerith> | We're starting to get out from under that (in part by dramatically reducing the rate of incoming work), but we have a lot of catching up to do. |
| 19:24 | <&jerith> | In related news, we're hiring. *grins* |
| 19:41 | | macdjord|slep is now known as macdjord |
| 19:45 | | AverageJoe [evil1@Nightstar-fb1kt4.ph.cox.net] has quit [[NS] Quit: Leaving] |
| 19:52 | | Turaiel[Offline] is now known as Turaiel |
| 20:02 | | Derakon[AFK2] is now known as Derakon |
| 21:01 | < froztbyte> | hshs |
| 21:01 | < froztbyte> | haha* |
| 21:12 | | Kindamoody|out is now known as Kindamoody |
| 21:35 | | Kindamoody is now known as Kindamoody[zZz] |
| 21:48 | | Turaiel is now known as Turaiel[Offline] |
| 21:52 | | Vornicus [Vorn@ServerAdministrator.Nightstar.Net] has joined #code |
| 21:52 | | mode/#code [+qo Vornicus Vornicus] by ChanServ |
| 22:38 | <@TheWatcher> | jerith: if it didn't involve moving to .za, I'd actually be tempted right now |
| 22:38 | <&jerith> | TheWatcher: It doesn't have to involve moving to .za! |
| 22:38 | <&jerith> | We all work remotely. |
| 22:38 | <&jerith> | Although I think we're about to hire an ops person. |
| 22:39 | <&jerith> | So you'd have to go for one of the dev positions. |
| 22:40 | <&jerith> | That may or may not be to your taste. |
| 22:41 | <&jerith> | We write lots of Python. There's no perl at all. |
| 22:41 | <@TheWatcher> | Aye |
| 22:41 | <&jerith> | We desperately need someone who's good at UIs. |
| 22:42 | <&jerith> | (Our product manager has been buying beer for hordes of frontend web devs for months to try find someone locally.) |
| 22:42 | <@TheWatcher> | snerk |
| 22:43 | <&jerith> | (He's been sponsoring meetups and such.) |
| 22:43 | <@TheWatcher> | And while I've been doing a shitton of webdev that involves UIs that /admin staff/ can use, it's all perl based, alas |
| 22:44 | <&jerith> | Oh the frontend stuff we need is mostly JS and Strong Opinions. |
| 22:44 | <@TheWatcher> | Ahaha |
| 22:44 | <&jerith> | We can write Django code fine, we just need to be told what to write. |
| 22:46 | | * jerith goes to brush his teeth while a colleague deploys the latest message processing optimisations. |
| 23:12 | | ErikMesoy is now known as ErikMesoy|sleep |
| 23:41 | | Turaiel[Offline] is now known as Turaiel |
| --- Log closed Sun Apr 27 00:00:22 2014 |