<Cheery>
ELLIOTTCABLE: does that explain what I'm doing?
<ELLIOTTCABLE>
Will have to look when I get back
<ELLIOTTCABLE>
Mayyyyve tonight if you remind me
<Cheery>
well the idea is to create text prompt, which sort of explains the grammar for you if you get it wrong, and proposes fixes.
<ELLIOTTCABLE>
Ohhhhhh interesting
<ELLIOTTCABLE>
So an interactive, feedback-y parser
<ELLIOTTCABLE>
What an interesting idea, where'd you get that?
<Cheery>
it came by sort of an accident last thursday
<Cheery>
Were trying out if I could make a transpiler which targets C, that'd be able to type inference
<ELLIOTTCABLE>
so what's your approach to prediction? How do you know what feedback might be interesting to the user
<ELLIOTTCABLE>
(At a high-level. Explain it like I'm ELLIOTTCABLE.)
<ELLIOTTCABLE>
ELIec
<Cheery>
made a pretty parser, which parses directly to structure, then realised how my current parser for my VM language sucks.
<Cheery>
then realised that I couldn't parse my stuff with that pretty way
<Cheery>
then went to play with parsers..
<Cheery>
it's combination of techniques here.
<Cheery>
I use the kind of parser that tries to match to the whole grammar. It produces lot of trash.
<Cheery>
the overall idea is that the user is trying to do something, but he doesn't possibly know the syntax, or wants shortcuts
<Cheery>
so the parser matches it to everything, and then goes through the matches. I'm trying to sort of diff it to the every rule in the grammar
<Cheery>
then calculate how large changes the input requires to produce the thing.
<Cheery>
sum of this kind of 'searches'.
<Cheery>
series of calculations and probabilities, then it picks couple, synthetises examples from them.
<Cheery>
I don't know if it will exactly work. :) I'll see
<Cheery>
if it doesn't work, it will guide me to another tryout.
<Cheery>
one problem that I'm wondering is about the ratio, on objects that have otherwise good diff, but it's partial, somewhere in a long string there's an error.
<Cheery>
I guess I have to do some matching magic to drop out the edges of the match to let the user fix one error at a time.
<purr\Paws>
Paws.js/Master e602f2d elliottcable: (- re api) stage() respects immediate: instead of incrementAwaiting:
<purr\Paws>
Paws.js/Master 4936433 elliottcable: (new tests) Exercise most of the untested reactor basics
<ELLIOTTCABLE>
well that was unreasonably much work
<ELLIOTTCABLE>
barely even started on "round completion".
<ELLIOTTCABLE>
luckily, I now see how to do it, so, this should be easy.
<ELLIOTTCABLE>
but then I have to write an entire testing module for within Paws.js
<devyn>
haha, I've been working on round completion,
<devyn>
though I think it may need to change a bit once I implement responsibility (I only have ownership atm)
<ELLIOTTCABLE>
also,
<ELLIOTTCABLE>
159 passing (586ms)
<ELLIOTTCABLE>
5 pending
<ELLIOTTCABLE>
woo, I suppose
<ELLIOTTCABLE>
wat
<ELLIOTTCABLE>
oh, I get it
<ELLIOTTCABLE>
nothing actually is responsible for anything, you just have the in-memory data-structures created
<devyn>
er, I mean executions just can't be charged at the moment
<devyn>
you can own() or disown() things and that's all there
<devyn>
and I've been mindful to create objects with appropriate ownership
<ELLIOTTCABLE>
yah that's what I assumed
<devyn>
I just haven't figured out a sane way to implement ownership masking yet
<devyn>
that's all that's waiting on
* ELLIOTTCABLE
nods
<ELLIOTTCABLE>
yeah that's actually up-in-the-air
<ELLIOTTCABLE>
not design-wise, but optimizability-wise
<ELLIOTTCABLE>
there's *got* to be an efficient storage and comparison formats for sub-graphs …
<devyn>
yeah, I know what Paws.rs does ;)
<ELLIOTTCABLE>
right?
<devyn>
er
<devyn>
Paws.js
<ELLIOTTCABLE>
huh?
<devyn>
yes, I would think so
<ELLIOTTCABLE>
no, Paws.js's is **completely** naive
<devyn>
(I mean, I know that Paws.js's is naive)
<ELLIOTTCABLE>
in fact, so completely slow and naive that I literally have a comment in the source-code
<devyn>
yeah
<devyn>
I read it
<devyn>
lol
<purr>
lol
<ELLIOTTCABLE>
despite it being JavaScript, and despite it being Paws, and despite it being a reference implementation,
<ELLIOTTCABLE>
I still found it fit to point out that "no matter how slow you're assuming things are, this particular part is ridiculously unoptimized by even *those* standards."
<ELLIOTTCABLE>
like, that's saying a lot. :P
<ELLIOTTCABLE>
happy about only 5 pending, now.
<ELLIOTTCABLE>
still really really want to add TODO's and FIXME's to `test` output as pending tests.
<ELLIOTTCABLE>
centralize incomplete shit.
<devyn>
I've been pretty good about keeping up with unit testing. I've got 63 tests at the moment and they're not just little sanity checks since I have a typechecker :p
<ELLIOTTCABLE>
hahah yeah
<devyn>
lol
<purr>
lol
<devyn>
[master 55ee57e] Round completion part 1: stall detection in the queue 11 files changed, 385 insertions(+), 206 deletions(-)
<ELLIOTTCABLE>
wat
<devyn>
sidenote: I love how in Rust you can just write `unimplemented!()` when you're working on something and that part isn't done yet
<ELLIOTTCABLE>
check out the sports/ section and explorer/ section
<ELLIOTTCABLE>
both in detail
<ELLIOTTCABLE>
I'm almost orgasmic over the data.
<ELLIOTTCABLE>
the only downside is the whole bit where he's a fucking runner, but, lol watever
<purr>
lol
<devyn>
god damn that's impressive
<devyn>
there's so much data
<devyn>
like
<devyn>
it even has his heart rate while he was out at a certain place on a trip
<ELLIOTTCABLE>
I probably have about ten times that much data,
<ELLIOTTCABLE>
minus the awesome heart-rate specifics.
<ELLIOTTCABLE>
I *really* want to collate it all, some day, in a way like that.
<devyn>
haha
<ELLIOTTCABLE>
but, "some day"
<ELLIOTTCABLE>
I'm super data-insane.
<ELLIOTTCABLE>
You should see how much I snap at people if they check in at a location on Foursquare and don't check me in with them. >,>
<devyn>
haha
<devyn>
I can see you doing that
<ELLIOTTCABLE>
for a really, really long time, I maintained reliable transportation-type data via my Foursquare checkins *and* reliable arrive-leave times.
<purr\Paws>
Paws.js/support-rulebook 037f63b elliottcable: (new API) Emit 'flush' event on empty-queue
<purr\Paws>
Paws.js/support-rulebook 4724af7 elliottcable: (- meta doc) Add some TODOs for the executable
<devyn>
ELLIOTTCABLE: by the way, remember my branch-a-lot.paws that does 8192 branches and then a print at each one? well, now I can time it. 0.32 seconds ;)
<ELLIOTTCABLE>
devyn: make sure this functionality is hidden behind the "am_running_language_specs" flag of whatever sort you have
<devyn>
and also takes significantly less work to change, I'm sure
<devyn>
moreso even in the future
<devyn>
which is why it's the reference impl, as well
* ELLIOTTCABLE
nods
<ELLIOTTCABLE>
I don't feel *bad*
<ELLIOTTCABLE>
doesn't mean I'm not jealous :D
<devyn>
well you can have it too :D
<ELLIOTTCABLE>
someday.
<ELLIOTTCABLE>
but there'll always be a balance: only optimizations that don't obscure the code.
<devyn>
no, I mean Paws.rs; you can have it too
<ELLIOTTCABLE>
a less-extensible, blazing-fast optimized JS impl is a reasonable idea
<ELLIOTTCABLE>
perhaps even writing and compiling it to asm.js.
<ELLIOTTCABLE>
as long as the compiled stuff exports a JS API.
<ELLIOTTCABLE>
ohhhhh yes
<devyn>
there are some obvious optimizations you could do on Paws.js that wouldn't make a shred of difference to clarity I'm sure, if you just ran a profiler
<ELLIOTTCABLE>
actually that's a very good point, I still haven't installed it O_O
<ELLIOTTCABLE>
defffinately
<ELLIOTTCABLE>
I expect it to be orders of magnitude faster than it is now, once I start paying attention
<ELLIOTTCABLE>
but not going to worry about it. no good reason to spend that time right now
<devyn>
mmhm
<devyn>
yeah
<ELLIOTTCABLE>
*if* I didn't have you with you head on optimizations, then maybe.u88u7u7
<ELLIOTTCABLE>
'cuz then I'd have good reason to prematurely optimize: to scout the optimization potential of the design itself
<ELLIOTTCABLE>
(Despite that being an explicit non-goal of Paws' design …)
<devyn>
yeah
<devyn>
well, so far it's not looking terrible for an optimized implementation
* ELLIOTTCABLE
smiles
<devyn>
there are certainly still things I can do that I'm not doing yet
<ELLIOTTCABLE>
anyway. just a reminder that Paws itself is HUGELY fucking broken and nowhere near mattering, still.
<devyn>
and there are still things I have to look at, like responsibility
<ELLIOTTCABLE>
we're fucking around with implementations of a completely broken and damned-near useless language, with the sole purpose of informing the next design decisions that can hope to *fix* that brokenness.
<devyn>
yep
<ELLIOTTCABLE>
#realitycheck
<devyn>
ELLIOTTCABLE: one of the things I actually planned to do a long time ago is scrap advance() completely and just compile scripts down to a minimal op set with embedded objects and a stack. does that interfere with anything?
<ELLIOTTCABLE>
I hope to hell not. That's actually kinda the design-target.
<ELLIOTTCABLE>
advance() is a weird hybrid of that, the real implementation in the original C impl, and the desired *semantic* of reduction
<devyn>
cool
<devyn>
yeah 'cuz the advance() algorithm as it is is a total clusterfuck and it could be compiled down to something so much simpler
<devyn>
I actually already did that once, in Haskell
<devyn>
haha
<ELLIOTTCABLE>
unless I'm very mistaken … an execution that has been advanced to an arbitrary point, should be *indistinguishable* in every way from an execution created with only the content after that point, whose data-graph state (including locals and receiver) are copied from the previous sort
<ELLIOTTCABLE>
yeah advance is so fucked
<ELLIOTTCABLE>
so so fucked
<ELLIOTTCABLE>
kinda terrified to touch it
<devyn>
and I *ported* that, ELLIOTTCABLE, based on your spec, even, not even looking at Paws.js
<ELLIOTTCABLE>
it's like micah's parser in that I don't really understand it, but worse, because *I wrote it*, so I can't go running to micah if I break it.
<ELLIOTTCABLE>
>,>
<devyn>
and it's still a clusterfuck
<ELLIOTTCABLE>
LOL
<purr>
LOL
<ELLIOTTCABLE>
that's because it's tightly-specified, duh
<devyn>
yeah, that's right, 120 lines with comments
<devyn>
I understand it completely, though; that's why I wrote the comments
<devyn>
still a clusterfuck
<ELLIOTTCABLE>
god that's still insane LOL
<ELLIOTTCABLE>
wow.
<ELLIOTTCABLE>
question.
<devyn>
yes?
<ELLIOTTCABLE>
there's subtle differences between running each test as a separate file (more specifically, in a separate *Unit*)
<ELLIOTTCABLE>
and running a whole suite of
<ELLIOTTCABLE>
actually nope that's Solveable™.
<devyn>
what differences?
<ELLIOTTCABLE>
any objections to dictating that the execution passed to `test()` be run in a new Unit?
<devyn>
that sounds a little too complex for early Paws impls
<devyn>
not sure about that
<ELLIOTTCABLE>
hrm
<devyn>
but the subtle differences really don't matter, I think
<devyn>
or at least, they really shouldn't, with well written tests
<ELLIOTTCABLE>
but it's important that the compiled-to-Paws versions, or more complex files that are written in Paws from the start, don't introduce subtle changes from when they're invoked directly and individually from the YAML files.
<devyn>
right, well we can test the test file for any inherent flaws like that
<devyn>
but I would consider that a test file bug
<ELLIOTTCABLE>
it's not just about well-written tests, though. We can assume perfect/excellent tests, and it's still adding really sneaky ways for confusion on the implementer's part.
<ELLIOTTCABLE>
like, if the *implementer* as a bug that leaks stuff out into global state, and that makes the tests pass locally, but fail when run by somebody else
<ELLIOTTCABLE>
just begging for all sorts of trouble
<ELLIOTTCABLE>
hrm.
<devyn>
then I think that's a useful bug for our tests to find
<devyn>
I see that as an advantage, not a source of confusion
<ELLIOTTCABLE>
hm k
<ELLIOTTCABLE>
will stop worrying about it for now
* ELLIOTTCABLE
installs js-yaml and grins
<ELLIOTTCABLE>
oh shit nope not yet
<devyn>
if we help someone figure out that their impl is doing anything really stupid like that, that's good
<devyn>
encourage people to run it both ways, if their impl supports it
<ELLIOTTCABLE>
ugh node
<ELLIOTTCABLE>
why the *fuck* don't you globals-sandbox modules ;_;
<ELLIOTTCABLE>
at the moment, there's a huge issue with scoping in Paws.js
<ELLIOTTCABLE>
like, I don't understand Node / JavaScript scoping well enough, because half the codebase "just works" when it shouldn't
<ELLIOTTCABLE>
(i.e. the files that are needed for that file to make sense, are never required.)
<ELLIOTTCABLE>
I'm leaking shit into globals in some way that's really bad, somewhere, and I haven't yet gotten around to hunt it down.
<ELLIOTTCABLE>
>,>
<devyn>
can't you just crack open an interpreter and inspect globals after loading it?
<ELLIOTTCABLE>
I mean, I know it's there.
<ELLIOTTCABLE>
not that big a problem.
<ELLIOTTCABLE>
just bitching that it *can* be a problem.
<ELLIOTTCABLE>
node ;_;
<ELLIOTTCABLE>
basically, I don't like typing Paws.Thing everywhere … but nor do I want to have ten lines at the top of every file doing `Thing = Paws.Thing` and similar …
<ELLIOTTCABLE>
so I tend to do some sort of crap where I throw all of the members of Paws.* (or reactor.*, or … whatever) onto the `globals` in the current file.
<ELLIOTTCABLE>
but my approaches to that and crap seem to leak into *other*, completely unrelated, global namespaces, commonly.
<ELLIOTTCABLE>
like, in ways I don't understand.
<ELLIOTTCABLE>
or I guess I do.
<ELLIOTTCABLE>
it's all one global namespace.
<ELLIOTTCABLE>
but it's fucking *impossible* for me to remember that.
<ELLIOTTCABLE>
like, no matter what I do, every time I'm writing JavaScript code, I tend to throw things into `globals` when I need local-variable-name access to those things …
<ELLIOTTCABLE>
just idk words
<ELLIOTTCABLE>
I can't ever wrap my head around the idea of a real language in the real world where there's no *objective* access to variables.
<ELLIOTTCABLE>
lexical scope is the worst fucking invention in the history of computer science.
<ELLIOTTCABLE>
wore than goto.
<ELLIOTTCABLE>
ಠ_ಠ
<devyn>
I dunno, I think type coercion is pretty useless, but I guess lexical scope is worse
<ELLIOTTCABLE>
I just I just I just I just I just … am not compatible with small concessions against usability, made in the name of huge gains in performance.
<ELLIOTTCABLE>
it's a personal failing.
<ELLIOTTCABLE>
I *get* where lexical binding is fast and efficient and analyzable and shit, and necessary for static knowledge, and all the huge benefits from all that,
<ELLIOTTCABLE>
but just, *none* of that shit is worth it to me, if I can't do `blah = my_current_scope`, and `do_generic_object_y_stuff_to_the_argument(blah)`
<ELLIOTTCABLE>
so. yeah. I abuse Node's exposure of the `globals` object constantly.
<devyn>
heh
<ELLIOTTCABLE>
and it's biting me in the ass right now.
<purr\Paws>
Paws.rs/master 2fd8225 Devyn Cairns: bin/paws_rs actually does useful stuff now
<devyn>
ELLIOTTCABLE: so basically I added the -R/--reactors option to add more reactors in parallel and it seems like parallelism is massively slowing things down at the moment, very probably due to contention, so I'm going to have to look into that
alexgordon has joined #elliottcable
alexgordon has quit [Quit: My iMac has gone to sleep. ZZZzzz…]