ELLIOTTCABLE changed the topic of #elliottcable to: Embrace, extend, extuingish.
_whitelogger__ has joined #elliottcable
Sgeo has quit [Ping timeout: 240 seconds]
purr has quit [Quit: No ping reply from server]
glowcoil_ has quit [Ping timeout: 240 seconds]
_whitelogger_ has quit [Ping timeout: 240 seconds]
Navarr has quit [Ping timeout: 240 seconds]
ohhmaar has quit [Ping timeout: 240 seconds]
glowcoil_ has joined #elliottcable
<devyn>
ELLIOTTCABLE: explain execution branching again? is that just cloning an execution?
ELLIOTTCABLE has quit [Ping timeout: 240 seconds]
manveru_ has joined #elliottcable
<alexgord_>
devyn: ELLIOTTCABLE SAYS NO
<devyn>
alexgord_: …
purr has joined #elliottcable
manveru has quit [Ping timeout: 240 seconds]
rf has quit [Ping timeout: 240 seconds]
purr has quit [Client Quit]
manveru_ is now known as manveru
purr has joined #elliottcable
ELLIOTTCABLE_ has joined #elliottcable
Navarr___ has joined #elliottcable
<devyn>
17:05:53 <+devyn> ELLIOTTCABLE: explain execution branching again? is that just cloning an execution?
ohhmaar has joined #elliottcable
<devyn>
ELLIOTTCABLE_: additionally, how would `() locals` possibly work, since `()` is self-as-execution, you'd be staging yourself with `locals` as a response
purr has quit [Client Quit]
<devyn>
ELLIOTTCABLE_: which doesn't make any sense
<devyn>
god damn it purr
purr has joined #elliottcable
<devyn>
purr: hi
<purr>
devyn: hi!
<ELLIOTTCABLE_>
devyn: was shorthand for infra find () () locals
<ELLIOTTCABLE_>
or similar
<devyn>
hmm, does that mean that `locals` should be a member of the execution?
<devyn>
I guess that makes sense
<devyn>
instead of being opaque haha
<ELLIOTTCABLE_>
branching is creating a copy, yes
<ELLIOTTCABLE_>
A copy of a pointer into the tree implies the ability to branch at that point.
<ELLIOTTCABLE_>
If you never give a handle on yourself at a particular location, you're linear in that location.
glowcoil_ is now known as glowcoil
glowcoil has quit [Ping timeout: 260 seconds]
glowcoil has joined #elliottcable
Rusky1 has joined #elliottcable
Rusky has quit [Disconnected by services]
Rusky1 is now known as Rusky
irclogger_com has quit [*.net *.split]
inimino has quit [*.net *.split]
nuck has quit [*.net *.split]
nuck has joined #elliottcable
irclogger_com has joined #elliottcable
inimino has joined #elliottcable
vil has quit [Ping timeout: 252 seconds]
vil has joined #elliottcable
<joelteon>
so i just bought a lacie thunderbolt external HD
<joelteon>
dat build quality though
alexgord_ has quit [Quit: Computer has gone to sleep.]
<devyn>
ELLIOTTCABLE_: can you tell me if this is any good?
<devyn>
ELLIOTTCABLE_: …if so, there's a problem. due to all of the `infrastructure execution stage`, none of that will really execute in order if we go with my immediate-return idea…
<devyn>
ELLIOTTCABLE_: well it would still be in order, but not in the intended order; all of the stage()s would happen first, completely breaking it
<devyn>
ELLIOTTCABLE_: and stop() would get called before anything interesting happens so yeah. lol
<purr>
lol
ELLIOTTCABLE_ has quit [Ping timeout: 240 seconds]
<devyn>
oh fuck you irccloud
<devyn>
piece of shit
ELLIOTTCABLE_ has joined #elliottcable
_whitelogger has joined #elliottcable
ohhmaar has quit [Ping timeout: 240 seconds]
ohhmaar has joined #elliottcable
alexgordon has joined #elliottcable
yorick has joined #elliottcable
alexgord_ has joined #elliottcable
* alexgord_
is watching a documentary about 1%ers, sees a condo that looks suspiciously like ELLIOTTCABLE_'s
<devyn>
35 unit tests. done in 13 ms. fucking love Rust's test runner
<devyn>
these are not simple tests, either!
<devyn>
…unfortunately, compiling the whole thing with tests and running them all together takes 6.6 seconds, so it's kind of negated by compile time
<devyn>
lol
<purr>
lol
<ELLIOTTCABLE_>
devyn: can't wait to try running the example files on it, and telling you all the Things You Did Wrong You Dumbperson
Willox has joined #elliottcable
<devyn>
ELLIOTTCABLE_: well the only problem, really, is that `implementation execution stage` *should* as far as I know stage something right away and return immediately, potentially to be executed in parallel
<devyn>
ELLIOTTCABLE_: the only reason your examples work is because your reactor doesn't do parallel
<devyn>
your machine* I mean
<ELLIOTTCABLE_>
"Should"? 'splain
<ELLIOTTCABLE_>
The stage alien stages *both* the target *and* the caller.
<ELLIOTTCABLE_>
I think that's the semantics we arrived at a while back.
<devyn>
well all stage() is supposed to do, is add the given execution and response to the queue, and also the caller to the queue
<devyn>
right
<devyn>
but the queue may be operated on in parallel
<ELLIOTTCABLE_>
You've got to then call unstage immediately afterwards to be "synchronous"
<devyn>
this example seems to conflict with those semantics
<devyn>
in its usage
<ELLIOTTCABLE_>
will read in a bit, ask me tomorrow
<devyn>
mmkay
<ELLIOTTCABLE_>
The examples are far from canonical, which is kind of the point of bugging people to make implementations for me :P
<ELLIOTTCABLE_>
Want to find those nasty design corners where I just made assumptions and didn't notice.
<devyn>
well really the main thing is that you're using `infrastructure execution stage() ...` one HELL of a lot there, when I see no reason to; it just makes it wrong
<devyn>
unless affix() and charge() and such don't return when they've got all their arguments
<devyn>
which... is a problem
<devyn>
ELLIOTTCABLE_: yeah, looking through μpaws.js, seems like if the return value is undefined (JS), it just doesn't return, which is bad. it should return something anyway, even if it's just the caller or something
<devyn>
probably returning the alien itself again would make the most sense
<ELLIOTTCABLE_>
This is a long-standing argument.
<ELLIOTTCABLE_>
I'm *still* not convinced that Paws needs a Boolean type built-in;
<ELLIOTTCABLE_>
and I'm even more convinced that "returning a value to indicate there is no value to return" is folly introduced by languages with synchronous, forced "returning."
<ELLIOTTCABLE_>
Until somebody comes up with some *very* convincing arguments, I'm very unlikely to add a return value to things that don't calculate or find a value.
<ELLIOTTCABLE_>
I know that sounds crazy, but it's actually very Paws-y; think about the abstractions that you'd actually *use* with it.
<ELLIOTTCABLE_>
In Paws, a "call" is only one type of abstraction on top of staging. instead of call-pattern, you might stage-pattern them (if you don't care about the execution order with regards to what you're spinning off), or wait-pattern them (if you have further things to do, that don't make sense until the other is complete)
oldskirt_ has joined #elliottcable
oldskirt_ has joined #elliottcable
oldskirt has quit [Ping timeout: 240 seconds]
<ELLIOTTCABLE_>
remember: call-pattern isn't *special*, it's just "sort of the default." The `foo ()` syntactic sugar utilizes the default-receiver for executions, which is a call-pattern (synchronously clone `other`, stage `clone`, and leave `caller` unstaged)
<Cheery>
ELLIOTTCABLE_: can you explain me about this paws? what kind of language is it?
<ELLIOTTCABLE_>
it's actually sort of a high-level VM.
<ELLIOTTCABLE_>
the thing devyn and I and the rest are (ocassionally) building isn't, itself, a language you'd sit down and write code in.
<ELLIOTTCABLE_>
I mean, here's the raw code required to create "a subroutine" and store it in a variable:
<ELLIOTTCABLE_>
instead, it's a tool to *construct* languages, lots of languages, easily, in a particular family: asynchronous-friendly dynamic languages.
<ELLIOTTCABLE_>
normal VMs, if you have a language idea or syntax planned out or something, you *target* the VM by "compilation": you take your code, parse it in, and then programmtically generate some sort of output-code with your compiler, in that VM's intermediate-form.
<ELLIOTTCABLE_>
this language is unique: it's targetted by *abstraction*. There's no single, big step of compilation. Instead, you build a language on top of it by basically writing libraries. Small, granular steps of abstraction.
<ELLIOTTCABLE_>
anyway.
<ELLIOTTCABLE_>
Paws as a language shines in one particular area; the same one that Node.js or friends would excel in. Anything where the primary thing you're interacting with is very, very slow. (Human user, network, disk ...). It's a very slow language; execution-speed is far from my interests, but it's very good at allowing users to efficiently / sanely write heavily
<ELLIOTTCABLE_>
asynchronous code. No callback-hell, no stupid "promises" (although *actual* futures are easy enough to implement), no confusing "yield" semantics for explicit coroutines ... it all looks like synchronous code, but it's all *massively* asynchronous, automatically.
<ELLIOTTCABLE_>
it's very unusual.
<ELLIOTTCABLE_>
I've got a plane to catch, and am rushing, so I'm happy to explain more later. (=
<ELLIOTTCABLE_>
the (absolutely, fucking, terrible, because I'm bad at these things) current specification is here:
<ELLIOTTCABLE_>
(also, the text in that README might exlain better than my hurried chat here)
<ELLIOTTCABLE_>
bbl. <3
<Cheery>
ok.
<Cheery>
I'm bit missing out still.
sharkbot has quit [Remote host closed the connection]
sharkbot has joined #elliottcable
<devyn>
ELLIOTTCABLE_: okay, that's all good, but in that example, we *do* care about the ordering, and once we do a stage(), it implies we don't care about ordering very much, and we could continue running in parallel, which would be bad
<devyn>
in this case
alexgord_ has quit [Quit: Computer has gone to sleep.]
<devyn>
ELLIOTTCABLE_: I guess my point is that even for operations with no result, they still have side effects, and we still need to know when those operations are complete so we can do things that depend on t hem
<devyn>
them*
<devyn>
ELLIOTTCABLE_: I guess a related question is how do we handle a false Paws boolean
<ELLIOTTCABLE_>
yeah, ugh, another big discussion in (glacially slow, as with everything Paws-related) progress.
<ELLIOTTCABLE_>
semantics you should implement right now, depend on using ownership to determine completion / dependency.
<ELLIOTTCABLE_>
that is, the canonical way to handle a Paws "falsey" (just not re-staging, and completing yourself.), is to create an arbitrary mutex object, charge yourself with it (instant and free, since you just created it), then charge the target with it before staging the target (instant and free, since you own it), then *discharge* yourself so the target is the only
<ELLIOTTCABLE_>
owner.
<ELLIOTTCABLE_>
then after dispatching all your information to the target, you can at any time charge yourself with that mutex *again*, which will block you until it completes (since all ownership is discharged at completion)
<ELLIOTTCABLE_>
this is guaranteed to work *within those constraints*, because the target never knows about this thing that it owns, and thus can't discharge it before it's complete.
<ELLIOTTCABLE_>
obvious problems with this:
<ELLIOTTCABLE_>
- if target has any more complex semantics than "my work ends with my very last computation", everything goes wonky, because it never technically fully completes, and thus the unknown mutex held against it never gets discharged
<ELLIOTTCABLE_>
- there's issues with the current branching semantics; as if target gets indefinitely branched (as opposed to definitely-branched, in a way that the branch is immediately used up as well) ... such as being added to some sort of indefinite callback-queue ... then the indefinite branch may never complete, and ditto above with the ownership never being
<ELLIOTTCABLE_>
discharged
<ELLIOTTCABLE_>
there's a couple other edgecases I'm aware of
<ELLIOTTCABLE_>
I need to jet
<ELLIOTTCABLE_>
tl;dr I'm very open to any simple solutions you can come up to, to that latter problem, it's very much an open-problem in my head (that is, how branching should interact with ownership, especially with regards to operations that may stay incomplete indefinitely)
<ELLIOTTCABLE_>
as for the original problem of Paws falseys,
<ELLIOTTCABLE_>
or rather, the more general problem of "depending on side-effects of an operation, rather than data",
<ELLIOTTCABLE_>
also open to solutions. however, this problem begs solutions that change the design rather intensely (see: Tires.), and thus will probably need a lot more discussion.
<ELLIOTTCABLE_>
('completion of task with no results' being a general case of 'side-effect.')
oldskirt_ has quit [Ping timeout: 244 seconds]
eligrey has joined #elliottcable
oldskirt has joined #elliottcable
Sgeo_ has quit [Read error: Connection reset by peer]
Sgeo has joined #elliottcable
<glowcoil>
ELLIOTTCABLE_: i seriously do not understand your argument for this *at all*
<glowcoil>
ELLIOTTCABLE_: it's *possible* to use the blocking mechanism to wait until completion, but
<devyn>
ELLIOTTCABLE_: I believe a way better solution is to provide a completion-arg, or multiple completion-args for true/false/whatever
<glowcoil>
ELLIOTTCABLE_: spinning something off, waiting till it's done, and using some values that happened to result from it should look the same as spinning something off, waiting till it's done, and then doing something that doesn't need values from it
<ELLIOTTCABLE_>
it's not the best plan, I'm agreed.
<ELLIOTTCABLE_>
but it's better than the traditional one, IMO. far more semantic / accurate / whatever you want to call it.
<glowcoil>
ELLIOTTCABLE_: *especially* since a boolean return value *is* some information that comes out of the end of the process
<devyn>
ELLIOTTCABLE_: if you want to ignore something, you can always throw it at implementation void
<glowcoil>
ELLIOTTCABLE_: like, writing a not-operator would look really shitty and gross!
<ELLIOTTCABLE_>
hell, if the only purpose of the block-until-completion mechanism is to make us *so annoyed* that we come up with a better solution, that's great. it's been useful.
* ELLIOTTCABLE_
shrugs
<purr>
¯\(º_o)/¯
<ELLIOTTCABLE_>
not operator / etceteras absolutely would not *necessarily* look shitty and gross. These are still easy to abstract away.
<ELLIOTTCABLE_>
remember, this is Paws; there's no need to worry too much about how weird stuff looks if you write it raw. It just needs to be semantically clean to think about, intuitive in operation, and easy to abstract over.
<glowcoil>
ELLIOTTCABLE_: ok, so obviously some things return N times, like a_list each(). there is a difference between this and returning the answer to a yes or no question
<ELLIOTTCABLE_>
oh, no, yes/no can certainly *return* a boolean.
<ELLIOTTCABLE_>
boolean is a result, is a value.
<ELLIOTTCABLE_>
what i'm against is the existence of an `undefined` default return value.
<ELLIOTTCABLE_>
devyn's example was, uhhh,
<ELLIOTTCABLE_>
affix() and charge()
<ELLIOTTCABLE_>
affix is a great example. It semantically *produces no results*, in the code-path.
<ELLIOTTCABLE_>
its results are in the data-path: side-effects on the data-graph.
<glowcoil>
there should certainly be a completion-value as well
<ELLIOTTCABLE_>
the booleans issue is a completely different topic, to me.
<ELLIOTTCABLE_>
yes, we still don't have booleans; because I'm not convinced we need them.
<devyn>
yeah, I think having a completion-value that gets staged makes sense
<glowcoil>
so we have YES/NO and we have OK
<devyn>
glowcoil: no, I think something like Church booleans could be not too bad
<ELLIOTTCABLE_>
I *believe* that return-arbitrary-object vs return-nothing *could* be used to abstract booleans, in a Church style (using program-flow-branching instead of lambdas as the basic element of computation)
<ELLIOTTCABLE_>
but, I'm not remotely dead-set on that.
<ELLIOTTCABLE_>
what I *am* dead-set on, is not worrying about it right this moment.
<ELLIOTTCABLE_>
it's literally the most bikesheddy, trivial thing to change.
<glowcoil>
devyn: whatever they are underneath there'll probably be an if syntax and sequence-syntax
<glowcoil>
from the macro system
<ELLIOTTCABLE_>
what *is* interesting, is the completionist argument
<ELLIOTTCABLE_>
and that's one that's real trouble.
<ELLIOTTCABLE_>
the current system satisifies my goals, almost, but it's also painful
<ELLIOTTCABLE_>
and being unpainful is also a goal.
<ELLIOTTCABLE_>
hence the almost.
<ELLIOTTCABLE_>
that said, devyn nailed it:
<ELLIOTTCABLE_>
ELLIOTTCABLE_: I believe a way better solution is to provide a completion-arg, or multiple completion-args for true/false/whatever
<ELLIOTTCABLE_>
er, devyn:*
<devyn>
yeah
<ELLIOTTCABLE_>
I'm not going to expect users to "return" a meaningless argument (it's the meaninglessness that bothers me, not the returning),
TheMathNinja has joined #elliottcable
<ELLIOTTCABLE_>
so perhaps a new system that provides values, to be staged, that represent events in the lifecycle of a procedure.
<ELLIOTTCABLE_>
this would also possibly solve the problem that holes try to solve.
<ELLIOTTCABLE_>
tentatively, before I run off again to keep wildly packing,
<ELLIOTTCABLE_>
perhaps adding a new op-type, besides stage and charge, something like "notify"
<ELLIOTTCABLE_>
semantics of stage, but instead of a value, it explicitly takes, say, a label; and the staging only proceeds with a matching notify-wait of some sort in the thing-to-be-staged.
<ELLIOTTCABLE_>
sorta like an inside-out hole.
<ELLIOTTCABLE_>
additionally, somewhat similar to interrupt-based programming, but cooperative.
<devyn>
yeah but then you gotta generate unique labels
<ELLIOTTCABLE_>
ObjC doesn't care what the string "messageWithArgument" is. Just that it's the same as what is expected.
<ELLIOTTCABLE_>
notifications might be a bit like inside-out named arguments, I suppose.
<ELLIOTTCABLE_>
notify: "I am prepared for my first argument"
<ELLIOTTCABLE_>
notify: "I am prepared for my second argument"
<ELLIOTTCABLE_>
notify: "I am complete"
<ELLIOTTCABLE_>
idk. just a thought.
<ELLIOTTCABLE_>
but devyn: you're definitely on the right track, IMO.
<ELLIOTTCABLE_>
breaking out of the "what Paws is doing is clearly dumb in this situation, let's immediately revert back to what we know works and have been doing for ages" mindset and actually looking *at the situation* for new solutions.
<ELLIOTTCABLE_>
bbl, packing
<devyn>
okay
<ELLIOTTCABLE_>
FYI:
<ELLIOTTCABLE_>
My family's not really ready for me to be there, so to speak; nobody has *off* until the 4th itself and afterwards
<glowcoil>
ok, the whole point of paws' syntax is that you pass continuations through normal synchronous-looking hierarchies
<ELLIOTTCABLE_>
so the first half of this coming week, I should be sitting at my parents' place, bored, chillin' with my sick sister and fucking around on the computer
<devyn>
cool
<glowcoil>
which preclues multiple continuations without some other shit
<ELLIOTTCABLE_>
(glowcoil: reading on my phone)
<ELLIOTTCABLE_>
(remember to hilight me y'all)
<ELLIOTTCABLE_>
(heats)
<ELLIOTTCABLE_>
(hearts)
<ELLIOTTCABLE_>
(heaurts)
<ELLIOTTCABLE_>
(heyaurts)
<devyn>
<3
<devyn>
will do
<devyn>
have a good flight
<glowcoil>
ELLIOTTCABLE_: bye <3
<Cheery>
anyone remember/knows how C programmers/authors used to think about assembly?
<devyn>
Cheery: what do you mean?
<Cheery>
I keep thinking python is quite abstract, because there are just abstract values, and functions working on those values
<Cheery>
compared to C, C is bit like assembly, but with objects.
<Cheery>
instead of having abstract values, you have to care about how the object looks like in memory
<Cheery>
only having abstract values for small, primitive data
<Cheery>
and having to plot what everything is.
<joelteon>
but C does the stack automatically
<joelteon>
which is nice
<joelteon>
okay, so my laptop can either do disk or network I/O, but not both at the same time
<joelteon>
this is interesting
<devyn>
what about multiple disk I/O
<devyn>
in parallel
<joelteon>
i don't know
<devyn>
maybe the scheduler is just broken and it's only able to do one I/O anything at a time
<joelteon>
but i know that during my time machine backup, all my internet connections time out
<joelteon>
and if i eject the backup drive then everything works normally
<devyn>
you should really not use beta OS software
<devyn>
lol
<purr>
lol
<joelteon>
maybe not
<Cheery>
would you like to help by previewing my next blog entry?
<Cheery>
I keep entertaining myself with that thing. reading through what others are posting and doing few of my own.
<Cheery>
the last one was mine.
oldskirt_ is now known as oldskirt
<Cheery>
it's actually quite simple to come up with those, if you've got the webgl reference card
<Cheery>
after that it's just some usual entertainment with your geometry, and functions related to geometry.
<devyn>
hmm cool, looking at it again it makes sense
<Cheery>
well.. as long as you understand what you're programming there. in fragment shader, it's a fragment function running over every fragment. The function is evaluated by a GPU, which has few restrictions of it's own.
<nuck>
A quote from one of the guys in devchat about him is "then he told me to fuck off and permabanned me"
<Cheery>
I'm starting to get frustrated as they don't get this funded.. starting to consider throw money at it myself. although I know it'd be just a toy even then.
<Cheery>
imagining it might become something like the glsl.heroku - fun stuff to study.
rf has joined #elliottcable
<devyn>
Cheery: oh damn, that's something glowcoil would definitely like.