eligrey has quit [Read error: Connection reset by peer]
<ELLIOTTCABLE>
lol glowcoil I still have cut.tl
<purr>
lol
<devyn>
fuccckking throatsinging is awesome
<devyn>
ELLIOTTCABLE: going to implement Paws anyway but without any ownership stuff because I'm sure that's going to have to change to fix the parallel problem
<ELLIOTTCABLE>
er
<ELLIOTTCABLE>
Paws without any ownership is completely not a thing, and completely pointless,
<ELLIOTTCABLE>
and to boot, ownership has nothing to do with parallelism.
<ELLIOTTCABLE>
I've said this over and over, nobody listens.
<ELLIOTTCABLE>
ownership is about *ordering*.
<ELLIOTTCABLE>
you can have a completely non-parallel-at-all-in-any-way-whatsoever chunk of code that still makes absolutely no sense whatsoever in the absence of the ownership system to order it
<devyn>
yes, yes, I know, but it gets in the way of parallelism to do it that way
<ELLIOTTCABLE>
also, I just said “fuck it.” and kicked http://wikipedi.as/ live.
<ELLIOTTCABLE>
despite not having a landing page that's working or at all designed pretty
<ELLIOTTCABLE>
about to replace the landing-page that *is* showing up there with a 404, lol
<purr>
lol
<ELLIOTTCABLE>
shaddup purr you're not even written in paws
<devyn>
at least, I think. it seems to me that the looking for responsibility trees and comparing masks thing is something that requires a lot of locking between reactors
<ELLIOTTCABLE>
yeah, not disagreeing. It's on my mind.
<ELLIOTTCABLE>
The design changes aren't going to *change* that, though, because if you change that, it's no longer Paws:
<ELLIOTTCABLE>
one of two things are going to happen, most likely
<ELLIOTTCABLE>
well, ignoring the third case, which is “there's a magical solution I haven't thought of yet” :P
<ELLIOTTCABLE>
1. I give up on true parallelism, and just declare that all Paws implementations are single-threaded
<ELLIOTTCABLE>
which arguably defeats part of the point of Paws, but whatever,
<ELLIOTTCABLE>
2. I nail down semantics for pipelining.
<devyn>
…I think there might actually be a solution
<devyn>
instead of locking on global data structures for responsibility
<devyn>
and ownership
<devyn>
just let the reactors send messages to each other about that
<devyn>
when things change
<ELLIOTTCABLE>
sounds like a great big heap of “Not the specification's problem.”
<ELLIOTTCABLE>
:P
<devyn>
it might actually not be a problem with the spec :)
<devyn>
this might be solveable without changing any design
<ELLIOTTCABLE>
implementation specifics. Unless *enabling* a solution like that A) becomes obviously and seriously necessary, and B) obviously requires a change in the design,
<ELLIOTTCABLE>
definitely not something I think about it.
<devyn>
yes, definitely implementation-specific; if it works though it means the design doesn't need to be changed
<ELLIOTTCABLE>
anyway, because it's interesting regardless of whether it's relevant to my work:
<ELLIOTTCABLE>
shared-global-state for the data-graph, but reactor-local copies of the ownership table, and then some sort of heuristic for saying a given section of the data-graph “belongs to” a particular reactor?
<ELLIOTTCABLE>
executor*
<ELLIOTTCABLE>
sorry, let's be terminology-specific, heh
<ELLIOTTCABLE>
I suppose the idea being that widely-different parts of the code can hopefully/often operate on completely different parts of the data-graph?
<devyn>
not even tying sections of the data-graph to particular reactors; instead, the reactors just inform each other when the ownership table changes so that they can have their ownership table up to date before they try to execute anything else. it won't affect them while they're in the process of a combination
<devyn>
but it's something they check for before they try to combine; they see if they've received any ownership table update notifications
<ELLIOTTCABLE>
well, of course. But I don't see how widespread copying of it is any faster.
<ELLIOTTCABLE>
it *always* has to be checked; it's the writes that would be the problem
<ELLIOTTCABLE>
oh this is relevant to your point:
<ELLIOTTCABLE>
I haven't written it into the spec, yet, but I'm 99% sure that the theoretical Paws reactor is going to gain multiple operations.
<devyn>
it doesn't require locking this way. the problem is that there would be *tons* of contention between combinations, because they would all have to try to lock the ownership table all the time
<ELLIOTTCABLE>
as opposed to the current singular “combination” operation, that is overloaded to handle ownership as well, which is a mess.
<ELLIOTTCABLE>
in the new machine, “charge” ops will be interleaved with, but separate from, “combine” ops.
<devyn>
what do charge ops look like
<ELLIOTTCABLE>
the only obvious *opsem* difference is that the `infrastructure charge` native no-longer “returns” anything to the thing being charged.
<ELLIOTTCABLE>
it was one of the glaring errors in my “never return a value if there is no meaningful ‘result.’”
<ELLIOTTCABLE>
because you *had* to *stage* an execution, to give it new responsibility …
<ELLIOTTCABLE>
… and you *have* to pass a value when staging something
<ELLIOTTCABLE>
meaning that a “give responsibility to this execution” involved, counter-intuitively, advancing it. which is messy, and needs preexisting knowledge of the current state of the execution in question.
<ELLIOTTCABLE>
it worked out okay-enough *when* the execution was charging *itself* … but was really obscure and strange when charging somebody else.
<ELLIOTTCABLE>
so. now, “charging” is still *ordered*, and still affects ordering *of* other actions (which is the entire point, it's a locking system, duh),
<ELLIOTTCABLE>
but it no longer includes a superfluous combination-processing (basically, a resumption) as well.
<devyn>
have you put all of this in the spec yet? there was nothing about charging before really, nor how things worked from Paws-world
<devyn>
…hell, there's nothing in there about how things work from Paws-world, really
<devyn>
I want a Paws-world perspective on things
<devyn>
:D
<ELLIOTTCABLE>
nope
<devyn>
i.e., assume we're in Paws, now how do we do shit
<ELLIOTTCABLE>
yeah, I'm bad at writing specs, clearly
<devyn>
I think that's probably the biggest thing
<ELLIOTTCABLE>
going to try to learn from the R5RS for my next attempt, buuuuut, don't expect miracles
<devyn>
everything should flow naturally if you go from that perspective
<ELLIOTTCABLE>
the ops from Paws-side are all really simple, once you know all the dirty implementation details that the spec is currently full of.
<ELLIOTTCABLE>
theoretically, yes.
<ELLIOTTCABLE>
realistically, no.
<ELLIOTTCABLE>
charge:
<devyn>
you can demonstrate those implementation details by their effects, generally
<ELLIOTTCABLE>
basically equivalent to `infrastructure stage`, but with what the spec calls a requestedMask.
<ELLIOTTCABLE>
-spec
<purr>
ELLIOTTCABLE: Paws' Version 10 specification <http://ell.io/spec>
* ELLIOTTCABLE
checks
<ELLIOTTCABLE>
“ Now they’re explosives which are on fire, and those have a different name: explosions.”
gozala has quit [Quit: Connection closed for inactivity]
<devyn>
lol
<purr>
lol
<ELLIOTTCABLE>
-find raft
<purr>
ELLIOTTCABLE: Found: canadian, mods, and minecraft
<ELLIOTTCABLE>
-canadian
<purr>
ELLIOTTCABLE: Kraft Dinner! Canadian bacon! Maple syrup! Snow! More snow! Wood! More wood! Lumberjacks! Gay people! More gay lumberjacks! More Kraft Dinner! More asians — wait, what?
<devyn>
hahahahahaha
<ELLIOTTCABLE>
wat even
<devyn>
oh I hope that was me
<devyn>
-factoid canadian
<purr>
devyn: Popularity: 5, last changed by: <unknown>, <unknown time> ago
<ELLIOTTCABLE>
it says #incomplete, but it's not. that's just where I eventually wanted to write up some rationale.
<ELLIOTTCABLE>
each entry in the queue has A) a value (the ‘response’), and B) an optionally requested ‘mask’.
<ELLIOTTCABLE>
if an execution is queued by somebody calling `infra stage` libside, or by any of the native queueing stuff described in the spec, then there is no request mask associated (it's null, or undefined, or whatevs.)
<ELLIOTTCABLE>
but if it's queued by somebody calling `infra charge`, which is otherwise identical to `infra stage`, then it's *also* got a mask associated.
<ELLIOTTCABLE>
there's some messy semantics in there I haven't laid out, that are non-functional in my implementation, too; but I don't feel like fixing them, because I'm about to change all that for the multi-op executors we were just discussing *anyway*
<ELLIOTTCABLE>
but the idea is pretty simple. understand?
<devyn>
okay, yeah, I see
<devyn>
and yes it's definitely silly to have charge act like stage in that you have to provide a response and it advances
<devyn>
wholeheartedly support multiop
sharkbot has quit [Remote host closed the connection]
sharkbot has joined #elliottcable
<devyn>
ELLIOTTCABLE: going to sleep; mention me if you have more thoughts
<ELLIOTTCABLE>
hah
<ELLIOTTCABLE>
sleep well
<ELLIOTTCABLE>
buried in making sure wikipedi.as can run without attention for the time being