<purr\Paws>
Paws.rs/master be8bde8 Devyn Cairns: Support Rust nightly (as of today)
<devyn>
joelteon: “if it works…”
<joelteon>
fair enough
<joelteon>
i guess that's the argument for using python, nodejs, and puppet in production
<devyn>
lol
<purr>
lol
alexgordon has joined #elliottcable
<vigs>
wtf is this enumerable property nonsense? :|
<alexgordon>
?
<vigs>
ELLIOTTCABLE told me to look into Object.defineProperty() because this loop was iterating through some properties I added to Array and Array.prototype
<vigs>
I set the enumerable property to false, but it's still iterating through it ಠ_ಠ
<joelteon>
puppet might be the worst thing ever
<devyn>
vigs: how are you iterating through the array?
<devyn>
and normally for..in on objects does go over the prototype
<devyn>
which is why when you really want the keys of an object minus prototype, you use object.hasOwnProperty(k)
<vigs>
yeah makes sense
<devyn>
that and for..in is just a looot slower, too
<vigs>
huh, TIL
<vigs>
why's that?
<devyn>
because it's associative. it has to go through all of the keys of the object, treating all of the numeric indices as string keys (well, at least virtually) as well as any other keys
<devyn>
a plain loop is just incrementing an integer
<devyn>
up to the length
<devyn>
vigs: at least virtually, from a design perspective, all indices on objects, even arrays, are strings. so array[1] is actually like array["1"] because it gets converted to a string (though obviously it doesn't actually do that because that would be extremely stupid, but from the design's perspective…)
<vigs>
ahh
<vigs>
thanks devyn
<devyn>
np vigs
alexgordon has quit [Quit: Computer has gone to sleep.]
<ELLIOTTCABLE>
devyn: awake?
<ELLIOTTCABLE>
devyn: fully transparent part?
<ELLIOTTCABLE>
oh, as in, transparent re-mapping
<ELLIOTTCABLE>
brainsed out more specifics on the libside of federation/Units/whatever
<purr\Paws>
Paws.rs/master c81ca41 Devyn Cairns: Simplify ObjectRef down to single Arc, and remove the weird ndebug stuff for tags (shouldn't matter now)
<ELLIOTTCABLE>
devyn: current goings-on in the ivory tower:
<ELLIOTTCABLE>
I'm trying to decide whether it's necessary to restrict operations any further than by-argument.
<ELLIOTTCABLE>
i.e., I like the cleanliness and simplicity of “capability = partially-applied routine”-ish-design,
<ELLIOTTCABLE>
but that has clear restrictions:
<ELLIOTTCABLE>
there's no way to restrict *which* indices on a given object the receiver can `get()`
<ELLIOTTCABLE>
next:
<ELLIOTTCABLE>
still got my mind on recursing into the graph (or rather, limitations of extents / flow of permissions)
<ELLIOTTCABLE>
or really, it's not about *limiting* flow, as it is *allowing* flow.
<ELLIOTTCABLE>
a routine, partially-applied; our model for a capability; can only affect the *one thing* it's handed to you on.
<devyn>
meanwhile, down on the ground, I still have no idea how to make this not suck at parallelism. I'm starting to think it may be necessary to restrict this to one-reactor-per-unit
<ELLIOTTCABLE>
distributing the queue itself isn't helping?
<ELLIOTTCABLE>
just too much copying?
<devyn>
nah, I didn't even try that because I thought about it a bit more and realized it wasn't a good idea
<devyn>
doesn't really solve the synchronization problem at all, and just adds a lot of copying for no reason
<devyn>
leaning toward using Rust's builtin channels which are totally lock-free to send but require a lock to receive
<devyn>
but, have to be able to implement some kind of stop()
<devyn>
as well as stall detection
<devyn>
not impossible, but still thinking about that
<devyn>
keep throwing out code, haha
* ELLIOTTCABLE
frowns
<ELLIOTTCABLE>
so, walk me through your impression of what aspect of the design is *most problematic*, so far.
<ELLIOTTCABLE>
I'm not throwing anything out or changing anything for the sake of performance *yet*, but I want it on my mind.
<devyn>
from what I have experience with, most problematic is the guarantee of some kind of ordering at the global level other than responsibility
<devyn>
from what I don't have experience with, the whole concept of distribution is pretty problematic… seems to me, at least at the moment, that it guarantees that Paws can't really be all that performant just because of the overhead that that carries
<devyn>
if it were very explicit, it could still be abstracted over and muuuch more performant, but of course, that wouldn't be anything new or exciting
<devyn>
I'm thinking you could just provide some low level communication/federation primitives and have it not really be transparent at all, and then libside could do whatever it wants with moving things around and abstracting that
<devyn>
the ability to change an object's receiver opens up quite a bit of nice abstraction over that automatically, I would think
<devyn>
then again, there's also transactional logic/insanities, which complicate all of that again so
<devyn>
I dunno, there's just so much in the design that makes it like, the exact opposite of performant
<devyn>
what we've seen so far is really only the beginning of performance woes I think :/
<devyn>
and it *needs* to be performant, because we're planning huuuuge towers of abstraction on top of this
<devyn>
going back to branch-a-lot.paws, that executes in 2 seconds now on 4 reactors on my octacore
<devyn>
but that's only 8192 branches
<devyn>
which is probably only tens of thousands or hundreds of thousands of Paws ops
<devyn>
if we add everything planned, that time would probably increase dramatically
<devyn>
and then be brought back down again with Science™ but probably not all the way
<devyn>
ELLIOTTCABLE: but anyway in summary I really think at the moment the biggest issue is Unit-global ordering, actually. which is a pretty critical part of Paws
<devyn>
because when I execute with just 1 reactor,
<devyn>
I can run branch-a-lot.paws in 0.2 seconds
<devyn>
that's 10x faster
<ELLIOTTCABLE>
reading
<ELLIOTTCABLE>
idcare new and exciting
<ELLIOTTCABLE>
just useful and happy-making
<ELLIOTTCABLE>
been thinking about that, wondering if I'll eventually need to add low-level primitives, or even munge up the design itself, to provide exactly the sort of explicit framework for distribution that I do for concurrency
<ELLIOTTCABLE>
Science™, my old friend
<devyn>
I think it's going to need to be explicit
<devyn>
and I think that's not such a bad thing, I mean, Nucleus is this super simple small core, and then there's all kinds of massively complicated stuff related to distribution and federation and stuff
* ELLIOTTCABLE
nods
<ELLIOTTCABLE>
distribution, idk, I could live with out. My work could be a success in my eyes without that being super-magical.
<ELLIOTTCABLE>
but parallelization? need to figure that out.
<ELLIOTTCABLE>
the only way Paws makes *any* sense is if it can seamlessly handle embarrassingly parallel tasks
<devyn>
yeah
<ELLIOTTCABLE>
we've hit too much of a wall for me to say “It's okay if Paws is slow, processors will be fast enough to handle it by the time it's done *anyway”
<ELLIOTTCABLE>
Paws' assumptions of “more expressive and flexible, but slow, is okay!” only works if it can take advantage of where our computers are in four, eight years.
<ELLIOTTCABLE>
(in terms of design, not impl)
<devyn>
well this particular parallelism problem is not even a problem of the speed of the processors… unless we can figure out a way to make that problem go away, either by changing the design a bit or some really clever implementation-magic or more likely a combination of both,
<devyn>
it's a theoretical issue that really has nothing to do with the speed of the underlying processor.
<ELLIOTTCABLE>
yes that's what I'm saying
<devyn>
mmhm
<devyn>
yeah, I'm agreeing
<devyn>
lol
<purr>
lol
<ELLIOTTCABLE>
I'm *tentatively* of the belief that a ton of the ordering constraints can be removed from Paws, without substantially changing the feel of the language.
<ELLIOTTCABLE>
just haven't had time to really think about *how*. /=
<ELLIOTTCABLE>
oh
<ELLIOTTCABLE>
got sidetracked
<ELLIOTTCABLE>
so, gimmie some feedback on my ivory-tower shit
<ELLIOTTCABLE>
basically, tentatively:
<ELLIOTTCABLE>
natives to ‘wrap’ executions (including partially-applied / non-pristine ones),
<ELLIOTTCABLE>
in semantics, that when they result, their resumption-values (coming “out” of another Unit; data that is basically alien) are accessible by a subset of ‘normal operations.’
<ELLIOTTCABLE>
ugh nope just, unhappy with this stil.
<ELLIOTTCABLE>
I *really like* the idea that when you ask another unit for `foo`, what you actually get is kinda-sorta the result of `infrastructure get[] [foo] ...`, waiting to be further applied, except *not* exactly the same obviously in several ways,
<devyn>
I think you can still just go with capabilities… just make it so capabilities have to wrap the objects they hand out in capabilities themselves if they want to restrict behavior somehow
<ELLIOTTCABLE>
these *are* capabilities. Just describing the exact API for creating them.
<ELLIOTTCABLE>
the API being, something like,
<ELLIOTTCABLE>
cap = infrastructure capture [infrastructure get] [foo]
<ELLIOTTCABLE>
so, several steps in preparing a capability for exposing:
<ELLIOTTCABLE>
take an ability (a procedure.) or a set thereof,
<ELLIOTTCABLE>
partially apply them to any restrictions (usually, for instance, whatever data you want that ability applied to),
<ELLIOTTCABLE>
and then describe what further abilities apply to children-data.
<ELLIOTTCABLE>
problem is, the root-level idea there, is very ability-centric, not data-centric
<ELLIOTTCABLE>
and changing to a data-centric thought-process for children … doesn't make a whole lot of sense … mrrrrghgb
<devyn>
what I'm saying is to just not worry about abilities applying to children-data
<ELLIOTTCABLE>
oh?
<ELLIOTTCABLE>
oh, misr-ead
<ELLIOTTCABLE>
mis-read*. yep.
<devyn>
if the capability wants to enforce stuff over children-data, it has to create new capabilities to access that children data.
<ELLIOTTCABLE>
typing with fingernails is hard. need to go cut mine.
<devyn>
otherwise they just get that object
<devyn>
no automatic enforcement
<ELLIOTTCABLE>
hrm
<ELLIOTTCABLE>
feels very backwards. One slip-up, and you've given the consumer your entire data-graph. a bit overwhelming.
<ELLIOTTCABLE>
but, I getcha, at the same time.
<ELLIOTTCABLE>
“the capability to get capabilities for child-data”, if we were to describe that in english.
<devyn>
but this is Nucleus. you could create everything you want from within
<ELLIOTTCABLE>
yeah trying to imagine how difficult this would be to abstract over.
<devyn>
unless I'm missing something, there's really not even anything that needs to be added to Nucleus for this
<devyn>
it's all abstraction-level
<ELLIOTTCABLE>
well definitely the initial handshake ‘protocol’ for *getting* a capability from somebody else
<ELLIOTTCABLE>
and there's still some nuance here:
<ELLIOTTCABLE>
if have (a, b, c) as a thing from Unit B, and it's going into Unit A,
<ELLIOTTCABLE>
it's not a “normal object”, in the system I've got in my head right now.
<ELLIOTTCABLE>
for instance, Unit A's `infrastructure get[]` wouldn't function on it.
<ELLIOTTCABLE>
it'd be like passing an Execution to `explode[]`. the data that your natives need to function meaningfully, just isn't there. by intention.
<ELLIOTTCABLE>
only this foreign, magical (from your point of view) `B get[]` that it's given you, that has basically closed-over a version of (a, b, c) from within B, operates on that data. or rather, *is* that data. or as much of it as you hold.
<ELLIOTTCABLE>
so the question is, in that framework, if I say `B get[] 3`, what do I receive? a copy of the entire data-structure `c`, whatever that may be, that is now local to my unit, and accessible with my unit-native operations?
<ELLIOTTCABLE>
what about *modifying* that?
<ELLIOTTCABLE>
what if B wants me to be able to modify all of that?
<ELLIOTTCABLE>
so, you mention wrapping it all in further capabilities. okay, maybe. lessee.
<ELLIOTTCABLE>
unless *I'm* now mistaken, that means an abstraction that deconstructs <my unit's> stuff, replacing each arbitrary thingamajigg with a capability-for-thingamajigg …
<ELLIOTTCABLE>
could work. could work. hm.
<ELLIOTTCABLE>
sounds violently slow, and verrrrry difficult to build, but may be enough.
<devyn>
it is, but I think it's the optimizable kind of violently slow :p
<devyn>
not sure.
<devyn>
not slow compared to network latency, for sure
<ELLIOTTCABLE>
mmmmmmmmmmm
<ELLIOTTCABLE>
okay well let's talk about how it would work for the other half (or even, “the majority portion”) of units:
<ELLIOTTCABLE>
modules.
<ELLIOTTCABLE>
files on the disk. frozen, or interpreted from source, or whatever.
<devyn>
yeah yeah I know I've been thinking about that too
<ELLIOTTCABLE>
yepnope still stuck on the Copying Question.
<devyn>
ah it's 2am
<devyn>
have work
<devyn>
should probably sleep
<devyn>
see you later
<ELLIOTTCABLE>
I'd *really* really *really* really, that “a capability” be able to ensconce, invisibly possibly, an entire subgraph.
<ELLIOTTCABLE>
aw poop
<ELLIOTTCABLE>
sleep well
<devyn>
you too, whenever you do
<devyn>
:)
<devyn>
send stuff at me still if you have thoughts, heh
<ELLIOTTCABLE>
ick
<ELLIOTTCABLE>
devyn: so, yep, am very interested in a design, Nuclear-level, that's *capable* of describing entire sub-graphs at a stroke.
<ELLIOTTCABLE>
this is important to the idea of capabilities themselves: “the capability to recurse”, so to speak.
<ELLIOTTCABLE>
I'm all for abstractive solutions, but this doesn't seem the place.
prophile has joined #elliottcable
prophile has quit [Quit: The Game]
prophile has joined #elliottcable
prophile has quit [Remote host closed the connection]
prophile has joined #elliottcable
nuck has quit [Ping timeout: 240 seconds]
nuck has joined #elliottcable
yorick has joined #elliottcable
Sgeo has quit [Read error: Connection reset by peer]
prophile has quit [Quit: The Game]
prophile has joined #elliottcable
prophile has quit [Quit: The Game]
prophile has joined #elliottcable
<Cheery>
ELLIOTTCABLE: looking at this LR stuff.. realising parsing just turned out lot less messy for me
<Cheery>
my parser generator & engine ~300 lines of python
prophile has quit [Quit: The Game]
prophile has joined #elliottcable
eligrey has joined #elliottcable
prophile has quit [Quit: The Game]
eligrey_ has joined #elliottcable
eligrey has quit [Ping timeout: 240 seconds]
eligrey has joined #elliottcable
eligrey_ has quit [Ping timeout: 255 seconds]
prophile has joined #elliottcable
prophile has quit [Quit: The Game]
alexgordon has joined #elliottcable
prophile has joined #elliottcable
prophile has quit [Quit: The Game]
gozala has joined #elliottcable
yorick has quit [*.net *.split]
yorick has joined #elliottcable
prophile has joined #elliottcable
prophile has quit [Quit: The Game]
Sgeo has joined #elliottcable
prophile has joined #elliottcable
yorick has quit [Remote host closed the connection]