2014 02 01

      • harikb joined the channel
      • dsal
        "conversion" conveys the feel of "I just got a new thing that is a different type"
      • shanemhansen joined the channel
      • jbub joined the channel
      • badfwdfs has quit
      • chuck_
        is there a performance penalty for using buffered channels vs unbuffered channels? and what about channels with huge buffers vs channels with small buffers?
      • darkgray
        I prefer the term transmutation, since it makes you feel like your variables are worth something.
      • dsal
        chuck_: testing.B :p
      • dominikh
        channels with huge buffers will use huge amounts of memory 🙂
      • dsal
        huge buffers are rarely what you want, though.
      • wsc
        chuck_ it will depend on your application
      • i like to make sure it works w/o a buffer first and then see if buffering speeds it up later
      • aspires has quit
      • gmilleramilar has quit
      • aspires joined the channel
      • viking joined the channel
      • dominikh
        there's a very limited set of problems where you need a buffer (usually of size one). then there's a moderately bigger set of problems where buffered channels hide flaws in your design, and then there's a set of problems that can use buffering to increase performance
      • tarndt has quit
      • bmats has quit
      • wallyworld_ has quit
      • adiabatic joined the channel
      • tvw has quit
      • bmats joined the channel
      • dsal
        Even where buffering increases performance, it's hard to imagine where a large buffer would.
      • geetarista has quit
      • tiglionabbit
        I have two struct types that embed the same base struct type. I'm trying to use them generically in some places, but specifically require one or the other in other cases
      • dsal
        e.g. if it's kind of expensive to produce and to consume, you don't want to be doing no work while preparing stuff to produce, so keeping the pipeline full is pretty good.
      • mikejholly has quit
      • metasansana joined the channel
      • tiglionabbit
        but I'm having some difficulty with this, because if I make an interface for them, I lose my struct accessors...
      • dsal
        tiglionabbit: It's hard to know how to fix that without more concrete info.
      • gust1n joined the channel
      • embedding is kind of unfortunate. I see that abused more than used well.
      • TapocoL has quit
      • jordanorelli has quit
      • e.g. a thing I've seen a lot lately is people embedding a mutex. Oh, so now your User is a Locker?
      • tiglionabbit
        dsal: that's standard in Java 😛
      • FunnyLookinHat has quit
      • ndrei has quit
      • dsal: Idk how to get more specific without giving irrelevant details that will probably lead nowhere 😛
      • aspires has quit
      • kalloc joined the channel
      • I'll make a simplified case
      • bmats has quit
      • aspires joined the channel
      • dsal
        Modeling your problem with words like "base" and "embed (but I really mean "extend")" and "generic" often makes things unnecessarily difficult.
      • ndrei joined the channel
      • shurcooL has quit
      • tiglionabbit
        k
      • shanemhansen has quit
      • Wessie
        the mutex embedding is just because it's such a simple thing to abuse
      • bmats_ joined the channel
      • sqwishy
        How do I do transactional memory in Go?
      • Wessie
        the documentation also has it as example I believe, if I'm not mistaken
      • mapop joined the channel
      • jbub has quit
      • gust1n has quit
      • jbub joined the channel
      • shanemhansen joined the channel
      • astropirate has quit
      • kalloc has quit
      • adiabatic has quit
      • lyon joined the channel
      • adiabatic joined the channel
      • hammon joined the channel
      • hammon has quit
      • wallyworld joined the channel
      • jackdanger joined the channel
      • mathadder has quit
      • joshnz joined the channel
      • andrewpthorp has quit
      • andrewpthorp joined the channel
      • sqwishy
        Does java have transactional memory?
      • virtualsue joined the channel
      • kc5tja
        uugh, I hate performance reviews. I always come out OK in them, but they still scare the bejeezus out of me.
      • nphase has quit
      • harikb has quit
      • tiglionabbit
        ok, here's some broken code that should give you an idea of what I'm trying to do http://play.golang.org/p/1wLFD8KW5a
      • nphase joined the channel
      • neurodrone joined the channel
      • prophit joined the channel
      • t3rm1n4l has quit
      • carif joined the channel
      • nanoyak has quit
      • nphase has quit
      • kc5tja
        It won't let you pass a Special as a Normal; you'd need to pass a reference to the Normal field. See http://play.golang.org/p/WrPUZCjIDm
      • dsal
        Damnit, I was cleaning that up in my browser and it ate my homework.
      • kc5tja
        In this case, rethinking the data structure layout is preferable.
      • rpd
        teacher, my browser ate my homework
      • sgen joined the channel
      • realrocker has quit
      • sgen has quit
      • dsal
        Yeah, that's what I was oding.
      • Basically, if Special is Normal + a field, just add that field, perhaps as a *string
      • RaCx has quit
      • I'd probably not make all those errors either unless you *really* need apps to switch on them.
      • fmt.Errorf
      • And then everything's easy.
      • RaCx joined the channel
      • tiglionabbit
        kc5tja: ok, I could do it that way. btw, I made a mistake in the example. breaks now: http://play.golang.org/p/Q_wc9EJc8j
      • kc5tja: but I suppose this just means I should make the part that finds the special problem be a different function that I don't run on normal things
      • swaj has quit
      • Project_2501 has quit
      • dsal
        It's called a "type assertion" because you're asserting that you know what the type is that's backing an interface. It's panics when you lie to it.
      • swaj joined the channel
      • lyon has quit
      • Argh. I drove to work today. I never do that. I was planning some reading material, but I can't read and drive legally.
      • tibor has quit
      • Wessie
        compiler: The programmer is mean to me and lied!, now I'm panicking
      • or well, the runtime rather
      • emocakes has quit
      • virtualsue has quit
      • sgen joined the channel
      • I don't see exactly why you would create errors in such a way though tiglionabbit
      • tiglionabbit
        Wessie: to inspect them later, I guess?
      • they're hardly exceptional errors
      • Wessie
        I mean more like, why are they not created in whatever involves *Special
      • Why are they created, after the fact
      • tiglionabbit
        how do you mean?
      • well, I do a database query and it tells me what constraint was violated, so I make a more understandable error to represent what happened
      • dsal
        Why not just fmt.Errorf?
      • Wessie
        Is there a reason you don't want to show the original error
      • tiglionabbit
        another agent has to be able to figure out what went wrong from the error, preferably without string parsing it
      • matt_c
        that's a slippery slope.
      • what about errors other than constraint errors?
      • kc5tja
        tiglionabbit: This is my own solution based on what you tried to write earlier. http://play.golang.org/p/ebFXjIggV0
      • tiglionabbit
        matt_c: those are fine
      • pdkl has quit
      • kc5tja
        tiglionabbit: Basically, my approach involves composing behavior via interfaces.
      • dsal
        I still wouldn't have most of those types.
      • But I'm going to drive home instead.
      • Wessie
        Don't die~
      • kc5tja
        And actually, you can take away lines 28, 29, and 30 and it'll still work, as interface composition will ensure that Special.NameProblem() will still be defined.
      • dsal
        Wessie: That's the plan. I'm going to try not to read. I read one of the things here at my desk instead of in my car.
      • ttyl, *
      • tiglionabbit
        cool
      • kc5tja
        dsal: Yeah, I hear you on the types issue. But, I was trying to be as close to the original as possible.
      • dsal: Laters!
      • derferman has quit
      • derferman joined the channel
      • hajimeho_ joined the channel
      • burlyscudd joined the channel
      • ay joined the channel
      • cenuij has quit
      • tiglionabbit
        this is cool, but the errors it returns aren't inspectable...
      • elopio has quit
      • blakesn joined the channel
      • rpd
        how is it different from your implementation?
      • in terms of being inspectable
      • beachandbytes has quit