<ec>
Wow, that did a thoroughly good job of having *nothing* to do with *either* of those things.
<Nuck>
I want to go spam /mlp/ with this now
<ec>
… 4chan has a brony board now!?
<ec>
anyway
<Nuck>
Yes. It's where the creepiest bronies live
<Nuck>
They discuss their fluttershy sex dolls all day :I
<ec>
whitequark: I'd love to talk to you some time about the concurrency mechanism I've got.
<Nuck>
(with pictures of it in use)
<whitequark>
ec: btw, I just understood it
<ec>
I don't know anything interesting going on in the PLT field, I don't have the background to understand most of what I come across, so I've ended up ignoring most of it
<whitequark>
your continuations are, well, not.
<ec>
oh, absolutely not
<ec>
I was realllllly against calling them continuations
<whitequark>
what you have is... *drumroll*
<whitequark>
fibers.
<whitequark>
or threads
<ec>
they sued to be called executions; and they're closer to first-class program-counters
<ec>
nope, those neither
<whitequark>
depending on how are they preempted.
<Nuck>
>sued
<whitequark>
ec: how so?
<Nuck>
Is ec saying that a programminc concept sued him?
<Nuck>
oooooh used
joelteon has quit [Ping timeout: 276 seconds]
<ec>
Nuck: wat
<Nuck>
ec: >they sued to be called executions
<purr>
lol
<ec>
oh lol oops
<ec>
thx purr
<Nuck>
I actually read that as a legal briefing
<whitequark>
LOL
<whitequark>
LOL.
<whitequark>
LOL!
<ec>
“They're suing to called executions; it's becominh a real problem”
<whitequark>
purr: fuck you.
<Nuck>
loli
<Nuck>
:(
* ec
laughs
<ec>
whitequark: he doesn't love you enough
<Nuck>
I miss when I could discuss loli and purr would loli back at me
* ec
snuggles up close to purr
* purr
rrrr
<Nuck>
purr: hi
<purr>
Nuck: hi!
<ec>
purr: i love you
<purr>
ec: thank you! ^_^
<Nuck>
purr is the best bot ever.
* ec
cries a little
<ec>
purr is my best friend ;_;
<Nuck>
purr is mai waifu
<whitequark>
if your best friend is a bot...
<whitequark>
duh, your life is still better than Nuck's
<Nuck>
;_;
<ec>
Oh my god.
<ec>
Your first entry on the quotesblog.
<ec>
Welcome to #ELLIOTTCABLE.
<Nuck>
haha
<Nuck>
Hm
<Nuck>
I don't assume any of you could proofread my Udev rule and tell me what I'm doing wrong
<whitequark>
I could
<whitequark>
but I won't
<Nuck>
:(
<whitequark>
mwahaha
<Nuck>
All I want is for my backlight to fucking work well, but no, Udev has to piss all over my parade
<ec>
But instead of always pointing to the *start* of the code-block, they move-forward as the code-block is executed
<ec>
so any time the code-block is exited or otherwise paused, they're still “pointing” to the last location the code-block was executed-up-until.
<ec>
waive the wishy-washy wording.
<ec>
have always been terrible at explaining this, for years
<ec>
the best explanation I've ever been able to come up with, short of simply thoroughly expressing the implementation details … is “They're continuations, but instead of always pointing at the place they were ‘taken’ like call_cc() might, they move-foward every time they're called.”
<ec>
or, as inimino once put it, “They're program-counters *as an object* that you can pass around.”
Determinist has quit [Ping timeout: 248 seconds]
<whitequark>
ec: well, the whole point of (regular) continuations is that they're multiple-entry
<ec>
yes, I know
<whitequark>
if they're not, it's a fiber.
<ec>
this is an even-lower-level building block
Determinist has joined #elliottcable
<whitequark>
or coroutine (same thing).
<ec>
nonono
<ec>
these can build coroutines *or* continuations.
<ec>
if you take one and clone it, and hold on to the clone before calling the original again, then you have a “continuation.”
<whitequark>
if you can duplicate coroutines complete with internal state, you have a continuation ;)
<ec>
You can continue cloning-and-calling as many times as you want.
<whitequark>
so
<whitequark>
fiber.dup # => you just made yourself a continuation.
<whitequark>
(kinda)
<ec>
if you have one that hands itself off to other things when it needs a value, then you have something like a coroutine.
<ec>
it's a lower-level program-flow building block that can do any/all of the above
<whitequark>
ec: there's just one thing which needs to be verified
<whitequark>
if the answer is yes, well, you have coroutines.
<whitequark>
if the answer is no, you don't, and this is likely very bad
<whitequark>
where is the internal state?
<ec>
“if yes, this; if that, no … <non-boolean question>”
<whitequark>
... ok, not a yes/no
<ec>
sorry, what do you mean by internal state?
<ec>
there is no internal state. Code doesn't carry state.
* whitequark
nods
<whitequark>
code doesn't
<ec>
There's nothing like scoping (lexical or dynamic), variables, or anything else
<whitequark>
you know what a coroutine is?
<ec>
there's no “functions” carrying around internal state
<whitequark>
pc+stack.
<ec>
all of the state is completely global to one of these ‘units’
<ec>
there's no stack, either
<whitequark>
pc, I see here.
<whitequark>
how do you hold temporary results of evaluation?
<ec>
Paws has no returning
<ec>
if you want somebody to have a “previous caller” to “return” to, then that caller has to *give* themselves to you, to call back to.
<ec>
it's a pattern we call coproduction
<ec>
or coconsumption
<whitequark>
whatever
<ec>
depending on which side you look at it from.
<whitequark>
if paws has values, it has to hold them somewhere
<ec>
yes, data-graph. Like I said, all one big global state-graph
<ec>
the thingie with all that ugly locking ;)
<whitequark>
so basically
<whitequark>
if you want to replicate something like lexical scoping on top of paws
<whitequark>
then you duplicate a scope each time you entry into one?
eligrey has quit [Quit: Leaving]
<ec>
something like that
<ec>
depends on how you want to do it
<ec>
the “language” you're hearing about here is basically a high-level VM
<whitequark>
this way a pc implicitly addresses the state, yeah
<whitequark>
it's fairly low-level :p
<ec>
*everything* you want, is supposed to be implemented as a tower of abstraction on *top* of this.
<ec>
hahaha
<whitequark>
and your continuations are indeed coroutines
<ec>
it's high-level in that it doesn't have a bytecode
<whitequark>
you can name them so :p
<ec>
i.e. higher-level than LLVM.
<whitequark>
or fibers, whatever you like
<whitequark>
LLVM is not a VM.
<whitequark>
it's a compiler IR. nothing more nothing less
<ec>
also a high-level VM in that it's not *compiled* into, it's *abstracted* into
<whitequark>
same shit
<ec>
at some level, Paws programs are still Scripts after all of the syntax-sugar-magic
<ec>
nah, not at all
<whitequark>
I can write a paws-processor
<whitequark>
not even that hard.
<ec>
meaning, evaluator/interpreter/whatever? or
<whitequark>
hardware thingy
<whitequark>
something something verilog
sharkbot has quit [Remote host closed the connection]
<ec>
writing a Paws interpreter definitely should not be hard
sharkbot has joined #elliottcable
<ec>
especially at this point, sans distribution or time-travel
<whitequark>
the challenge is in making it efficient :p
<ec>
prob's
<ec>
outside my purview or interest
<ec>
I'm here to design a language. I don't have the knowledge, skills, or even *interest* to design a *fast* language. It's up to other people, should that ever become necessary, to make it fast. I'll happily take tips and pointers along the way to make it *more* make-fast-in-the-future compatible … but not at the expense of any of the aspects I care about.
<whitequark>
fundamentally broken approach
<ec>
verilog?
<whitequark>
IF
<whitequark>
you want to design a practical language.
<ec>
disagreed
<ec>
but an argument for another time
<whitequark>
(verilog) google it
<whitequark>
(languages) it's quite evident in ruby
<ec>
I did
<ec>
over my head
<whitequark>
a language for designing processors.
<whitequark>
it's... parallel by default
<whitequark>
like that.
<ec>
Ruby's an excellent language. If I ever achieve anything even remotely close to Ruby, I'll be happy as a tit.
<whitequark>
ruby's meh.
<whitequark>
it definitely gets some things right. it gathers the best parts of smalltalk.
<whitequark>
it has EXCELLENT metaprogramming. I'd say better metaprogramming than in lisp.
<ec>
THANK YOU
<whitequark>
however
<ec>
but, moving on
<whitequark>
well, ok
<Aria>
OH GOD NO RUBY METAPROGRAMMING IS MOSTLY EVIL
<Aria>
Need hygenic macros to do it right.
<whitequark>
not sure why the idea of lexical expansion is so prevalent.
<ec>
not this argument, not right now ;_:
<ec>
looking for constructive feedback on my design-work.
<whitequark>
it seems almost an antipattern to me, lately.
<whitequark>
Aria: read an article about vau calculus
<whitequark>
<3
<whitequark>
the vau calculus itself is totally shit, but the thesis is excellent
<whitequark>
ec: yeah yeah, gimme
<whitequark>
I'll just say that making a fast language is extremely hard even if you have it as a major design goal. You have to have a LOT of experience, bake it in the core of the language
<whitequark>
and yet you will likely fail
<whitequark>
more correctly... fast and predictable.
<whitequark>
JS is fast these days, but you have no idea why or how.
<whitequark>
fuck that.
<whitequark>
ec: gimme the design to comment on already!
<whitequark>
before parsing ruby gets the best of me
<ec>
whatcha mean
<ec>
sorry, still working on the spec
<ec>
yeah, agreed
<ec>
re: fast language
<ec>
which is exactly why I'm not doing that
<ec>
First, making a fast language is *extremely uninteresting* to me. I don't believe fast languages lend themselves to the horizontal, which is the direction I'm interested in.
<ec>
Second, making a fast language requires *ten times the knowledgebase* that making a <any-other-positive-aspect>† language does.
<ec>
Someday, I hope, to make a language that's somehow interestingly-fast.
<whitequark>
agreed
<ec>
But at this young point in my “language-design career”, so to speak; my very first *real* language, I've got more important things to focus on.
<ec>
So, back to my original stance: I'll happily take advice. “That's stupid, that will make optimizing later nearly impossible.” “If you can, design for <this, this and this>”
<ec>
I got a lot of advice to that effect from alexgordon, prophile early on.
<whitequark>
good.
<ec>
anyway. I'm genuinely concerned about your perception of the concurrency mechanism.
<ec>
Concurrency is not a *huge* aspect of the design-goals for the language … it's not as big as the asynchronicity or distribution, at least … but it's important to me. Not for speed, but for the asynch. no-blocking. etc.
<ec>
it's a programming model I believe in, and if the concurrency is inherently yuck-ridden and broken and slow, I need to start thinking through alternative models that I can drop-in now, not later.
<whitequark>
ok.
<whitequark>
explain it to me, together with async and federation
<whitequark>
or, the bits of those which you know.
<ec>
federation ain't done yet
<ec>
asynch is what you've already heard described.
<ec>
there's no returning. that was the very first, very last, and most important design-aspect.
<ec>
wanted a truly stackless language, with true CPS baked right in.
<ec>
you never “call” another function, you only resume a continuation … you never “return” to your caller, you resume the continuation they gave you … etcetcetc.
<whitequark>
mhmm
<whitequark>
error handling?
<ec>
error handling started out undefined
<ec>
been working slowly on a plan we had a couple years ago, it's basically “time travel within the language”
<whitequark>
because, well, traditional way to combine error handling with CPS is, basically
<whitequark>
to have callbacks and errbacks
<whitequark>
the huge gaping problem with this way is that a) no one writes errbacks
<ec>
nonononono
<whitequark>
b) it doesn't exactly compose.
<ec>
I don't want a language where errors happen.
<whitequark>
wat
<ec>
Every single “error handling” system I've ever seen is complete bullshit and makes me sick
<ec>
errbacks, exception-throwing, blah de fuckin' blah
<ec>
tentative goal here:
<whitequark>
there's CL's resume system
<ec>
reversible operations, reverting entire trees of operations; but retaining some bounded set of the data-graph *disallowing* reversions … the goal being using those building-blocks to build error-handling systems wherein the code that *KNOWS ABOUT* the error can go back and propose alternative solutions to the code that *NEEDED SUCCESS*
<ec>
if that makes any sense at all
<ec>
not familiar with common-lisp at all; only Lisp I'm remotely familiar with is Scheme
<whitequark>
hah
<whitequark>
what you invented is at least somewhat close to CL's resumes
<ec>
know the R6RS pretty well. Need to go back and learn R5RS since nobody seems to care about R6RS.
<whitequark>
basic idea
<whitequark>
you are neck deep in some code in CL
<whitequark>
you wanted to call (car list)
<whitequark>
however you typoed and called (caw list)
<whitequark>
oh shit what happens?!?!?!
<whitequark>
and what happens is that the operator (yes human) gets a prompt saying: "A function called caw was called, no such function exists. What to do?
<whitequark>
a) call function: [it asks for the name]
<whitequark>
b) abort
<whitequark>
c) go into a REPL
<whitequark>
now, it isn't very meaningful to expect that a human will sit there all the day
<whitequark>
so you can also invoke these programmatically.
<whitequark>
and you make sense from errors with pattern matching, or so I'd guess.
<whitequark>
oh, sorry, wrong name... they're called restarts
<whitequark>
not resumes.
<whitequark>
restarts are fucking awesome and it's cool that you've invented them
<whitequark>
no language I know except CLs is even close to implementing them.
<ec>
sorry reading
<ec>
'ppreciate it
<ec>
obviously, yet more insanely slow implementation problems
<whitequark>
not really
<ec>
so tips as to how to tweak the design so optimization *may be possible* later, are always cool
<whitequark>
this can be fast
<whitequark>
but
<ec>
storing reversibleness-information for every operation,
<whitequark>
there's a worse problem.
<ec>
ensuring that changes within a reversible section aren't visible to the unreversible sections of code,
<whitequark>
ec: I'm going to show you something incredibly cool.
<ec>
which I've actually got designed pretty awesomely
<ec>
all of this ties in *really* beautifully with the execution-model I've got
<whitequark>
I have to admit
<ec>
readlater'd
<whitequark>
even with all my systems- and languages- knowledge
<whitequark>
I have no fucking clue how that thing works
<whitequark>
or how it can *EVER* work
<whitequark>
or how it can be not slow as to take years
<whitequark>
even if it works at all, which it shouldn't.
<whitequark>
readlater'd... ok I'll tell you tl;dr
<ec>
no, skimming now
<ec>
lol is dat some powerline
<purr>
lol
<whitequark>
you run your program and record it with a "video recorder". later, you can navigate that recorded stuff back and forth, as long as you want, without significant perf penalty
<whitequark>
yeah
<whitequark>
time machine.
<whitequark>
...
<ec>
hard to believe there's no performance penalty
<ec>
but yeah
<ec>
I've kinda naïvely designed this with things that seem obvious to me to be optimization-enablers.
<whitequark>
so.
<whitequark>
it seems that you may be onto something with your time travel.
<whitequark>
reversible debugging is also a thing
<whitequark>
where you step backwards with a debugger
<ec>
No ability to *explicitly* roll back-and-forward in time; only reversion to particular moments
<whitequark>
yeah yeah
<ec>
no ability to roll back when you haven't previously marked a section as roll-backable,
<whitequark>
this is what you do if you can't unwind stack.
<whitequark>
because there's no stack
<whitequark>
or, rather, there is no *explicit* stack
<whitequark>
because you still have implicit stack which is dispersed all the way around in stored data
<ec>
oh, there will obviously be an operation-history for time-travel
<ec>
explicit, not implicit in the data-graph or anything
<ec>
I'll go into more detail on my ideas later
<ec>
they're getting close to implementation
<ec>
actually, close *enough*, that I had to put work on them on hold
<ec>
because the implementation I had to work with, to try out my ideas and iterate with, was fucking disgusting and broken (you've seen the source)
jdhartley has joined #elliottcable
<ec>
current project is re-writing everything from scratch.
<ec>
in all of the technologies I hate, that are easy and quick and productive to work with.
<ec>
(CoffeeScript, npm, etcetcetc.)
<whitequark>
... which I won't touch.
<whitequark>
so
<ec>
then, once I've got it *cleanly* implemented and executing code at the current Stratum, I can go back to work on Bubbles (which are the implementation of time-travel)
<whitequark>
work on the damn spec ;)
<ec>
LOL
<purr>
LOL
<ec>
yep.
<ec>
between you and alex, I've perrrrdy much decided to complete a “spec” (or at least the half-arsed form of one you see in that google doc) for Stratum 10, *before* continuing work on Stratum 11.
<ec>
which is bubbles/time-travel.
<ec>
so, tentative time-line, obviously mitigated by real-life concerns over the next few months (… if you've been listening in here much …),
<whitequark>
next few? not sure
<ec>
is re-implementation running code @ Stratum 10, and spec for Stratum 10, within the next month. I'd like to imagine.
<whitequark>
cool
<ec>
if not then, whenever it *is* done, then I can personally start work on time-travel specification/specifics/re-design-whatevers-necessary, i.e. Stratum 11,
<ec>
and hopefully I can get alexgordon to simultaneously work on his *own* implementation of Strat-10.
<whitequark>
btw
<ec>
which should allow us to eventually/soon work on the distribution stuff!
<whitequark>
forget all I said about delimited continuations
<ec>
exciting times.
<whitequark>
your variant doesn't suffer from the problems of regular ones
<whitequark>
it's just cps
* ec
nods
<ec>
basically, since it's so fucking hard to *nicely* ape asynchronicity in a synchronous environment,
<ec>
Paws' entire fucking purpose is to try achieving asynchronous systems “from the other direction:”
<ec>
aping synchronicity in an asynch environment.
<ec>
synch abstractions on top of an inherently asynch/agnostic VM.
jdhartley has quit [Quit: Page closed]
<whitequark>
nah
<whitequark>
you didn't change anything
<whitequark>
cps is directly equivalent to synchronous code
<ec>
oh, scribe uses a custom kernel
<whitequark>
ec: syscalls
<whitequark>
gotta nail those fuckers somehow
jdhartley has joined #elliottcable
<whitequark>
ec: basically, paws is just as sequental as, say, ruby.
<whitequark>
but for each operation, you explicitly specify the next one, as opposed to it being implicit (next)
<ec>
woah, jdhartley
<ec>
jeannicolas: what's up!
<jdhartley>
hey guys
<ec>
whitequark: hm, not explicitly; it's all scheduled
<ec>
unless I'm misunderstanding you
<whitequark>
ec: this can make a HUGE difference to the *language*
<whitequark>
well, look at JS and what promises/generators/etc do with it... completely different thing
<ec>
speaking of which, you should definitely get in here with me and talk to micah about our diagonal-execution thing sometime
<whitequark>
but from the VM point of view
<whitequark>
this is completely irrelevant
<ec>
it's a direction I almost took Paws, then decided not to … micahjohnston's obsessed with it (in the best way :), and it's got interesting possibilities
<ec>
whitequark: not quite understanding.
<whitequark>
CPS is directly equivalent to sequental code.
<whitequark>
get your sequental code, attach goto to the tail of each instruction, bam, cps
<whitequark>
stepping to/away from CPS makes a huge difference when you have to write it by hand (callback hell, etc, etc)
<whitequark>
but for a VM it doesn't matter.
<ec>
on some level, I think I understand
<whitequark>
VMs almost always use CPS because it's convenient for mechanized transformation of code... in particular, optimization
<ec>
didn't know
<whitequark>
LLVM uses CPS. every VM which has explicit goto for control flow uses CPS
<ec>
jdhartley: are you really here? o_O
<ec>
jdhartley: what is this LYINGNESS.
<jdhartley>
ec: yeah man I figured I could use the company while I fix some shit I broke
<ec>
well hi!
<ec>
I'm having my programming language torn apart by more people who are smarter than me. That's always nice. ;)
<ec>
What're you fixing?
<ec>
whitequark: (JD's a friend from here in Chicago. He's rarely in here.)
<jdhartley>
I broke a lot of websites (namely my girlfriend's oops) the other day cause I did > instead of >=
<whitequark>
ec: the reason for using CPS is trivial. what people build on top of CPS is structured control flow... if, while, etc
<whitequark>
ec: do you know what's the manifesting feature of CPS? the fact that continuation calls *do not grow call stack*, in other words, they're *tail calls*, in other words again... they're directly equivalent to gotos
<joelteon>
all i see is a black rectangle
<ec>
gawwwwwd stagebloc is slow
<whitequark>
this also explains very neatly why your "continuations" only have pc
<ec>
whitequark: gotcha
Determinist has quit [Ping timeout: 240 seconds]
<ec>
I feel so bad for calling them continuations, especially if they're not even that
<whitequark>
so. you didn't solve asynchronity in any way... yet :)
<ec>
going back to calling them “executions”
<ec>
not seeing how-not
<whitequark>
executions, yeah... or coroutines :p
<ec>
point is, that every call has no returning
<jdhartley>
k if you refresh it is no longer a black rectangle oops.
<ec>
don't feel like coroutines to me.
<whitequark>
ec: no
<ec>
I, or any other normal programmer hears coroutines, they think “I define a routine, and I put call-me-with-another-value-<here>-holes into it.”
<whitequark>
ec: (coroutines) since they've no stack, I agree... let's call dem executions
<whitequark>
it's really a non-issue.
<whitequark>
ok.
<whitequark>
or "contexts".
<ec>
nonononono
<ec>
important to me, because I'm trying to learn from you here
<ec>
(in my own way)
<ec>
call it playing devil's advocate.
<whitequark>
ok, I'll elaborate then
<ec>
best way to teach Elliott, is to tell him how he's wrong.
<ec>
… but there's none of those holes in ours. *Every single word* in the routine is “call-me-with-a-value-<here>” place.
<ec>
micah calls them ‘holes.’
<whitequark>
coroutine, traditionally, is a tuple of (pc, stack), for a stack machine
<ec>
Coroutines, at least every use I've ever seen with them, basically scatter “arguments”-holes throughout the body of the function.
<whitequark>
however, you don't have stacks. you do not even have function calls, in the traditional sense
<whitequark>
ec: it doesn't matter and it is not a defining feature of coroutines
<ec>
I feel like you operate with a different definition of some of these terms than I do :x
<ec>
see, that's exactly what I mean!
<whitequark>
the defining feature of coroutines is that they suspend execution
<ec>
I care about what the end-user sees, and works with/plays with
<whitequark>
for holes
<ec>
so, yes, by implementer's-standards, or VM-designer-standards, they're probably coroutines
<ec>
but I don't feel like I could ever call them that in a “manual” as you called it
Determinist has joined #elliottcable
<whitequark>
well, it's a spec for implementers
<ec>
end-user-documentation.
<whitequark>
ah, it isn't
<whitequark>
well
<ec>
oh agreed
<whitequark>
executions, then
<ec>
the *spec* is for implementers. not arguing that again, right now, you're right enough for me
<ec>
BUT.
<ec>
I want to be *naming* things, what will make most sense for the end-user.
<whitequark>
awesome
<whitequark>
executions
<ec>
easiest to learn. Most natural-feeling. Most instant-I-know-what-that-is.
<ec>
lol you're bored with the conversation. get it. movin' on.
<purr>
lol
<whitequark>
executions or execution contexts, whatever's better for you
* ec
pats purr
* purr
r
<ec>
yeah “execution” has always been intended to mean exactly that
<whitequark>
I got my point to you.
<ec>
execution-context, “first class representation of *a particular execution* of that code.”
<ec>
wish I'd thought of “execution contexts” earlier.
<whitequark>
the reason coroutines almost always have "holes"
<ec>
would have been so much easier than typing “first class representation of *a particular execution* of that code.” all of the time when people asked what an execution was ;)
<ec>
go on
<whitequark>
is because you usually want to explicitly yield to something else to get some value
<whitequark>
but this is not necessarily so.
<whitequark>
for example, in embedded dev you often yield to another task because it has stuff to do on its own
<whitequark>
e.g. sound and video may do that
<whitequark>
consequentally, embedded implementations of coroutines do not necessarily have that "holes" feature.
<ec>
also: scheduling is pre-emptive here
<ec>
incase that weren't obvious.
<whitequark>
sure
<ec>
interesting. coroutines.
<whitequark>
an example would be Contiki
<ec>
I need to read some literature on this. Assuming I can dig through the mountains of whitepapers and find a few that I can get through my thick skull.
<whitequark>
it's otherwise a really shitty OS and it's probably the only time I found it useful
<whitequark>
this conversation that is
<ec>
wat
<ec>
skimming
<ec>
oh gods already Twitter Bootstrap
<whitequark>
don't :D
<joelteon>
twitter bootstrap sucks!
<joelteon>
i hate that fucking
<ec>
so.
<whitequark>
it's done by a dude who fucks the same embedded sensors based on avrs for ten years or so
<ec>
we kinda got off-track here. in general.
<whitequark>
and he's not particularly bright.
<whitequark>
but yeah
<ec>
didn't really get to cover anything else about Paws, except what I told you in answering your questions
<ec>
I should describe some of my thoughts on time-travel/bubbles and how it interacts with A) the data-graph, and B) executions
<ec>
in a similar way that we de-scribe boundaries around “at-risk data” in the *data*-graph with responsibility/ownership/locking/whatever,
<ec>
I want to de-scribe boundaries around “at-risk code” with bubbles.
<ec>
if some ‘infected’ code (that is, code within a time-travel-possible section) calls something *else*, then that something-else becomes infected;
<ec>
and data that is locked against from *within* that bubble-of-infection, never *appears* to become unlocked from outside it.
<whitequark>
your architecture is unique in the way that it doesn't map well in any aspect to von neumann OR harvard machines, ie all computers in existence.
<whitequark>
I start to like it
<ec>
yes, I know
<ec>
this channel's entire mandate is “Fuck vonn neumann”
<whitequark>
hah
<whitequark>
how is infection represented?
<whitequark>
is it transient?
<ec>
(i.e. if it's modified from within the bubble, it's never unlocked-for-read from *outside* the bubble, and thus any code that tries to … say, read data … that may be reverted in the near future, is blocked until we know whether it's going to be reverted or not.)
<whitequark>
is it ever erased?
<ec>
honestly, this entire design sickens me.
<ec>
I'm sure it's going to largely change.
<ec>
but it's a starting-point.
<ec>
yes, it's transient.
<ec>
at some point, we become “sure” that the reversibility can be discarded.
<ec>
at that point, presumably, we do some GC'ing of extra reversibility-information (the “stack” we've been saving, the undo-information for stuff that was deleted/removed … whatever.) …
<ec>
and then we propagate all of the changes to locking from *within* the bubble, to the world *outside* the bubble
<ec>
so all the things that were locked up waiting for changes they couldn't see happening within it, can proceed to execute.
<ec>
now.
<ec>
the important question being “how do we know we never need to reverse.”
<ec>
haven't yet decided if A) there's an obvious way to know this programmatically, something we can build into the VM,
<ec>
or B) if it's going to be added to the list of “primitive concepts the VM can't easily and reasonably deduce without Massive Computer Science.”
<ec>
B) is the entire category of stuff that we solve at a higher level, with abstractions.
<ec>
so, B) is the category of stuff that we expose controls for, to userspace.
<whitequark>
ok. so bubbles are transactions.
<ec>
like encoding responsibility into the data-graph in the first-place.
<ec>
yepyepyep
<whitequark>
yeah, you'd need a reflog
<whitequark>
er no
<ec>
but they're long-existing transactions, or are supposed to be;
<whitequark>
wal.
<whitequark>
write-ahead log
<ec>
and they're supposed to exist en masse; and they're supposed to enclose one-another.
<whitequark>
yup
<ec>
nah, not a write-ahead log
<whitequark>
any good SQL engine does that
<ec>
if I understand the meaning of that properly, anyway
<whitequark>
you said you needed some kind of a structure to record changes in
<whitequark>
that's it
<ec>
only the *undoability* of changes? I think?
<ec>
i.e. if we delete a thing from an array, we need to hold onto that thing, so the reverse-of-delete operation can be preformed if it's time-travel'd over, yes?
<whitequark>
yeah
<Navarr>
meow
<ec>
that, and the “stack” (or, since it's paws, the tree) of operations as a whole, so they can be reversed in-order
<ec>
ohshitit'snavarr
<whitequark>
in the case of WAL, you'd add a record "this row was deleted"
<whitequark>
and then if you commit, you linearly apply it to your data
<whitequark>
or just discard
<whitequark>
for example.
<Navarr>
ec: I pop in every now and again. I mostly just waste CPU cycles on ell.io, though.
<ec>
right? :D
<ec>
SO MANY CPU CYCLES
<ec>
I like all of this.
<whitequark>
ec: it's a tree only if you consider all the world at once
<ec>
how so?
<whitequark>
for a single thread of operations it's linear
<ec>
ermmmmmm,
<whitequark>
*thread of execution
<whitequark>
or
<whitequark>
execution
<ec>
woah, very confused
<ec>
completely lost you.
<whitequark>
explain to me how is it a tree
* ec
tries to words
<ec>
guthguthgty I'm bad at this
<whitequark>
in unrelated news
<ec>
at the moment, I'm actually trying to figure out why you *can't* just have a linear log of operations preformed within the bubble
<ec>
hrm
<ec>
okay. this will make you sick,
<whitequark>
I can finally say that you're clever, and not mad-genius kind of clever (like, writing an OS complete in x86 assembly), but practical kind of clever. which kinda makes me respect you
<ec>
but a huge amount of what I've done so far as been feeling. I'm not smart enough, or knowledgable enough, to go about a lot of this logically.
<ec>
and I can't logically figure out why you can't just keep a linear log of ops.
<ec>
but I *feel* like you can't?
<ec>
maybe I'll figure it out later; or maybe you're just right. ;)
<ec>
omg touched
<whitequark>
what makes respect you more is how you designed paws. it's abstract enough to be a *formal* foundation for something higher-level, like lambda-calculus
<whitequark>
this is not something that happens by accident
<ec>
I just wanted to keep it small.
<whitequark>
you should get some *good* formal education.
<ec>
huge deal.
<whitequark>
shoulda help you.
<whitequark>
ok.
<ec>
every time I had an idea, I tried to remove it from the bottom, and imagine implementing it in what I had *already* … and then only add the bits I still needed, to *do* that.
<ec>
there's some shit with Paws' Nucleus (this crap), Paws' Core, and Paws' Fullness
<ec>
not gonna get into it
<whitequark>
I conjecture that you can keep a linear log :)
<ec>
but brb gotta tell my girlfriend that somebody respects me D:
<whitequark>
maybe you feel that you cant because your code structure is kinda like a tree?
Determinist has quit [Ping timeout: 252 seconds]
<whitequark>
but that doesn't make it execute like a tree.
<ec>
sommat like that
<ec>
will look into it when I can focus on bubbles.
<ec>
I'm too practical, and too dumb, to talk about most of this at such an abstract level, though.
<ec>
I've had about as many abstract ideas and maybes and kinad-like-this-right?'s, as I can handle.
<ec>
The way I operate, I need to get my hands into code right now, and see what comes out.
<ec>
So, gotta get Strat-10 implemented in a clean style that gives me a blank-slate to experiment with bubbles on.
<whitequark>
first, people call it Fillergun, and for a reason... they made two seasons and an OVA, and almost nothing of interest happens there
<whitequark>
but I somehow like it. why?
<whitequark>
pretty picture? well, yes, it is really amazing... but I do not generally like pretty picture enough to rewatch the thing thrice.
<whitequark>
eg, GoT is really pretty, but it is really unlikely that I will ever rewatch it. maybe if bored to death.
<whitequark>
fanservice? meh, no. especially given that it always feels out-of-place in TKnR... like if it was slapped over a script indiscriminately
<whitequark>
(which it likely was)
<whitequark>
so, what is it?..
<whitequark>
it doesn't even make sense. no, not that. it doesn't even *try* to make sense.
<whitequark>
whereas western series often try to abide by the real-world laws and rules (and mostly miserably fail at it), TMnI/TKnR (though not only they) go a different route... there still is principle of casuality
<whitequark>
(so it doesn't look like schzophrenia), there still are highlights of social problems, hence, there must be some following to the rules of a society, even if inconsistent
<whitequark>
but the actions are never dictated by a rational thought.
<whitequark>
or, there is no appearance that actions are derived from a rational thought, or that they should be.
<whitequark>
maybe that's it?
<whitequark>
and also the devotion to presenting what may look like complete nonsense as well as it is possible. I swear that *all* of the team has advanced OCD.
<devyn>
whitequark: that name is hilarious. toaru kagaku no railgun… “some kind of RAILGUN OF SCIENCE”
<devyn>
or maybe I'm grouping it wrong :p
<devyn>
could be ((toaru kagaku) no railgun)
<whitequark>
devyn: you're right
<whitequark>
the canonical translation is "a certain scientific railgun"
<whitequark>
it's a wordplay. the whole series is a spinoff from "toaru majitsu no index", ie, "a certain magical index"
* whitequark
was going to build a railgun for what, last five years?
<whitequark>
they're about as amazing in reality as they're in the show. well, except bullet time, but that can't be helepd