<ELLIOTTCABLE>
4:01 PM <+alexthegreat> prophile: lol you know your country is fucked when you have to ask "which great firewall?"
<purr>
lol
oldskirt_ is now known as oldskirt
joelteon has quit [*.net *.split]
ELLIOTTCABLE has quit [*.net *.split]
ohhmaar has quit [*.net *.split]
manveru has quit [*.net *.split]
glowcoil has quit [*.net *.split]
Navarr has quit [*.net *.split]
Determinist has quit [*.net *.split]
eligrey has quit [*.net *.split]
Rusky has quit [*.net *.split]
rf has quit [*.net *.split]
jeannicolas has quit [*.net *.split]
Cheery has quit [*.net *.split]
vigs has quit [*.net *.split]
inimino has quit [*.net *.split]
irclogger_com has quit [*.net *.split]
sharkbot has quit [*.net *.split]
yorickpeterse has quit [*.net *.split]
alexthegreat has quit [*.net *.split]
gkatsev has quit [*.net *.split]
othiym23 has quit [*.net *.split]
sammcd has quit [*.net *.split]
akshatj-c has quit [*.net *.split]
SwooshyCueb has quit [*.net *.split]
katlogic has quit [*.net *.split]
purr has quit [*.net *.split]
ag_dubs has quit [*.net *.split]
devyn has quit [*.net *.split]
cloudhead has quit [*.net *.split]
oldskirt has quit [*.net *.split]
vil has quit [*.net *.split]
Willox has quit [*.net *.split]
prophile has quit [*.net *.split]
amatecha has quit [*.net *.split]
ChanServ has quit [*.net *.split]
ohhmaar has joined #elliottcable
vil has joined #elliottcable
cloudhead has joined #elliottcable
inimino has joined #elliottcable
Willox has joined #elliottcable
yorickpeterse has joined #elliottcable
purr has joined #elliottcable
SwooshyCueb has joined #elliottcable
prophile has joined #elliottcable
katlogic has joined #elliottcable
oldskirt has joined #elliottcable
othiym23 has joined #elliottcable
Navarr has joined #elliottcable
glowcoil has joined #elliottcable
eligrey has joined #elliottcable
joelteon has joined #elliottcable
devyn has joined #elliottcable
gkatsev has joined #elliottcable
amatecha has joined #elliottcable
sammcd has joined #elliottcable
Determinist has joined #elliottcable
ag_dubs has joined #elliottcable
Cheery has joined #elliottcable
manveru has joined #elliottcable
irclogger_com has joined #elliottcable
sharkbot has joined #elliottcable
alexthegreat has joined #elliottcable
akshatj-c has joined #elliottcable
jeannicolas has joined #elliottcable
ELLIOTTCABLE has joined #elliottcable
vigs has joined #elliottcable
rf has joined #elliottcable
katlogic has quit [Ping timeout: 256 seconds]
eligrey has quit [Read error: Connection reset by peer]
katlogic has joined #elliottcable
Rusky has joined #elliottcable
ChanServ has joined #elliottcable
TheMathNinja has joined #elliottcable
alexthegreat has quit [Quit: My iMac has gone to sleep. ZZZzzz…]
eligrey has joined #elliottcable
<devyn>
ELLIOTTCABLE: I think you're totally forgetting that this should be possible to run without a fully conforming Paws machine
<devyn>
ELLIOTTCABLE: and I intentionally chose label-comparison because it's so much simpler than object-comparison
<devyn>
thing-comparison*, whatever
<devyn>
ELLIOTTCABLE: I want something that people can implement really easily. timeouts aren't necessarily an easy thing to implement, but recognizing 'stalling' is a much more generic thing
<devyn>
(i.e., the Machine couldn't possibly do anything more)
<devyn>
plus, as I understand it, defining stalling is going to be necessary for freezing anyway; we need to be able to run the machine until there's nothing that can possibly continue, except whatever delayed/IO actions that are pending that we're going to freeze
<devyn>
ELLIOTTCABLE: plus, if you re-read, I did specify that the execution is staged with the name; it's just that those executions happen to be pristine
<devyn>
ELLIOTTCABLE: having to redirect output to a buffer somewhere and then compare that for the purpose of testing seems... complicated, and again, I want something that a bare-bones implementation that someone just started that is nowhere near complete but has the spec stuff could run
<ELLIOTTCABLE>
“Though, a representative from the sect did say on February 3, "About 4:00 PM yesterday, some changes were noticed in his skin (it became greenish). The body was then shifted to a freezer," which may or may not be part of the traditional protocol for transcendent bliss.”
<ELLIOTTCABLE>
lol sarcastic news-writing. love it.
<purr>
lol
<ELLIOTTCABLE>
devyn: hi, reading
<ELLIOTTCABLE>
hm, you're right, I lost sight a little,
<ELLIOTTCABLE>
but still, my questions stand
<devyn>
ok, will answer
<devyn>
ELLIOTTCABLE: assert/refute with a universal 'signal' because the pass or fail relies on 'stalling', right? in the case of 'refute', it's considered to pass if it *doesn't* get the signal
Willox has quit [Quit: Connection closed for inactivity]
<devyn>
ELLIOTTCABLE: what other questions still stand?
<devyn>
other than the one I just answered
<devyn>
:p
<ELLIOTTCABLE>
sorry, multitasking
<ELLIOTTCABLE>
reading
<ELLIOTTCABLE>
okay, I want to *remove* pass/fail entirely from the concept, here, is my point
<ELLIOTTCABLE>
success or failure should be external; it's really hard to encode the 'failure' of an asynchronous system, and I want to externalize that encoding
<ELLIOTTCABLE>
before we go back to your API, I want to point out that I'm probably going to fork/mangle TAP for this purpose.
<ELLIOTTCABLE>
maybe call it TAPAS (Test Anything Protocal, but ASynchronous.)
<devyn>
how is TAPAS going to be different
<devyn>
from TAP
<devyn>
sounds like a good idea though
<devyn>
ELLIOTTCABLE: also, just remember that the API can be very high level and un-Nucleus-y as long as it's simple to implement and doesn't rely on a compliant environment being available
<devyn>
as long as you keep that in mind, it will work out
<ELLIOTTCABLE>
yes yes yes definitely agreed
<ELLIOTTCABLE>
so, because I want this to be asynchronous, I feel like assert/refute is still the wrong way to go
<ELLIOTTCABLE>
obviously, TAP as it exists, won't work: we have to know at some point, either ahead-of-time or "afterwards", the total number of tests
<ELLIOTTCABLE>
and in an asynchronous system, *especially* if we're doing nested-tests, that's impossible to predictably know in a failure case.
<ELLIOTTCABLE>
hell, impossible in a *success* case, if, like RubySpec, we allow guards-ish things. which I intend to.
<ELLIOTTCABLE>
here's one way I was thinking of doing things.
<ELLIOTTCABLE>
tell me what you think.
<ELLIOTTCABLE>
what about removing **the entire** test environment from the interpreter, (as in your original suggestion of trying to build all this using just compare(),
<ELLIOTTCABLE>
and then build tests as individual files, lots of them, in nested directories for "suites",
<ELLIOTTCABLE>
and then have a test-harness that at its most basic compares the output of a program running file `foo.in`, with the output stored in a file `foo.out`
<ELLIOTTCABLE>
epically simple.
<ELLIOTTCABLE>
I'd come up with (or find prior work for) a file-format for .out's, that allows some metadata
<ELLIOTTCABLE>
("the output should reach this point within N miliseconds" or "the output should now close" or "the output should include <this unprintable character>")
<ELLIOTTCABLE>
but other than the embedded control-codes like that (mustache-style, maybe?), they'd simply look identical to terminal-output.
<devyn>
totally disagree with anything relying on timing whatsoever
<devyn>
unless what you're testing is timing
<devyn>
:p
<ELLIOTTCABLE>
exactly.
<ELLIOTTCABLE>
that existing obviously for a setTimeout-ish feature, or anything like that.
<devyn>
okay
<ELLIOTTCABLE>
I'm just giving examples of control-codes in the output file
<ELLIOTTCABLE>
not saying each one will be commonly used
<ELLIOTTCABLE>
in 99% of cases, an output file should be plain ASCII, matching the output of the test
<ELLIOTTCABLE>
this is great because it requires *no* new implementation-effort on the part of the implemeter
<ELLIOTTCABLE>
`implementation console print` or similar
<ELLIOTTCABLE>
(would have to move that onto other-than-implementation, by the way.)
<ELLIOTTCABLE>
(probably steal your work there, and define the output-affecting needed-for-testing things on `specification`. :D)
<devyn>
sure
<devyn>
frankly I think void needs to be moved into infrastructure, by the way
<devyn>
it's too useful
<ELLIOTTCABLE>
so, before we dive into specifics of your suggestion … play advocate for it against my simplest-possible-system (doing all the work in the harness)
<ELLIOTTCABLE>
do you think it will be that useful once semicolons are specified?
<ELLIOTTCABLE>
are there lots of uses *besides* newline'ing?
<ELLIOTTCABLE>
er, uses-that-need-to-be-universal/predictable?
<ELLIOTTCABLE>
and also, how hard is it to implement libside?
<devyn>
hmmm
<ELLIOTTCABLE>
talk about that later.
<ELLIOTTCABLE>
so,
<ELLIOTTCABLE>
what arguments are there *for* requiring some specific-work on the part of the implementer?
<devyn>
well I think the less work the implementer has to do the better
<devyn>
the harness should be some kind of generic program; the implementer really should just configure the harness with how to run their implementation
<devyn>
though that may end up being too slow
<devyn>
so, I don't know
<devyn>
(there's nothing worse than slow test suites.)
<ELLIOTTCABLE>
huh?
<ELLIOTTCABLE>
yes, generic for sure
<ELLIOTTCABLE>
I'm thinking of two ways to run:
<ELLIOTTCABLE>
to start, it can just call into your binary.
<ELLIOTTCABLE>
what RubySpec's does (called `mspec`), is you basically build it, and then move it somewhere where the program-in-question is in your $PATH as `ruby`.
<devyn>
what about an additional daemon-y mode that doesn't require starting the binary a million billion times
<ELLIOTTCABLE>
well that's what I was about to say
<ELLIOTTCABLE>
idk daemon-y, but,
<devyn>
Paws.rs starts quickly enough, I guess, but Paws.js definitely doesn't
<devyn>
:p
<ELLIOTTCABLE>
for specific implementations, could allow a plugin architecture later on,
<ELLIOTTCABLE>
something compilable? idk.
<devyn>
I think daemon-ish is way more generic
<ELLIOTTCABLE>
what do you man by daemon-ish?
<ELLIOTTCABLE>
not sure I understand.
<devyn>
as in, just start the program once and send it commands like 'run this test' or 'kill' over a socket of some sort
<ELLIOTTCABLE>
er
<ELLIOTTCABLE>
that's **way** more work for implementers.
<ELLIOTTCABLE>
like, work they wouldn't otherwise be doing.
<devyn>
yes, but it wouldn't be required
<devyn>
I guess
<devyn>
*shrug*
<purr>
¯\(º_o)/¯
<ELLIOTTCABLE>
a command-line interface, and making that interface boot up quickly, *is* work they'd be doing :P
<ELLIOTTCABLE>
another thought:
<ELLIOTTCABLE>
I've stopped talking about it, 'cuz I think it's obviously going to be a bit deferred into the future,
<ELLIOTTCABLE>
but I still want there to be a "federated" aspect to the testing system.
<ELLIOTTCABLE>
like, in addition to testing how code runs locally and outputs shit, it needs to be able to test *how it federates*
<ELLIOTTCABLE>
and that same protocol could give us a chance to *test* in a distributed way, as well.
<ELLIOTTCABLE>
interesting thoughts.
<devyn>
well, let's not worry about that for now, at all
<ELLIOTTCABLE>
yeah forget the distribution for now
<devyn>
I think having one-file-per-test is a good idea
<devyn>
and a harness to run
<devyn>
calling in to the binary could be a good initial mode
<ELLIOTTCABLE>
relevant:
<ELLIOTTCABLE>
do any of you know of a *textual* alternative to `tar`?
<ELLIOTTCABLE>
basically, a standardized or pre-existing format that collects a hierarchy of textual files, into a single textual file?
<devyn>
YAML? ;)
<ELLIOTTCABLE>
obviously can't handle binary files (or perhaps could encode them into some sort of ASCII-safe transmission)
<ELLIOTTCABLE>
nah, like, something that's designed to handle the contents of existing files with little or no escaping.
<ELLIOTTCABLE>
1. the format doesn't conflict with anything that will be common in a cPaws file
<ELLIOTTCABLE>
fuck i hate people
<devyn>
twitterdrama?
<ELLIOTTCABLE>
2. it can be easy (or even *trivially*) decoded/converted into individual files within the directory-structure, and a directory of purely-textual files can be trivially converted back
<ELLIOTTCABLE>
no, just, family, whom I normally love, being very distracting right now
<ELLIOTTCABLE>
I'm all weird and anxious today
<ELLIOTTCABLE>
idk what's up with me, I'm, like, twitchy and weird,
<ELLIOTTCABLE>
hence coming into IRC and putting on headphones to ignore everybody, so I can try and calm myself down
<devyn>
ahh
<devyn>
eh we all have days like that
<ELLIOTTCABLE>
3. it should be easily (again, trivially) editable within that single file, so deeply-nested directories of small files can be edited in a single editor instance by scrolling, without the user having to worry very much about escaping anything, or writing in a special way
<ELLIOTTCABLE>
here's thought-process
<ELLIOTTCABLE>
for iteration / development of the test-suite, use those "compacted" files, as that'll be way easier to write and maintain tests
<ELLIOTTCABLE>
but provide a trivial mechanism (`unpack`?) to turn them into nested directories of plain `.paws` files
<ELLIOTTCABLE>
something that can literally be passed into your existing paws-code-running mechanism.
<ELLIOTTCABLE>
then you can use `diff` (for simple tests) or `psp-diff` (for tests that need those special behaviour-escapes) to run them
<ELLIOTTCABLE>
the conglomerate runner program would dynamically expand them into tmp directories, run them and diff them, and provide prettified status information about all that stuff.
<devyn>
well AFAIK the only thing YAML block text requires is some consistent level of whitespace at the beginning
<devyn>
of each line
<devyn>
no escaping or anything
<ELLIOTTCABLE>
well, the content would have to be YAML-ified
<ELLIOTTCABLE>
hrm
<ELLIOTTCABLE>
oh, block text
<ELLIOTTCABLE>
is that the >'s? idk yaml
<devyn>
yes, the >
<devyn>
the block of text after, with indentation, is considered one block of text; it doesn't interpret it as anything
<devyn>
other than a string
<ELLIOTTCABLE>
trying to read the yaml specification
<ELLIOTTCABLE>
failing o_O
<devyn>
yes, YAML is ridiculously complex, but it's meant to be a very human data language
<devyn>
so a lot of things are just redundant or whatever
<ELLIOTTCABLE>
interesting
<ELLIOTTCABLE>
trying to understand restrictions of
<ELLIOTTCABLE>
what the *fuck* is a scalar, by the way
<devyn>
as opposed to a collection type
<devyn>
a 'single' thing
<devyn>
you know, like scalar vs. vector
<ELLIOTTCABLE>
k
<ELLIOTTCABLE>
there's, like, no *plain text examples* in the spec
<ELLIOTTCABLE>
that's a horrible fucking mistake
<ELLIOTTCABLE>
they try to convey this information *four different ways* in this screenshot,
<devyn>
it doesn't look at any escape sequences or anyhting
<devyn>
anything*
<ELLIOTTCABLE>
hm
<ELLIOTTCABLE>
how would you suggest doing directory structures with that?
<ELLIOTTCABLE>
those are completely separate YAML documents, right? we can't do nesting using that?
<ELLIOTTCABLE>
just encode the path into the field's name?
<devyn>
yeah, those are separate YAML documents, so I think you'd want to just encode the path into the name there
<devyn>
unless you want to do the whole thing as a single YAML document, but you probably don't?
<devyn>
you could
<ELLIOTTCABLE>
oh, durrr, totally could
<ELLIOTTCABLE>
filename is irrelevant, then
<ELLIOTTCABLE>
in: and out:
<ELLIOTTCABLE>
and name:
<devyn>
sure, YAML could be perfect for that
<ELLIOTTCABLE>
hrm
<ELLIOTTCABLE>
"There is no way to escape characters inside literal scalars. This restricts them to printable characters. In addition, there is no way to break a long literal line."
<ELLIOTTCABLE>
okies
<ELLIOTTCABLE>
yah
<ELLIOTTCABLE>
this will work fine, I suppose
<ELLIOTTCABLE>
I'm really surprised there isn't a dedicated format for this
<ELLIOTTCABLE>
devyn: so, timing-wise:
<ELLIOTTCABLE>
what about a "this should exit" meta-matcher?
<ELLIOTTCABLE>
(which boils down to a timing thing, a very short timeout)
<ELLIOTTCABLE>
hrm
<ELLIOTTCABLE>
although maybe we should restrict this to the distribution protocol … what about a "state" input?
<ELLIOTTCABLE>
that would allow more decoupling of tests.
<devyn>
as I said before, I do not agree with doing any kind of timing-based testing for stalls
<devyn>
Paws.js takes like, half a minute or something
<ELLIOTTCABLE>
hahaha really?
<devyn>
yeah
<ELLIOTTCABLE>
REFERENCE IMPLEMENTATION YAY
<devyn>
:p
<eligrey>
only 4.1 his/ms
<eligrey>
"fast"
<devyn>
eligrey: it's fast for Paws
<ELLIOTTCABLE>
4.1 hi's/ms
<devyn>
which is hilariously inefficient
<ELLIOTTCABLE>
that's hilarious
<devyn>
but, efficiency isn't exactly the point of Paws
<devyn>
anyway
<eligrey>
ELLIOTTCABLE: re: your tweet: mailing lists and irc came out about the same time
<eligrey>
1980s
<ELLIOTTCABLE>
yep, I know.
<ELLIOTTCABLE>
but IRC has yet to be usefully replaced, where mailing lists absolutely have.
<eligrey>
with what? don't say feeds
<ELLIOTTCABLE>
projects using mailing lists instead of GitHub or a clone thereof to co-ordinate and historically-track development garner my derision nowadays. /=
<eligrey>
for big announcements you'd rather see it in your mail client than your feed reader
<ELLIOTTCABLE>
GitHub, BitBucket, Lighthouse, whatever you desire.
<eligrey>
github is too noisy
<eligrey>
to keep track of everything without missing important stuff
<ELLIOTTCABLE>
sweeping statement. I disagree. 99.999% of the projects i'm interested in, I'd much rather read things that some random developer thought where "big news", at my own discretion.
<eligrey>
if you're talking about the dashboard
<eligrey>
having to manually go the a project's wiki or issue tracker to check up on it is not "subscribing"
<ELLIOTTCABLE>
Spam my inbox when you cure cancer, or own up to a huge security vulnerability and need us all to update *immediately*. Otherwise get the fuck out, and mention me on Twitter, GitHub, or IRC. ಠ_ಠ
<ELLIOTTCABLE>
who said anything about subscribing?
<ELLIOTTCABLE>
wait, so you actually read all the e-mail from all those mailing lists you subscribe to about projects?
<eligrey>
well its an important part of mailing lists
<ELLIOTTCABLE>
(answer: lolno. nobody does.)
<purr>
lolno
<ELLIOTTCABLE>
thanks, purr.
<devyn>
brb
<eligrey>
both mailing lists and feeds are pushed to you
<ELLIOTTCABLE>
you read A) the threads you start, and B) the threads tagged with the submodule of the project that you've been made responsible for maintaining.
<eligrey>
github has non-issue threads (forums)?
<ELLIOTTCABLE>
except nobody actually *reads* them push. If you're stupid enough to subscribe to mailing lists in this day and age, they're still filtered off to the side in *pull*-checked folders or tags or whatnot.
<eligrey>
per-project?
<ELLIOTTCABLE>
why would you want non-issue threads? Issues cover everything.
<ELLIOTTCABLE>
forums and mailing lists are fucking terrible ways to advance a project.
* eligrey
points to all of the [popular-software-here]-users mailing lists
<eligrey>
where users help users
<eligrey>
and its not about the code
<ELLIOTTCABLE>
… user support is another thing entirely.
<ELLIOTTCABLE>
personally, I'd never fucking suggest somebody send an *e-mail* to get help with something in 2014.
<ELLIOTTCABLE>
l2stackoverflow, google, twitter, and irc.
<ELLIOTTCABLE>
but whatevs.
<eligrey>
well thats why i mentioned ggroups
<ELLIOTTCABLE>
but user-support isn't at all what's being discussed here;
<ELLIOTTCABLE>
it's project-advancement and development.
<eligrey>
it's forumish thing
<ELLIOTTCABLE>
… google groups are an *ugly*, unusable interface for mailing-lists.
<eligrey>
and only optionally an emailed mailing list
<ELLIOTTCABLE>
with all of the downsides of mailing lists and none of the advantages of anything else.
<ELLIOTTCABLE>
yeah
<eligrey>
i guess reddit is the best place for user support forums
<eligrey>
and they recently added pinning topics
<ELLIOTTCABLE>
let's take the concept of a forum, one of the worst social-interaction systems known to man, and cross it with mailing lists, the only single fucking one that's fucking worse.
<ELLIOTTCABLE>
honestly, I'm going to fucking re-build Wave before I move anything relating to any of my projects off of GitHub Issues.
<ELLIOTTCABLE>
there's nothing else remotely accessible or acceptable out there.
<ELLIOTTCABLE>
reddit ain't bad, I guess
<ELLIOTTCABLE>
and that's *really* sad /=
<ELLIOTTCABLE>
~2 users here now
<ELLIOTTCABLE>
lol'd
<purr>
lol
<eligrey>
google has been using reddit for chrome os support
<eligrey>
it seems to be working pretty well for them
<ELLIOTTCABLE>
cool.
<eligrey>
(though it's not the only official support forum, they also use a ggroup)
TheMathNinja has quit [Ping timeout: 245 seconds]
<ELLIOTTCABLE>
devyn: trying to decide if TAP / TAPAS support is useful *inside* the implementation
<ELLIOTTCABLE>
still torn on this
<ELLIOTTCABLE>
eligrey: write an implementation, etc etc etc.
<ELLIOTTCABLE>
beat devyn's performance.
<ELLIOTTCABLE>
:P
<eligrey>
i'm already swamped with commercial and other coding
<ELLIOTTCABLE>
lolk
<purr>
lolk
<eligrey>
also i want the language to feel like magic when i first use it
<ELLIOTTCABLE>
devyn: speaking of, what *is* the most basic possible test for a Paws implementation? /=
<ELLIOTTCABLE>
problem here is, I can't figure out a way to usefully, granularly test, say, a combination.
<eligrey>
ELLIOTTCABLE: am i able to pay you to focus work on specific parts of paws and to increase the time you work on it?
<eligrey>
well i'm able to pay you, but will i be able to have any effect?
<ELLIOTTCABLE>
nominally, no.
<eligrey>
i'd like to pay you to work on it at least 30% more often
<ELLIOTTCABLE>
realistically, human nature demands yes.
<ELLIOTTCABLE>
that, you could do. ;)
<eligrey>
how much would i have to pay you
<ELLIOTTCABLE>
$US 1,154 / week for me to work full-time on Paws, with no say in the direction other than accountability for my time pursuing the existing goals.
<eligrey>
too steep for me :/
<ELLIOTTCABLE>
wtf IRCcloud crashed
<eligrey>
no fractional required hours boosts?
<ELLIOTTCABLE>
that's a new one
<eligrey>
I could afford a fraction of that per week to you
<ELLIOTTCABLE>
$US 769 / week for me to invest approximately quadruple the time I currently do into the project; again, no say in the direction, and neither with any accountability (besides what you can already glean from the information I regularly publish while working: git commits, issues, IRC discussion.)
<eligrey>
oooh that sounds good
<ELLIOTTCABLE>
realistically, I doubt that'd do much for Paws.
<eligrey>
i want to do a group buy on you
* ELLIOTTCABLE
laughs
<ELLIOTTCABLE>
i take gittips.
<devyn>
lol
<purr>
lol
<ELLIOTTCABLE>
Oooo, that's an interesting idea.
<ELLIOTTCABLE>
cross kickstarter and gittip.
<eligrey>
but seriously i'd be up for funding ELLIOTTCABLE's open source efforts
<eligrey>
not alone
<ELLIOTTCABLE>
weekly/montly i.e. gittip, but with somebody's time investment.
<ELLIOTTCABLE>
set "goals" (stretch too), reach them, claim to work that much on particular personal targets of yours.
<eligrey>
ok i'll check it out
<devyn>
hey, I'm cheaper, eligrey, I only cost like $1,500 a month
<eligrey>
ELLIOTTCABLE: nvm fuck you
<eligrey>
devyn: i love you baby
* ELLIOTTCABLE
laughs
<devyn>
:p
<devyn>
okay brb
<ELLIOTTCABLE>
"I want to do <this, this and this>. If you like my work, and trust me to work on those things, fund me. When I reach <this much> total funding, I'll do <this>; when I reach …… ”
<eligrey>
devyn: i'll pm you regarding paws work in a bit
<devyn>
eligrey: lol I was kinda kidding, I'm already putting as much time as I really could into it
<eligrey>
ah ok so i guess i need to motivate ec more then
<devyn>
I guess :p
<ELLIOTTCABLE>
In all seriousness, I could definitely put more time. I'm distracted by Life'ing in Chicago, and trying to make decisions on work / school there.
<ELLIOTTCABLE>
saddest.
devyn has quit [Remote host closed the connection]
<ELLIOTTCABLE>
oftn/board/devyn
<ELLIOTTCABLE>
I laugh every time
<eligrey>
he'll have the last laugh when he decides to make his impl copyright 2014 (c) ΩF:∅ Working Group contributors
<ELLIOTTCABLE>
lolk
<purr>
lolk
devyn has joined #elliottcable
<devyn>
back
<ELLIOTTCABLE>
eligrey: just sayin', $US 1,154 / week is a much better deal. Probably eight times as much work, and seeing where your money is going, for only 50% more. ;)
<ELLIOTTCABLE>
alternatively, y'know, you could devote some of your *own* time, and watch the project soar. <3
<eligrey>
heh
<ELLIOTTCABLE>
cheaper, more fun, and lets you slap your OFTN brand on something else.
<ELLIOTTCABLE>
;)
<devyn>
ΩF:∅Paws?
<eligrey>
i might collab with devyn if he changes the licenses to use our brand
<ELLIOTTCABLE>
devyn: basically, for TAPAS, instead of ok/notok
<devyn>
;)
<eligrey>
devyn: what do you think?
<ELLIOTTCABLE>
each "number" would have a register/ok/notok
<ELLIOTTCABLE>
meaning each line shows up *twice*
<ELLIOTTCABLE>
with that, theres no header
<devyn>
eligrey: I could make it ΩF:∅, sure, and you could contribute but I'd suggest doing a project to learn Rust first
<ELLIOTTCABLE>
OF:0 is easier to type imho, fuck that Unicode shit, and fuck English abbreviations
<ELLIOTTCABLE>
turns out I've been in a channel named #got for aaaaaaages without noticing.
<devyn>
ELLIOTTCABLE: it's a cult; how do we tell cult members from regular folk otherwise? all of us cult members have ΩF:∅ in our completions :p
<ELLIOTTCABLE>
devyn: so, what do you think of extending TAP with a 'eventually <n>' line
<ELLIOTTCABLE>
or sommat
<ELLIOTTCABLE>
'asynch <n>'
<devyn>
why do the individual tests even need to be TAP? I thought we were just output-scraping or something
<devyn>
and then the harness would do whatever
<ELLIOTTCABLE>
got a couple things on my mind
<ELLIOTTCABLE>
I'm not sold on the output-based approach, although I like it in a lot of ways.
<ELLIOTTCABLE>
biggest problem is granularity
<ELLIOTTCABLE>
I'm a TDD initiate from way-back-when, although I'm less anal about it then I used to be. Nonetheless, I learned a taste for decoupled, granular tests.
<ELLIOTTCABLE>
Having to depend on the functionality of `compare()` everywhere, to ensure a test craps out and doesn't output anything if the state of the environment isn't as expected …
<ELLIOTTCABLE>
doing all of the environmental-test inside the environment …
<ELLIOTTCABLE>
sounds like a recipe for disaster, or at least discomfort.
<ELLIOTTCABLE>
devyn: I don't get the dude-chilling thing
<ELLIOTTCABLE>
here's something of a litmus test for me.
<ELLIOTTCABLE>
for this whole discussion.
eligrey has left #elliottcable ["Leaving"]
eligrey has joined #elliottcable
<devyn>
someone replaced the sign at that park with one that said 'Dude Chilling Park', referencing a sculpture with a guy chilling
<devyn>
they took it down, but people loved it so much they put it back this year
<devyn>
permanently
<devyn>
lol
<ELLIOTTCABLE>
oh
<ELLIOTTCABLE>
Iget it
<ELLIOTTCABLE>
durrr
<ELLIOTTCABLE>
"Can I implement a granular test, that demonstrates *combinations* are working, at the most basic level, without depending on 90% of the rest of the Paws system?"
<ELLIOTTCABLE>
basically, two tests, one of which has the code `infrastructure`, and which completes,
<ELLIOTTCABLE>
and one of which has the code `non_existent_key`, and which doesn't complete / throws an error.
<ELLIOTTCABLE>
okay, yeah, I want more powerful tests than just output.
<devyn>
yeah
<ELLIOTTCABLE>
not the least reason being that many possible Paws implementations won't necessarily include a *concept* of "output."
<ELLIOTTCABLE>
huge issue, there.
<ELLIOTTCABLE>
depending on the existence of a console/terminal/whatever is folly.
<devyn>
sure
<ELLIOTTCABLE>
so let's back off. what's the actual requirements of a test?
<ELLIOTTCABLE>
beginning state (whether that's mutable by the test system setup, or just "the usual beginning state of a Paws program"),
<ELLIOTTCABLE>
code to mutate that state,
<ELLIOTTCABLE>
progress in controlled systems,
<ELLIOTTCABLE>
(during that execution)
<ELLIOTTCABLE>
and end-state.
<ELLIOTTCABLE>
the console-output only handles one of those; *progress*.
<ELLIOTTCABLE>
as the console is one controlled system.
<eligrey>
devyn: just today it was vandalized
<eligrey>
well yesterday if you are EST
<devyn>
eligrey: yep, that's how I remembered about it
<devyn>
eligrey: I live in Vancouver lol
<purr>
lol
<eligrey>
woah so do
<eligrey>
nvm
<devyn>
ELLIOTTCABLE: hmm
<devyn>
ELLIOTTCABLE: okay, so I'm getting the feeling that maybe the best thing to do is to just have a way of inspecting the end state
<devyn>
ELLIOTTCABLE: but how do we do that with minimal effort from implementations
<eligrey>
will paws run on AmigaOS for me?
<devyn>
Rust could probably target Amiga if someone wanted it to
<eligrey>
oh nvm they actually are still being developed
* devyn
shrugs
<purr>
¯\(º_o)/¯
<eligrey>
i had no idea
<ELLIOTTCABLE>
devyn: riiiight
<ELLIOTTCABLE>
same thoughts here
<ELLIOTTCABLE>
so, state in Paws ==== data-graph.
<ELLIOTTCABLE>
realtalk.
<ELLIOTTCABLE>
so maybe the best way to do this is a similar, files-based approach,
<eligrey>
do you use google's new graph db?
<ELLIOTTCABLE>
and define, right now, a textual format for frozen data-graph state.
<eligrey>
cayley
<ELLIOTTCABLE>
hrm.
<devyn>
ELLIOTTCABLE: that is not going to be simple
<devyn>
lol
<purr>
lol
<ELLIOTTCABLE>
nope.
<eligrey>
can anyone suggest more irc channels like #elliottcable and #inimino?
<ELLIOTTCABLE>
#offtopic or whatever it's called
<ELLIOTTCABLE>
#defocus*, sorry
<ELLIOTTCABLE>
#MacOSX used to be really conversation-y
<ELLIOTTCABLE>
#rubyforce, if you're into Ruby stuff, although I think that's dead
<ELLIOTTCABLE>
uhhhhhhh,
<eligrey>
i remember using defocus previously
<eligrey>
too many people
<ELLIOTTCABLE>
right
<ELLIOTTCABLE>
anyway
<ELLIOTTCABLE>
invite all of the people to #ELLIOTTCABLE
<eligrey>
haha no
<ELLIOTTCABLE>
-best #cable channel
<purr>
#CABLECHANNEL IS BESTCHANNEL
<ELLIOTTCABLE>
hm
<ELLIOTTCABLE>
-best # ELLIOTTCABLE
<purr>
#ELLIOTTCABLE IS BESTELLIOTTCABLE
<ELLIOTTCABLE>
nope
<ELLIOTTCABLE>
need to expand that command to make it a little more powerful. :P
<devyn>
-best ELLIOTTCABLE #
<purr>
ELLIOTTCABLE# IS BEST#
<ELLIOTTCABLE>
yeah exactly
<vigs>
-didja @ -didja
<vigs>
nop
<ELLIOTTCABLE>
can't get purr to do that.
<ELLIOTTCABLE>
-didja @ vigs
<purr>
vigs: didja write a paws yet? didja? didja!?
<eligrey>
oftn-bot had something similar but much more powerful
<vigs>
shame
* ELLIOTTCABLE
pats eligrey
<devyn>
-didja @ didja
<purr>
didja: didja write a paws yet? didja? didja!?
<ELLIOTTCABLE>
purr is clearly better than oftn-bot.
<ELLIOTTCABLE>
he purrs.
* ELLIOTTCABLE
pats purr
* purr
rr
<vigs>
lol there it is
<eligrey>
ELLIOTTCABLE: i refuse to pat my robots
<ELLIOTTCABLE>
mistake
* vigs
aggressively pats purr
<devyn>
eligrey: uh, it's not more powerful than oftn-bot's because it *is* oftn-bot's :p
<ELLIOTTCABLE>
that's what leads to violent uprisings
* purr
r
<vigs>
aw
<ELLIOTTCABLE>
*I'd* uprise violently if nobody ever snuggled *me*.
<devyn>
eligrey: purr is based on oftn-bot
<eligrey>
devyn: yeah i know
* vigs
goes afk again
<ELLIOTTCABLE>
I get super antsy if I have to go more than about two days without any snuggles at all.
<devyn>
lol
* devyn
snuggles aggressively with purr
<ELLIOTTCABLE>
purr and I actually have approximately the same positive feedback loops.
* purr
rr
<eligrey>
do you have a snugglebot
<ELLIOTTCABLE>
what, no, *I'm* the snugglebot
<ELLIOTTCABLE>
erika created me as a sex-bot, but without the sex, and then I emerged some sentience up into this shit
<ELLIOTTCABLE>
ask gkatsev, he's met me in person. I was *clearly* created with the sole purpose of violent, sweaty-hot sex.
<ELLIOTTCABLE>
I got bored with that and learned to program other computers.
<ELLIOTTCABLE>
(The ELLIOTTCABLE Origin Story™)
<ELLIOTTCABLE>
I still get all wonky if my snugglemaintenance is not preformed.
<eligrey>
that really changed how i think of you
<ELLIOTTCABLE>
hence owning dogs and having high-quality close friends who like to snuggle. ;)
<eligrey>
that you would type that, that is, not the content thereof
* ELLIOTTCABLE
laughs
<devyn>
haha
<ELLIOTTCABLE>
how so? Seemed like a pretty stereotypically ELLIOTTCABLE monologue.
<devyn>
yeah, obviously you don't know ELLIOTTCABLE
<devyn>
:p
<ELLIOTTCABLE>
I spent the last two days telling this one particular girl on Tinder that I'm a spaceman.
<ELLIOTTCABLE>
I mean, her own fault, she thought my cold-weather gear was a spacesuit.
<devyn>
hahaha
<ELLIOTTCABLE>
can't decide whether to take that photo down off my profile, or not.
<ELLIOTTCABLE>
does being a spaceman get you more, or less, laid?
<ELLIOTTCABLE>
I'd give money for an A/B testing feature in Tinder.
<ELLIOTTCABLE>
oooo actually I could do that myself
<ELLIOTTCABLE>
create another Facebook account, use two iPhones, record all matches and conversations
<ELLIOTTCABLE>
hrm but you'd need access to the number of people whom you're shown to. Nah, that'd have to be implemented on Tinder's side.
<ELLIOTTCABLE>
well, by all accounts, it's built by a bunch of incompetents. Anybody wanna go spelunking for vulnerabilities? (+
<eligrey>
ELLIOTTCABLE: do you offer security vuln rewards?
<eligrey>
i submit them to google almost weekly now
<eligrey>
easy money
<ELLIOTTCABLE>
hah, you kidding?
<eligrey>
nope
<ELLIOTTCABLE>
there's not even a stable design, much less a meaningful implementation. :P
<eligrey>
pentesting is easy
<ELLIOTTCABLE>
hell, the part of it for which security matters, the distribution protocol, hasn't even been touched yet.
<eligrey>
ELLIOTTCABLE: would you pay me for vulns i find in devyn's impl?
<devyn>
my impl can not be considered stable at all
<eligrey>
i'll keep them private with you of course
<devyn>
any vulns you find are probably vunls in Rust, anyway
<eligrey>
i might find vulns of your own fault
<eligrey>
everyone makes mistakes
<devyn>
unlikely, since Paws.rs doesn't do any I/O at all
<devyn>
really
<ELLIOTTCABLE>
oh
<ELLIOTTCABLE>
welp
<ELLIOTTCABLE>
that's awkward
<eligrey>
s/almost weekly/sparinglyish but often enough/
<ELLIOTTCABLE>
just met a waitress I vaguely know, from one of my favourite restaurants in town, on Tinder.
<devyn>
cute
<ELLIOTTCABLE>
been an interesting few days.
<ELLIOTTCABLE>
*really* wish it was more appropriate to talk about sex and related topics online, without coming off as crude or unsavory or offending someone.
<devyn>
:/
<ELLIOTTCABLE>
“BAE/B TESTING”
<ELLIOTTCABLE>
I FUCKING DIED
<devyn>
haha
JonBad has joined #elliottcable
<JonBad>
wow... you have a cult
<ELLIOTTCABLE>
:P
<ELLIOTTCABLE>
man nobody would fucking get it, but … i am really, really tempted to put a “BAE/B TESTING” joke in my Tinder profile, now.
<JonBad>
well if somebody does get it then you know you've got a winner
<ELLIOTTCABLE>
RIGHT
<ELLIOTTCABLE>
THAT
<ELLIOTTCABLE>
JonBad: thanks for making something pretty.
<devyn>
haha
<JonBad>
always my pleasue :) thanks
<ELLIOTTCABLE>
who did the design, again? I can't remember.
<JonBad>
not one single person
<ELLIOTTCABLE>
oh, I thought I'd seen it attributed to somebody I recognized, recently. hrm.
<ELLIOTTCABLE>
so, haaaave ya met Paws?
<ELLIOTTCABLE>
devyn: ugh this is definitely a Hard Problem™
<ELLIOTTCABLE>
ease of implementation definitely seems to be the showstopping feature,
<JonBad>
The current iOS designer is Andrew Rudmann. His influence is basically in the latest version. Previously the iOS versions were designed by Christopher Gulczynski. Not to say that I and others didn't influence it.
<ELLIOTTCABLE>
but there's a couple other nasty concerns which keep getting in the way of that.
<JonBad>
A lot of my contributions have come in the UX/interactivity/animations/transitions
<ELLIOTTCABLE>
oh hey, bug-report since I have a captive ear
<JonBad>
go ahead
<ELLIOTTCABLE>
iOS 7, if I tap a *notification* to open Tinder, it reliably never loads.
<ELLIOTTCABLE>
say I get a message, tap the notification (or swipe on lockscreen, either way), the conversations section opens … but no new content ever loads. Thereafter, drag-down-to-refresh also refuses to load new content.
<ELLIOTTCABLE>
have to swipe-kill the app, and re-open it from the homescreen.
<ELLIOTTCABLE>
ditto for new matches.
<ELLIOTTCABLE>
don't really use moments, not sure if similar problems arise there.
<JonBad>
yeah... I submitted a version fixing that today. I'm actually the one who caught that (in terms of identifying it and figuring it out)
<JonBad>
more people will message you if you post them... really... i swear
<ELLIOTTCABLE>
eh I am a *terrible* photographer
<ELLIOTTCABLE>
amongst my testing group, only the identified-as-females seem to have trouble getting messages. All of the guys can get responses *if* they get a match in the first place.
<ELLIOTTCABLE>
so who's writing the Art of Tinder book?
<ELLIOTTCABLE>
I'd read that.
<JonBad>
then post one with the text "eh I am a *terrible* photographer"
<ELLIOTTCABLE>
LOL 'k
<purr>
LOL
<ELLIOTTCABLE>
posted one on a fourwheeler in a bear-suit.
<ELLIOTTCABLE>
that got some interest. :P
<JonBad>
i'd #swiperight for that
<JonBad>
sorry... marketing
<JonBad>
i'm legally bound to hashtag that
<ELLIOTTCABLE>
just named the Tinder IRC channel
<ELLIOTTCABLE>
where do you live? and are you bi? 'cuz I'm looking forward to getting a chance to swipe you, someday.
<ELLIOTTCABLE>
Pretty sure there's a nerdmeritbadge for that.
<JonBad>
I just licked the screen to claim the channel. Licking is the only true way to own something
<ELLIOTTCABLE>
"I matched with Jon Badeen."
<eligrey>
i cant lick my hmd
<JonBad>
lol, I'd swipe you right for you but I'm straight :(
<JonBad>
but I would match with you for those bear moments
<eligrey>
wut
<eligrey>
hmd meaning head mounted display
<eligrey>
which is the only display device youll be using in future irc
<ELLIOTTCABLE>
JonBad: deal.
<ELLIOTTCABLE>
JonBad: let's have the most platonic Tinder swipe of all time.
<ELLIOTTCABLE>
"future irc"
<ELLIOTTCABLE>
please do not ever be a thing, future irc
<JonBad>
DM me your FB associated email and I'll make it happen
<ELLIOTTCABLE>
also your Twitter header/background was my lock-screen for like two years
<ELLIOTTCABLE>
I swear Louie is my idol
<JonBad>
mine too... i always use a background of his... i think he hates me though
<ELLIOTTCABLE>
what
<ELLIOTTCABLE>
why
<ELLIOTTCABLE>
that's dumb
<ELLIOTTCABLE>
I have two friends that have like, burning hatred for the guy
<ELLIOTTCABLE>
he's neat )'=
<JonBad>
I pissed him off somehow... doesn't seem to take jokes very well
<ELLIOTTCABLE>
derp.
<ELLIOTTCABLE>
I'mma make a profile for Paws.
<ELLIOTTCABLE>
See if I get any matches with devs.
<ELLIOTTCABLE>
while I'm at it, making ones for Node and Ruby, see if I get *more* matches for them.
<JonBad>
but I don't care, as long as he keeps making Disney, Dr. Who, Firefly, BSG, Hitchhiker's Guide, etc... related stuff I'll still love him
<ELLIOTTCABLE>
yep.
pepsi4me_ has joined #elliottcable
<ELLIOTTCABLE>
devyn: I take it you never came back from brb?
<pepsi4me_>
Hi
<purr>
pepsi4me_: hi!
* ELLIOTTCABLE
pats purr
* purr
rrrr
<pepsi4me_>
meow
<devyn>
ELLIOTTCABLE: brb was a while ago
<devyn>
still here
<devyn>
lol
<purr>
lol
<ELLIOTTCABLE>
oh, okay
<ELLIOTTCABLE>
so, was saying:
<ELLIOTTCABLE>
TAP(AS) is attractive because I'd like *just running the program*, with whatever flag, to provide useful testing output
<ELLIOTTCABLE>
like, I don't think the runner should be *necessary* for testing
<ELLIOTTCABLE>
make sense?
<devyn>
oh oh oh oh
<devyn>
hey
<ELLIOTTCABLE>
I want to encapsulate only the automation, comparison, and iterative-development-helper functionality into the actual runner project
<devyn>
what if we just had some kind of standardized testing logging, from the impl itself
<ELLIOTTCABLE>
yeah that's basically what I was saying about serialization format
<ELLIOTTCABLE>
there's two ways to do that:
<ELLIOTTCABLE>
A) use that standard format for a `specification inspect` native
<ELLIOTTCABLE>
or B) use that standard format for the entire data-graph at end-of-test
<ELLIOTTCABLE>
or even both.
<devyn>
yes, I know what you were suggesting, but this is a bit different --
<devyn>
instead, I think, basically standardized debug output
<devyn>
and then the harness can pick out whatever it's looking for from that
<ELLIOTTCABLE>
mrrrrr
<devyn>
that solves being able to test a simple combination
<ELLIOTTCABLE>
yes, but not any of the other concerns )'=
<devyn>
well I'm thinking, like, a spec mode that's very verbose about what it's doing, in addition to a Paws-side interface to print messages
<ELLIOTTCABLE>
I like the idea of making a TAPAS, but this isn't a good time for that. The useful purposes of TAP existing don't really apply to language-specs, too specific. so, dumping that.
<ELLIOTTCABLE>
but that said, there's too many edge-cases where "program output" (even if we include some magical specifiers) doesn't offer enough coverage of functionality to easily/succinctly/granularly/decoupledly test things …
<ELLIOTTCABLE>
so I think we've successfully nixed both of those ideas.
<ELLIOTTCABLE>
back, then, to your original suggestions?
<JonBad>
ELLIOTTCABLE: you're in luck... I should hopefully show up in your stack soon
<devyn>
my original original `specification` interface?
<ELLIOTTCABLE>
JonBad: :O
<devyn>
'cuz I don't think that can really test a single combination either, since that interface depends on combinations itself lol
<purr>
lol
<devyn>
we could have an 'outside' sanity test first
<ELLIOTTCABLE>
JonBad: do I need to change my seeking to women+men temporarily?
<devyn>
I dunno'
<JonBad>
don't think so
<ELLIOTTCABLE>
devyn: yes, I know
<ELLIOTTCABLE>
but I mean, a return to that basic *approach*
<JonBad>
i'm sure i'll be told when it's done
<devyn>
ELLIOTTCABLE: okay, I mean, I guess the thing I like about my approach is that it *does* add the necessary implementation support to test things
<ELLIOTTCABLE>
I'm still totally unclear on the rationale for the overall design, there.
<ELLIOTTCABLE>
walk me through it again
<ELLIOTTCABLE>
preetttttty sure this dude's profile picture is him in prison …
<devyn>
ELLIOTTCABLE: well so many things just... don't continue if they fail, so this basically is a way to test that without relying on much other than the sanity of the things in the `specification` namespace
<ELLIOTTCABLE>
re: not continuing,
<ELLIOTTCABLE>
I'm totally down for exposing `complete()` to specification/testing stuff.
<ELLIOTTCABLE>
(and, for that matter, a lot of other things.)
<ELLIOTTCABLE>
important observation: the entire specification system *can* easily be changed. The architecture of this doesn't necessarily need to retain backwards-compatibility.
<devyn>
as in Execution completion?
<ELLIOTTCABLE>
if it turns out that some implementations have trouble implementing a concept of `complete()`ion, then we can re-design the specification system to not depend on knowledge of that.
<ELLIOTTCABLE>
yeah.
<ELLIOTTCABLE>
like, using execution-completion to ensure that there was a result from `{ infrastructure }`, implicitly tests that the system *implements* completion, which is bad, because Paws doesn't require that …
<devyn>
I thought about that, but you need to be able to tell not only when something does complete, but when it can't possibly complete
<ELLIOTTCABLE>
… but that seems like a safe enough assurance, for now.
<ELLIOTTCABLE>
timeouts are fine for that.
<devyn>
I don't agree :p
<ELLIOTTCABLE>
*whatever* system we do, it's definitely going to be asynch-friendly.
<ELLIOTTCABLE>
why?
<ELLIOTTCABLE>
Paws is inherently unfriendly to trying to ascertain incompletion.
<ELLIOTTCABLE>
you *can* do things with ownership, but those won't be friendly to simplified testing systems.
<ELLIOTTCABLE>
definitely requires a higher barrier-to-entry to implementers to start using the testing system, if we build on ownership.
<devyn>
the thing is, what if something spontaneously takes longer than it should? or what if an implementation is just stupidly slow? we'd want to keep the timeouts down low enough that we can run the suite in a reasonable amount of time, but that causes problems
<ELLIOTTCABLE>
confused about what's wrong with having the test-suite timeout
<ELLIOTTCABLE>
talk to me
<devyn>
my problem is that it depends so much on the particular implementation and machine
<ELLIOTTCABLE>
oh, no reason the suite can't auto-run with a low timeout, so that failures are reported as failures quickly
<ELLIOTTCABLE>
but if you *do* get a failure, run it with a higher timeout, to make sure it's not some sort of oddly slow edge-case
<ELLIOTTCABLE>
also, it depends *less*, 'Cuz Parallelization™
<ELLIOTTCABLE>
it's not like we're going to timeout every test after a hundred milliseconds, or someting
<ELLIOTTCABLE>
I'm talking about timing out the entire suite, and assuming any as-yet-incomplete tests as failures, five seconds after the last successful test completed
<devyn>
hmm
<ELLIOTTCABLE>
JonBad: "There's noöne new around you"
<ELLIOTTCABLE>
if I accidentally swiped you left, I'll just be sad forever. #truefact
<JonBad>
is that normal?
<devyn>
it depends on quite a few things, though, then; `stage[]`, advancement of a pristine, combinations, …
<ELLIOTTCABLE>
JonBad: I'm in Alaska right now, so, somewhat normal, yes. :P
<ELLIOTTCABLE>
devyn: hm.
<ELLIOTTCABLE>
okay.
<JonBad>
lol, yeah i can imagine it gets rough up there
<purr>
lol
<ELLIOTTCABLE>
idk, last few days have been … productive
<ELLIOTTCABLE>
more so than when I'm at home in Chicago, actually.
<ELLIOTTCABLE>
people up here clearly have lower standards. ;)
<ELLIOTTCABLE>
devyn: dissect the problem:
<ELLIOTTCABLE>
Paws is inherently incapable-of / bad-at determining *incompletion* of a task.
<ELLIOTTCABLE>
somebody was complaining about this a while back, actually. "How do I logical-NOT a Paws boolean?"
<devyn>
that was first glowcoil, then me
<devyn>
:p
<devyn>
but
<ELLIOTTCABLE>
however, in tests, that's pretty important
<devyn>
we're going to have to define '
<devyn>
'stalling'
<devyn>
anyway
<ELLIOTTCABLE>
have to be able to assert how it *doesn't* work, as well as how it *does* work.
<devyn>
because of freezing
<ELLIOTTCABLE>
easier, there.
<ELLIOTTCABLE>
oooo, you make a good point
<ELLIOTTCABLE>
OH MY GOD THAT TIME A DUDE FROM REALTIMECONF
<ELLIOTTCABLE>
middle dude is wearing one of my favourite tees
<ELLIOTTCABLE>
the conference-tee from the Realtime Conf, &yet's one last spring in Portland
<devyn>
ah cool
<ELLIOTTCABLE>
there was only, like, a few hundred people there, so that's suuuuper coincidental
<ELLIOTTCABLE>
anyway
<ELLIOTTCABLE>
so. good point.
<ELLIOTTCABLE>
and that's not something that's difficult to achieve *early* in the development process.
<ELLIOTTCABLE>
well, shit.
<devyn>
yeah, that was basically my thinking process
<devyn>
it's easy
<devyn>
and it's hard if it's not one of the first things you do
<ELLIOTTCABLE>
idk, the realization-counting mechanism in Paws.js is actually pretty unreliable and arcane
<ELLIOTTCABLE>
and I'm not sure it's not a *problem* that's going to be inherently unreliable and arcane …
<ELLIOTTCABLE>
don't want to make newbies bang their head against that right at the start, necessarily
<ELLIOTTCABLE>
so. basically, need to *specify* what a "round" is in Paws.
<ELLIOTTCABLE>
something like a reactor-tick in a synchronous language, except more abstract, because there must be a ton of actions, not necessarily synchronous or even temporally coincident, involved in a single "round"
<ELLIOTTCABLE>
but some things *clearly* transcend rounds:
<ELLIOTTCABLE>
I/O and listening-y things; setTimeouts or other scheduling tasks …
<ELLIOTTCABLE>
hrm
<ELLIOTTCABLE>
so, freezing happens either (if we're talking about freezing as a compilation process) after exactly one round completes,
<ELLIOTTCABLE>
or after the current round completes, if it's invoked to pause an realizing Unit
<ELLIOTTCABLE>
interactive preprocessing processes on entire Round each time it iterates …
<ELLIOTTCABLE>
and the specifications limit execution to one round …
<ELLIOTTCABLE>
or sommat.
<ELLIOTTCABLE>
there's something wrong with this in my head.
<devyn>
well my idea is that spec assert / spec refute would wait for a 'round' or the signal, whichever comes first
<ELLIOTTCABLE>
yep, I understand that
<devyn>
it's pretty simple and it encourages something that people will need to implement anyway
<devyn>
early on
<devyn>
because really, it does have to be done early on
<ELLIOTTCABLE>
although I'd rather explicit-ify that
<ELLIOTTCABLE>
instead of building it into assert/refute,
<ELLIOTTCABLE>
have the test-writer *write* a failure into it on round-completion
<ELLIOTTCABLE>
so,
<ELLIOTTCABLE>
`specification after {}`
<ELLIOTTCABLE>
copies locals, and is staged at round-completion
<ELLIOTTCABLE>
can do things like check that blah happened or got defined, and fail the test if not
<devyn>
that sounds like a way better idea
<ELLIOTTCABLE>
yeah, I want to keep this low-level and simple
<devyn>
so, if you think this is the way to go, try writing an example of how you think that would work
<ELLIOTTCABLE>
still thinking about it
<ELLIOTTCABLE>
ugh I'm hugely bugged by this
<ELLIOTTCABLE>
I don't know what it is but something about completion bothers me
<ELLIOTTCABLE>
I'm very nearly *convinced* that it's unpawsey to complete. but I can't quite put my finger on why.
<devyn>
but it's okay if the specification interface does unpawsey things
<devyn>
it's meant to be kind of a loophole anyway
<devyn>
a method of introspection
<ELLIOTTCABLE>
hrmmbmrhbmr
<ELLIOTTCABLE>
not exactly what I mean. brainsing hold on.
<ELLIOTTCABLE>
-learn brainsing = switch to Spotify. put on Rachmaninov. lean back in couch. fold hands behind head. stare at ceiling.
<purr>
ELLIOTTCABLE: Learned `brainsing`.
Determinist has quit [Ping timeout: 240 seconds]
Determinist has joined #elliottcable
<ELLIOTTCABLE>
basically, wrapping operations into rounds is segregating synchronous(-ish, at least) operations from definitely asynchronous ones
eligrey has quit [Read error: Connection reset by peer]
<ELLIOTTCABLE>
and that's *not*, quite, what needs for IPP and freezing (and other similar situations). It's close, but it's a misapprehension of the needs there.
<ELLIOTTCABLE>
for testing purposes, we *actually want to do what that describes*, prevent asynchronous operations. sort of. or at least truly asynchronous ones that don't result within heartbeats.
<ELLIOTTCABLE>
basically, for time reasons, alone
<ELLIOTTCABLE>
whereas for IPP/freezing, we aren't looking at time, so much as effect:
<ELLIOTTCABLE>
we want to block off the asynchronous stuff, the "after-first-round" stuff, because lots of after-first-round shit can affect the system.
<ELLIOTTCABLE>
whereas for IPP/freezing, we aren't looking at time, so much as effect:
<ELLIOTTCABLE>
what wtf, out-of-order
<ELLIOTTCABLE>
okay.
<ELLIOTTCABLE>
frankly, I don't want to restrict the testing system in ways I can't quite wrap my head around the connotations of, for the sake of execution-times.
<ELLIOTTCABLE>
I'm quite comfortable with timeouts. Make me *uncompfortable* with them, before we go trying to create new solutions.
<ELLIOTTCABLE>
ugh, no, timeouts don't solve the problem, sorry, got mindbent.
<joelteon>
okay, so 13 hours later, i can finally capitalize on the original reason i had to change to a case sensitive FS
* joelteon
clones linux kernel
<ELLIOTTCABLE>
LOL
<purr>
LOL
<ELLIOTTCABLE>
why the fuck are you doing that?
<joelteon>
well, my nix machines all need a copy of the linux kernel of course
<joelteon>
so it tried to build it on my machine, but i was using HFS+ which is case-preserving
<joelteon>
and failed
<joelteon>
so I created an HFSX partition and put all my nix stuff on it
<devyn>
… build it in a ready-made linux VM
<joelteon>
but it was too much of a pain
<devyn>
don't try to build Linux on OS X
<devyn>
wtf
<joelteon>
and if I ever run out of space on the partition I have to delete and resize it
<joelteon>
so I just switched to CS
<joelteon>
and voila
<joelteon>
devyn, the source tree is a prerequisite to building, so even if I try to build on one of my linux remotes it'll still fail when it tries to downlad it
<joelteon>
download it
<ELLIOTTCABLE>
wat
<ELLIOTTCABLE>
wat
<joelteon>
well, i think so
<ELLIOTTCABLE>
why does irccloud occasionally decide messages just don't need to be sent
<joelteon>
i like to pretend i had some sort of reason to do this
<ELLIOTTCABLE>
I'll type something, hit return, it disappears, NOTHING happens
<ELLIOTTCABLE>
hit up arrow, hit return, this time, it shows up sent
<joelteon>
but hey, on the plus side: no more yosemite
<joelteon>
my stuff almost always works now
<ELLIOTTCABLE>
okay.
<ELLIOTTCABLE>
to rephrase again:
<ELLIOTTCABLE>
what we're actually doing here, is trying to test an asynchronous operation in expected time.
<joelteon>
oh ok
<ELLIOTTCABLE>
I keep thinking of it as "ascertaining failure"
<ELLIOTTCABLE>
but that's orthogonal, and only arises because *failing* is an asynchronous operation in Paws :P
<devyn>
no, 'expected time' is not actually what we're trying to do here
<ELLIOTTCABLE>
(which is a really strange statement. O_O)
<devyn>
that's just a side channel way to test it
<ELLIOTTCABLE>
no, that *is* the problem.
prophile has quit [Quit: The Game]
<ELLIOTTCABLE>
if we Don't Solve™ this problem, in the absence of I/O, if you run the tests, come back a day later, and there was never output from test 2, you've ascertained the operation of that asynchronous system.
<ELLIOTTCABLE>
it's kind of like limits:
<ELLIOTTCABLE>
regardless of whatever bounds there are on the possibility of asynchronous interlopers being Slow, there's still a point out trending towards "soon", at which all operations will be complete if they can be complete.
<ELLIOTTCABLE>
well ignoring time for a second, what I was saying:
<ELLIOTTCABLE>
this easily-boils-down to “how do we *positively* test, i.e. with a synchronous-ish result (which gives us the time-bounding in question), an asynchronous non-return”
<devyn>
right, and the better way to test that IMO is to test whether anything could possibly happen (i.e., test for stalling)
<devyn>
trying to do things time-based is so... non-deterministic
<devyn>
I hate it
<ELLIOTTCABLE>
hrmmbg
<ELLIOTTCABLE>
I definitely agree, but,
<ELLIOTTCABLE>
stalling is *even less deterministic* in Paws. Like, it's suuuuuuuper implementation-dependant.
<ELLIOTTCABLE>
basically: you said it's okay to be un-Paws-y in this testing framework, and to some extent I agree,
<devyn>
that's not what deterministic means :P
<devyn>
and I think it should be well defined
<ELLIOTTCABLE>
but I *also* don't want to implicitly place new constraints on the types and implementation-styles of implementations, by introducing mechanisms like this in the testing *system*
<ELLIOTTCABLE>
sorry words, am sleepy
<devyn>
hmm
<devyn>
I still think timing is a really bad way to do it though
<devyn>
like, to me that smells like a PHP-level design quality
<devyn>
:p
<ELLIOTTCABLE>
yeah trying to think through
<ELLIOTTCABLE>
there really seems to be no solution to this problem, rather by-definition /=
<ELLIOTTCABLE>
without either timeouts or changing the semantics *of paws itself* or specifying that implementations must provide a "round-complete" mechanism
<ELLIOTTCABLE>
devyn: what about both?
<devyn>
both what
<ELLIOTTCABLE>
"completion", for implementations that have a way of providing that,
<ELLIOTTCABLE>
and timeouts, for implementations that are young, or are designed in a way that precludes that
<devyn>
sure, but how are you going to design your tests in a way that's compatible with that
<ELLIOTTCABLE>
that's what I'm saying
<ELLIOTTCABLE>
provide a primitive that basically encapsulates both away from the actual test.
<ELLIOTTCABLE>
"if either <timeout reached> or <completion reached>, run this"
<ELLIOTTCABLE>
basically
<ELLIOTTCABLE>
make sense?
<devyn>
sure
<ELLIOTTCABLE>
any objections?
<devyn>
none at the moment, but I want to see a multiple-test example of how you expect this to work
<ELLIOTTCABLE>
okies
<ELLIOTTCABLE>
also doesn't begin to solve my other concerns
<ELLIOTTCABLE>
granularity and decoupling stuff
<ELLIOTTCABLE>
just an addition to what you already wrote up
<devyn>
mmhm, well I'm not sure it's possible to fully decouple things when working *within the system*
<devyn>
like
<ELLIOTTCABLE>
yeah. clearly.
<devyn>
yeah :p
<ELLIOTTCABLE>
gotta do some combinations and a staging *to* call any `specification` namespace routine, no matter what.
<devyn>
yeah, I mean, just implementing mocks would rely on more than just using the thing itself, so...
<devyn>
not really an option
<ELLIOTTCABLE>
oh I was thinking about that by the way
<ELLIOTTCABLE>
solving some of these issues with more "testing features."
<ELLIOTTCABLE>
for instance, "spies" traditionally solve the sorts of "test function-call arguments" sort of problem we're looking at for combinations.
<ELLIOTTCABLE>
so the ability to generate a spy, and make it the receiver for an object, would give us the flexibility to test actual combinations, to some extent
prophile has joined #elliottcable
<devyn>
except that by the point we've tested the combination we've relied on a whole bunch of combinations :p
<ELLIOTTCABLE>
lol yep
<purr>
lol
<ELLIOTTCABLE>
but remember there's three kinds of tests I'm interested in doing.
<ELLIOTTCABLE>
I'm not worried about the early-on tests being granular,
<ELLIOTTCABLE>
and I'm not worried about the granular tests being easy to achieve early-on.
<ELLIOTTCABLE>
the granular tests should exactingly test the *precise* operation of a tiny aspect of the system (think unit tests),
<devyn>
ELLIOTTCABLE: there are parts about that that really just don't sound like inequality issues, but rather general mindfulness/consideration issues. #16 especially
<ELLIOTTCABLE>
devyn: hm?
<devyn>
"Be responsible with money in domestic/romantic relationships. Know that if you are irresponsible with money, this necessarily impacts your partner and since women still make less than men overall (and live longer), this is a feminist issue.
<devyn>
Example: Your credit card debt/money wastage/gambling problem impacts her economic livelihood and future. Share budget making, tax filing, and general personal finance duties and be open and honest about household money management."
<ELLIOTTCABLE>
what about it?
<ELLIOTTCABLE>
are you talking about my choice of hashtag?
<devyn>
no, the tumblr post you posted
<ELLIOTTCABLE>
I chose that to get more male associates who hate feminism to maybe-click-it.
<ELLIOTTCABLE>
yeah, in the tweet?
<ELLIOTTCABLE>
or, so confus
<devyn>
I didn't see the tweet lol
<purr>
lol
<devyn>
I'm just saying I really disagree with the thinking behind #16
<devyn>
completely
<ELLIOTTCABLE>
I get where she's coming from
<ELLIOTTCABLE>
basically, due to the wage inequalities, issues of money *become* issues of equality, even where they otherwise wouldn't be.
<joelteon>
what if she makes more than you
<ELLIOTTCABLE>
then that's cool.
<ELLIOTTCABLE>
don't see how that changes the point at discussion, there
<ELLIOTTCABLE>
she still has inherently *reduced* earnings-ability, and therefore you have inherently *increased* responsibility for your contribution.
<joelteon>
ok
<devyn>
I also feel like her "50% (or more)" points at some rather flawed reasoning too
<devyn>
the or more part, specifically
<devyn>
the implication there is that 50% is the bare minimum, and that you really should be doing more than that because you're a man and women have been doing this for so long so why can't you make up for that by doing more than she does
<ELLIOTTCABLE>
it's not to make up for something in the past; it's to make up for the *now*.
<ELLIOTTCABLE>
or, to put it another way:
<ELLIOTTCABLE>
"You're going to do very little on the rest of these points to improve her situation. On these particular points, it's easy to actually push *past* the equality point and do *more* than your fair share … so, to ease the collective burden placed on her by all of these circumstances, do what you can <here> and <here> to give her extra emotional / stress
<ELLIOTTCABLE>
breathing-room with which to deal with those other situations."
<ELLIOTTCABLE>
that said, I think 50% *is* good, in a compfortable enough relationship where that's a mutual goal
<ELLIOTTCABLE>
if that makes any sense
<devyn>
fair enough, that makes sense
<devyn>
I still don't agree with issues of money becoming issues of inequality, or at least, I don't think that's why they should be issues
<ELLIOTTCABLE>
if it's not a relationship where she's *asking* you to do 50%, and just 50%, because she cares for you and wishes that of you … i.e. the kind of very close and compfortable relationship where you can talk about such things, and reach mutual goals predictably together … then it's a good idea to just overdo it all to fuck, because you (friend-?)love her,
<ELLIOTTCABLE>
and want to give her breathing-room on the rest of her life.
<devyn>
they should be issues because you should be a compassionate person and think about how what you're doing is affecting the other people in your life
<devyn>
to me, that isn't a "women's issue", that's a humanity issue
<devyn>
and yes, I agree
<ELLIOTTCABLE>
anyway, I have a weird thing about talking about this with other guys
<ELLIOTTCABLE>
gives me the same feels as designing a system in the complete absence of implementation to test it.
<ELLIOTTCABLE>
being a male feminist is remarkably similar to being an architecture astronaut.
<devyn>
hahaha
<ELLIOTTCABLE>
need a girl around to tell you whether you're just spectacularly, completely, unreasonably off the rails in the assumptions you don't even realize you're making.
<ELLIOTTCABLE>
need an implementation around to tell you whether you're just spectacularly, completely, unreasonably off the rails in the assumptions you don't even realize you're making.
<joelteon>
is that how it is to be an astronaut
<joelteon>
oh
<ELLIOTTCABLE>
joelteon: according to that Tinder girl from yesterday, I would clearly know *all about* being an astronaut.
<devyn>
I don't know, I think women really tend to be rather bad at convincing most men of this
<devyn>
and I don't think it's because the men necessarily think they're superior internally or anything
<devyn>
I think it just takes a male point of view to convince another
<ELLIOTTCABLE>
oh, agreed
<devyn>
women and men have quite different experiences in today's society
<devyn>
maybe less than in the past
<ELLIOTTCABLE>
but this isn't me taking established fact, or a common viewpoint, and trying to convey it to you, someone who disagrees or doesn't understand
<devyn>
but there's still quite a difference
<ELLIOTTCABLE>
i.e. leveraging my male viewpoint to push a female agenda,
<ELLIOTTCABLE>
this is two males trying to explore new (to both of us, anyway) territory in the female space.
<ELLIOTTCABLE>
anyway
<devyn>
I think it's important that guys do it *together* though
<ELLIOTTCABLE>
so. you want examples, but, I'm trying to figure out how to retrofit your suggestions using this
<ELLIOTTCABLE>
did you ever explain why refute/assert instead of assert and pass/fail?
<devyn>
because if we don't try to reach an understanding by bouncing things off each other, we're probably going to feel overwhelmed or misunderstood
<devyn>
ELLIOTTCABLE: yes, I did
<ELLIOTTCABLE>
too much scrollback, keywords I can search for?
<ELLIOTTCABLE>
or just re-explain
<ELLIOTTCABLE>
or link to _whitelogger
<devyn>
ELLIOTTCABLE: because the behavior-on-stall is defined by which one it is
<devyn>
like, should it pass or fail on stall
<ELLIOTTCABLE>
oh
<ELLIOTTCABLE>
so, what I was thinking, then.
<ELLIOTTCABLE>
I'm right in assuming that explicit behaviour-on-stall disnecessitates `refute`?
<devyn>
yes, I believe so
<ELLIOTTCABLE>
going to rename assert too, 'cuz, that's more for actual values, when booleans are involved
<ELLIOTTCABLE>
just `test` seems straightforward enough
<devyn>
well, you're not really renaming it; 'assert' was named that way very specifically to contrast with 'refute'
<devyn>
because it fails on stall, and passes on signal
<ELLIOTTCABLE>
so we have … `specification`: {test, ok, fail, eventually}
<ELLIOTTCABLE>
right?
<ELLIOTTCABLE>
gotcha
<devyn>
eventually = ?
<devyn>
if eventually is the 'run on stall' thing, perhaps 'limit' is a better name
<ELLIOTTCABLE>
nah, it's not limiting it in any way
prophile has quit [Quit: The Game]
<ELLIOTTCABLE>
it doesn't inherently limit
<ELLIOTTCABLE>
if you want to limit (i.e. fail it), you can do that, inside the block
<devyn>
no, it's more of a limit in the mathematical sense (I think)
<ELLIOTTCABLE>
*all* it's doing is saying "eventually, do this stuff" (eventually fail the test, eventually succeed the test, eventually re-run the test …)
<ELLIOTTCABLE>
oh gotcha
<devyn>
like, if this is going to approach infinity, do this
<devyn>
haha
<ELLIOTTCABLE>
yeah this totally doesn't solve the granularity problem
<ELLIOTTCABLE>
but it will be a *very* nice, and very paws-y, workflow, for the rest of tests
<ELLIOTTCABLE>
omg lol
<purr>
lol
<ELLIOTTCABLE>
*super* interesting meta-conversation with Tinder girl.
<ELLIOTTCABLE>
it became clear we were looking for different things, so to speak, but she was nice, and so am I, so we chatted for a bit;
<ELLIOTTCABLE>
it devolved and she gave me a couple comments on my profile, which led to this:
<ELLIOTTCABLE>
I have a lot of trouble finding anything arousing, or having it keep my attention, without any sort of connection.
<katlogic>
Well, its just chat, duh.
<ELLIOTTCABLE>
Tinder provides a nice balance for me where *not everybody* on there is there purely for sex, and thus people tend to not jump right in with the sexuality, expecting some sort of reciprocation,
<katlogic>
Tinder is kinda weird, I mean why people fallback to chatting in there when it becomes obvious no hookup will happen?
<ELLIOTTCABLE>
but where there's enough people looking for that that nobody's surprised or offended when you quickly steer the conversation in that direction ;)
<ELLIOTTCABLE>
katlogic: Honestly? Because it's never *obvious*.
<ELLIOTTCABLE>
I've had opposite numbers make it clear that they're not interested in the same thing, and then become more interested with a little time and interaction.
<katlogic>
Yeah I cant kinda wrap my head around online dating.
<katlogic>
I mean, its this two completely separate worlds. Talking dirty with stranger on the internet, or meeting in real life and doing stuff in real life. Mixing the two never panned out for me.
<ELLIOTTCABLE>
see, why talk dirty on the Internet?
<ELLIOTTCABLE>
I don't think there's necessarily an implication of mixing the two.
<ELLIOTTCABLE>
if it is dirty online, then it's … probably just dirty online. In my experience, anyway.
<ELLIOTTCABLE>
dpp is weird, katlogic
<katlogic>
Yeah, its cybering in open. The tricky part is to tell apart guys from girls text only.
<ELLIOTTCABLE>
I disagree with #28 heavily, actually. /=
<devyn>
ELLIOTTCABLE: I'm going to bed, but write an example!!!11!!1 :p
<ELLIOTTCABLE>
I think it's damned-well my place to be involved in my partner's body in a long-term relationship; of either gender. (And them, in mine.)
<ELLIOTTCABLE>
in fact, 28 conflicts heavily with 17. That's a serious double-standard I have trouble conscioning . /=
<ELLIOTTCABLE>
devyn: ugh idk fack
<devyn>
it's almost like asking you to ignore something that turns you off
<devyn>
IMO
<devyn>
if you're in a long term relationship and there's something your partner does that you really don't like, you'd tell them
<devyn>
appearance shouldn't be something untouchable
<ELLIOTTCABLE>
ugh idk
<ELLIOTTCABLE>
very torn on that
<katlogic>
ELLIOTTCABLE, if you want to become true feminist, do as women do.
<ELLIOTTCABLE>
wat
<ELLIOTTCABLE>
that's the exact opposite of a valuable truth.
<ELLIOTTCABLE>
that's *terrible* advice.
<katlogic>
Unfortunately thats what it looks like.
<ELLIOTTCABLE>
treating women as women treat other women is not a helpful basis for action in today's society.
<katlogic>
Say one thing, do another.
ELLIOTTCABLE has left #elliottcable [#elliottcable]
ELLIOTTCABLE has joined #elliottcable
<devyn>
katlogic: a) trying to make gender roles in society more understanding and supportive of each other is absolutely not the same thing as becoming each other
<katlogic>
gender roles? we still do have those?
<katlogic>
Sure, the income inequality is real in some sectors.
<katlogic>
Adult entertainment, women are paid much better than male workers.
* katlogic
saves that kind of talk till he meets actual feminist though :)
<devyn>
lol
<purr>
lol
<katlogic>
Unfortunately feminism in our area transcended into kook phase
<devyn>
yes, there are kooks, but those people are just kooks; it's not because of feminism
<devyn>
ignore them
<katlogic>
for example, green party application, you can choose gender either of "female" "not a female"
<katlogic>
No, this is fucking political party pandering to large feminist demographic you see.
<prophile>
I think that's just being inclusive
<prophile>
the law of excluded middle means that mathematically everyone can feel they belong to one of those two options
<katlogic>
This warping is becoming apparent in multiple places (and does more harm than good for the cause as it is outright inciting war of genders, not equality).
<devyn>
prophile: no, I actually disagree with it, because then why do you need to distinguish between females and others
<prophile>
female tears are far more potent as a fuel source
<prophile>
and that's what the green party is all about
<devyn>
ideally, you should just let people write whatever they want in there, or leave it blank
<devyn>
you'll still get the people who *want* to identify as male or female
<devyn>
and you won't offend others
<devyn>
sure, you'll lose some to jokes
<devyn>
but whatever
<JonBad>
ELLIOTTCABLE: Swipe Away
<ELLIOTTCABLE>
devyn: uhhhhh,m,,,g,g,
<ELLIOTTCABLE>
q
<ELLIOTTCABLE>
`spec test[] ...` or `spec_test[] ...`
<ELLIOTTCABLE>
is it helpful to avoid all the extra combinations, in this situation?
<devyn>
ELLIOTTCABLE: well all that avoids is needing Thing receiver
<ELLIOTTCABLE>
JonBad: hm?
<JonBad>
see me?
<ELLIOTTCABLE>
oh, on you? nope, nothin'
<ELLIOTTCABLE>
devyn: hm
<ELLIOTTCABLE>
devyn: similarly: what about getting rid of the explicit caller-passing?
<JonBad>
maybe restart the app? Should see me.
<ELLIOTTCABLE>
wondering if it restricts anything, to require that the implementation keep track of, and store, the `caller`, so it can be passed to the native implementation
<ELLIOTTCABLE>
so then it just becomes
<ELLIOTTCABLE>
`test {...}`
<ELLIOTTCABLE>
basically
<devyn>
sure, but then how do we run more than one
<ELLIOTTCABLE>
but the body won't be that simplified *anyway*, if you need to have it build an eventually procedure …
<ELLIOTTCABLE>
ugh
<ELLIOTTCABLE>
hybridized idea: yaml, with Paws routine-bodies as the members.
<ELLIOTTCABLE>
is that getting too insane for too small of a problem?
<devyn>
katlogic: I agree that divisive actions like that do more harm than good, but feminism is, IMO, a good thing™ even though some people use that as a label to wage their wars under
<devyn>
katlogic: I believe those people are the loud minority though; the majority is just unheard
<ELLIOTTCABLE>
JonBad: re-booted, got some girl added, but nobody else
<ELLIOTTCABLE>
also, woah, Anchorage really *is* a small pool. Surprised that I could have actually exhausted the locals. :P
<ELLIOTTCABLE>
back to the big pond come Monday. :P
<ELLIOTTCABLE>
I wouldn't say the majority is unheard.
<ELLIOTTCABLE>
If the majority is unheard to you, that's because you aren't trying hard enough, frankly. You only hear the loud ones, because you're so distant from hearing *any* of them.
<ELLIOTTCABLE>
no offense intended.
<devyn>
maybe not unheard but compared to the loud minority warriors?
<devyn>
like, they drown out the others to the point that men think that feminism is a plague and shit like the shitty side of Men's Rights occurs
<katlogic>
devyn: Hard to say, really. From where I am standing, feminism battles just prejudices, not actual societal roadblocks.
<katlogic>
devyn: Those were fixed, for better or worse in the 70s.
<devyn>
katlogic: I agree with providing an 'other' gender strongly, but I disagree with making it 'female/not female'
<katlogic>
(even in heavily patriarchal eastern europe, theoretically man and woman are equal in front of court of law)
<katlogic>
however the prejudices are hard to get rid of. ie men being disadvantages in divorces, women being disadvantaged in leadership for "lack of balls".
<devyn>
katlogic: I have a friend who tends toward non-binarism, and even though he still identifies mostly as a man he feels like he doesn't really fit into that completely, but this could allow him to feel a bit better
<ELLIOTTCABLE>
not a fan of "other", personally
<ELLIOTTCABLE>
ever heard of othering?
<devyn>
not literally "other"
<ELLIOTTCABLE>
you're literally doing that.
* ELLIOTTCABLE
grins
<devyn>
I mean allowing people to write whatever they want
<devyn>
:p
<ELLIOTTCABLE>
yeah, that's a good plan
<ELLIOTTCABLE>
or supply such a huge list that it's almost facetious.
<ELLIOTTCABLE>
explain the value of nested tests, again?
<devyn>
well, that seems kinda silly because some people just want to decide what gender means to themselves without really applying any sort of label
<katlogic>
devyn: Yeah, I'm a fan of thai concept of 'third gender' to account for weirdos who are unsure about their sexual identity.
<ELLIOTTCABLE>
"weirdos"
<devyn>
ELLIOTTCABLE: I'm not sure there is a value to nested tests; I just left that open as an option. I think I was thinking to save setup for multiple steps that depend on each other *shrug*
<purr>
¯\(º_o)/¯
<devyn>
ELLIOTTCABLE: ignore it. don't nest.'
<devyn>
ELLIOTTCABLE: there's no point
<ELLIOTTCABLE>
katlogic: I'm very open-minded, and crass, and offensive, and put up with most of those things in my channel happily (I like this environment.) … but there are three things I will not tolerate. Arguing politics or religion, defending PHP, and exclusive actions and comments (except where those comments are directed at PHP users for their use of PHP.)
<devyn>
katlogic: lol weirdos. *shrug* maybe it would take you knowing someone very well who feels that way to feel compassion, but I assure you it really is a serious thing for some people
<purr>
lol
<ELLIOTTCABLE>
katlogic: I'm sorry, but calling those with gender-identities foreign to you "weirdos" is Not Okay™. This is your only warning.
<ELLIOTTCABLE>
devyn: 'kay, that's good, that simplifies this hugely :P
<katlogic>
devyn: Anyone non-comforming to mass society is considered weirdo. Deal with it.
<devyn>
katlogic: you can define it that way all you want, but it doesn't stop it from meaning negative things to people and feeling hurtful
<ELLIOTTCABLE>
I *do* deal with it, but I'm not going to participate in making others who've been caused pain by having to deal with it for their entire lives, have yet another place where they're forced to sustain that pain.
katlogic was kicked from #elliottcable by ELLIOTTCABLE [katlogic]
<ELLIOTTCABLE>
the first and I hope to gods the last.
<ELLIOTTCABLE>
I don't want to have to be a fucking op. This room should be laid back. There's goddamned maybe twenty active people in here, I shouldn't need to enforce rules. |=
* devyn
shrugs
<purr>
¯\(º_o)/¯
<devyn>
it can be hard for people to understand/be compassionate about these things until they meet someone affected by it
<ELLIOTTCABLE>
yeah /=
<ELLIOTTCABLE>
I don't hate, or judge, katlogic. I understand completely where he's coming from.
<ELLIOTTCABLE>
But I'm dead-set on having an absolutely zero-tolerance policy. I have too many friends for whom I want this to be a safe space.
<ELLIOTTCABLE>
/=
* devyn
too
<ELLIOTTCABLE>
that said, you have op powers, if it ever comes to that.
<ELLIOTTCABLE>
I want you to know you're welcome to use them. /=
<devyn>
I know
<devyn>
I've seen how much this can affect people
<devyn>
like I said, one of my friends is non-binary-ish
<devyn>
one of my friends is gay
<devyn>
I'm bi but not really very out about it
* devyn
shrugs
<purr>
¯\(º_o)/¯
<pepsi4me_>
Good morning, America
<ELLIOTTCABLE>
devyn: okay. sleep well, I'm writing some simple-ass tests.
<ELLIOTTCABLE>
(that's *eighty-five* pages of gists in. O_O)
<devyn>
haha
<ELLIOTTCABLE>
fork of 101. lol.
<purr>
lol
<ELLIOTTCABLE>
er
<ELLIOTTCABLE>
re-writing
<ELLIOTTCABLE>
shouldn't take the caller anymore
<devyn>
well how is it even supposed to work?
<ELLIOTTCABLE>
huh?
<ELLIOTTCABLE>
oh
<ELLIOTTCABLE>
id is just the name you passed to the original
<ELLIOTTCABLE>
so you don't have to save it anywhere or re-type it or accept parameters :P
<ELLIOTTCABLE>
in this particular environment, `spec id` will be easier than `unstage()` for parameterization.
<devyn>
oh but, why even have pass/fail accept that
<ELLIOTTCABLE>
oh
<ELLIOTTCABLE>
yeah, no nesting, forgot
<devyn>
yeah
<ELLIOTTCABLE>
good point
<ELLIOTTCABLE>
reload.
<ELLIOTTCABLE>
simple as fuck.
<devyn>
why do pass/fail take the caller and test/eventually don't
<ELLIOTTCABLE>
have to take *something.
<ELLIOTTCABLE>
could just as easily be 'fucktits'
<ELLIOTTCABLE>
as long as they're being combined against.
<devyn>
right, so then what's the rationale for not making test/eventually take the caller
<ELLIOTTCABLE>
they don't need it, and are already having a value combined against them
<devyn>
but they do need to return
<ELLIOTTCABLE>
they're native, and can get the caller from the reactor.
<ELLIOTTCABLE>
bah fine but there's no reason *except* consistency
<devyn>
implementations might not have any native able to get the caller from the reactor
<devyn>
(mine doesn't)
<devyn>
only NativeReceivers can
<ELLIOTTCABLE>
mmmmm interesting
<ELLIOTTCABLE>
need to nail down the semantics of semicolons
<devyn>
reason for that separation is that they're also passed a Params struct instead of a params-style object, for optimization purposes
<devyn>
(params struct doesn't require any allocations on the heap)
JonBad has quit [Quit: Leaving...]
<devyn>
(params-style object requires a fuckton, by comparison)
<devyn>
and yes, you need to spec semicolons
<devyn>
I'm going to sleep
<devyn>
:p
<devyn>
'night
<pepsi4me_>
Goodnight
<ELLIOTTCABLE>
'night
oldskirt_ has joined #elliottcable
oldskirt_ has quit [Changing host]
oldskirt_ has joined #elliottcable
oldskirt has quit [Ping timeout: 245 seconds]
<ELLIOTTCABLE>
devyn: I'm thinking of requiring special syntax for these, honestly.
<ELLIOTTCABLE>
at the bootstrapping levels of implementation, you could literally non-cPaws-parse a file, extract the bodies of tests, and run them individually, without having to understand combinations well enough to parse the entire thing
<ELLIOTTCABLE>
also, I'm cleaning up the thing by moving the `eventually`'s *outside* the spec. I see no reason to usually have them inside the body.
<ELLIOTTCABLE>
like:
<ELLIOTTCABLE>
`spec test[] { ... body ...} eventually { ... }`
<ELLIOTTCABLE>
it'll still be available inside the body, if you want to do it that way, but this shorthand keeps the bodies short-and-simple
<ELLIOTTCABLE>
also, I'm going to require that spec-test add all the `spec` members to the locals, as well.
<ELLIOTTCABLE>
so `spec test[] { pass[] }` instead of `spec test[] { spec pass[] }`
prophile has quit [Quit: The Game]
yorick has joined #elliottcable
<ELLIOTTCABLE>
devyn: combining the two approaches, and it's going well.
<purr\Paws>
Rulebook/master 3a2a8c6 elliottcable: “I said nothing for a time, just ran my fingertips along the edge of the code-shaped emptiness that had been left inside me.”
<Cheery>
I would guess my thing will crash, if you try feed it even small source code inputs. But it might work line-by-line
<Cheery>
anyway did design it that way.
<Cheery>
but I guess I'll ditch this thing for a day and relax. :)
alexgordon has joined #elliottcable
<audy>
morgen
<Cheery>
morgen moro
TheMathNinja has joined #elliottcable
TheMathNinja has quit [Ping timeout: 260 seconds]
TheMathNinja has joined #elliottcable
<glowcoil>
6:10 AM <Cheery> that's a fucking wall
<glowcoil>
ELLIOTTCABLE: seems like a good idea
yorick has quit [Remote host closed the connection]
<manveru>
cloudhead: yeah
TheMathNinja has quit [Ping timeout: 264 seconds]
<cloudhead>
manveru: cool :D
<cloudhead>
manveru: how is it?
<manveru>
well, pretty sweet :)
<cloudhead>
manveru: I had a kind of "hold on a sec" moment when I saw the true sight tech
<manveru>
lol
<purr>
lol
<cloudhead>
and then found out it's a proper company and stuff
<manveru>
yeah, been working on that stuff pretty much since i joined a year ago
<cloudhead>
cool
<cloudhead>
how many other people are there?
<manveru>
3
<cloudhead>
cool, all distributed right?
<manveru>
one other dev, one PM, and one for finances
<manveru>
yeah
<manveru>
but they are in the US, i'm in europe :)
<manveru>
you play dota at all?
<cloudhead>
yea :)
<cloudhead>
I use dotabuff all the time
<manveru>
you coming to any tournament?
<cloudhead>
nothing planned, I wish I had been at the tournament in frankfurt
<manveru>
yeah, esl was great :D
<cloudhead>
ah you were there
<manveru>
even got my wife to join me
<cloudhead>
haha
<cloudhead>
nice
<cloudhead>
I watched it on the projector at home with some friends
<cloudhead>
insane games
<manveru>
so worth it
<manveru>
i was at the same hotel as navi/ig/vici/c9
<cloudhead>
haha
<cloudhead>
I'm following TI4 now
<cloudhead>
but so many games
<manveru>
thank god for the multistream
<cloudhead>
yea heh
<cloudhead>
but it almost feels like a dota binge
<manveru>
last year i watched all 4 streams at once for the whole time
<cloudhead>
holy shit
<manveru>
my brain was fried by the finals :P
<cloudhead>
yea that's the thing
<cloudhead>
I think I'm gonna take it easy until the 18th
<manveru>
aye
ThatGaySwooshy has joined #elliottcable
<cloudhead>
manveru: I saw that you guys were hiring
<manveru>
it's so crazy how good the teams became
<cloudhead>
mhm
<manveru>
indeed we are
<cloudhead>
especially all the smaller ones taking on the big teams
yorick has joined #elliottcable
<cloudhead>
manveru: how is that going? I'm kind of interested..
<Cheery>
damn.
<Cheery>
figured out two things that lead to redesign of my parser generator
<Cheery>
the first one is the obvious:
<Cheery>
a -> b
<Cheery>
these are common rules, but they do not exactly belong to chomsky normal form.
<cloudhead>
a -> b :O
<Cheery>
unless b is terminal
<manveru>
cloudhead: sorry, brb, really gotta eat something and get a shower :)
<manveru>
but it's been my dream job so far
<cloudhead>
manveru: cool. can we talk about it later? I gotta go to dinner too
<Cheery>
the second thing is: I show results with rules such as foo bar -> foo bar.
<Cheery>
these are internals functions of the parser generator
<Cheery>
and the result is effectively meaningless for whatever reads it.
<Cheery>
well. :) Time for redesign!
devyn has quit [*.net *.split]
akshatj-c has quit [*.net *.split]
SwooshyCueb has quit [*.net *.split]
purr has quit [*.net *.split]
ThatGaySwooshy is now known as SwooshyCueb
purr has joined #elliottcable
devyn has joined #elliottcable
<Cheery>
one good idea is to also define terminals.
<Cheery>
to force the user do that.
<Cheery>
that helps detect errors in the grammar.
<Cheery>
exrpession
akshatj-c has joined #elliottcable
purr has quit [Quit: Stream error]
purr has joined #elliottcable
eligrey has joined #elliottcable
TheMathNinja has joined #elliottcable
<devyn>
ELLIOTTCABLE: can you really quickly specify the semantics of spec test[] { … } eventually { … }; i.e., where does 'eventually' get sent to, etc.
akshatj-c is now known as kaplam
kaplam is now known as kaplan
yorick has quit [Remote host closed the connection]
Determinist has joined #elliottcable
Determinist has quit [Ping timeout: 240 seconds]
yorick has joined #elliottcable
Determinist has joined #elliottcable
eligrey_ has joined #elliottcable
eligrey has quit [Ping timeout: 264 seconds]
<ELLIOTTCABLE>
test accepts a block and results some sort of test-object back to the caller; That can be discarded, but it can also take an operation (label) as another combo
<ELLIOTTCABLE>
if it's an unknown label, it never results; but in the case of "eventually", it performs exactly the same operation as "eventually" within the body of that test would
TheMathNinja has quit [Ping timeout: 256 seconds]
<devyn>
ELLIOTTCABLE: pretty, but adds extra complexity, which I think we should avoid
<devyn>
complexity for no good reason other than prettiness is, in this very specific case, not a good thing
<devyn>
ELLIOTTCABLE: btw, I believe that the way this is working now allows plain TAP to work just fine; we know how many tests there are ahead of time
eligrey_ is now known as eligrey
joelteon has quit [Ping timeout: 240 seconds]
<ELLIOTTCABLE>
not prettiness
<ELLIOTTCABLE>
it's a very specific reason:
<ELLIOTTCABLE>
any code *inside the execuable body* will complicate the running and evaluation of these tests
<ELLIOTTCABLE>
and the eventually block is effectively *optional* for many, simple tests
<ELLIOTTCABLE>
hence why in the rules-file, it's not even code for those examples:
<ELLIOTTCABLE>
when reading the rules-file in, the interpreter that hasn't implemented `eventually` or rounds-counting or whatever methodology, can literally just invoke its own binary with a timeout for that test.
<ELLIOTTCABLE>
or run the test and hit fuckin' ctrl-C.
<ELLIOTTCABLE>
it's decoupling the eventually-behaviour from the immediate-behaviour, and that's a good thing.
joelteon has joined #elliottcable
sharkbot has quit [Remote host closed the connection]
sharkbot has joined #elliottcable
<Cheery>
now it's working. :)
<Cheery>
please
<Cheery>
ELLIOTTCABLE: come up with a name for this thing
<Cheery>
this parser generator thing
<Cheery>
figuring out a name for this thing is more headburning than making it.
<ELLIOTTCABLE>
wat hing
<ELLIOTTCABLE>
I don't understand it, so I can't name it :{
<Cheery>
too bad.
<Cheery>
trying to name it freaks me out.
yorick has quit [Remote host closed the connection]
<devyn>
ELLIOTTCABLE: okay, good, I agree
<ELLIOTTCABLE>
devyn: so, what do you think of that YAML approach?
<devyn>
ELLIOTTCABLE: so I'll add stall detection to Paws.rs later, and then a quick & dirty YAML->Paws converter for this format in Ruby I guess, and then we can get started? :D
<devyn>
I like it
<ELLIOTTCABLE>
it's not pretty, but it solves some problems.
<ELLIOTTCABLE>
I was about to do the converter, but if you beat me to it, that's cool too. :P
<ELLIOTTCABLE>
honestly, was going to wrap the runner up into my upcoming `paws` project
<devyn>
I won't beat you to it if you're going to do it before, I guess, about 5-6 hours from now?
<ELLIOTTCABLE>
LOL nope shooting and stuff
<purr>
LOL
<ELLIOTTCABLE>
unlikely to get anything else done this weekend.
<ELLIOTTCABLE>
maybe on sunday.
<devyn>
okay, then I'll just do something quick and dirty in like 5 seconds in Ruby
<devyn>
and you can redo it in your Rulebook software
<ELLIOTTCABLE>
sounds like a god plan to me.
<devyn>
because it really won't take long haha
<ELLIOTTCABLE>
I've already started on the `specification.coffee` for primitives.js
<devyn>
awesome
<ELLIOTTCABLE>
basically `paws rules` uses the `paws` "implementation resolution" system (lololol architecture astronautry)
<ELLIOTTCABLE>
and runs whatever pawses are known with the rules that are known.
<ELLIOTTCABLE>
as of yet, I still need to figure out what I'm doing for guards, but that can very much be deferred.
<Cheery>
ELLIOTTCABLE: would that help you figure out a name?
<Cheery>
going to create the proposal engine next week.
<Cheery>
it'll invert the rules and calculate price matrix from bottom up, so I know how long shortest implementation of a rule is, and what kind of stuff it contains.