ELLIOTTCABLE changed the topic of #elliottcable to: Embrace, extend, extuingish.
<devyn> hahaha
<devyn> -best north korea
<purr> NORTHKOREA IS BESTKOREA
<devyn> ↑ the classic
Rusky has joined #elliottcable
TheMathNinja has joined #elliottcable
<ELLIOTTCABLE> devyn: hah. 'k.
<purr\Paws> [Paws.js] ELLIOTTCABLE pushed 1 new commit to Master: https://github.com/ELLIOTTCABLE/Paws.js/commit/58fa5d8d1c67bdef231ebe567a388b0b9648b4c6
<purr\Paws> Paws.js/Master 58fa5d8 elliottcable: (!! lib syn) Use brackets-based cPaws...
Rusky has quit [Quit: Leaving.]
thsutton has joined #elliottcable
Rusky has joined #elliottcable
<ELLIOTTCABLE> thsutton: o7
<thsutton> g'day
<ELLIOTTCABLE> I'm not completely sure what's up with the 'pref' command
<ELLIOTTCABLE> everything else on that page is pretty well-corroborated through my research, so far.
<ELLIOTTCABLE> protip, `--8192` when `brew install gpg2`'ing
<thsutton> Yeah, I think this is going to do exactly what I want (mostly just recover from lost phone or laptop easily).
Rusky has quit [Ping timeout: 255 seconds]
Rusky has joined #elliottcable
<ELLIOTTCABLE> yeah. that article is great. very great content.
<ELLIOTTCABLE> protip, imageoptim.app for the addphoto
<ELLIOTTCABLE> and resize it to be small. 100x100 perhaps.
<ELLIOTTCABLE> just enough to recognize you.
<thsutton> Do you know if you can add a photo after the fact? Or will that invalidate existing signatures?
<purr\Paws> [Paws.js] ELLIOTTCABLE deleted release-4 at 48ab490: https://github.com/ELLIOTTCABLE/Paws.js/commit/48ab490
<ELLIOTTCABLE> hm
Rusky has quit [Client Quit]
<ELLIOTTCABLE> thsutton: you can definitely modify a key in all sorts of ways.
<ELLIOTTCABLE> the metadata of a key doesn't affect the signatures of the key. it's metadata.
<thsutton> Cool. I probably won't bother with addphoto at first then; if for no other reason than that I have no photos. :-)
Rusky has joined #elliottcable
<ELLIOTTCABLE> the changes can then be pushed to keyservers, and are globally "associated" with your UID (by way of the key's hash)
<ELLIOTTCABLE> afaict
<thsutton> Cool. Should I use gpg or gpg2? In general and from homebrew in particular.
<ELLIOTTCABLE> the latter
<ELLIOTTCABLE> in fact, install both.
<ELLIOTTCABLE> the latter is better for all your user-facing tasks (`gpg2 --blah` is generally what you want to type),
<ELLIOTTCABLE> but lots of software assumes the former for actually verifying / generating signatures. You can think of it as the API package.
<ELLIOTTCABLE> (`git` in particular uses `gpg` when generating signed tags.)
<thsutton> Cool.
<purr\Paws> [Paws.js] ELLIOTTCABLE tagged r4 at 1c0e724: https://github.com/ELLIOTTCABLE/Paws.js/commits/r4
<thsutton> You looked into hardware integration (smartcards, etc.) at all?
<ELLIOTTCABLE> i totes love github
<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> I'd avoid listening to eligrey :P
<eligrey> + crouton w/keepass
<eligrey> or whatever native keyring you prefer
<eligrey> chrome os runs on your macbooks ELLIOTTCABLE
<eligrey> best open linux distro
<thsutton> Oh, that.
<ELLIOTTCABLE> devyn: give me admin access to Paws.rs, and I'll add a hook, since I've got this interface open
<thsutton> Thanks for the link.
<thsutton> Thanks for the tips ELLIOTTCABLE. The gym calls.
<ELLIOTTCABLE> o7
<ELLIOTTCABLE> lurk moar.
<thsutton> will do
thsutton has quit [Quit: Away]
Rusky has quit [Remote host closed the connection]
Rusky has joined #elliottcable
<purr\Paws> [Paws.js] ELLIOTTCABLE pushed 1 new commit to Master: https://github.com/ELLIOTTCABLE/Paws.js/commit/5e49d1f9248b3f2c7b200252f784785bf180b062
<purr\Paws> Paws.js/Master 5e49d1f elliottcable: (- doc new) Name the current version
Rusky has quit [Quit: Leaving.]
Rusky has joined #elliottcable
Rusky has quit [Client Quit]
gozala has quit [Quit: Connection closed for inactivity]
TheMathNinja has quit [Ping timeout: 260 seconds]
<devyn> ELLIOTTCABLE: I could just move it to github.com/Paws, but apparently I need admin access on Paws to move a repo
<devyn> there
<devyn> github.com/Paws/Paws.rs, I mean
<devyn> ELLIOTTCABLE: but yeah you know GitHub has 'transfer ownership' right?
<devyn> it handles setting up redirects for you and everything
<ELLIOTTCABLE> nah, keep it under your account
<ELLIOTTCABLE> it's your work and all
<devyn> okay
<ELLIOTTCABLE> but *fork* it to Paws/, and make sure Paws/* stays up to date with releases.
<devyn> I'll give you admin access then
<devyn> okay
<ELLIOTTCABLE> don't have to push all branches or all Master commits; just all tags.
<ELLIOTTCABLE> that's what I do for Paws/Paws.js
<devyn> ok, sur
<ELLIOTTCABLE> some day, might move it. I doubt it.
<devyn> sure*
<joelteon> is anyone here with TomL
<joelteon> or TOML
<joelteon> or however it's written
<ELLIOTTCABLE> think you have to add me as an owner, maybe
<ELLIOTTCABLE> not showing up for me
<devyn> ELLIOTTCABLE: how can I add you as an owner… I don't know if that's even possible
<devyn> no it's not
<devyn> you can't add webhooks?
<devyn> PM the hook info and I can just set it up myself
<ELLIOTTCABLE> just use my script
<ELLIOTTCABLE> same thing I always use for new projects
<ELLIOTTCABLE> can remove the OTP stuff if you don't have 2fa set up
alexgordon has quit [Quit: My iMac has gone to sleep. ZZZzzz…]
<ELLIOTTCABLE> change the json to:
<ELLIOTTCABLE> "room": "#ELLIOTTCABLE"
<ELLIOTTCABLE> "nick": "purr\\Paws",
<ELLIOTTCABLE> yeah, double slashes, JSON escaping
<ELLIOTTCABLE> (=
<ELLIOTTCABLE> so, thoughts
<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.
<purr\Paws> [Paws.js] ELLIOTTCABLE pushed 2 new commits to Master: https://github.com/ELLIOTTCABLE/Paws.js/compare/5e49d1f9248b...ce583c4ed86e
<purr\Paws> Paws.js/Master ce583c4 elliottcable: (- fix fun) Restrict the salutation to SIGINT exits
<purr\Paws> Paws.js/Master e7062f3 elliottcable: (doc re) Majorly refactor usage-text
<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> does that make sense?
<ELLIOTTCABLE> reallllly interesting question re: "consumers' consumers"
<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]
<purr\Paws> [Paws.rs] devyn pushed 1 new commit to master: https://github.com/devyn/Paws.rs/commit/a5e3f5c5883b428cbfb33b3a6e557d9cceb3be44
<purr\Paws> Paws.rs/master a5e3f5c Devyn Cairns: Add huge hack to make Alien clone()able
<devyn> I can't believe it even works
<devyn> lol
<purr> lol
<purr\Paws> [Paws.rs] devyn pushed 1 new commit to master: https://github.com/devyn/Paws.rs/commit/9c117027541bf0a55250931264927f42152447cc
<purr\Paws> Paws.rs/master 9c11702 Devyn Cairns: Make Object implement AnyRefExt and AnyMutRefExt
Guest45674 has quit [Ping timeout: 244 seconds]
<purr\Paws> [Paws.rs] devyn pushed 1 new commit to master: https://github.com/devyn/Paws.rs/commit/d255bbbca53192b509011c57d4c9be88ca5db18e
<purr\Paws> Paws.rs/master d255bbb Devyn Cairns: Move as_any() and as_any_mut() downward in order to de-emphasize their importance and usefulness
<Cheery> ELLIOTTCABLE: I'm implementing a language, because it's devilishly hard to try it out if there's not an implementation.
<Cheery> the implementation affects language design though, yes.
<ELLIOTTCABLE> devyn: push less commits at once :P
<devyn> ELLIOTTCABLE: lol
<purr> lol
<Cheery> implementation of things also clearly affects APIs.
<Cheery> it's the performance of things that forces them to roughly following the shape of the underlying layer.
Willox has joined #elliottcable
<Willox> Someone wanted some source engine exploits
<purr\Paws> [Paws.js] ELLIOTTCABLE pushed 1 new commit to Master: https://github.com/ELLIOTTCABLE/Paws.js/commit/ccef5652d31082ecffb9e716588027827f830955
<purr\Paws> Paws.js/Master ccef565 elliottcable: (new lib syn) Parse quoted labels
<ELLIOTTCABLE> devyn: so, that's done.
<ELLIOTTCABLE> this [is] [now] "cPaws code"
<ELLIOTTCABLE> my implementation is terrible. micah's parser is clever, but I'm bad at maintaining it.
<ELLIOTTCABLE> probably going to rip it out and just use a parser-generator. /=
<ELLIOTTCABLE> at the very very least, I need to write **extensive** tests for that.
<ELLIOTTCABLE> Paws code.
yorick has joined #elliottcable
alexgordon has joined #elliottcable
<Cheery> I got my stack tangled.
<Cheery> sort of happy because it's the most complex piece in my vm
<Cheery> I have to concentrate on it next. ^^
Willox has quit [Quit: Connection closed for inactivity]
oldskirt has quit [Ping timeout: 272 seconds]
oldskirt has joined #elliottcable
joelteon has quit [Quit: ZNC - http://znc.in]
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]
sharkbot has joined #elliottcable
joelteon has joined #elliottcable
joelteon has quit [Quit: ZNC - http://znc.in]
joelteon has joined #elliottcable
joelteon has quit [Quit: ZNC - http://znc.in]
joelteon has joined #elliottcable
Guest45674 has quit [Ping timeout: 255 seconds]
yorick has joined #elliottcable
eligrey has quit [Quit: Leaving]
eligrey has joined #elliottcable
joelteon has quit [Quit: ZNC - http://znc.in]
Guest45674 has joined #elliottcable
oldskirt has quit [Ping timeout: 240 seconds]
oldskirt has joined #elliottcable
Guest45674 has quit [Ping timeout: 260 seconds]
oldskirt has quit [Ping timeout: 240 seconds]
yorick has quit [Read error: Connection reset by peer]
joelteon has joined #elliottcable
joelteon has quit [Client Quit]