alexgordon has quit [Quit: My iMac has gone to sleep. ZZZzzz…]
SwooshyCueb has quit [Ping timeout: 252 seconds]
SwooshyCueb has joined #elliottcable
TheMathNinja has quit [Quit: Leaving]
TheMathNinja has joined #elliottcable
Willox has quit [Quit: Connection closed for inactivity]
TheMathNinja has quit [Quit: Leaving]
<joelteon>
ok so safari supports SAN certificates
<joelteon>
but I don't *think* chrome does
<joelteon>
you'd think it would
<joelteon>
have i done something wrong
<devyn>
ELLIOTTCABLE: no, definitely not a Haskell born; I had a lot of misconceptions about functional programming before glowcoil set me straight and had me learn Haskell; before that I was really only fluent in Ruby
<devyn>
vigs: don't listen to him, ΩF:∅ doesn't do a whole lot
<devyn>
:p
<vigs>
hi
<purr>
vigs: hi!
<vigs>
oh
<devyn>
I'm technically a board member of ΩF:∅
<vigs>
whoa
<vigs>
neat
<devyn>
#elliottcable is much louder than #oftn these days
<devyn>
it wasn't always that way
<devyn>
I miss dsamarin
<devyn>
what happened to him
<devyn>
he wrote most of the code that purr is based on
<devyn>
(oftn-bot)
<joelteon>
i remember when I was about to become an oftn board member, then gothalice showed up and was elected two days later or so
<joelteon>
so I gave up
<vigs>
huh
<devyn>
I haven't seen her in forever
<devyn>
if she's still on there, you could probably take her place
<devyn>
lol
<purr>
lol
<joelteon>
nah, if he wants to elect the gothalice caliber of programmer, I'm probably not fit for the job
<joelteon>
fuck it
<devyn>
I wasn't really very impressed by her; she just talked big
<joelteon>
no kidding...
<joelteon>
talking big is ok as long as that's not the sum total of your personality
<devyn>
haha
<devyn>
I dunno, she did some things
<devyn>
she had her python web framework
<joelteon>
it was probably the best python web framework ever made
<devyn>
based on what she said it was way faster than other python web frameworks, but who cares
<devyn>
it's a web framework
<devyn>
one of the most useless things you can make
<devyn>
better to just work on improving an existing framework if you feel that passionate about it
<devyn>
I think that most people who make web frameworks really just do it to learn
<joelteon>
that reminds me about how glowcoil said he hates yesod because it's like evil haskell
<joelteon>
i'm deeply disturbed
<devyn>
is yesod the one that uses a lot of template haskell
<devyn>
because I hate TH
<devyn>
ELLIOTTCABLE: does Paws have a way to transfer responsibility atomically? because if I just un-charge and then re-charge, it's possible that the Object will have changed while it lost responsibility
eligrey has quit [Quit: Leaving]
Willox has joined #elliottcable
yorick has joined #elliottcable
oldskirt has joined #elliottcable
oldskirt_ has quit [Ping timeout: 264 seconds]
Sgeo_ has quit [Read error: Connection reset by peer]
Willox has quit [Quit: Connection closed for inactivity]
alexgordon has joined #elliottcable
<glowcoil>
joelteon: i don't even remember saying that but i would probably say that
<glowcoil>
anything with the phrase "monad stacks" within several miles of it is evil to me
<glowcoil>
joelteon: wait so there was a point you took oftn seriously and dedicated effort and time to it
<ELLIOTTCABLE>
Devyn, yes. something with responsibility can charge something *else* with that responsibility.
<ELLIOTTCABLE>
I believe there was some other stuff with implicit responsibility transfer …
<ELLIOTTCABLE>
man, *none* of this made it into the spec, somehow. o_o
<ELLIOTTCABLE>
so, charge-other then discharge-self is atomic
<cloudhead>
glowcoil: joelteon: it was me :)
<cloudhead>
devyn: it is the one with TH
<cloudhead>
that's the problem
<cloudhead>
it's too complicated for its own good
<cloudhead>
uses quasiquotation
sharkbot has quit [Remote host closed the connection]
sharkbot has joined #elliottcable
Willox has joined #elliottcable
<ELLIOTTCABLE>
hi
<purr>
ELLIOTTCABLE: hi!
eligrey has joined #elliottcable
<devyn>
ELLIOTTCABLE: okay, yeah, that makes sense. I thought a bit more about separating stage() and charge() operations, and I'm really unclear on how that would work if the queue's order is not enforced (as we were also thinking about)
<devyn>
ELLIOTTCABLE: I'm designing Paws.rs assuming that the queue order won't be enforced, and native receivers will be able to tell the reactor to do something immediately without going to the queue
<devyn>
ELLIOTTCABLE: for the sake of parallelism
<devyn>
ELLIOTTCABLE: I want Paws.rs to be the fastest sane impl, if possible ^_^
<ELLIOTTCABLE>
yeah, and I'm happy to see some implementation work that tests the limits of the current design
<ELLIOTTCABLE>
re: disparate ops,
<ELLIOTTCABLE>
the same limitations apply as apply when they're unseperated, so I don't see the problem
<ELLIOTTCABLE>
i.e. without separation, if we *were* to remove ordering,
<ELLIOTTCABLE>
any operations (execution or charging) that were queued *after* a charge-changing operation, would have to be held in the global queue, and could never be "order-inlined" as you're planning
<ELLIOTTCABLE>
er, realization* or charging.
<ELLIOTTCABLE>
hate confusing those words.
<ELLIOTTCABLE>
doesn't matter if some realization is associated with the charging operation (as it is now), or not (as we're considering); it still changes the ordering semantics of any subsequent ops.
<ELLIOTTCABLE>
also, that raises an issue with your plans, now that I think about it:
<ELLIOTTCABLE>
each reactor would *still* have to check a global queue-structure (or, admittedly, their copy of it, if you copied it across all reactors ... perfectly reasonable approach, I believe), before preforming basically *any* operation
<ELLIOTTCABLE>
i.e. that arbitrary alien operation you mention, may need to, say, stage an execution
<ELLIOTTCABLE>
hrm
<ELLIOTTCABLE>
nope, not a good example
<ELLIOTTCABLE>
basically:
<ELLIOTTCABLE>
if process A attempts to undertake action B affecting item C,
<ELLIOTTCABLE>
then, **if** there is known to be no conflicting responsibility on item C, **and** there are no responsibility-changing operations in the global queue that would affect C; we can reason that it it is safe to undertake B immediately (that is, disregarding ordering constraints.)
<ELLIOTTCABLE>
right?
<ELLIOTTCABLE>
but if there are any ops possibly affecting C in the queue, then A cannot possibly undertake B without *possibly* (although not certainly) causing race conditions or out-of-order accesses, and so it must put it into the global queue in the traditional manner.
<ELLIOTTCABLE>
still seems like a pretty solid optimization, though, if I understand my mental-model of what you're talking about correctly.
<devyn>
if some execution A has responsibility over an object, and some execution B tries to access the object without first trying to acquire responsibility, is responsibility still implicitly enforced? because I think it shouldn't be
<devyn>
also it's problematic if the queue has to be checked at all -- copying the queue around doesn't really seem like a great solution anymore; locking would actually be more efficient as long as the lcok is never held for too long
<ELLIOTTCABLE>
god every time I see Rust documentation, it makes me slaver over learning Rust and writing shit like this
<ELLIOTTCABLE>
no idea why.
<devyn>
okay, A: Execution, B: Execution, C: Empty; A has responsibility over C and B doesn't. B tries to do something to C while A has responsibility over it, without trying to charge itself with C first
<ELLIOTTCABLE>
I *really* want to capture the "why" of that, because it speaks directly towards the things that interest me (programmer psychology, capturing hearts 'n minds.)
<ELLIOTTCABLE>
er
<ELLIOTTCABLE>
that's the entire purpose of responsibility.
<ELLIOTTCABLE>
to say that in that situation, B can do any *single*, non-mutating operation, without worrying about responsibility.
<ELLIOTTCABLE>
only if it needs to ensure no mutation will happen between multiple operations (multiple-sequential-read, or MSR),
<ELLIOTTCABLE>
or if it needs to ensure that its own mutation won't affect others' MSR (write).
<devyn>
okay, good, that's what I thought
<devyn>
and that plays okay with parallelism
* ELLIOTTCABLE
nods
<ELLIOTTCABLE>
but.
<ELLIOTTCABLE>
in the majority of cases, it will be doing either MSR or mutation.
<ELLIOTTCABLE>
single-read operations, that are truly invariant on other context of the object, are very rare. /=
<ELLIOTTCABLE>
s/object/data-structure/ sorry
* katlogic
has no slightest idea what the hell you two are talking about but it vaguely resembles RCU
<devyn>
I want to make sure we don't have to look at the queue for an immediate-reaction though; if there's something to be realized immediately then it should be realized immediately
<ELLIOTTCABLE>
katlogic: what's under discussion is implementation of Paws' concurrency / parallelism construct.
<ELLIOTTCABLE>
well, that's the thing.
<ELLIOTTCABLE>
read the summary above, again:
TheMathNinja has joined #elliottcable
<katlogic>
Gathered as much, can't break loose of my tight-knit notion of concurrency.
<ELLIOTTCABLE>
read the summary above, again: if you're going to be changing ownership (and any core operation that's going to mutate, or preform multiple reads spread across the queue-timeline, will have to involve ownership checks), you have to check the queue *and* the ownership-table
<ELLIOTTCABLE>
katlogic: it's really not complex or special.
<ELLIOTTCABLE>
katlogic: it's just locking.
<katlogic>
ah
<ELLIOTTCABLE>
with some of the effort and shit, moved into the data-space, instead of the code-space; but still.
<ELLIOTTCABLE>
it's very high *level* locking, though.
<ELLIOTTCABLE>
all of the actual operations are guaranteed to be parallelism-safe, they have to be.
<ELLIOTTCABLE>
The only situation where this locking system comes into play, is with all the asynchronicity in Paws.
<katlogic>
Well, when low-level explicit locks don't work for me, for example when it is data driven in queues, I resort to proxies.
<katlogic>
Which hide the complexity through accessors.
<ELLIOTTCABLE>
this is how you "lock up" some data that you're not done with, when you need to asynchronously farm out to other operations, and don't know how long that will take. (all the time, in Paws.)
<ELLIOTTCABLE>
the entire time that the system is doing other stuff, until your continuation is resumed, that data is safely assocated with you.
<ELLIOTTCABLE>
proxies? 'splain
<katlogic>
Say, you want threading in JS, mkay? But that's not really possible. So you fire two V8 isolates.
<katlogic>
You can import object from one isolate to another through interceptor proxy. The proxy does per-object locking too, tracks who owns the object at the moment (for locks, but gc too) and so on.
<devyn>
ELLIOTTCABLE: hmm, okay, I can leave that up to the individual Alien implementations to do that, then
<katlogic>
Basically its really efficiently implemented RPC calls across two JS reactor instances.
<devyn>
ELLIOTTCABLE: won't have to do anything intelligent
<devyn>
ELLIOTTCABLE: that's good, I think
<ELLIOTTCABLE>
katlogic: woah, didn't know V8 could do that.
<katlogic>
ELLIOTTCABLE: It's a generic approach. Did that in python and lua too.
<katlogic>
Worst part is probably the gc.
<ELLIOTTCABLE>
devyn: well, at the same time, no.
<ELLIOTTCABLE>
devyn: basically, for any sort of sanity, there need to be alien-level APIs to handle a lot of this.
<katlogic>
Because you must destroy object when references to it and all its proxies cease to exist, but not sooner.
<ELLIOTTCABLE>
like, the equivalent of "charge", but nukeside.
<ELLIOTTCABLE>
obviously, that'll have *substantially* different semantics: since lots of aliens will be synchronous, they don't even need to necessarily *change* the ownership table, at all; they simply need to check that nobody else is saying "don't mutate, I have responsibility", and then Do Their Thang
<ELLIOTTCABLE>
and utilize the nukeside *actual-locking* constructs, unrelated to ownership, to ensure that their atomic synchronous operations don't interact negatively with other, parallel, operations on other reactors.
<ELLIOTTCABLE>
make sense?
<ELLIOTTCABLE>
but all that should definitely be abstracted away if you want other people writing aliens in dylibs for your Rust impl
<ELLIOTTCABLE>
clearly :P
<ELLIOTTCABLE>
or, for that matter, if you want any measure of sanity when implementing the `infrastructure` aliens or your own `implementation` aliens
<devyn>
yeah, well I have a lot of thinking to do around that still, but I want to avoid as much contention as possible, and so a lot of work on Paws.rs' architecture will be just focused on making sure parallelism can work as smoothly as possible
<devyn>
anyway this helps
<ELLIOTTCABLE>
good thoughts, good thoughts
<ELLIOTTCABLE>
oh but on the original topic:
<ELLIOTTCABLE>
any reason I'm wrong, from your implementer's-point-of-view?
<ELLIOTTCABLE>
any reason I can't specify *both* disparate-op and loose-ordering?
<ELLIOTTCABLE>
the ops seem irrelevant to the ordering, afaict. Saying "this next action can't be synchronously undertaken, and must be placed on the queue" when there's a staging-with-requestedMask in the queue, which is how it would have to work right now if you want to do synchronous operations,
<ELLIOTTCABLE>
is no different from saying the same when there's a charging "op" in the queue.
<ELLIOTTCABLE>
right?
<joelteon>
hey devyn, how would you do DB migrations without template haskell
<joelteon>
I'm curious for input
<joelteon>
because this TH solution is just not doing it for me
<devyn>
ELLIOTTCABLE: I don't mean to say that they conflict, just that you can't really consider them separately since I think disparate-op has to operate a little differently given loose-ordering
<devyn>
ELLIOTTCABLE: but I think we've solved that
<devyn>
I'll let you know if we have when I work on Paws.rs later :p
<ELLIOTTCABLE>
LOL k
<purr>
LOL
<ELLIOTTCABLE>
Paws. Got so much work to do. Not really spending any time on it.
<ELLIOTTCABLE>
Really unhelpful that i'm stuck on Windows. Dealing with Windows shit keeps me from implementing at all on Paws.js (I'm so fucking close! i just need to crank out some aliens.)
<ELLIOTTCABLE>
and not being able to implement keeps me out of the mind-space I need to be in to work on the design.
<ELLIOTTCABLE>
that completely defeats the point of coffeescript |=<
<ELLIOTTCABLE>
it's supposed to compile into idiomatic, human-readable JavaScript, as much as possible.
<ELLIOTTCABLE>
the relations between the toffeescript and JS quickly become incomprehensible as I read down that page.
<ELLIOTTCABLE>
fuck that.
<katlogic>
Yeah, It's a hack
<katlogic>
But saves a lot of spaghetti callback hell if the code is truly async (or dare I say free monad?) heavy
<katlogic>
ELLIOTTCABLE: Speaking of the devil, this guy is asking me tricky questions lately, he is writing coffeescript-esque language VM from scratch (Lua-esque register machine) https://github.com/cheery/language/ ... is it ok to invite him to the cult?
<ELLIOTTCABLE>
absolutely :)
<ELLIOTTCABLE>
ooo, that reminds me
<ELLIOTTCABLE>
devyn: did I talk to you about my plans for API-hashed versioning?
<joelteon>
yes ELLIOTTCABLE
<joelteon>
type safety for a webapp
<joelteon>
why not? too much trouble?
<katlogic>
It's a whole can of worms
<katlogic>
To duck or to not duck, that's the question.
<joelteon>
well I appreciate the fact that Haskell can prevent me from giving a user a non-sanitized name
<katlogic>
Inference and optional arity is even bigger can of worms
<joelteon>
the problem with Haskell is that even the TH provided by Yesod doesn't really express what I want to express
ELLIOTTCABLE has quit [Ping timeout: 272 seconds]
ELLIOTTCABLE has joined #elliottcable
<devyn>
joelteon: honestly I think Rust could be a good candidate for webdev. its static typing isn't as good as Haskell's but for this purpose it's probably good enough, and it has an absolutely fantastic macro system that makes macros a joy to write, really
<joelteon>
unfortunately, rust isn't close to ready
<devyn>
yeah, not for production right now, but you could play around with it
<devyn>
I think it will be very good ~1.0 though
<devyn>
once there's some level of guarantee of API stability
<devyn>
not just API, the language syntax and such too
<joelteon>
gotta say i do like rust
<joelteon>
but i don't think it's my solution yet
<devyn>
Rust is like... C++-niche Scala with object lifetime tracking and good macros
<devyn>
I just love it so much
<joelteon>
so what's wrong with TH vs macros
<cloudhead>
any of you use blaze-html by any chance?
<joelteon>
ye
<cloudhead>
joelteon: you know how to create empty tags without ""?
<joelteon>
empty tags?
<cloudhead>
like, the script tag
<joelteon>
oh
<cloudhead>
I have to do script "" ! src "foo"
<cloudhead>
which is weird
<joelteon>
well i mean
<joelteon>
ok no i don't know
<cloudhead>
hm
<cloudhead>
any ideas?
<devyn>
joelteon: AFAIK TH basically gives you an AST and you have to transform that yourself, plus the transformation routine can do any kind of IO it wants at compile-time
<joelteon>
why would you want to? it's three characters
<devyn>
joelteon: it's not type safe at all, or anything
<cloudhead>
you mean ""?
<joelteon>
TH doesn't give you an AST
<joelteon>
i wish it did
<joelteon>
you have to produce one yourself
<cloudhead>
TH just makes things opaque
<cloudhead>
macros are used for simpler purposes usually
<cloudhead>
they're more "local"
<cloudhead>
at least idiomatic use
<joelteon>
so if you wanted to produce a function that performs a database migration
<devyn>
Rust macros are definitely detailed enough to handle something like Sequel.migration
<joelteon>
that would be cool
<joelteon>
there are some things that frustrate me about haskell