devyn changed the topic of #elliottcable to: a super duper cult :)
<devyn>
joelteon: is the cool part that it completely breaks if someone fucks up?
<joelteon>
yeah
<devyn>
alexgordon: oh, by the way, since we were talking about it, strings on the stack: this is going to be part of DST in Rust too; both &[T] and &str are currently legal as 'slice types' but they aren't legal without the &
<devyn>
alexgordon: but with DST, both [T] and str will be legal bare
<alexgordon>
devyn: yeah
<devyn>
alexgordon: at the moment your options for strings are &'static str (similar to const char * in C) and String (heap allocated, owned)
<devyn>
it's a little complicated because all Rust strings are UTF-8, which is not indexable
<alexgordon>
devyn: *no* string representation is indexable
<alexgordon>
because graphemes in unicode are of arbitrary length
<alexgordon>
you can keep piling on combining characters as far as you like
<vigs>
My copy of K&R's The C Programming Language arrived today <3
<alexgordon>
devyn: furrow's string representation is 'struct String { char* ptr; size_t size; char storage [16]; }' although I wonder if I can do some type magic with that too
<devyn>
alexgordon: yes, though many Unicode string implementations just ignore that and treat them as different chars
<alexgordon>
devyn: and they're wrong :P
<devyn>
yeah, I suppose so
<devyn>
though at least they usually document that as a caveat
<devyn>
heh
<alexgordon>
devyn: நி yo!
<alexgordon>
two characters my arse
<joelteon>
two arses my character
<devyn>
wow that's pretty cool how that works
<alexgordon>
devyn: I feel like programming languages would be a LOT better at unicode if silicon valley was in the indian subcontinent
<ELLIOTTCABLE>
so. let's chat units / module system
<devyn>
that was a very detailed way of saying "circular dependencies are usually bad, m'kay? don't"
<ELLIOTTCABLE>
it's stack overflow, yo
<ELLIOTTCABLE>
it's not IRC
<devyn>
haha
<devyn>
I know
<ELLIOTTCABLE>
can't just be like "You're being dumb, and doing it wrong." even if that's actually usually the answer.
<ELLIOTTCABLE>
doesn't get you points.
<ELLIOTTCABLE>
which is my single favourite part of SO.
<devyn>
haha
<ELLIOTTCABLE>
you want my points, you'll damn well treat me like I know what I'm doing.
<ELLIOTTCABLE>
bitch.
<ELLIOTTCABLE>
so.
<ELLIOTTCABLE>
re: federating units,
<devyn>
yes, please
<ELLIOTTCABLE>
it's occured to me that "capabilities" on Paws objects,
<devyn>
it's kinda related to what I'm working on right now, ish
<ELLIOTTCABLE>
do you remember the previous discussion on this?
<ELLIOTTCABLE>
I know the general direction I want to go.
<devyn>
ehh not really
<ELLIOTTCABLE>
okay.
<ELLIOTTCABLE>
basically:
<ELLIOTTCABLE>
you can grab the rest out of the logs, but I settled on capabilities as the best, and most flexible, encapsulation scheme for modularization of code.
<ELLIOTTCABLE>
it being Paws, and me wanting everything to be extensible / abstractable, while being simple at the core,
<ELLIOTTCABLE>
*all* I'm going to specify is the ability to A) request <something>, and B) accept and handle requests to yourself, when you are <something>.
<ELLIOTTCABLE>
tentatively, the relevant API would look like:
<ELLIOTTCABLE>
request(foreign-identifier, capability-identifier) on the part of the requester,
<ELLIOTTCABLE>
and expose(block<capbility-identifier>) on the part of the receiver
<ELLIOTTCABLE>
basically, Units have a chance to interrogate incoming Units regarding their request, and decide what to give them. (Will probably have some sort of `identify` API, by which the requestor can share itself with the Unit it's requesting access from.)
<ELLIOTTCABLE>
so. backstory complete.
<ELLIOTTCABLE>
that's all pretty straight-forward stuff. bikeshed away if you like, but,
<ELLIOTTCABLE>
something that's been up in the air, is exactly what you *get* when you manage to federate with somebody. As described above, ‘capabilities.’
<ELLIOTTCABLE>
the core characteristic of a capability is that it is both your right-to-access, *and* method-of-access. Basically, if you're holding a capability to do something, you use *that capability* to do that thing. Access and exercising of access are synonymous (like a car-key.)
<devyn>
this is also probably most optimal for networking, such that you only need a single point of access
<ELLIOTTCABLE>
transcendence is such a bad movie. Acting is terrible, writing is terrible, science is terrrrrrrible
<devyn>
(we are going to be federating over the network, too, right?)
<ELLIOTTCABLE>
presumably, yep
<devyn>
cool
<ELLIOTTCABLE>
well, it's not necessarily single-point
<ELLIOTTCABLE>
“access me and my children” could easily be a form of capability, as well.
<devyn>
hmm, well, I guess it depends on exactly how transparent that's supposed to be to libside
<ELLIOTTCABLE>
a really common one, I imagine, is exposing an entire data-structure (think exporting a single Object, in Node)
<ELLIOTTCABLE>
so, perhaps a common capability might be “traverse from this root along ownership edges”
<ELLIOTTCABLE>
transparent?
<ELLIOTTCABLE>
hm?
<devyn>
well, these objects are potentially located over the network,
<devyn>
so how transparent are operations to them
<devyn>
can we treat them like any other object
<ELLIOTTCABLE>
oh, that's a huge part of distribution.
<ELLIOTTCABLE>
data is *supposed* to be shared.
<ELLIOTTCABLE>
I'm hoping I don't have to specify the exact semantics of that, in terms of the language
<ELLIOTTCABLE>
(although the distribution protocol, which is an entirely different beast *anyway*, is another matter)
<ELLIOTTCABLE>
but,
<ELLIOTTCABLE>
way back when I was envisioning Paws as a distributed language, I wanted to believe it was possible for data and code to flow *around* the web of federated machines.
<ELLIOTTCABLE>
the canonical example being a single file which has both DOM accesses and databases-queries, or something:
<ELLIOTTCABLE>
the code-parts of the program that are 'closer' to the immovable (because they're implementation-specific) DOM-interface procedures, will be executed on the machine that *has* those procedures, so the calls don't have to go over-the-wire,
<ELLIOTTCABLE>
i.e. the client,
<ELLIOTTCABLE>
whereas the close-to-database-calls stuff would run on the database machine.
<ELLIOTTCABLE>
all transparently, because from within the language, that stuff doesn't differentiate. All that matters is what's in your unit. (your module.)
<ELLIOTTCABLE>
so, more concretely:
<ELLIOTTCABLE>
so the distribution protocol should ideally be able to “re-site” both data and code.
<devyn>
okay, so how to we measure that "closeness" :p
<devyn>
magic?
<devyn>
do*
<ELLIOTTCABLE>
yeah, heuristic magic, probably.
<devyn>
lol
<purr>
lol
<ELLIOTTCABLE>
“Hm, I seem to be sending a *lot* of calls over-the-wire to <client machine> from <Script doing DOM>. Let's request re-site that code to <client machine.>”
<devyn>
this is going to be extremely complicated and probably not work that well :s
katlogic has joined #elliottcable
<ELLIOTTCABLE>
k, how so
<katlogic>
ohai SJW fellows :) /me promises to not break teachings of the order
<ELLIOTTCABLE>
(katlogic: SJW?)
* devyn
sighs
<devyn>
ELLIOTTCABLE: anyway
<devyn>
it... just is
<ELLIOTTCABLE>
I don't see it as being a requirement for implementations. If all that's too complex, a young implementation can simply site an entire unit on it self, and send out external requests for every bit of data or procedure-call sited elsewhere.
<devyn>
it's really complicated
<ELLIOTTCABLE>
seems pretty normal.
<devyn>
it's not about being "young" I think, it's just inherently very complicated
<ELLIOTTCABLE>
which part, the re-siting?
<ELLIOTTCABLE>
I'm pretty sure I've seen this done before
<devyn>
yeah
<devyn>
I haven't lol
<purr>
lol
<ELLIOTTCABLE>
hell, I got the word "site" in the context of an object belonging to different distributed implementations, from somewhere else
<ELLIOTTCABLE>
just can't remember at the moment which language it was, ugh
<ELLIOTTCABLE>
I vaguely remember stuff about data being strongly-sited vs weakly-sited,
<ELLIOTTCABLE>
and some data being safe to be be unsited entirely (i.e. it can exist everywhere), such as immutable stuff
<devyn>
but I mean, in Paws, if you consider the sheer amount of data that's necessary to perform these kinds of heuristics
<devyn>
Paws doesn't really differentiate between... anything, all that much
<devyn>
you'd have to figure out who has references to it, trace code paths up until it actually goes over the network to figure out whether it's worthwhile, etc...
<devyn>
I think it's a really pretty idea from a consumer point of view, but it requires magic to happen
<devyn>
of the probably-so-inefficient-you-don't-even-want-to-use-it kind
<ELLIOTTCABLE>
kkk
<katlogic>
It's not really magic as long there are guarantees of no-shared-state.
<ELLIOTTCABLE>
lessee
<katlogic>
Either explicit or via heuristics.
<ELLIOTTCABLE>
katlogic: all state is shared, that's kind of the point.
<ELLIOTTCABLE>
long story short, would need to find boundaries in the data-graph, with code that stays (mostly) within (mostly) those boundaries
<katlogic>
Pretty tough then, especially with high latencies. There are solutions to that - speculative execution and checkpointing (basically you retract execution state whenever independent threads reach conflicting state).
<katlogic>
commit/rollback
<ELLIOTTCABLE>
interesting.
<ELLIOTTCABLE>
idk if relevant, never heard of it before,
<ELLIOTTCABLE>
but if it provides you context, Paws is already necessarily transactional
<ELLIOTTCABLE>
(our error-handling is transactional)
<ELLIOTTCABLE>
anyway. all irrelevant to the semantics *within the language*, still.
<katlogic>
It's mostly distributed database thing, but is used in HPC as well. Trouble is, it is really possible to save checkpoints to restart from whenever collision occurs?
<ELLIOTTCABLE>
I guess the only relevancy of this conversation right now is in informing the design of the federation API, yes/no?
<ELLIOTTCABLE>
katlogic: by definition, yes. Except in very obscure / extreme circumstances, it's illegal preform any operation in Paws which you cannot undo.
<ELLIOTTCABLE>
curiosity: whatcha mean by collision
<katlogic>
threads of executing mark start and end of "atomic" operation. basically begin() and commit()
<katlogic>
whenever it is found out that two commits() were intervoven, you must undo all that happened up to begin() point
<katlogic>
and resolve the conflict by redoing things in sequence
<katlogic>
begin() and commit() is necessary to package changes on one done into bulk operation which is transmitted on commit, there is no other way to solve the latency problem.
<ELLIOTTCABLE>
yesyesyes I know how transactional execution works
<ELLIOTTCABLE>
man, you guys are all so implementational in your thought-process :P
<katlogic>
Well then, it's exactly like that. Except database entries, its all of your execution state.
<katlogic>
*Except instead of
<ELLIOTTCABLE>
what I was asking, the part I don't know anything about: under what situations are you suggesting that transactions be rolled back?
<katlogic>
of course you can make implicit marks too
<ELLIOTTCABLE>
rephrase: what does transactional execution have to do with distribution? walk me through it.
<katlogic>
ELLIOTTCABLE: Because you have global shared state, all nodes must keep the world in sync.
<katlogic>
The transactions are there to implementat that in efficient manner.
<devyn>
ELLIOTTCABLE: designing things is fine but thinking about how you're actually going to accomplish it is important too... that's basically why you're telling us about these designs, anyway, so that we can figure out if they're reasonable or not
<ELLIOTTCABLE>
devyn: oh, I don't mean not thinking about implementation at all
<ELLIOTTCABLE>
it's just weird to see somebody describe actual function-names when describing a high-level concept.
<ELLIOTTCABLE>
not important, movin' on
<ELLIOTTCABLE>
ignoring all those issues for the moment (to get back to the API discussion) I wanted to touch on my thoughts about *what* one module of code exposes to another.
<devyn>
ELLIOTTCABLE: if you mean begin() and commit(), those are pretty well recognized/standard actions in transaction stuff
<devyn>
:p
<devyn>
not necessarily function names
<ELLIOTTCABLE>
kk
<devyn>
okay, sure
<ELLIOTTCABLE>
so, given a 'capability' for "allow read of members from object foo",
<ELLIOTTCABLE>
where in the existing Paws design have we already seen that?
<ELLIOTTCABLE>
infrastructure get[] [foo] ...
<ELLIOTTCABLE>
now we have what is basically a partially-applied function, that only gives you the ability to give it an index, and retrieve members from foo.
<ELLIOTTCABLE>
in fact, it even goes a little bit further in its similarities than *that*: since nominally you can't reverse executions, the earlier code-data doesn't even need to *exist*.
<ELLIOTTCABLE>
(you can literally transmit over the wire to a consumer *only* the bits of the code that do what you want to allow them to do, if that makes sense)
<ELLIOTTCABLE>
so, we have half the formula: we can describe an allowed operation (literally, describing the operation is *providing* the operation, and what already provides the operation? an execution.), and describe restrictions on what can be operated *on* (partial application of that operation),
<ELLIOTTCABLE>
the other half is recursion or scope.
<ELLIOTTCABLE>
how do we describe 'you can iterate over my members, and invoke each of them as a procedure', if we're exposing a bag of procedures?
<ELLIOTTCABLE>
i.e. need to figure out applying that operation / restrictions tuple, further down the graph.
<ELLIOTTCABLE>
idk nebulous
alexgordon has joined #elliottcable
Sgeo_ has quit [Read error: Connection reset by peer]
yorick has joined #elliottcable
alexgordon has quit [Quit: My iMac has gone to sleep. ZZZzzz…]
alexgordon has joined #elliottcable
alexgordon has quit [Quit: My iMac has gone to sleep. ZZZzzz…]
alexgordon has joined #elliottcable
prophile has joined #elliottcable
prophile has quit [Quit: The Game]
alexgordon has quit [Quit: My iMac has gone to sleep. ZZZzzz…]
eligrey has joined #elliottcable
<joelteon>
anyone good with python
<Cheery>
me
alexgordon has joined #elliottcable
eligrey has quit [Quit: Leaving]
eligrey has joined #elliottcable
<SwooshyCueb>
I'm fairly decent with Python
<joelteon>
i found it out
<joelteon>
nvm
oldskirt_ has joined #elliottcable
oldskirt_ has joined #elliottcable
oldskirt has quit [Ping timeout: 260 seconds]
<devyn>
I don't Pyth
<joelteon>
#python didn't want to help me metaprogram
<devyn>
metaprogramming is for rubyists!
<devyn>
here in python land we believe in one way to do everything
<Cheery>
a question. does anyone consider vim here a good editor design?
<alexgordon>
Cheery: no
<Cheery>
what brings it lacking?
<alexgordon>
nativity
<alexgordon>
like sheep and a manger
<alexgordon>
Cheery: I guess I just disagree with every design decision vim makes. but that's why I built my own :P
<Cheery>
your own vim?
<alexgordon>
my own editor
<alexgordon>
chocolatapp.com
<Cheery>
ok
<alexgordon>
I want an editor that 1) uses native keybindings, 2) can support webviews etc, 3) doesn't require hours of googling and setup to get it to do basic stuff like indentation when you press return
<Cheery>
how did you implement the buffers in your editor?
<alexgordon>
Cheery: ?
<alexgordon>
which bit of it
<Cheery>
text insertion, deletion
<alexgordon>
Cheery: oh that comes for free from NSTextView
<alexgordon>
the hard part is syntax highlighting
<Cheery>
okay.
<Cheery>
well I had this idea yesterday, and been working towards this thing few hours.
<Cheery>
I'm trying to implement a vim editor clone, but with a twist.
<Cheery>
aside text there are cards, that may be more text, or anything other data.
<alexgordon>
well good luck LOL
<purr>
LOL
<alexgordon>
you'll need it
<Cheery>
heh not relying on luck because I lack it.
<Cheery>
instead I'm going to implement sort of working vim editor first.
<Cheery>
had my first try fail already. got few ideas from that
<Cheery>
it's going to be interesting to create vim motions on top of this.
<Cheery>
studied what they are, actually.
<Cheery>
cursor motions are stuff like.. "move from this position to this"
<Cheery>
if there's line in between, it pretends you did a line selection if you delete or yank
<Cheery>
then there are operator style motions, meant for selecting elements.
<Cheery>
anyway my plan is:
<Cheery>
hook lalr parser directly into the editor
<Cheery>
have bunch of cards you can move between, which together define the program.
<Cheery>
the cards come as 'links', in between the text.
<Cheery>
but they organize below the code.
<Cheery>
it's entirely curses program.
<Cheery>
planning to have few different editors there, with conversion modes between 'cards'
<Cheery>
but starting with code and text cards first. :)
alexgordon has quit [Quit: My iMac has gone to sleep. ZZZzzz…]
alexgordon has joined #elliottcable
yorick has quit [Remote host closed the connection]
alexgord_ has joined #elliottcable
<vigs>
ELLIOTTCABLE: No, I'm gonna learn C. I've got a Systems Programming class coming up that's supposed to be SUPER hard, so I figured I'd get a jump start now. Also, I'm in a phase where I'm super curious about systems programming so yay!
<vigs>
And it's the 1st Edition, not the 2nd. vil mentioned that the 2nd is updated with the ANSI standard and now I'm considering buying the 2nd if it's as cheap as the 1st Edition