ELLIOTTCABLE changed the topic of #elliottcable to: bucket of fitbits
cloudhead has quit [Ping timeout: 240 seconds]
<devyn> so evillllll
alexthegreat has joined #elliottcable
<purr> <joelteon> smoke the ovaries
<vigs> kinky
<alexthegreat> wtf
<alexthegreat> hi vigs
<vigs> hello alexthegreat
prophile has quit [Quit: The Game]
<whitequark> glowcoil: variants are sum types
<whitequark> polymorphic variants are extensible sum types
retina has joined #elliottcable
<glowcoil> whitequark: ah ok neat
retina has quit [Remote host closed the connection]
gozala has quit [Quit: Connection closed for inactivity]
sunline has joined #elliottcable
alexthegreat has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
alexgordon has quit [Quit: My iMac has gone to sleep. ZZZzzz…]
<eligrey> i was just wondering: can limitations of liability apply to public domain licenses/dedications?
<eligrey> also used by json2.js
<whitequark> they absolutely can
<whitequark> "public domain" concerns copyright. liability doesn't really play any role in that
<whitequark> (also worth noting that "public domain" doesn't exist everywhere)
<gkatsev> which is why I prefer the MIT license. It's supported in more places than public domain is.
<gkatsev> and with that comment, I go sleep.
jesusabdullah has quit [Read error: Operation timed out]
<eligrey> all of my stuff is MIT licensed
<eligrey> except classlist.js
jesusabdullah has joined #elliottcable
eligrey has quit [Quit: Leaving]
<whitequark> so this guy is a designing engineer
<whitequark> right now his job requires him to, quote, mould a house for mice
<whitequark> I don't even
<ELLIOTTCABLE> hello
<ELLIOTTCABLE> goodbye
glowcoil has quit [Remote host closed the connection]
<whitequark> lolwhat?
<purr> lolwhat
jesusabdullah has quit [Ping timeout: 255 seconds]
jesusabdullah has joined #elliottcable
glowcoil has joined #elliottcable
<glowcoil> hy
<glowcoil> ELLIOTTCABLE:
<glowcoil> ya :\
sunline has quit [Remote host closed the connection]
sharkbot has quit [Remote host closed the connection]
sharkbot has joined #elliottcable
<purr> <Benvie> cool thing is that es6 makes most templating engines obsolete
<glowcoil> ELLIOTTCABLE:
<glowcoil> ELLIOTTCABLE:
<glowcoil> ELLIOTTCABLE:
<ELLIOTTCABLE> glowcoil: hi
<ELLIOTTCABLE> am coding almost kinda
<ELLIOTTCABLE> sup
<ELLIOTTCABLE> u dickface
<ELLIOTTCABLE> glowcoil:
<ELLIOTTCABLE> goddamnit
<ELLIOTTCABLE> whitequark: hi!
<whitequark> hi ELLIOTTCABLE
<ELLIOTTCABLE> i'm trying to write code i am bad at it
<ELLIOTTCABLE> but hey
<ELLIOTTCABLE> would be cool to see some Paws code run, by a codebase, that isn't fucksane
<whitequark> ELLIOTTCABLE: well
<whitequark> Paws code or Wick code?
<whitequark> I'm maybe not even opposed to former, I just like the latter much more ;p
<ELLIOTTCABLE> Paws, lol.
<purr> lol
<whitequark> on the second thought your non-returning booleans disgust me to the very core of my existence
<whitequark> I mean.
<whitequark> go write me a not() function that works
<glowcoil> oh man remember battlecollie
<ELLIOTTCABLE> glowcoil: yes
<glowcoil> <3
ELLIOTTCABLE is now known as BATTLECOLLIE
<BATTLECOLLIE> you mean me
<glowcoil> :DDD
<BATTLECOLLIE> whitequark: if they don't work well, and I find myself to need a boolean type in the core of the language, I'll add one.
<whitequark> BATTLECOLLIE: no, seriously
<whitequark> how do you write a not() function with your booleans?
<whitequark> as per your original proposal, i.e. me to write a pure Paws VM... what's the incentive?
* whitequark shrugs
<purr> ¯\(º_o)/¯
<BATTLECOLLIE> there is none;
<BATTLECOLLIE> and if you like the ‘other parts’ of it enough to be inspired to write an awesome language that uses them, I'm all agog.
<BATTLECOLLIE> seriously.
<BATTLECOLLIE> All I want in the entire universe is to see the programming world made slightly less terrible by my efforts.
<BATTLECOLLIE> I've known *forever* that the chance of Paws becoming a real, working product … much less a well-known language, much-much less one that makes anybody's life better,
<BATTLECOLLIE> is miniscule.
<whitequark> (other language) there's one thing I'm not doing ever again, and it is advocating my own language
<BATTLECOLLIE> but the chances of somebody somewhere, in this room or elsewhere, being inspired by my ideas, or my talking about it, or my philosophy, to do something that benefits others?
<BATTLECOLLIE> Mission accomplished, IMO.
<whitequark> basically the entire purpose of Wick is to serve a proof of concept that it is a better Paws than Paws
<BATTLECOLLIE> but, if you want an incentive:
<whitequark> it doesn't exist outside of that, nor it ever will
<BATTLECOLLIE> a language with two people working on it is (some huge multiplier)-times more likely to be successful, and to be something *other* than a waste of either of those peoples' time.
<BATTLECOLLIE> and ditto three people vs two people,
<BATTLECOLLIE> and so on, up to some level of diminishing returns.
<BATTLECOLLIE> Or, to simplify: Working on a terrible Paws with me is more productive work, in the end, than working on an excellent Wick. ;)
<BATTLECOLLIE> anyway:
<BATTLECOLLIE> re not()'s
<BATTLECOLLIE> A) dunno, would have to think about it. Busy elsewhere.
<BATTLECOLLIE> B) doesn't matter, because ‘boolean’ is a misnomer.
<BATTLECOLLIE> If I need a *true boolean*, I'll add one.
<BATTLECOLLIE> For instance, there's a good chance that i'll add one to a later version of the spec, or at least use 'true' and 'false' labels or something, because of compare() existing.
<BATTLECOLLIE> At the moment, conceptually *boolean* operations (compare, etc) using a ‘Paws' boolean’ is a bit of a hack. Possibly temporary, depends on if it pisses me (or others, e.g. you) off enough.
<BATTLECOLLIE> But, that said, Paws' booleans *themselves*, that is, the concept of *literally not returning when no ‘result’ is relevant or generated*, is something I'm fairly dead-set on, unless it makes the language truly unwieldily to use.
<BATTLECOLLIE> My opinion:
<BATTLECOLLIE> things returning numeric 0, or undefined in JavaScript, or something like that, are mildly-harmless *bad habits* that encourage a *not at all harmless* bad habit: not fucking thinking about the return value of your API very much.
<whitequark> I disagree, simply because "no result at all" is different from "the result of no"
<BATTLECOLLIE> no, agreed.
<BATTLECOLLIE> read above.
<BATTLECOLLIE> “that is kind of a hack.”
<whitequark> i.e. if you always return undefined, then you're right
<BATTLECOLLIE> I'm speaking, here, of "no result at all." Paws' booleans in their *intended* form, not when they're being used to convey falseness.
<whitequark> if nothing is returned, how do you sequence actions?
<BATTLECOLLIE> what do you mean?
<whitequark> say you want to execute a combination A returning nothing, and *after* it executes, combination B
<BATTLECOLLIE> (going to go back to coding in a sec, mildly drunk, and really want to produce a little here. Not in the mood for in-depth chats, right this sec.)
<BATTLECOLLIE> er, not sure on the *combination* level.
<BATTLECOLLIE> but it's a simple, solved-problem at the routine level.
<whitequark> how?
<BATTLECOLLIE> As with everything else **ordering** is dictated by responsibility:
<whitequark> plesae don't tell "locking".
<BATTLECOLLIE> …
<BATTLECOLLIE> why not?
<BATTLECOLLIE> It's Paws. It's how it's designed. All ordering is managed by locking. That's the *purpose* of our locking system.
<whitequark> no, your ordering is mainly managed by the executions
<BATTLECOLLIE> It's so important I even wrote a note in my terrible spec: ‘This isn't just about concurrent-access; it's a system used for all sorts of purposes throughout the language.’
<whitequark> ugh. fuck this.
<BATTLECOLLIE> glowcoil: gone?
<glowcoil> sorry was focusing on homework for a bit
<glowcoil> BATTLECOLLIE: ordering is usually accomplished through *value-returning*
<glowcoil> BATTLECOLLIE: *only* in the case of when there isn't a value do you use locking for ordering
<glowcoil> BATTLECOLLIE: just because you *can* use locking for ordering doesn't mean it's a good idea
<whitequark> the idea that the proper way to maintain ordering is to abuse the system used to represent ownership is abhorrent
<whitequark> yes, exactly what glowcoil says
<BATTLECOLLIE> ಠ_ಠ
<BATTLECOLLIE> then I mis-named, or you mis-associated, responsibility as a whole.
<BATTLECOLLIE> 's a reason I'm not calling it locking.
<glowcoil> BATTLECOLLIE: calling-back
<glowcoil> BATTLECOLLIE: is how you sequence when a value is needed
<whitequark> what glowcoil says
<glowcoil> BATTLECOLLIE: responsibility is not involved
<BATTLECOLLIE> only if you're being **synchronous**. And that's not true in a majority of situations.
<BATTLECOLLIE> hence, you know, the entire point of Paws.
<glowcoil> ddis
<glowcoil> the point of paws is that
<BATTLECOLLIE> yes, in the *single use-case* where you're called synchronously, and then you result synchronously, you're ordered by *the calling* itself*
<glowcoil> you can write f(g)
<glowcoil> where f gets suspended until g returns
<glowcoil> and the *next line* or however you want to organize
<glowcoil> gets executed regardless of g's or f's completion
<glowcoil> like, the point of paws is specifying those relationships
<BATTLECOLLIE> if A) your caller has other work to do, and doesn't stop its entire world to wait on you; or B) *you* have other work to do after trying to provide this particular result to the caller, then ordering is entirely in the domain of the responsibility system
<BATTLECOLLIE> 'n that's exactly what it's designed to handle.
<glowcoil> remember stage()
<BATTLECOLLIE> not-returning-a-value is one of the many special cases of those possibilities;
<BATTLECOLLIE> and thus should be handled by the responsibility system.
<glowcoil> although i think stage() as a primitive is Bad, and it should be possible syntactically
<whitequark> BATTLECOLLIE: or, you know, you could not spuriously enforce synchronity *also in Executions*
<glowcoil> but responsibility should *not* be necessary here
<BATTLECOLLIE> whitequark: hm?
<glowcoil> responsibility is for disparate things accessing the same resource
<whitequark> there's *no* reason to enforce synchronity in executions, and the whole mess with locking being necessary to perform ordering stems from just that
<BATTLECOLLIE> no, that's locking. and locking is a side-effect of responsibility.
<glowcoil> BATTLECOLLIE: you should be able to write some code that says: do f. when f is done, do g. but while that's going on, do h.
<BATTLECOLLIE> What you're seeing is the effect of the responsibility-system handling locking; *not* an effect of the locking-system handling responsibility.
<glowcoil> BATTLECOLLIE: if you can write arbitrary dependency-trees, then that is possible
<BATTLECOLLIE> glowcoil: you can; that kind of stuff is supposed to be handled by granular executions
<whitequark> glowcoil: I don't care how you call it; what you have in the spec *is* a locking system
<whitequark> er
<glowcoil> BATTLECOLLIE: right and you do not need responsibility for this
<whitequark> BATTLECOLLIE: ^
<BATTLECOLLIE> … you can. by writing arbitrarily nested executions.
<glowcoil> right so
<whitequark> BATTLECOLLIE: it does all of locking and nothing more, therefore it is a locking system
<BATTLECOLLIE> whitequark: yes, I'm aware. But I'm saying *that locking system* was *not designed for locking*. It happens to walk like a locking system, and quack like a locking system, *but it's an ordering system*.
<BATTLECOLLIE> Yes, it damn-well does more, it fucking orders
<BATTLECOLLIE> you just don't *like* that it orders.
<BATTLECOLLIE> i'm going back to code.
<BATTLECOLLIE> I'm too drunk for this argument right now.
<glowcoil> BATTLECOLLIE: it orders in an entirely different fucking way
<glowcoil> BATTLECOLLIE: ok we can continue talking later but you are confusing two entirely different things
<whitequark> BATTLECOLLIE: yes, exactly
<glowcoil> very specific order-recipes from the programmer
<glowcoil> and ordering based on competing for the same resource, not planned by the programmer but necessary to stop race conditions and inconsistent states
<BATTLECOLLIE> long story short: I understand your reservations; but none of them are convincing *outside of actively using it*. If, *writing code in it* is literally obtuse and difficult and whatnot, yes, I'll clearly be changing how it works; but none of the arguments against it *in the absence of actual user-experience testing* make it sound like a bad thing.
<whitequark> BATTLECOLLIE: you can have asynchronity as a tool, you can have it as philosophy, and you can run around and masturbate with it
<glowcoil> BATTLECOLLIE: please illustrate
<glowcoil> BATTLECOLLIE: please please illustrate how you use responsibility to order like, print a and then print b
<glowcoil> not necessarily code-illustrate
<glowcoil> just ideas-illustrate
<whitequark> you *are* masturbating with it, and I'm tired of having arguments where the main argument is "because asynchronity!!1one"
<glowcoil> like, how does responsibility even come into play there
<whitequark> not participating in Paws anymore.
<BATTLECOLLIE> glowcoil: I didn't say it does *all* ordering.
<BATTLECOLLIE> I'm saying, only, this:
<BATTLECOLLIE> It was designed, from the very start, to do some of the ordering.
<glowcoil> ugggggh i know that
<glowcoil> i agree and like that
<glowcoil> what i'm saying is
<glowcoil> does print ever return
<BATTLECOLLIE> so the argument “You're conflating your locking system to do the ordering!??! GET A REAL ORDERING SYSTEM YOU DUMBTARD!”
<BATTLECOLLIE> is in valid.
<BATTLECOLLIE> because it *is* the real ordering system, for those situations.
<glowcoil> uggggggggghhhhh
<glowcoil> BATTLECOLLIE: does print return
<glowcoil> when done
<BATTLECOLLIE> undefined, there is no print. (Not being pedantic, I literally can't figure out what you're asking me)
<glowcoil> BATTLECOLLIE: ok, take some side-effecting opreation with no useful valuers to give back to the caller
<BATTLECOLLIE> I mean, give me a question of the form “given a print which doesn't re-stage,” or “given a print that re-stages,”
<glowcoil> BATTLECOLLIE: does it just leave a synchronous-caller hanging forever, or does it resume them when done
<BATTLECOLLIE> ah k
<BATTLECOLLIE> Leaves it hanging, presumably, given the phrase ‘synchronous caller.’
<glowcoil> ok so
<glowcoil> why is that sensible, when
<glowcoil> if that side-effecting opreation *does* have a value ot give back
<glowcoil> it *does* resume normally, with a value
<BATTLECOLLIE> that's the sort of thing you convey in documentation. Invocation pattern being specific to a particular API chunk, the caller should know, and then use, the correct method
<glowcoil> why not use the same system for sequencing in the cases where there's a value, or multiple values, or no valuse
<glowcoil> like, this could be unified so you can use the same tools
<glowcoil> or you use *entirely* different methods of programming paws depending on whether a method returns "ok done" or "ok done and also here's a message"
<glowcoil> which is unnecessary, and bad design
<glowcoil> responsibility is a great system, i like it
<glowcoil> but use it for things that it is
<glowcoil> and use resuming for things that that is
<BATTLECOLLIE> last two sentences didn't make sense, rephrase?
<glowcoil> like, so if A wants to jump to B, and then get a value back from B and then continue with that value
<glowcoil> A calls B, and B resumes A with the value
<glowcoil> but if A wants to jump to B, but B has no values to give back, but A wants to continue *after B is done*, just like in the previous situation
<BATTLECOLLIE> no, *just* the last two messages; I get the rest
<glowcoil> all of a sudden you use something entirely different?!
<glowcoil> ok the last two messages
<glowcoil> we have a good system for ordering
<glowcoil> the dependency tree/calling-and-resuming/whatever
<glowcoil> that is for *intentional ordering*
<BATTLECOLLIE> the problem is in *thinking* about everything like that, as if the B in the first message and the B in the second message are the same thing.
<BATTLECOLLIE> Look at it this way:
<glowcoil> they ARE the same FUCKING thing
<BATTLECOLLIE> you're basically saying,
<BATTLECOLLIE> “So, if A wants to call function B, …”
<BATTLECOLLIE> and then “So, if A wants to throw exception B, …”
<glowcoil> what?!
<glowcoil> not in any way whatsoever
<BATTLECOLLIE> and then yelling at me for those two things having different syntax or different patterns-of-use.
<glowcoil> how is
<glowcoil> printing
<glowcoil> throwing an exception?
<glowcoil> that's complete nonsense
<glowcoil> how is closing a port throwing an exception?
<glowcoil> how is drawing to a screen throwing an exception?
<glowcoil> there are plenty of things that have nothing to say back except for that they are done
<BATTLECOLLIE> A bit of code that *never returns* is substantially different from a multi-entry coproducing tool, is substantially different than a synchronous mutate-and-return ‘function’, is substantially different from …
<BATTLECOLLIE> blahblahblah.
<glowcoil> and they are *not* exceptions, they're the same code-pattern as tasks that have something to say back when they're done
<BATTLECOLLIE> executions are **a primitive**, in an *intermediate-form* language.
cloudhead has joined #elliottcable
<BATTLECOLLIE> Something that they can be made to do via abstraction on top of existing tools, is something I have a hard time believing I should build into the language.
<glowcoil> BATTLECOLLIE: you don't have to build it into the language
<glowcoil> BATTLECOLLIE: this is a library choice
<glowcoil> BATTLECOLLIE: both are entirely possible given the tools we have designed into the langauge
<BATTLECOLLIE> so, again: I'm not sure why we're arguing it. Like I said: I'm *open to change*. I've heard your arguments, and all. Give me a chance to *use both solutions* while writing code, because I'm not actually *changing* it until I do.
<glowcoil> BATTLECOLLIE: and you're saying, every standard library function that doesn't have values to return just *shouldn't return*, indistinguishably from an infinite loop
<glowcoil> and then here comes this unrelated langauge feature we can make suck its own dick
<glowcoil> to use for this purpose as well
<glowcoil> ok so you have two routines, print something out and get a line of input
<glowcoil> so getting a line of input uses normal returning, no responsibility necessary
<BATTLECOLLIE> The language is basically stable. I'm not going to make any changes that don't *fix an actual design-bug*, until we start on the next big chunk. By which I mean, if it doesn't make something that's impossible, possible; or make something that's *obviously painfully obtuse* more sleek and friendly-UX, it's going to be put off.
<glowcoil> printing something out *could* use normal returning
<glowcoil> but instead oh we're going to use responsibility
<glowcoil> BATTLECOLLIE: this is NOT ADDING A LANGUAGE FEATURE.
<BATTLECOLLIE> yes, so it's even *more* trivial-why-are-we-arguing-this.
<BATTLECOLLIE> It's something that could *literally* easily be changed at the last moment, as opposed to something difficult-to-change, but premature-to-change-right-now.
<BATTLECOLLIE> /=
<BATTLECOLLIE> Okay. *breathes*
<BATTLECOLLIE> here's a more cogent example.
<glowcoil> if you explained the tools paws gives you
<glowcoil> then no one would naturally come up with your solution
<glowcoil> like, resuming is obviously for resuming
<glowcoil> and responsibility is not obviously for resuming, it's for atomicity and shit
<BATTLECOLLIE> Was trying to figure out how to get into the details of this, but it's really not worth it, so,
<BATTLECOLLIE> at a high level:
<BATTLECOLLIE> *Lots of things* in *lots of languages* provide different calling-patterns for fairly similar things; some of them, with more back-flips than others. Many of those *could* be more integrated, but aren't (usually, because it's not worth it; for me, this one's for different reasons, but …).
<BATTLECOLLIE> The *closest* example I can think of for this,
<BATTLECOLLIE> is “multiple return-values.”
<BATTLECOLLIE> (relevant, I'll get there in a sec)
<BATTLECOLLIE> you *could* have something like lisp's literally-returning-multiple-values-to-a-single-place,
<BATTLECOLLIE> but most languages have the user construct the pair or triplet of values, or whatever is relevant, into an array or set or something, and then return that.
<BATTLECOLLIE> the caller, then, has to deconstruct those into individual variables within its own scope.
<BATTLECOLLIE> Some languages even provide syntax / semantics for that exact situation.
<BATTLECOLLIE> with Paws, yes, there's a little more syntax to it, but preparing-to-call-something-that-doesn't-return needing its own little backflips *isn't conceptually different* from preparing-to-call-something-that-returns-multiple-results in some other language.
<BATTLECOLLIE> now, that's not a complete refutal to your argument: that's *just* preempting the response that ‘WHY are they treated differently, everything should be the same!’
<BATTLECOLLIE> a *non-producing bit of code* is substantially-enough different, that it doesn't bother me that the use pattern is slightly different.
<BATTLECOLLIE> as for the conceptual argument, I simply disagree. I mean, I'm not sure how to *argue* that, because I invented this thing in my head, and I simply clearly think about the entire architecture differently from how you do. To me, this is “the way it's always been”, and <clearly> makes sense and is the way it should be, for some value of <clearly.>
<BATTLECOLLIE> and the only way to resolve that particular aspect, is to *work with it*. See which has the best actual usability-affecting patterns in active use.
<glowcoil> there was a time before responsibility was even in paws, i thought
<BATTLECOLLIE> yah, and this was completely undefined.
<BATTLECOLLIE> but when responsibility ‘came in,’ it was definitely not a locking system.
<glowcoil> like, returning null or the equivalent was the solution
<BATTLECOLLIE> that came *after* it was originally conceived as necessary, waybackwhen
<glowcoil> i know for a *fact*
<BATTLECOLLIE> yeah, there was a lot of ‘nothingness’ concepts, all of which I've given up on including
<BATTLECOLLIE> (got deferred to userspace, just like booleans, for now)
<glowcoil> that responsibliity was not conceived to let you resume after something doesn't return
<BATTLECOLLIE> conceived as a whole, for that? lol no. conceived in part, though? absolutely!
<purr> lol
<BATTLECOLLIE> do you want to keep talking about this? we're clearly getting nowhere. I've spent the last *hour* talking in here. /=
<glowcoil> no i have to do homework
<glowcoil> your position absolutely boggles my mind, and has convinced whitequark to stop being involved with paws
<glowcoil> but yeah we're not getting anywhere
<glowcoil> and i need to get some things done
<BATTLECOLLIE> Frankly, it was far from the most likely thing to drive him away. He's, uh, fiery; and I'm very opinionated and stalwart.
<BATTLECOLLIE> Neither is he dumb, literally the first thing he said when he decided to participate was “99.9% chance I'll want you to change something, you won't, and I'll ragequit.” :P
<glowcoil> BATTLECOLLIE: regarding returning tuples, if you're returning multiple heterogenous values you should not be using multiple returns, you should be using tuples or whatever
<glowcoil> BATTLECOLLIE: like there can be a more first-class system for it than in most languages but
<glowcoil> BATTLECOLLIE: multiple returns is for homogenous sequences of values, since they go to the same syntactic place in the code
<BATTLECOLLIE> yah, not disagreed. was besides my point
<glowcoil> and in that case then no-returns means
<glowcoil> an empty sequence
<glowcoil> and thus should *not* return
<glowcoil> but in the case of things that *finish* but have no values
<glowcoil> that should not be semantically the same as something that has 0 values to return
<BATTLECOLLIE> holy crap, squat toilets are a thing
<BATTLECOLLIE> a really, really common thing
<BATTLECOLLIE> I mean, you assume life is different in other parts of the world, but I never thought *this* different
<whitequark> you can occasionally meet them in RU
<whitequark> though that implies that the building is *old*; dating back to at least 70s
<BATTLECOLLIE> whitequark: what'd you think, the first time you saw one? O_O
<whitequark> BATTLECOLLIE: what about it? it's a hole for shit
<whitequark> regular toilet is also a hole for shit
<whitequark> there's not really a difference
yorick has joined #elliottcable
<purr> <elliottcable> go burn orphanages for half an hour
<glowcoil> BATTLECOLLIE: sorry for angry fighting
<glowcoil> BATTLECOLLIE: <3
audy has joined #elliottcable
audy has quit [Changing host]
audy has joined #elliottcable
nuck has quit [Ping timeout: 240 seconds]
nuck has joined #elliottcable
PragCypher has joined #elliottcable
audy has quit [Ping timeout: 240 seconds]
Sgeo has quit [Read error: Connection reset by peer]
alexgordon has joined #elliottcable
Sorella has joined #elliottcable
Sorella has joined #elliottcable
alexthegreat has joined #elliottcable
alexthegreat has quit [Client Quit]
PragCypher has quit [Ping timeout: 240 seconds]
<purr> <elliottcable> My tests are too programmatic. I might have to write meta-tests to test my tests' functionality.
PragCypher has joined #elliottcable
Sorella has quit [Ping timeout: 252 seconds]
Sorella has joined #elliottcable
yorick has quit [Remote host closed the connection]
audy_ has joined #elliottcable
audy_ has quit [Client Quit]
<alexgordon> cloudhead: yo, here?
eligrey has joined #elliottcable
<cloudhead> alexgordon: ya
<alexgordon> cloudhead: yay! I have a question about https://github.com/cloudhead/node-static
<cloudhead> mhm
<cloudhead> (keep in mind I haven't looked at it in a few years)
<alexgordon> yeah yeah
<alexgordon> cloudhead: I'm trying to serve static files from node, but I need good range support
<alexgordon> I was using st but then I realized it didn't have any support for range requests, so I have to replace it
<cloudhead> ah i see
<alexgordon> is there a node module that'll do that or is my only option to reverse proxy to nginx or something
<cloudhead> I don't know of any
<cloudhead> I'd assume there is one though
<alexgordon> you'd think
<cloudhead> it's not too late to switch to Go
<cloudhead> lol
<purr> lol
<alexgordon> :D
<alexgordon> nah I tried go and it annoyed the hell out of me
<alexgordon> too many implementation details
<purr> <ec> gleaming fucking love sword.
PragCypher has quit [Quit: Leaving]
Sorella has quit [Quit: Ex-Chat]
<purr> <elliottcable> I'm perfectly safe inside my fish, thankyouverymuch
yorick has joined #elliottcable
cloudhead has quit [Ping timeout: 255 seconds]
<BATTLECOLLIE> o7 all
<purr\Paws> [Paws.js] ELLIOTTCABLE pushed 1 new commit to copy-reactor+: https://github.com/ELLIOTTCABLE/Paws.js/commit/9819fdca91b9754c7b1b774c9b40cd82d41122c1
<purr\Paws> Paws.js/copy-reactor+ 9819fdc elliottcable: + simple associative-table for ownership. (also discarding `Mask` type)
<purr\Paws> [Paws.js] ELLIOTTCABLE force-pushed copy-reactor+ from 9819fdc to 5da0972: https://github.com/ELLIOTTCABLE/Paws.js/commits/copy-reactor+
<purr\Paws> Paws.js/copy-reactor+ 5da0972 elliottcable: + simple associative-table for ownership. (also discarding `Mask` type)
vil has quit [Read error: Operation timed out]
vil has joined #elliottcable
<BATTLECOLLIE> Dude, let's build a henge or two! ♪
<BATTLECOLLIE> ♪ Stonehenge by Ylvis
<purr> BATTLECOLLIE is listening to “Stonehenge”, by Ylvis
<purr\Paws> [Paws.js] ELLIOTTCABLE pushed 1 new commit to copy-reactor+: https://github.com/ELLIOTTCABLE/Paws.js/commit/3279da4481aa2c1d74805510c6c95c7d31e362ff
<purr\Paws> Paws.js/copy-reactor+ 3279da4 elliottcable: + forcing ##construct to be responsibility-aware
yorick has quit [Remote host closed the connection]