<ELLIOTTCABLE>
thsutton: yes; I suggest a yubikey pro
<ELLIOTTCABLE>
or whatever the higher-level version is called.
<ELLIOTTCABLE>
it takes a little fucking around, but it can be re-flashed (sort of. it actually just takes a command that makes it change itself.) into a SmartCard-ish mode. Then it can run SmartCard software, over USB.
<ELLIOTTCABLE>
no need to have a smartcard reader around or anything, just stuff this featherweight little piece of plastic into a USB port on any computer and do your stuff.
<ELLIOTTCABLE>
grain of salt and all that, I've never successfully done so (although I *did* have, and use, a YubiKey for other purposes for a very long time).
<eligrey>
i just use authd phone proximity
<eligrey>
for everything
<eligrey>
authed*
<thsutton>
Yeah, I've used Yubikey a little (just the original OTP & stored password model) when I got one in the LCA swag a few years back.
<thsutton>
eligrey: Google fails me, do you have a link?
<ELLIOTTCABLE>
requirements for IPP are surprisingly similar to requirements for freezing, in terms of changes to the runtime semantics.
<ELLIOTTCABLE>
basically, if I say "take this library and freeze it",
<ELLIOTTCABLE>
it means run the reactor as long as there's combinations to process, but *don't* actually schedule deferred stuff, disk-changing stuff, network-dependant stuff …
<ELLIOTTCABLE>
same things the IPP does.
<ELLIOTTCABLE>
when all the combinations that can possibly be done are completed, and no more have been added (since any that would be deferred until a network request gets back, or a request comes in, or a disk responds, or … etc, will never be staged),
<ELLIOTTCABLE>
we can freeze the entire data-graph
<ELLIOTTCABLE>
and along the way, any of those things that *were* ignored, can also be frozen, to be re-invoked / queued / whatever, the moment it's unfrozen ('loaded')
<ELLIOTTCABLE>
all of this could be abstracted out of the IPP / freezing mechanism, and actually specified, to be used by both (and whatever else.)
<ELLIOTTCABLE>
basically, breaking down infrastructure/implementation aliens, into two categories: delayed (ones that do something that might be delayed, and thus shouldn't be invoked pre-freezing), and immediate (ones that affect only the data-graph or runtime environment in some way, and thus should be invoked pre-freezing)
<ELLIOTTCABLE>
when in "safe" mode, whether it's because we're about to freeze the Unit, or because we're scanning code for preprocessor instructions, combinations that would invoke such ‘delayed’ operations would be stored in their own queue; and that queue would not be executed by any reactor
<ELLIOTTCABLE>
in the former case, then, that queue would be serialized into the frozen Unit, and it would *become* the queue when unfrozen (thus, all those actions would immediately be spun-off to occur, setting up whatever servers or requesting data or … etc.)
<ELLIOTTCABLE>
in the latter case, they'd simply be discarded
<devyn>
ELLIOTTCABLE: IPP = ?
<ELLIOTTCABLE>
interpretative preprocessor.
<devyn>
ok
<ELLIOTTCABLE>
th'whole live-syntax thing.
<devyn>
mmhm
<devyn>
I still have no idea how you're going to accomplish that
<ELLIOTTCABLE>
how so?
<ELLIOTTCABLE>
seems pretty straight-forward.
<ELLIOTTCABLE>
it's basically a compilation step.
<ELLIOTTCABLE>
big part of why frozen units are great: none of that business. All of the syntax is already *read in*, and all of the changes-to-how-syntax-are-handled, for future code, are already determined and frozen in.
<ELLIOTTCABLE>
the *only* remotely unusual part, is the part described above (that of "blocking off" code-routes that mutate the greater environment of the program) … and we need that **anyway** for freezing! so IPP is basically design-free.
<devyn>
ELLIOTTCABLE: okay but how do we modify the syntax while processing it?
<devyn>
not sure I understand
<ELLIOTTCABLE>
it's not *simultaneous*, it's in stages.
<ELLIOTTCABLE>
interpret-using-current-syntax, until a point is reached where a new syntax-changing rule is known,
<ELLIOTTCABLE>
then abort and reinterpret from the start.
<ELLIOTTCABLE>
means:
<ELLIOTTCABLE>
- the IPP's parser must be a streaming parser, because we can't have it throwing up on an unmatched < later in the file, when earlier in the file there is a rule that changes the rules parsing that,
<ELLIOTTCABLE>
- users must not *use* a syntax until later in the file after it has been defined, unless A) that syntax properly *parses* without errors in the 'previous' syntax-iteration, even if the semantic meaning changes, **and** B) the location in which the syntax appears and is mis-parsed, is not executable at preprocess-time (i.e. inside an if-block or server-block
<ELLIOTTCABLE>
or something)
<ELLIOTTCABLE>
A+B being rare, unless you're insane. easier to just define syntaxes before using them.
<ELLIOTTCABLE>
a *lot* of this won't come into play, in general use.
<ELLIOTTCABLE>
honestly? it's mostly a learning thing.
<ELLIOTTCABLE>
when you're teaching somebody to write syntaxes (or, more generally, "teaching somebody to write their own language" to make themselves happy … which every single Paws tutorial, documentation, book, or anything else, should be doing, IMO),
<ELLIOTTCABLE>
it's simpler if they can write inside a REPL, or inside a single test file while they're learning,
<ELLIOTTCABLE>
define what <foo> means \n use <widget>
<ELLIOTTCABLE>
but even then, it only becomes multi-pass (instead of single-pass to determine that there *are* no IPP instructions) for particular files
<ELLIOTTCABLE>
and once those are evaluated, that stuff is frozen: those syntactic rules apply to consumers of that library, without any multi-pass weirdness.
<ELLIOTTCABLE>
realistically, I think this is all completely do-able / sane, as many jokes as I may make about me being insane and wanting to run files hundreds of times before you even see any output and blahblahblah
<ELLIOTTCABLE>
-h8rs
<purr>
ELLIOTTCABLE: gon' h8
<devyn>
does the Unit reset, minus syntax rules, every time?
<devyn>
also, syntax rules apply to consumers of the library… what about consumers of the consumers of the library?
<ELLIOTTCABLE>
"Reset"?
<ELLIOTTCABLE>
that would only be an issue with per-*file* syntax rules (I want scoped syntax rules, for sure; I don't have specifics nailed down in my head, yet, but probably some sort of block-syntax / block-defining thingamajigg)
<ELLIOTTCABLE>
and basically, it'll always be Good Practice to avoid the raw, line-text-modifying (or worse, entire-file-text-modifying) machinery
<devyn>
well like do locals/system/whatever reset?
<ELLIOTTCABLE>
and if you *have* to use it, then you're clearly doing something so powerful/insane/weird, that it's almost certainly going to be majorly compatible with unaware consumers *anyway*.
<ELLIOTTCABLE>
the locals for stuff that's already begun to execute in the unit, don't change.
TheMathNinja has joined #elliottcable
<ELLIOTTCABLE>
in the most usual case, you'll have *procedures* exported by Units, and thus you'll clone-and-call those as normal (so there's nothing particularly "frozen" coming into play)
<ELLIOTTCABLE>
canonical example, for me; the one I'm always thinking about when designing dynamic-syntax stuff:
<ELLIOTTCABLE>
"I want to write a syntax, in which I can nest delimiters."
<ELLIOTTCABLE>
that's, when you think about it, a *really* heavy-handed task, one that requires a lot of power out of the system.
<ELLIOTTCABLE>
for instance, let's say the base syntax you're working in doesn't have any double quotes.
<ELLIOTTCABLE>
it *does*, however, have parentheses.
<joelteon>
so i went to san francisco to buy a pair of shoes and i got the wrong size
<joelteon>
so now I have to go back and exchange them
<ELLIOTTCABLE>
now, I want to define double-quotes such that I can do the following, without changing the otherwise-existing semantics of parenthesis *outside* of double-quotes:
<ELLIOTTCABLE>
"hi ("
<ELLIOTTCABLE>
for stuff like that, that straight-up breaks common semantics from an earlier abstraction-layer, you may have to resort to doing the whole parsing of the file (or at least of the line) yourself.
<devyn>
ELLIOTTCABLE: hmm I'm still not exactly sure how the rules propagate. obviously we want different libs to be able to use completely different syntaxes, since that's one of the goals to begin with
<ELLIOTTCABLE>
errrrrrrrrrr,
<ELLIOTTCABLE>
feels to me like asking,
<ELLIOTTCABLE>
"how does the value of 'bar' in library Widget propagate, when you use MyCoolLib which includes Widget?"
<ELLIOTTCABLE>
hm. so this'll take some discussion of Unitary semantics *in general*, not just in terms of syntax.
<ELLIOTTCABLE>
ignoring syntax for a second:
<devyn>
ok
<ELLIOTTCABLE>
as it's going in my head right now, this is sort of what a "library" feels like in Paws.
<ELLIOTTCABLE>
user does <not defined by system> action to link a unit for "Widget" to their unit
<ELLIOTTCABLE>
ugh, definitely not as well-defined in my head as I usually hope
<ELLIOTTCABLE>
user does `acquire Widget, 'foo'`-y kinda thing.
<ELLIOTTCABLE>
syntax, specifics of that, whatever, are very nebulous, so, grazing over and moving on
<ELLIOTTCABLE>
lol
<purr>
lol
<ELLIOTTCABLE>
Widget called into the implementation to register (“export”, ish) 'foo', with code to be invoked when somebody's trying to acquire a capability for 'foo'
<devyn>
okay, so do syntax rules basically work like that?
<devyn>
would they be named?
<devyn>
would you do something like import-syntax?
<devyn>
I dunno
<devyn>
lol
<purr>
lol
_ has joined #elliottcable
_ is now known as Guest45674
TheMathNinja has quit [Ping timeout: 255 seconds]
<ELLIOTTCABLE>
sorry lololol
<purr>
lololol
<ELLIOTTCABLE>
devyn: basically, the exporter has control in the case of semantics, and should also have control in the case of syntax.
<ELLIOTTCABLE>
I'm imagining that at-export-check-time, i.e. when the foreign unit is running the can-i-generate-a-capability code, the library can also register preprocessor-API code (presumably, the same code it ran on itself?) for the foreign unit.
<ELLIOTTCABLE>
thus, at preprocess-time, when these acquisitions are also being run, that preprocessor-API code would be run.
<ELLIOTTCABLE>
definitely needs a lot more thought.
<ELLIOTTCABLE>
this is why I focus on one element of the design at the time, and then later focus on integrating the next part with the already-fairly-solid definition of the former parts :P
eligrey has quit [Read error: Connection reset by peer]
yorick has quit [Read error: Connection reset by peer]
joelteon has joined #elliottcable
joelteon has quit [Client Quit]
katlogic has quit [Ping timeout: 240 seconds]
katlogic has joined #elliottcable
<devyn>
ELLIOTTCABLE: awesome, are you going to make the 'system' change too?
<devyn>
ELLIOTTCABLE: also you should see my Executions' program counter, haha... it's just a vector of integer indices into the structure rather than a ref to a particular node, lol
<purr>
lol
<devyn>
I like that [] contrasts better with {} than () does
eligrey has joined #elliottcable
alexgordon has quit [Ping timeout: 255 seconds]
alexgordon has joined #elliottcable
Guest45674 has joined #elliottcable
sharkbot has quit [Remote host closed the connection]