ELLIOTTCABLE changed the topic of #elliottcable to: #ELLIOTTCABLE: Puppy paws patter placidly through the pale passageways ...
Determinist has quit [Ping timeout: 268 seconds]
Determinist has joined #elliottcable
<joelteon> UGH
<joelteon> I HATE when
<joelteon> an app runs fine in development
<joelteon> and THEN
<joelteon> it locks up
<joelteon> AAAAG
<joelteon> STDOUT BUFFERING
dnyy has joined #elliottcable
Determinist has quit [Ping timeout: 248 seconds]
Determinist has joined #elliottcable
Determinist has quit [Ping timeout: 240 seconds]
Determinist has joined #elliottcable
Determinist has quit [Ping timeout: 248 seconds]
Determinist has joined #elliottcable
chris-tina has quit [Quit: Ex-Chat]
Aria has joined #elliottcable
vil has quit [Ping timeout: 264 seconds]
Determinist has quit [Ping timeout: 240 seconds]
Determinist has joined #elliottcable
Determinist has quit [Ping timeout: 248 seconds]
Determinist has joined #elliottcable
Determinist has quit [Ping timeout: 240 seconds]
Determinist has joined #elliottcable
Determinist has quit [Ping timeout: 248 seconds]
Determinist has joined #elliottcable
Determinist has quit [Ping timeout: 248 seconds]
Determinist has joined #elliottcable
<ec> hi
<purr> ec: hi!
<micahjohnston> hi
<purr> micahjohnston: hi!
<ec> hi micahjohnston
<ec> did you take a glance at my start on a spec, yet?
<micahjohnston> yeah a glance
<micahjohnston> uggggh i am not excited to go on this awful campout
<ec> I suck so badly at this
<whitequark> ec: you dont
<whitequark> your spec is kinda neat
<ec> oh, it's pretty-ish
<ec> I'm good at *that*
<whitequark> wrt/ semantics ;)
<ec> but I suck at, you know, *thoroughly specifying* things in clear language.
<Nuck> Just hire a lawyer
<ec> Nuck: that is just about the best idea you've ever put forth in here.
<ec> oh my god.
<Nuck> *worst
<ec> I've got a firm on retainer. I could totally just sit down with them to specify things.
<Nuck> I've had some bad ideas, but this is one of the more frightening ones.
<Nuck> Oh god he thought I was serious D:
<ec> I'm sure at the middle-ground between Elliott-ness and Legalism is a nice, reasonable land of magical unicorns and formalism
<Nuck> Only if the Elliott-ness monster lives in the world of My Little Pony.
<ec> Elliott Ness.
<ec> and MLP.
<ec> -g Elliot Ness My Little Pony
<purr> ec: Molecular Libraries Program » MLP Probes (OLD) <http://mli.nih.gov/mli/mlp-probes/>
<ec> ¬
<Nuck> hahahahaha
<ec> …
<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
joelteon has joined #elliottcable
<Nuck> For some reason the keyboard backlight is under /sys/class/leds, but I'm not going to argue the logic on that one
<whitequark> of course it makes sense
<whitequark> if you know anything about linux driver model, that is
<whitequark> duh, it's a LED, for that matter :p
<ec> lol
<purr> lol
<Nuck> Well my backlight is an LED too
<Nuck> What I can't figure out is why this shit is doing *nothing*
<whitequark> yeah, but it is tied to a display panel
<Nuck> This is true
<whitequark> whereas keyboard backlight isn't.
<Nuck> Well
<Nuck> Actually I have two backlight listings, one tied to a display, one not (or so it seems)
<Nuck> Yay Mac?
<Nuck> acpi_video0 intel_backlight
<whitequark> oh.
<whitequark> no.
<whitequark> it's the same backlight
<whitequark> but one of these will work and the other probably won't
<Nuck> They both work for backlight controls
<whitequark> because clusterfuck aka intel.
<Nuck> Except differently
* whitequark shrugs
<purr> ¯\(º_o)/¯
<whitequark> decide which one you like more, that one "works"
<Nuck> acpi_video0 allows a 0-15 setting, intel_backlight allows a 0-4000 setting
<Nuck> Oh, I prefer intel_backlight (I can actually dim my display below 20%) but it requires root to configure
<Nuck> Hence hte udev rule trying to fix that :/
<whitequark> acpi_backlight=vendor as a kernel param
<whitequark> fuck, I just helped you
<whitequark> nevermind that
<Nuck> haha
<whitequark> ec: explain your continuations
<whitequark> how are they not threads/fibers?
<whitequark> no associated context?
<whitequark> (stack &/| registers)
Determinist has quit [Ping timeout: 240 seconds]
Determinist has joined #elliottcable
<ec> hi
<purr> ec: hi!
<ec> sorry, not too familiar with fibers.
<ec> They came to Ruby right after I *left* ruby; nothing I've used since then focuses on them.
<ec> as for threads … not seeing how they're related.
<ec> They're basically our “function” data-structure.
<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
<whitequark> velvetpulse.com/2012/11/27/scribe-the-deterministic-transparent-record-replay-engine/
<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
<ec> … how ‘broke’ we talkin'?
<joelteon> thousands lost their lives
<jdhartley> im about to fix it, but like all of these pages are broken: http://elliepritts.com/photos/albums/2097
<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.
<ec> sorry, Teeny-Tiny Time-Traveling Transactions. ;)
Determinist has joined #elliottcable
<ec> this is so odd
<ec> the guy who created *that*, is working at a Rails shop?
<ec> the guy who made Scribe, I mean
<whitequark> ec: there are odd companies which just look as Rails consultancies
<whitequark> for example, Atomic Object
<whitequark> <3 Atomic Object
<purr> Let it be known that whitequark hearts Atomic Object.
<whitequark> there's a bunch of really clever people there. not your usual rails programmers.
<ec> the American colloquialism is “moonlighting”
<ec> firms moonlighting as Rails consultancies
<whitequark> kinda.
<whitequark> the guy from velvetpulse is (obviously) also not a rails programmer :)
<ec> lol they built Catalog Choice?
<purr> lol
<ec> I use that.
<ec> yeah, I know
<ec> but Viennot works at a place called Croudtap or something
<ec> all their OSS is rails-related stuff; and they seem to be primarily building a Rails marketing app
<whitequark> yeah seen that
jdhartley has quit [Quit: Textual IRC Client: www.textualapp.com]
<ec> bye bye jdhartley >:
Determinist has quit [Ping timeout: 276 seconds]
<ec> dnyy, dskuza? around?
<ec> joelteon or Nuck, even.
<Nuck> I'm busy jiggling my tits at Cairo
<ec> not sure thats how programming works
<ec> unless you have a really weird keyboard
<joelteon> ec: i'm here
<joelteon> yeah nuck is a neckbeard
Determinist has joined #elliottcable
<Nuck> ec: You act like it's not normal for me to describe programming as tit jiggling
Aria has quit [Remote host closed the connection]
<Nuck> I got muh Udev rules working though, so I'm happy. Now I'm just finishing my battery indicator
<Nuck> How did I now know about this?
<gkatsev> how?
<Nuck> how what?
<gkatsev> how did you not?
<Nuck> I don't know
<Nuck> But I rather suck at vim
<Nuck> I only get the occasional boost in productivity from vim itself
<gkatsev> idle in #vim
<ec> vimgolf <3
<gkatsev> I've been idling there for the past 7 years. Much better vimmer thanks to that
<Nuck> I gotta admit, assilly as it is
<gkatsev> that's pretty neat
<ec> fuck everything.
<ec> fuck *everything*.
<ec> most depressed.
<whitequark> huh?
<ec> extremely unhappy. right now.
<ec> same stuff as usual, recently.
<ec> really unhealthy.
<ec> I'm signing off for the night. Perhaps see y'all tomorrow, although there's other things I should be doing.
Determinist has quit [Ping timeout: 264 seconds]
Determinist has joined #elliottcable
Determinist has quit [Ping timeout: 260 seconds]
Determinist has joined #elliottcable
Determinist has quit [Ping timeout: 264 seconds]
Determinist has joined #elliottcable
Determinist has quit [Ping timeout: 260 seconds]
Determinist has joined #elliottcable
Determinist has quit [Ping timeout: 264 seconds]
Determinist has joined #elliottcable
Determinist has quit [Ping timeout: 260 seconds]
Determinist has joined #elliottcable
Determinist has quit [Ping timeout: 264 seconds]
Determinist has joined #elliottcable
Determinist has quit [Ping timeout: 260 seconds]
Determinist has joined #elliottcable
Determinist has quit [Ping timeout: 264 seconds]
Determinist has joined #elliottcable
Determinist has quit [Ping timeout: 260 seconds]
Determinist has joined #elliottcable
Determinist has quit [Ping timeout: 264 seconds]
Determinist has joined #elliottcable
Determinist has quit [Ping timeout: 260 seconds]
Determinist has joined #elliottcable
Determinist has quit [Ping timeout: 264 seconds]
Determinist has joined #elliottcable
Determinist has quit [Ping timeout: 260 seconds]
Determinist has joined #elliottcable
Determinist has quit [Ping timeout: 264 seconds]
Determinist has joined #elliottcable
Determinist has quit [Ping timeout: 260 seconds]
Determinist has joined #elliottcable
Determinist has quit [Ping timeout: 264 seconds]
Determinist has joined #elliottcable
Determinist has quit [Ping timeout: 264 seconds]
Determinist has joined #elliottcable
yorick has joined #elliottcable
Aria has joined #elliottcable
vil has joined #elliottcable
Determinist has quit [Ping timeout: 260 seconds]
Determinist has joined #elliottcable
Determinist has quit [Ping timeout: 264 seconds]
Determinist has joined #elliottcable
Determinist has quit [Ping timeout: 260 seconds]
Determinist has joined #elliottcable
Determinist has quit [Ping timeout: 264 seconds]
Determinist has joined #elliottcable
Determinist has quit [Ping timeout: 260 seconds]
Determinist has joined #elliottcable
PragCypher has joined #elliottcable
Determinist has quit [Ping timeout: 264 seconds]
Determinist has joined #elliottcable
eligrey has joined #elliottcable
Determinist has quit [Ping timeout: 260 seconds]
Determinist has joined #elliottcable
Determinist has quit [Ping timeout: 264 seconds]
Determinist has joined #elliottcable
<micahjohnston> ec: i respect you
<micahjohnston> :o
Determinist has quit [Ping timeout: 260 seconds]
Determinist has joined #elliottcable
alexgordon has joined #elliottcable
<devyn> I am so sore
<devyn> hooooly fuck
<fannkuch> nigga its a spa day https://www.youtube.com/watch?v=Kqs7iXKc93Q
<fannkuch> oh la la mazel tov what can I say
<alexgordon> whitequark: LOL
<purr> LOL
* whitequark watches Toaru Kagaku no Railgun
<whitequark> it's weird
<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
Aria has quit [Remote host closed the connection]
<devyn> heh
<whitequark> also: watch TMnI and TKnR ;)
<Nuck> Woo, muh WebKit bug got fixed