<vigs>
I'm like three weeks behind in my Computer Design class so I'm playing catch up today, so no, I haven't written a paws yet :'(
<ELLIOTTCABLE>
hm. is process.title still non-functional on OS X? o_O
<gregwhitworth>
From reading this it seems like it's Java, write once run everywhere
<gregwhitworth>
I'm also inclined to ask if it can be run by a browser then why won't it run in all of them
<ELLIOTTCABLE>
Mmm, except it's write-once-run-everywhereatonce. Distributed programmin', and all that.
<ELLIOTTCABLE>
hm? it should run in all of them. Well, eventually. I introduced some code that's killing tests in a bunch of the browsers, but I'm a little preoccupied from fixing that yet.
<gregwhitworth>
Ok
<ELLIOTTCABLE>
it's definitely intended to be compatible with basically everything as far back as IE 6.
<gregwhitworth>
I get the async aspect I just am curious what I would use it for
<gregwhitworth>
maybe I'm missing something
<ELLIOTTCABLE>
Basically: it's meant to be what Node.js and JavaScript “could have been.”
<gregwhitworth>
ok
<ELLIOTTCABLE>
working in Node for web-related or network-related stuff is excellent; asynchronous programming is clearly the future for a huge sector of tasks
<gregwhitworth>
that's what I was curious about as it seemed very similiar to node
<ELLIOTTCABLE>
problem is, callback hell. Writing asynchronous logic in a purely synchronous language (no continuations, no promises or anything like that, etceteras) is truly a pain.
<gregwhitworth>
yeah, have you played with C# async
<ELLIOTTCABLE>
nope, never touched C#
<gregwhitworth>
that's where a lot of the yields and stuff came from
<gregwhitworth>
They had to tackle this a while back as well
<vigs>
C# has some interesting async stuff
<gregwhitworth>
It may be worth looking at
<vigs>
I had to use it once.
<vigs>
Once.
<ELLIOTTCABLE>
coroutines are neat, of course.
<gregwhitworth>
since you could see what you like and hate
<ELLIOTTCABLE>
Paws is *really* weird. Nothing like that, though.
<gregwhitworth>
Maybe that should be your opening line
<ELLIOTTCABLE>
Its single primitive is a little bit like some cross between a delimited continuation and a coroutine
<gregwhitworth>
:)
<ELLIOTTCABLE>
(is C#'s approach a coroutine one? I'll take a look.)
<gregwhitworth>
I believe so, I'm not a huge async person in C#
<gregwhitworth>
I just know some guys at Microsoft live by it
<gregwhitworth>
That's why it was added in, for reasons your stating but that doesn't mean it's perfect (no language will be though)
<ELLIOTTCABLE>
I'm a huge fan of anybody, anywhere, properly supporting asynchronous development. :D
<gregwhitworth>
I lived by PHP, switched over to C# and .NET and now even get annoyed by JS
<ELLIOTTCABLE>
yeah, looks like coroutines. await meaning a traditional ‘yield’
<gregwhitworth>
Typed languages are beautiful
<gregwhitworth>
yeah
<ELLIOTTCABLE>
so, if you're familiar with that, the core innovation of Paws is that every single operation acts as an `await` in that sense.
<gregwhitworth>
ok
<gregwhitworth>
gotcha, always waiting then, or at minimum expecting a result
<ELLIOTTCABLE>
nothing ever ‘returns’ in the synchronous sense; they simply hand themselves over to somebody, and that somebody can resume them whenever it wishes (traditionally, with results; although not remotely in *all* cases is that the call-pattern used)
<gregwhitworth>
async though
<gregwhitworth>
sounds pretty slick
<gregwhitworth>
would love to see it running something
* ELLIOTTCABLE
nods
<ELLIOTTCABLE>
thanks for taking a look for me. (=
<gregwhitworth>
especially in comparison to something else
<gregwhitworth>
No problem
<ELLIOTTCABLE>
Been a while since I did anything user-facing. Feels good to write.
<ELLIOTTCABLE>
spent the other day beautifying --help output, too.
<gregwhitworth>
I'll star it so that I can follow it
<ELLIOTTCABLE>
I'm always surprised when I hear that; I always tend towards assuming that only closeted Windows developers use it. ;)
<gregwhitworth>
No, it's quite popular actually, and .NET is very powerful
ELLIOTTCABLE has left #elliottcable [#elliottcable]
ELLIOTTCABLE has joined #elliottcable
gregwhitworth has quit [Quit: Page closed]
<vigs>
ELLIOTTCABLE: nothing too serious, but yes; at work, the (web) frontend automated testing framework is written in C# (just like the rest of the non-mobile software my company releases)
<vigs>
And I worked on that framework last summer
inimino has joined #elliottcable
<ELLIOTTCABLE>
ugh goddamnit
<ELLIOTTCABLE>
something amongst my fragile construction of coffee-coverage, coffee script, mocha, mocha-lcov-reporter, Travis CI, and Coveralls, is breaking horribly
<ELLIOTTCABLE>
and I can't figure out which bit is causing it
<purr\Paws>
Paws.js/Master 49b9c19 elliottcable: (- meta noop) Ignore failing coverage-generation on Travis builds
<ELLIOTTCABLE>
whee. Coverage and travis builds all fixed, so that feels good too.
<ELLIOTTCABLE>
devyn: any response? you went quiet!
<devyn>
ELLIOTTCABLE: my response is "neat"
<devyn>
it's a good overview
<ELLIOTTCABLE>
thanks (=
<ELLIOTTCABLE>
any ways I can improve it?
<devyn>
maybe some examples of what you can do with it
<ELLIOTTCABLE>
yeah, need some content in the `usage` category
<ELLIOTTCABLE>
getting there. (=
<devyn>
alright
<devyn>
^_^
<ELLIOTTCABLE>
really need to start thinking about federation
<ELLIOTTCABLE>
both 'cuz getting to the point where I need to start writing some abstractions, and thus I need a place to *put* them, and thus I need Units, and thus I need a unitary interface design
<ELLIOTTCABLE>
… and 'cuz, distribution is cool, and you're going to write me a paws, right? and then we can connect them up together and cheer and eat peaches
<ELLIOTTCABLE>
;)
<ELLIOTTCABLE>
-didja @ devyn
<purr>
devyn: didja write a paws yet? didja? didja!?
<devyn>
workin' on it!
<devyn>
right now
<ELLIOTTCABLE>
:D
<ELLIOTTCABLE>
I died.
<ELLIOTTCABLE>
I just, absolutely, fucking died. ('=
<ELLIOTTCABLE>
manveru: actually, just wrote that README today. I'm not really big on documenting my work in a static form, previously. >,>
<ELLIOTTCABLE>
trying to be a little bit better about writing down what the fuck it is I'm actually doing.
<ELLIOTTCABLE>
ah, k
<ELLIOTTCABLE>
anyway. done anything particularly neat, since last time we talked?
<ELLIOTTCABLE>
any open-souce work at all?
<manveru>
pretty much everything i do open-source is on github
<ELLIOTTCABLE>
oh my god, I forgot ramaze was a thing
<manveru>
though i haven't done much of that this year... apart from the steam client for go
<ELLIOTTCABLE>
node-steam. interesting.
<manveru>
atm i'm working on a replay parser for dota2
<manveru>
esports got fucking big :)
<ELLIOTTCABLE>
replay parser?
<ELLIOTTCABLE>
esports?
<ELLIOTTCABLE>
SPEAK ENGLISH, MAN
<manveru>
hehe
<ELLIOTTCABLE>
googled esports
<ELLIOTTCABLE>
and was immediately set upon by the urge to jump off my balcony ಠ_ಠ
<ELLIOTTCABLE>
now this crap has infiltrated my safe-haven of geekdom?
<ELLIOTTCABLE>
GOD FORBID
<manveru>
yes sir
<ELLIOTTCABLE>
revolting. truly revolting.
<ELLIOTTCABLE>
:P
<manveru>
i'll fly to seattle in summer for the biggest event this year :)
<ELLIOTTCABLE>
you're coming to the U.S.?
<manveru>
frequently
<ELLIOTTCABLE>
ah, neat
<manveru>
was in SF last year
<ELLIOTTCABLE>
let me know if you come through Chicago. (=
<manveru>
chicago was two years ago ^^;
<manveru>
was at a voip conference for a few days
<manveru>
so... where the hell can i find paws samples?
<manveru>
all i see so far is a half-assed lisp rip-off :P
<manveru>
in js none the less
<ELLIOTTCABLE>
That's because you don't have the mental capacity to look beyond syntax and pay attention to the seman—*cough*, I mean, let me enlighten you.
alexgordon has joined #elliottcable
<ELLIOTTCABLE>
there's no syntax; given that lisp gravitated towards s-exprs because McCarthy had more important things to think about than syntax, any code you've seen is a similarly syntax-light expression of a set of operations.
<ELLIOTTCABLE>
think a cross between lisp and the JVM bytecode.
<ELLIOTTCABLE>
anyway. important part of Paws is none of that. it's basically a JVM for CPS-transformed operations, designed to have those CPS-transforms abstracted away beautifully.
<ELLIOTTCABLE>
trying to leverage the excellent asynch properties of pervasive CPS, without the pain that comes from most of the attempts to mix CPS with, well, anything the fuck else.
<manveru>
what's a CPS?
<ELLIOTTCABLE>
er
<ELLIOTTCABLE>
crap.
<ELLIOTTCABLE>
okay, another approach.
<manveru>
continuation-passing-style?
<ELLIOTTCABLE>
yah
<manveru>
cyber-physical-system?
<manveru>
ok...
<manveru>
continuations i know at least
<ELLIOTTCABLE>
good, good
<ELLIOTTCABLE>
had me scared there, for a second :P
<ELLIOTTCABLE>
Paws-based programming languages' “functions” don't ever ‘return.’ There's no synchronous calls like that. Instead, when some code needs a subroutine to do some work for it, they pass *themselves* to that subroutine.
<ELLIOTTCABLE>
it's a lot like a delimited continuation, but with less state.
<ELLIOTTCABLE>
that structure, a bit of code that passes itself to other bits of code, is called an ‘execution’ … which is exactly what it is. Instead of being a bit of data that says “you have a handle on me, and that means you can *continue* from <given location>”, which is what a continuation does; an execution *is* the running-of-the-code that was previously
<ELLIOTTCABLE>
going on at <given location>.
<ELLIOTTCABLE>
Subtle difference, but has a couple important ramifications. Anyway, moving on.
<ELLIOTTCABLE>
Paws lends itself very, very strongly to asynchronous workflows: if `a` calls `b`, there's no reason that `a` has to stop and wait for `b`.
<ELLIOTTCABLE>
to turn that on its head, there's also no reason why `b` necessarily needs to worry about ever ‘returning’ to `a`.
<ELLIOTTCABLE>
less-obviously, since ‘returning’ results is now a flexible construct … not only can it happen <never>, or more traditionally <once> … it can happen <many> times, as well.
<ELLIOTTCABLE>
which obviously lends itself very well to ‘generator’-style code. `a` calls `b`, waits for results; then `b` resumes a copy of `a`'s frozen state every time it gets new data.
<manveru>
kinda sounds like chicken scheme
<ELLIOTTCABLE>
there's several more patterns like that that take advantage of those properties (it's fairly trivial to implement traditional continuations on top of executions, for instance; similarly, trivial to implement user-friendly explicit coroutines)
<ELLIOTTCABLE>
yep, like I said, pretty similar to delim continuations
<ELLIOTTCABLE>
so, that's the primary execution model of the machine.
<ELLIOTTCABLE>
there's some other crap thrown in there
<ELLIOTTCABLE>
ranging from the boring (lua/javascript/lisp-esque object system, straightforward as it can be) to the really fucking awesome (automated massive parallelization of your code; distributed computing; time-travelling error correction)
<ELLIOTTCABLE>
but most of that's still under development/design. Part I explained is the part that matters.
<ELLIOTTCABLE>
anyway. back to code!
<manveru>
:)
<ELLIOTTCABLE>
oh, thanks for coming and hanging out. Missed y'all.
<ELLIOTTCABLE>
trying to think of the name of the other guy.
<ELLIOTTCABLE>
not the furry, errrr, wassahwratface
<manveru>
shevy?
<ELLIOTTCABLE>
fuck. it really *has* been that long.
<ELLIOTTCABLE>
nahhh, although, lol yes him too,
<purr>
lol
<manveru>
that guy is still alive and planning world domination or something
<ELLIOTTCABLE>
shevy? really? :P
<ELLIOTTCABLE>
I more see him as the Ruby Lapdog of the Revolution.
<manveru>
uhm... yeah, pretty much
<manveru>
he tries to turn everything he touches into ruby
<manveru>
i just wish he actually knew ruby :P
<manveru>
anw, carry on, i'd love to have some distributed version of smalltalk some day
<ELLIOTTCABLE>
gemstone?
<ELLIOTTCABLE>
was pretty sure there *was* a distributed smalltalk. hm.
<manveru>
yeah, gemstone/s does that
<manveru>
but it also costs a fortune i think
<manveru>
whatever happened to maglev...
<ELLIOTTCABLE>
yeah I was about to say
<ELLIOTTCABLE>
afaik maglev is alive and well
<ELLIOTTCABLE>
but I haven't ruby'd in yeaaaaarrrs
<alexgordon>
man why is it so hard to find a suitcase without a telescoping handle
<katlogic>
Also polite way 'JS sucks since it does not allow arbitrary type as a key, only strings)
<alexgordon>
wait, it doesn't?
<katlogic>
No, keys are string only
<katlogic>
(Arrays is just special optimised case)
<ELLIOTTCABLE>
katlogic: lolrite
<purr>
lolrite
<ELLIOTTCABLE>
even arrays appear, for every single possible way, to be strings too
<ELLIOTTCABLE>
javascript array is map of string-ish base-ten integers to values.
<ELLIOTTCABLE>
or at least, looks that way from within the language.
<katlogic>
Well, it used to be like that, but the spec eventually matched the actual implementation in ES3 or so
<ELLIOTTCABLE>
current status: trying to fuck node's readline module in the anus.
<katlogic>
That is, for 0..n integers, keys are always coerced to integers
<ELLIOTTCABLE>
at this rate I should just tear the whole thing out and roll my own /=
<katlogic>
anything else, still string
<ELLIOTTCABLE>
katlogic: what's the practical difference between “strings coerced to integers” and “integers coerced to strings”?
<ELLIOTTCABLE>
in terms of acting as a key, that is.
<katlogic>
ELLIOTTCABLE: For example, iteration
<ELLIOTTCABLE>
oh, 'course. I'm only speaking in terms of assignment.
<katlogic>
lemma: a = []; a[-1] = 1; b[0] = 2; for (k in a) ...
<katlogic>
compared to for (k = 0; k < a.length; ...
<ELLIOTTCABLE>
the Array type seems easiest to understand if one thinks of it as an Object that has a magical .length property
<ELLIOTTCABLE>
that's how I tend to explain it to newcomers, anyway
<katlogic>
Well, it _is_ an object
<katlogic>
with magical semantics of [] for 0..n integers (and strings coerced to that :)
<katlogic>
That said, ArrayBuffers are even more wtf
<katlogic>
but meh, flaming about JSs consistency is kinda tired topic
<katlogic>
i really wish there was just built-in object which allowed arbitrary keys
<ELLIOTTCABLE>
ugh fuck me, the readline module really *does* stomp on just about every goddamn thing.
<alexgordon>
wtf you can get "men's" and "unisex" luggage, what's the difference
<ELLIOTTCABLE>
katlogic: don't we all.
<katlogic>
ELLIOTTCABLE: what are you trying to do with it?
<ELLIOTTCABLE>
I'm big on the pretties.
<katlogic>
Ah, ansi colors 'n stuff
<ELLIOTTCABLE>
current tweak out of many: the entire line that the prompt resides on should be inverted.
<ELLIOTTCABLE>
yep
<katlogic>
might be better off to just ffi ncurses
<ELLIOTTCABLE>
so, couple problems: readline.js like to stomp on the content of the line constantly, to ‘refresh’ the content … and monkey-patching my way into that looks like a nightmare, because it's spread across a ton of functions
<ELLIOTTCABLE>
god, nurses is worse
<katlogic>
indeed, but works for this kind of shit
<ELLIOTTCABLE>
believe me, I know, I've written a ridiculous quantity of code relying on nurses /=
<katlogic>
ie render buffers for line and all
<katlogic>
doing ansi manual is all fun and games ... until you need actual "pixel buffer"
<ELLIOTTCABLE>
only if you think/work in its model, which is the *worst* model evar
<ELLIOTTCABLE>
if you're not trying to draw some god-awful “window” approximation using Unicode characters and treating the terminal as a grid of pixels, then ncurses is *not* your friend.
<katlogic>
ELLIOTTCABLE: Anyways, just pull readline.js and beat it to your liking
<ELLIOTTCABLE>
katlogic: yah, about to do exactly that :P
<katlogic>
monkeypatching existing node apis might seem polite at first, but ultimately kinda silly is silly :)
<ELLIOTTCABLE>
ncurses was great back when that was still kitschy, but nobody sane wants to do that nowadays.
<ELLIOTTCABLE>
well, I'm more torn between diving in and pull-requesting a bunch of fixes, or just re-writing it locally
<ELLIOTTCABLE>
problem with both is that joyent/ry's coding style is massively anathema to me.
<ELLIOTTCABLE>
to me, all the syntax needs to get shoved over to the right edge of the file, out of the reader's way. It's bad enough that they dedicate entire *lines* to random syntax noise like brackets,