<ELLIOTTCABLE>
anyway, all the photos I have are from the *later* part, where it was all easy and flat (well, rocky, 'cuz streambed, but whatever)
<ELLIOTTCABLE>
but our first adventure of the afternoon, we ended up taking a different train that was.
<ELLIOTTCABLE>
mother.
<ELLIOTTCABLE>
fucking.
<ELLIOTTCABLE>
insane.
<vigs>
ooh
<ELLIOTTCABLE>
like, I wish I had some photos that conveyed it
<devyn>
mismatched types: expected `&[type error]` but found `&script::Instruction` (expected type error but found enum script::Instruction)
<devyn>
lol
<purr>
lol
<ELLIOTTCABLE>
the train was at a fucking 50, maybe even 55° angle at some points.
<ELLIOTTCABLE>
like I cannot even express how shitfuck terrifying that is on a wheeler.
<vigs>
wow
<ELLIOTTCABLE>
there were points where I was basically standing on the foot-wells' middle bar like a fucking ladder rung
<vigs>
.__.
<vigs>
that sounds so rad
<ELLIOTTCABLE>
and other ones, going back downhill, where I was literally standing *on* the front wheel-well, reaching as far down as I could to control the goddamn steering column
<ELLIOTTCABLE>
idk rad it was terrifying as shitfuck
<ELLIOTTCABLE>
we got nearly up to the treeline and gave up
<ELLIOTTCABLE>
thank god, it turned out the "really awesome trail" that "got up into the tundra quickly and was easy going way back for miles", that we'd been looking for and had suggested to us,
<ELLIOTTCABLE>
started half a mile further down the road from where we'd tried.
<devyn>
ELLIOTTCABLE: it basically replaces advance() by flattening scripts
<ELLIOTTCABLE>
kkay
<ELLIOTTCABLE>
would have waited until we had some tests, but whatever :P
<devyn>
[Discard, PushLocals, Push(symbol "hi"), Combine] represents {hi} for example, even encoding the 'pristine' state via [Discard, PushLocals]
<devyn>
nah, I'm 100% sure it's equivalent
<devyn>
it also will make it super easy to do semicolons later
<ELLIOTTCABLE>
basically, I think semicolons just encode into "replace resumption value with `locals`."
<ELLIOTTCABLE>
am I missing something, or is that literally all they do?
<devyn>
yep, encoded in this instruction language as [Discard, PushLocals]
<devyn>
(which is why pristine executions always begin with that)
<ELLIOTTCABLE>
gotcha
<devyn>
the pristine state is basically a semicolon
<devyn>
ELLIOTTCABLE: you might even consider dropping the idea of a 'pristine execution' altogether, since {; foo bar baz} is equivalent (it always discards the first response)
<ELLIOTTCABLE>
er, pristine has other meaning, but,
<ELLIOTTCABLE>
but only to advance().
<devyn>
exactly
<ELLIOTTCABLE>
when I refactor out advance(), pristine()'ll probably be removed, because it's not very paws-y to *know* that.
<ELLIOTTCABLE>
even in native code.
<devyn>
yeah, so I'm saying if {abc} as a pristine execution now, if you removed pristine executions, that would be equivalent to {;abc}
<purr\Paws>
Paws.rs/master c62ad35 Devyn Cairns: Fix documentation for Combine
<devyn>
ELLIOTTCABLE: also parallelism seems to be slowing things down a lot. when I go with 2 reactors it's often like 1.5x-2x the time, and 8 reactors is like 5-9x the time
<ELLIOTTCABLE>
that will probably change with different workloads.
<ELLIOTTCABLE>
need to explore methodologies of determining *when* to parallelize.
<ELLIOTTCABLE>
test 123
<ELLIOTTCABLE>
fucking fuck irccloud
<devyn>
well I know a major thing is if the 'locals' is shared, which is why branch-a-lot.paws is super slow
<devyn>
I think there are other things though
<devyn>
measuring lock contention seems to be hard though
<ELLIOTTCABLE>
shared?
<ELLIOTTCABLE>
all of it should be cloned
<devyn>
infrastructure execution branch[] [] doesn't clone all of the members
<devyn>
locals is a member of an execution
<ELLIOTTCABLE>
branches of executions should have a shallow-cloned copy of the original execution's members at branch-time
<devyn>
ELLIOTTCABLE: yes, but locals is one member in, so a shallow clone doesn't clone locals
<ELLIOTTCABLE>
nonono
<ELLIOTTCABLE>
it *specifically* clones the locals' members to the new execution, and assigns that clone to "locals"
<ELLIOTTCABLE>
interesting, never thought about that. forgot that you'd have to clone the *other* stuff, too.
<devyn>
okay
<ELLIOTTCABLE>
so yeah the cloning-of-locals is the part that's specified; but the cloning-of-existing-members …
<ELLIOTTCABLE>
oh snap.
<ELLIOTTCABLE>
peeeeerrrfect opportunity to exploit the reverse-lookup functionality.
<ELLIOTTCABLE>
just assign a new pair for the new clone-of-locals. The original locals-pair can be cloned along with the rest of the exec.
<ELLIOTTCABLE>
hell, you could basically tell how many times you'd been cloned by counting the results to `find('locals')` on yourself.
<devyn>
ok so just add a new pair
<devyn>
sure
<ELLIOTTCABLE>
gonna implement that now
<ELLIOTTCABLE>
or, later
<ELLIOTTCABLE>
meh
<ELLIOTTCABLE>
it's refreshing when I make an intended change, and then the test suite fails in the expected way
<devyn>
my test suite fails to typecheck more often than it actually catches things
<ELLIOTTCABLE>
yeah
<ELLIOTTCABLE>
wait, isn't that catching a thing?
<devyn>
well, not really, because it only failed to typecheck because I hadn't updated the test suite
<devyn>
if the test suite didn't exist there would be nothing to change
<ELLIOTTCABLE>
ah
<devyn>
but it does help make sure I know exactly how what I just wrote works
<devyn>
so
<devyn>
*shrug*
<purr>
¯\(º_o)/¯
<devyn>
so that change doesn't seem to have helped at all
<devyn>
might have done something wrong
<devyn>
not sure
<devyn>
I actually have a feeling that a lot of overhead's just coming from the queue
<devyn>
perf stat shows 38 context-switches for branch-a-lot(8192) with 1 reactor,
<devyn>
but 53,629 with 2,
<devyn>
and 175,123 with 4
<devyn>
I don't know exactly what that means though
<devyn>
in this case
<ELLIOTTCABLE>
wat fuck
<devyn>
yeah locals isn't getting cloned, I fucked something up
<devyn>
(fun fact, that produced over a million lines of debug output)
<ELLIOTTCABLE>
O_O
<devyn>
okay, it's a bit faster now (I think)
<devyn>
nvm
<devyn>
nvm, it's actually slower
<devyn>
lol
<purr>
lol
<devyn>
miiight be the queue
<devyn>
wonder if I can find a faster queue
<ELLIOTTCABLE>
premature optimization.
<ELLIOTTCABLE>
is it *too slow* to develop on / iterate with / test, when multiple-reactors are enabled?
<ELLIOTTCABLE>
if not, don't worry about the speed-loss for now. Consider that a new baseline, and work with them enabled, to catch bugs and shit.
<ELLIOTTCABLE>
optimize later.
<devyn>
nah, it's not too slow, but it's bugging me
<devyn>
:p
<ELLIOTTCABLE>
lolol
<purr>
lolol
<ELLIOTTCABLE>
strangest bug.
<devyn>
8192 branches with 8 reactors is like, 4 seconds
<ELLIOTTCABLE>
implementing it as we speak, actually
<ELLIOTTCABLE>
um
<ELLIOTTCABLE>
whatchoowannaknow
<ELLIOTTCABLE>
basically:
<devyn>
like, what happens? obviously the staging of the test execution can't be deferred
<ELLIOTTCABLE>
sure it can
<devyn>
er how
<ELLIOTTCABLE>
`spec test[] {...}` doesn't stage the test *immediately*, it stores it.
<devyn>
like, unless 'eventually' is mandatory
<devyn>
oh
<devyn>
okay
<ELLIOTTCABLE>
can either have an explicit way in the parent body to spin off all known tests,
<ELLIOTTCABLE>
or maybe dictate that that, too, happens on timeout/flush? idk.
<ELLIOTTCABLE>
or just on completion of the body.
<ELLIOTTCABLE>
I'm doing them as suites, sort of.
<devyn>
okay, hm, I don't really have a place to store global state like that
<devyn>
I guess perhaps on the 'spec' itself
<ELLIOTTCABLE>
global state?
<devyn>
well you've got to store 'all known tests'
<devyn>
where?
<devyn>
:p
<ELLIOTTCABLE>
I *do* have a global bit (`Collection.current`) specific to this spec stuff, but that's very much a hack, and implementation-dependant
<ELLIOTTCABLE>
yeah no don't store all known tests.
<ELLIOTTCABLE>
create a "Suite" type, store tests *on* a suite,
<ELLIOTTCABLE>
and in the **thing spinning off the test file**, create a Suite for that file.
<ELLIOTTCABLE>
(i.e. within the binary, whatever's receiving the treat-this-code-as-a-test, add-`specification`-namespace-stuff, instructions.)
<ELLIOTTCABLE>
make sense? not global. local, ish, to that invocation of "test-ish code."
<devyn>
ah, yeah, I think that makes sense
<ELLIOTTCABLE>
mind you:
<ELLIOTTCABLE>
should also be possible, somehow, to include output from multiple Paws files in a single "suite"
<ELLIOTTCABLE>
assuming your suites or whatever will be providing TAP output, I'm going to require that the output be complete amongst the entire Rulebook.
<ELLIOTTCABLE>
also: barring innovations, Rulebook will be "open." People can improve it with new tests that ascertain edge-cases of the actual written specification; and more usefully, people can add tests for Surfees.
<ELLIOTTCABLE>
(sounds like a kinda candy.)
<devyn>
surfees?
<devyn>
lol
<purr>
lol
<ELLIOTTCABLE>
features.
<ELLIOTTCABLE>
SRFI-equivalents.
<devyn>
ah
<devyn>
mmmkay
<ELLIOTTCABLE>
"ways that we're agreeing to extend both of our implementations."
<ELLIOTTCABLE>
the very first surfee, or whatever they're called, will probably be what we're writing **right now**.
<ELLIOTTCABLE>
the `specification` namespace / Rulebook support.
<ELLIOTTCABLE>
basically, Amendments to the Paws specification.
<ELLIOTTCABLE>
lol, actually, that's a great name. Going with it.
<devyn>
so wait, is the namespace 'specification' or 'spec'?
<ELLIOTTCABLE>
`specification`
<devyn>
and yeah sure
<devyn>
:p
<devyn>
ok
<ELLIOTTCABLE>
since they're usually compiled, I see no reason to care if it's long.
<ELLIOTTCABLE>
also pretty 'cuz it matches `infrastructure` and `implementation`
<devyn>
almost, it's one char off
<ELLIOTTCABLE>
aw damn
<ELLIOTTCABLE>
`specifcation`
<ELLIOTTCABLE>
just to fuck with people.
<ELLIOTTCABLE>
-best plan
<purr>
PLAN IS BESTPLAN
<devyn>
no, actually, it needs one more char
<devyn>
sspecification?
<devyn>
lol
<ELLIOTTCABLE>
lol
<purr>
lol
<ELLIOTTCABLE>
`specifications`?
<ELLIOTTCABLE>
non-issue.
<ELLIOTTCABLE>
good way to start a habit of choosing things' names so they're exactly the same length as all three of those, in the future, instead of based on what's intuitive :P
devyn changed the topic of #elliottcable to: length matching is better than intuitiveness
<ELLIOTTCABLE>
this is going very well, over here.
<ELLIOTTCABLE>
damn near have TAP output.
<ELLIOTTCABLE>
not … totally sure eventually works as intended.
<ELLIOTTCABLE>
will see very very soon.
<ELLIOTTCABLE>
damn, I might have this supporting Rulebooks before I sleep.
<ELLIOTTCABLE>
… I wonder what the total number of LOC written for Paws at this point, is.
<ELLIOTTCABLE>
have to include complete re-implementations, which would take a little digging through git histories.
<devyn>
Paws.rs is 5504
alexgordon has joined #elliottcable
<ELLIOTTCABLE>
I shat my pants.
<ELLIOTTCABLE>
`cloc` said I had 845,470 SLOC, 524,225 of JavaScript.
<ELLIOTTCABLE>
… then I realized I'd omitted `--exclude-dir=node_modules`.
<devyn>
hahaha
<ELLIOTTCABLE>
Paws.js is 2,516.
<devyn>
well, idk about SLOC
<devyn>
guess cloc should work for Rust
<devyn>
apparently it actually supports Rust, directly
<devyn>
o.o
<ELLIOTTCABLE>
my entire Paws-implementations directory (you'd be scared to know how many folders are in there. >,>)
<ELLIOTTCABLE>
is 8,344 when deduped
<ELLIOTTCABLE>
`brew install cloc`. `cloc .`
<devyn>
so yeah Paws.rs is 3350 SLOC
<ELLIOTTCABLE>
it's simple as fuck, big fan
<ELLIOTTCABLE>
I'm surprised I've only written 8,344 SLOC relevant to Paws. Strange.
<devyn>
apparently I like blank lines: 1,068 blank lines
<devyn>
also 903 comments
<ELLIOTTCABLE>
more random stats:
<ELLIOTTCABLE>
Across all those projects, 493 commits / 36,940 insertions / 25,080 deletions
<ELLIOTTCABLE>
(by me)
<devyn>
wow
<devyn>
lol
<purr>
lol
<ELLIOTTCABLE>
especially interesting stat,
<ELLIOTTCABLE>
because my *all time* impact is 100,000 lines, 2,000 commits.
<ELLIOTTCABLE>
(although those numbers are rounded and old.)
<ELLIOTTCABLE>
but vaguely, that means Paws is approximately 62% of all the code-changes I've ever made. ish. (depends on how useful a stat "impact" / insertions+deletions is.)
<ELLIOTTCABLE>
… but only 25% of all commits. bigger commits? o_O
<devyn>
awesome, you're missing the count though :p
<ELLIOTTCABLE>
i no
<ELLIOTTCABLE>
got other blockers,
<ELLIOTTCABLE>
like,
<ELLIOTTCABLE>
the bit where that's not doing the right shit AT ALL
<ELLIOTTCABLE>
the eventually isn't *remotely* connected to the body of the rule at all LOL
<purr>
LOL
<ELLIOTTCABLE>
and the rule body isn't even run right now …
<ELLIOTTCABLE>
and,
<devyn>
lol
alexgordon has quit [Quit: My iMac has gone to sleep. ZZZzzz…]
<ELLIOTTCABLE>
I'm still confused as to how thef uck I'm going to tie the Unit to the body
<ELLIOTTCABLE>
like.
<ELLIOTTCABLE>
eventually has to do with *the entire unit*.
<ELLIOTTCABLE>
how can we possibly run multiple tests, in a single unit, in parallel?
<ELLIOTTCABLE>
won't all their eventuallies fuck with each other?
<ELLIOTTCABLE>
any one of them could run anytime the queue flushes.
<ELLIOTTCABLE>
vair confused.
<ELLIOTTCABLE>
three redbulls in,
<ELLIOTTCABLE>
5:15 AM.
<devyn>
I have a solution for that, actually
<devyn>
I think
<ELLIOTTCABLE>
oh?
<devyn>
basically don't make them each individual eventuallies; just put one eventually up that loops through the rules and runs their eventuallies if they didn't get any pass/fail already
<devyn>
and pass[]/fail[] won't be able to be on `specification`; they'll have to be in the locals of the body
<devyn>
and specific to that rule
<devyn>
but yeah I think it can work
<ELLIOTTCABLE>
well, I'm doing something vaguely similar to that
<ELLIOTTCABLE>
flush is an *event* in my impl
<ELLIOTTCABLE>
you know, node-style
<ELLIOTTCABLE>
so I'm not sure if it'll work as intended, yet, or not, haven't really thought it through,
<ELLIOTTCABLE>
but tests can register/de-register their eventuallies with the flush event.
<ELLIOTTCABLE>
basically, if they register *right before* staging, and then de-register if completed (pass/fail) *before flush* …
<ELLIOTTCABLE>
nothing could cause a flush **before** the body is complete, by definition (except ownership backflips)
<devyn>
that sounds complicated
<ELLIOTTCABLE>
basically, flush-to-flush is a "round."
<ELLIOTTCABLE>
not a specified thing just an implementation thing.
<ELLIOTTCABLE>
no way to inject a *new* flush into a round,
<ELLIOTTCABLE>
but can inject new *activities* into a round, i.e. delaying the flush.
<ELLIOTTCABLE>
that can't break eventuallies, can it?
<ELLIOTTCABLE>
in the pathological case, all of the tests stage simultaneously, and thus any ones that haven't completed (i.e. de-registered) at the "end of the round" (at the flush), have their eventuallies run.
<ELLIOTTCABLE>
yea, that's okay. cool.
<devyn>
oh, yeah, maybe I can do that
<devyn>
my eventually also works as an event-like thing
<ELLIOTTCABLE>
so basically:
<ELLIOTTCABLE>
you only need to *deregister* eventuallies if the test *does* complete.
<ELLIOTTCABLE>
i.e. pass/fail.
<devyn>
machine.on_stall(proc(machine) { … })
<ELLIOTTCABLE>
yah that
<devyn>
can be called indefinitely but is a one-shot
<ELLIOTTCABLE>
unit.on 'flushed', -> ...
<ELLIOTTCABLE>
identical
<devyn>
yep
<ELLIOTTCABLE>
er, sorry
<ELLIOTTCABLE>
unit.once 'flushed', -> ...
<ELLIOTTCABLE>
yeah.
<ELLIOTTCABLE>
I had exactly that bug earlier tonight, was using .on,
<ELLIOTTCABLE>
and finally-things were happening over and over and over and over :P
<devyn>
haha
<devyn>
well they actually have to be a one-shot in Rust, due to the way proc() and lifetimes work
<ELLIOTTCABLE>
interesting
<devyn>
regular closures (which have Ruby-ish syntax) are bound to whatever environment you're in,
<devyn>
but proc()s can escape that environment and own their own environment
<devyn>
but they can only be called once
<devyn>
after that they're consumed
<ELLIOTTCABLE>
interesting.
<ELLIOTTCABLE>
okay i have two twittercrushes, and it's annoying
<ELLIOTTCABLE>
at the place I am in my life, I don't have time or energy for childish crushy shit; I just want to go get laid, in real life, in my own city. Not fall in like (gigglegiggle) with people on the internet.
* ELLIOTTCABLE
frowns
<devyn>
:c
<ELLIOTTCABLE>
hi devyn
<devyn>
hihi
<ELLIOTTCABLE>
u r awke
<ELLIOTTCABLE>
cray
<ELLIOTTCABLE>
currently testing my testing-framework
<ELLIOTTCABLE>
which is weird.
<devyn>
it's too hot during the day lately
<devyn>
so I just sleep
<devyn>
all day
<devyn>
lol
<purr>
lol
<ELLIOTTCABLE>
lololol
<devyn>
ELLIOTTCABLE: do pass[] and fail[] unstage?
<ELLIOTTCABLE>
I can't imagine anything useful happening in a test after that, so let's say yes.
<devyn>
kk
<ELLIOTTCABLE>
and again, their argument is arbitrary
<devyn>
of course
<ELLIOTTCABLE>
-best nacho sleep
<purr>
NACHOSLEEP IS BESTSLEEP
<ELLIOTTCABLE>
why the fuck didn't I register the purr username on Twitter when I created purr?
<ELLIOTTCABLE>
it was probably still available back then.
<devyn>
nah, that wasn't thaaat long ago
<ELLIOTTCABLE>
wasn't purr pre-Paws?
<ELLIOTTCABLE>
that's going on 5 years.
<ELLIOTTCABLE>
Twitter's only, what, 8 old, now?
<devyn>
yeah, but come on, a four letter English word? people would be snagging those already by then
<ELLIOTTCABLE>
hahaha
<ELLIOTTCABLE>
ah. it was registered about a month after I joined. lol.
<purr>
lol
<ELLIOTTCABLE>
… or a year and a month?
<devyn>
yeah, not surprised
<devyn>
lol
<ELLIOTTCABLE>
lied
<ELLIOTTCABLE>
year and a month
<devyn>
still not surprised; you were an early adopter
<devyn>
lol
<ELLIOTTCABLE>
strange
<devyn>
@devyn was already registered by the time I joined, and that was pre-Paws too
<ELLIOTTCABLE>
I've never felt like a Twitter early-adopter
<ELLIOTTCABLE>
I was like, a fucking year late on that one
<ELLIOTTCABLE>
well, half a year
<ELLIOTTCABLE>
whatevs, a long time.
<devyn>
though I had something before @devynci, I think
<ELLIOTTCABLE>
… now *there's* a bit I'd like to flip …
<devyn>
hehe
<devyn>
"hireable": false.
<devyn>
lol
<purr>
lol
<ELLIOTTCABLE>
103 public repos.
<ELLIOTTCABLE>
time to go delete some forks.
<devyn>
I have 73
<devyn>
most aren't even forks
<ELLIOTTCABLE>
yeah I'm looking at ours side-by-side
<ELLIOTTCABLE>
I have about a dozen new forks recently
<ELLIOTTCABLE>
submitted some simple-ass pull-requests to almost every project I've used in the past month
<ELLIOTTCABLE>
GitHub's web-editor really *has* changed project management in some ways
<ELLIOTTCABLE>
also, contributing to my ability to "drip off the internet" :P
<devyn>
heh
<Cheery>
need to go get myself some paper.. and maybe walk.
<Cheery>
were going to do few queries on the grammar, but not sure about specifics, also a headache.
<ELLIOTTCABLE>
fuck.
<ELLIOTTCABLE>
devyn: I like Cheery's suggestive-syntax thing.
<ELLIOTTCABLE>
that could play really well with an IPP.
<joelteon>
heh
<joelteon>
suggestive syntax
<joelteon>
"ay gurl, wanna see my list literal"
<devyn>
lol
<purr>
lol
* ELLIOTTCABLE
smiles at joelteon
<ELLIOTTCABLE>
thanks for rocking.
* ELLIOTTCABLE
gives joelteon a cookie
* joelteon
gyrates back and forth
<ELLIOTTCABLE>
-cookie @ joelteon
<purr>
joelteon: +v means cookie
<devyn>
++ jeannicolas
<purr>
Let it be known that devyn loves jeannicolas.
<devyn>
err
<devyn>
++ joelteon
<purr>
Let it be known that devyn loves joelteon.
<ELLIOTTCABLE>
++ joelteon
<purr>
Let it be known that ELLIOTTCABLE loves joelteon.
<joelteon>
EC how close is paws to being production ready
<joelteon>
is it in the same municipality
<devyn>
hah, production ready
<joelteon>
is there a concept of production readiness for paws
<ELLIOTTCABLE>
Paws being “production-ready” is laughable.
<joelteon>
that's what I thought
<ELLIOTTCABLE>
but in terms of it being interesting in ways *other* than building the next Twitter …
<ELLIOTTCABLE>
there's basically two stages.
<ELLIOTTCABLE>
if you enjoy building tooling, or exploring new languages … basically, the kind of person who *enjoys programming*,
<ELLIOTTCABLE>
it's at that point right now.
<joelteon>
shots fired
<joelteon>
nice
<ELLIOTTCABLE>
(in some ways, it's in a similar place to Rust, if you ignore *implementation*: it's unstable, but the core ideas have pretty well stabilized.)
<ELLIOTTCABLE>
(any code you write is going to basically be wasted effort and meaningless in the long-run, because it's definitely not stable enough for actual code of any complexity whatsoever to carry through …
<ELLIOTTCABLE>
… but any concepts you learn now *will* carry through; such that "learning Paws" now, or involving yourself in the ecosystem, is pretty likely to *not* be wasted effort.)
<ELLIOTTCABLE>
the second stage, where there's an actual, easy-to-use product … sort of my *own* goal for the project,
<ELLIOTTCABLE>
still years of work away.
alexgordon has joined #elliottcable
<ELLIOTTCABLE>
I'd originally slated that point as 2017, basically. ("Seven years or more of work", said early 2010.)
<ELLIOTTCABLE>
wasted time partying, wasted time moving, wasted time all over. I'm at *least* a year behind.
<joelteon>
dude you could marry her after that time
<ELLIOTTCABLE>
that said, we're still at least three years of solid work in, on that schedule; and nothing's arisen to suggest to me that that timeline is too hugely skewed. So, idk, 2018?
<ELLIOTTCABLE>
marry who what
<joelteon>
bible joke
<ELLIOTTCABLE>
see I'd -paws that
<ELLIOTTCABLE>
except i have no idea where that potoshop went.
<ELLIOTTCABLE>
potatoshop.
<devyn>
ELLIOTTCABLE: looks like you're allowed to print the test count at the end with TAP
<devyn>
if you really want to
<ELLIOTTCABLE>
yeah i saw
<ELLIOTTCABLE>
that's definitely happening
<devyn>
ok, I probably will print it at the beginning
<devyn>
I see no point to print at the end the way I'm doing it
<devyn>
just more work
<ELLIOTTCABLE>
kkkk
<ELLIOTTCABLE>
I'm not being strict about suites, at all
<ELLIOTTCABLE>
which is probably bad
<ELLIOTTCABLE>
but it's all very loosely-associated
<ELLIOTTCABLE>
if a test *happens* to run, and *happens* to either pass or fail (or pend or …),
<ELLIOTTCABLE>
then cool. it'll print some output when that happens.
<devyn>
heh
<ELLIOTTCABLE>
but it's super un-strict and sketch.
<ELLIOTTCABLE>
it'll probably be totally possible to write tests that don't complete before the system decides to crap out and close the reactor,
<ELLIOTTCABLE>
or that get out of order or something
<ELLIOTTCABLE>
idk we'll see LOL SKETCHY CAFFEINECODE
<purr>
LOL
<devyn>
lol
katlogic has quit [Read error: Connection reset by peer]
<devyn>
ELLIOTTCABLE: to what extent is the eventually block set up? are locals from outside copied into it? is it run even if the test has already passed or failed? (in that case, surely any pass or fail within that block must be ignored)
<ELLIOTTCABLE>
the exact same locals should be *copied* into both the test-body, and any further blocks like eventually
<ELLIOTTCABLE>
but neither should they share locals with each other, or with the outer environment
<ELLIOTTCABLE>
it shouldn't be run if the test has passed or failed
<ELLIOTTCABLE>
hence 'eventually': "if nothing happens, 'eventually do this"
sharkbot has quit [Remote host closed the connection]
sharkbot has joined #elliottcable
<ELLIOTTCABLE>
Hi, all.
<joelteon>
High, awl.
<alexgordon>
ELLIOTTCABLE!
<alexgordon>
trying to work out what to do about data structures
<alexgordon>
joelteon: care for some bikeshedding?
<joelteon>
absolutely
<ELLIOTTCABLE>
alexgordon: "what to do about data structures"
<ELLIOTTCABLE>
alexgordon: so, big things, happening in the world of Paws.
<alexgordon>
ELLIOTTCABLE: ^ e.g. ADTs vs structures vs enums vs constant groups
<ELLIOTTCABLE>
You should go back and read the logs about testing and shit
<ELLIOTTCABLE>
You'll find it interesting.
<alexgordon>
k will do
<alexgordon>
but later :P
<alexgordon>
joelteon: lemme gist
<alexgordon>
oh btw
<ELLIOTTCABLE>
I'm basically trying to hybridize SRFIs and RubySpec, into a single system that programmatically aids in "healthy-izing the Paws ecosystem"
<alexgordon>
I've decided to add optional curly braces to furrow