ELLIOTTCABLE changed the topic of #elliottcable to: Embrace, extend, extuingish.
<devyn> ELLIOTTCABLE: well what about locals inheritance?
<devyn> ELLIOTTCABLE: also making aliens loop is a terrible idea, because it's possible to have two executions trying to access the same alien at the same time and then what the alien would get fed as arguments wouldn't make any sense
<devyn> ELLIOTTCABLE: I think it's better if `implementation` and `infrastructure` are more like alien-factories which produce new aliens when they receive, instead of being plain-old-Empties
<devyn> ELLIOTTCABLE: maybe Empties with a custom receiver-Alien or something idk
<devyn> ELLIOTTCABLE: also, locals is not really in the spec; it occurs exactly once and you commented "...this never gets documented anywhere else. I missed something substantial, somewhere."
<ELLIOTTCABLE> during proper TDD, there'd be a nearly 1-to-1 correspondance between property/versions
<ELLIOTTCABLE> crap. internet went out.
<ELLIOTTCABLE> locals have no inheritance. like I said a long time ago, Paws has no scope.
<ELLIOTTCABLE> just the tools to design a scoping system.
<ELLIOTTCABLE> I've got neat plans for a branching scope system for Core,
<ELLIOTTCABLE> if we ever get that far >,>
<ELLIOTTCABLE> will read the rest of that ina moment
<ELLIOTTCABLE> dealing with so much shit ;_;
<devyn> ELLIOTTCABLE: okay, so do locals just get `implementation` and `infrastructure` available by default, or do we have to transfer them manually to any executions we create
<ELLIOTTCABLE> currently, manually
<devyn> okay, I think that's good
<ELLIOTTCABLE> locals *only* provide a reference to themselves, recursively.
<devyn> anyway what do you think of my implementation/infrastructure-as-alien-factory pattern
<ELLIOTTCABLE> re-reading
<ELLIOTTCABLE> re: your worries about loops, well, that's really got nothing to do with aliens
<ELLIOTTCABLE> and is re-hashing an old problem, unrelated to all this, that I havenew thoughts on as well
<ELLIOTTCABLE> (the problem which "holes" solves. don't haveanother name for it.)
<ELLIOTTCABLE> fuckin' windows
<ELLIOTTCABLE> I suspect we *might* be able to disnecessitate holes using ownership, but I also suspect that might get messy fast.
<ELLIOTTCABLE> holes might be a much more elegant solution, and it's very much on the forefront of my mind.
nicksergeant has joined #elliottcable
nicksergeant has left #elliottcable ["WeeChat 0.4.3"]
TheMathNinja has quit [Ping timeout: 252 seconds]
alexgordon has quit [Ping timeout: 264 seconds]
TheMathNinja has joined #elliottcable
<devyn> tried Firefox again, really like it, switching to it at least on my desktop for now
<devyn> and its GPU acceleration isn't broken on linux!
<vigs> install Vimperator
<devyn> eh I used to use that
<devyn> didn't really like it
<vigs> I loooove Vimperator/Vimium
<vigs> I wish there was a decent one for Safari
<vigs> the one I found sucks
<vigs> Might just fork it and make it better
Willox has quit [Quit: Connection closed for inactivity]
<ELLIOTTCABLE> I don't understand why anyone would use firefox
<ELLIOTTCABLE> devyn: level-headed arguments that don't involve "THEMES!" or "EXTENSIONS!"?
<devyn> ELLIOTTCABLE: well, I'm really just talking from a Linux perspective, but I was using Chrom(ium) for the longest time, and GPU acceleration was broken and the fonts looked kinda shitty and things would randomly not work
<devyn> so far, Firefox's font rendering looks way better, GPU accel works perfectly, and it feels faster and uses less memory
<ELLIOTTCABLE> I need my browser to be a spectacular *browser*. I give zero shits about all the bells and whistles. :x
<devyn> plus smooth scrolling actually works.
<devyn> yes, exactly; this is all about browser experience, not extensions or whatever
<devyn> and GPU accel actually really matters, because it's the difference between someone's shitty animation looking very shitty or very smooth
<devyn> ELLIOTTCABLE: their new UI is also very customizable and you can remove most of the crap and have it look more like Chrome http://i1.minus.com/iYdRAWlHBAPeJ.png
<devyn> and at first glance their development tools seem to be quite good now
<devyn> it draws actual guides instead of just boxes
<vigs> wait fuck
<vigs> wrong link
<vigs> "It was only supposed to be a joke, I never thought people would take the book seriously."
eligrey has quit [Quit: Leaving]
TheMathNinja has quit [Quit: Leaving]
<devyn> lol at the example here
<purr> lol
<Cheery> a single data structure in my app did not fit the model I was thinking of.
oldskirt_ has joined #elliottcable
oldskirt_ has joined #elliottcable
oldskirt has quit [Ping timeout: 248 seconds]
oldskirt has joined #elliottcable
oldskirt_ has quit [Ping timeout: 240 seconds]
<Cheery> hmmm
<Cheery> this lua way of handling upvalues is quite smart after all.
<Cheery> it has three points where it interfaces with the rest of the system
<Cheery> well the important points
<Cheery> stack correction - when the stack address changes, the open upvalues need to be shifted into the new stack
<Cheery> stack closing - when the stack is closed, the open upvalues dropping from the stack need to be lifted from the stack.
<Cheery> promotion - when a closure requests an upvalue to the stack, it needs to be created
<Cheery> I can contrast this with upvalue system I designed into my language:
<Cheery> upvalue creation - when a call frame is opened, upvalue slots are created for every new upvalue.
<Cheery> upvalue propagation#1 - when a call frame is opened, the upvalues are copied from the closure into the frame.
<Cheery> upvalue propagation#2 - when a closure is created, the upvalues are copied from the frame into the closure.
<Cheery> lua system increases the upvalue size by at minimum pointer size.
<Cheery> my system doubles the pointers, in the frame and in the closure, though.
<Cheery> doubles the allocations too
<Cheery> I guess I'll switch to the lua's system, because it's simpler.
<devyn> ELLIOTTCABLE: so uh, I just changed my implementation because I realized that equivalent Symbols have to have the same object identity and it would be nice to be able to compare symbols without locking them anyway,
<devyn> ELLIOTTCABLE: soooo, as a consequence, symbols can have members that persist
<devyn> as part of that symbol
<devyn> lol
<purr> lol
<cloudhead> Cheery: lua has the simplest closure representation I know
<cloudhead> the rest of the vm is excellent too
judofyr has joined #elliottcable
yorick has joined #elliottcable
Willox has joined #elliottcable
judofyr has quit [Remote host closed the connection]
judofyr has joined #elliottcable
judofyr has quit [Remote host closed the connection]
judofyr has joined #elliottcable
judofyr has quit [Ping timeout: 248 seconds]
Sgeo has quit [Read error: Connection reset by peer]
TheMathNinja has joined #elliottcable
sharkbot has quit [Remote host closed the connection]
sharkbot has joined #elliottcable
yorick has quit [Remote host closed the connection]
eligrey has joined #elliottcable
<Cheery> katlogic: maybe you were right. it doesn't now seem that hard to implement the GC into my code.
<Cheery> I collected every object into single file.
<joelteon> so now i'm gonna learn how to use emacs
<joelteon> lol
<purr> lol
alexgordon has joined #elliottcable
<Cheery> joelteon: are you going to that from vim, or from scratch?
<katlogic> Cheery: Don't attribute me any wisdom, thats just how I've seen it implemented by others all the time.
<katlogic> (Lua, V8, SBCL)
<Cheery> haven't peeped into SBCL.
<Cheery> is there anything interesting there, that wouldn't appear in lua or luajit?
<joelteon> Cheery: from vim
<katlogic> Cheery: All lisps are kinda worlds of their own.
<Cheery> katlogic: you mean even now after half of their features have been leaked into all the other languages?
<katlogic> Ie the actual implementation is rather involved as the line between runtime is much blurrier.
<katlogic> Ie in Lua, you have just C runtime, Lua guest code. Not so in lisp, the two are deeply intertwined at runtime level.
<Cheery> have a concrete example about that?
<katlogic> Guile or SBCL source code.
<katlogic> It's kinda hard to explain.
<Cheery> well..
<Cheery> yesterday I started having a feeling that the C I write, is sort of like what assembly used to be.
<katlogic> In concrete examples, because the runtime is half-bootstrapped like this, most of GC is actually written in Lisp.
<Cheery> there are clean definitions for things, but I need to hand-write them into C, because getting to write a compiler between would be a distraction into writing second language.
<ELLIOTTCABLE> Vil pmg lol
<purr> lol
<ELLIOTTCABLE> "Java is, in many ways, C++-.”
<Cheery> katlogic: I'll look into SBCL
<katlogic> Cheery: SBCL is kinda top of the line complex beast.
_ has joined #elliottcable
<katlogic> It has interesting gc, though. Uses page protection to implement barriers in moving GC.
_ is now known as Guest13022
<Cheery> I have a feeling I shouldn't have problems with finding what I'm interested about.
<ELLIOTTCABLE> Cheery: upvalues?
<Cheery> as in what are they?
<katlogic> Lua term, variables captured in intermediatelly upper closure.
<ELLIOTTCABLE> devyn: huh?
Guest13022 has quit [Client Quit]
TheMathNinja has quit [Ping timeout: 264 seconds]
TheMathNinja has joined #elliottcable
<Cheery> they are variables that aren't in local scope.. in my case not in local or global(constants) scope.
<Cheery> but are accessed somehow from the scope where they aren't local.
<katlogic> Cheery: I'm not sure you technically implement upavlues as defined by lua (upvalues are pointers to either upper stack frame slot or instantiated outside if the frame ceases to exist).
<katlogic> As you allocate the space always, ie there is no act of "closing" upvalues like in lua (this should be more efficient at runtime, but makes compiler more complex).
<Cheery> katlogic: I'm thinking about changing that.
<Cheery> yes I did not have concept of closing upvalues
<katlogic> Cheery: While "closing" approach is easier on the bytecode compiler, it becomes a burden in JIT.
<katlogic> (I've implemented FNEW/UCLO in LuaJIT with only partial success because of that).
<Cheery> well that may be good counterpoint
<Cheery> lets keep it the way it is, little longer. I'll still adjust my upvalue system, but to avoid the extra allocations I had.
<Cheery> there is one property in my system, which doesn't exist in lua
<Cheery> the values in the stack do not change by external effects.
<Cheery> because the upvalues are always out from the stack
<Cheery> joelteon: how's your emacs learning coming?
<joelteon> i'm installing a lot of plugins
<joelteon> a LOT
<joelteon> of plugins
<joelteon> I like its fuzzy finder though, also the fancy special character entering stuff
<katlogic> joelteon: What made you jump the ship, traitor?
<joelteon> katlogic: I wanted an IDE
* katlogic tried to give st3 a chance
<katlogic> ended up using vim again
<katlogic> st3 modal plugins are just way too clunky, some cool features like multi select dont compensate it enough
Sorella has joined #elliottcable
eligrey has quit [Ping timeout: 240 seconds]
eligrey has joined #elliottcable
erynofwales has joined #elliottcable
erynofwales has quit [Client Quit]
yorick has joined #elliottcable
glowcoil_ has joined #elliottcable
amatecha_ has joined #elliottcable
jeannicolas_ has joined #elliottcable
glowcoil has quit [Ping timeout: 240 seconds]
amatecha has quit [Read error: Connection reset by peer]
jeannicolas has quit [Ping timeout: 240 seconds]
glowcoil_ is now known as glowcoil
amatecha_ is now known as amatecha
<Cheery> in case my computer would suddenly explode
<Cheery> all the objects in my runtime.. listed.
<Cheery> tomorrow will rewrite lot of the code remaining in other files, feature wise.
glowcoil has quit [Changing host]
glowcoil has joined #elliottcable
amatecha has quit [Changing host]
amatecha has joined #elliottcable
<joelteon> ok i gave up on emacs
<joelteon> it sucks
<Cheery> so soon?
<joelteon> yeah
<Cheery> I imagine vim is worse than fly paper. somehow no other program can replace it.
<joelteon> evil-mode is really good, but I have ctrl-c mapped to esc
<joelteon> and ctrl-c is the first key combination in about 3,000 emacs mappings
vil has quit [*.net *.split]
Sorella has quit [Quit: Ex-Chat]
vil has joined #elliottcable
ELLIOTTCABLE_ has joined #elliottcable
ELLIOTTCABLE has quit [Ping timeout: 264 seconds]
ELLIOTTCABLE_ is now known as ELLIOTTCABLE
<devyn> ELLIOTTCABLE: originally when I was implementing Symbols, I asked if they would be global object instances i.e. &"hello" == &"hello" (the same Object, by-address)
<devyn> ELLIOTTCABLE: which implies you could edit their members and the same symbol would always have those members
glowcoil has quit [*.net *.split]
joelteon has quit [*.net *.split]
ag_dubs has quit [*.net *.split]
manveru has quit [*.net *.split]
jeannicolas_ is now known as jeannicolas
<ELLIOTTCABLE> devyn: yes? and?
<devyn> ELLIOTTCABLE: well originally you said no, you can't
<devyn> lol
<purr> lol
<ELLIOTTCABLE> the spec no longer implies that: Symbols are completely seperate objects; the only special functionality is that their `infrastructure label compare()` result must be truthy
<ELLIOTTCABLE> yeah, there was a worry about that for a while
<ELLIOTTCABLE> I decided it's a non-issue, by no longer really*having* symbols.
<ELLIOTTCABLE> now, we have immutable, easily-comparible strings.
<ELLIOTTCABLE> you can 'instantly' compare two labels, but it's not by *data* identity. Just string-identity.
<devyn> wait what, are you kidding? I just spent a whole bunch of time fixing my Symbol impl to be actual symbols lol
<devyn> :/
<ELLIOTTCABLE> for instance, Paws.c implemented them as a trie
<ELLIOTTCABLE> lol how so
<ELLIOTTCABLE> if they're actual symbols, then they have to be *identity* comparable. can't do that and have content.
<ELLIOTTCABLE> clearly, my specification is *even more* terrible than I thought. ;_;
<devyn> yeah, exactly, they're identity comparable and can have content and the content just persists globally
<ELLIOTTCABLE> ugh nope. opposite of how it should work.
<ELLIOTTCABLE> we talked about that for a while, a couple years back.
<ELLIOTTCABLE> caused a lot of problems with ownership, encapsulation, etcetcetc.
<devyn> and there's a problem with making them not, too: the 'default receiver' specifies that the keys should be compared by object identity
<devyn> additionally I don't want to have to lock a symbol every time I want to compare it
<devyn> that's crazy
<ELLIOTTCABLE> it should be using the same comparator as `infrastructure label compare()`, which falls back to object-identity if it can't ascertain that both objects are labels
<ELLIOTTCABLE> hm. why do you need to lock?
<devyn> well because they're Objects, and I don't have objects segmented into immutable-part and mutable-part because that just doesn't make any sense for most objects
<devyn> symbols would be a special case
<ELLIOTTCABLE> yeah, there's unforseen advantages to truly-object-identical symbols, then. hm.
<ELLIOTTCABLE> well, let's see if we can solve it in implementation instead of in design. because I *really* am dead-set on having different object-data for equivalent labels in different contexts.
<devyn> I don't think it's even a problem that symbols can have 'leaked' members
<devyn> is it?
<devyn> if someone uses that, it's their fault
<ELLIOTTCABLE> yes.
<ELLIOTTCABLE> it's not so much about the leaking.
<ELLIOTTCABLE> a *huge* design-goal for Paws is to enable interoperable 'patois' - fundamentally different languages (object-systems, concurrency constructs, garbage collectors, locking systems, all sorts of mutable semantics.), that can still interoperate in the same object-space
<ELLIOTTCABLE> (i.e. the *actual* goal, most directly, being: I don't want to require that every library I use, use the exact same "language" as I do, to use that library to some extent of sanity.)
<devyn> okay, so symbols having members affects that how?
<ELLIOTTCABLE> sorry keep geting called afk
<ELLIOTTCABLE> multitasking out the ass
<devyn> kk np
<ELLIOTTCABLE> language A wants to handle "symbols" one way. language B wants to handle them another way.
<ELLIOTTCABLE> the canonical way to abstract new functionality on top of the alien types, is to expose new constructors that call into the Paws infrastructure in the background, and then modify the returned objects.
<ELLIOTTCABLE> if language A creates a comparable-label "foo" at the API consumer's request, constructs it the way that is necessary for its semantics (changing the receiver, say)
<devyn> oh, okay, so that immediately tells me what the problem is, haha
<ELLIOTTCABLE> now language B is either going to stomp on, or trip over, or some horrible combination thereof, any situation where a consumer of *it's*, sharing the object-space, needs to use the label "foo".
<ELLIOTTCABLE> yeh
<ELLIOTTCABLE> so.
<ELLIOTTCABLE> implementation solutions.
<ELLIOTTCABLE> I like comparable symbols, I really do. so here's an idea.
<ELLIOTTCABLE> reverse the relationship I'd been imagining so far ("label" objects, individualized, each have a reference to a trie-stored globally-unique "symbol" for compare-purposes),
<ELLIOTTCABLE> so that instead, there's a single global symbol for each string, and that's what's in the object graph,
Sgeo has joined #elliottcable
<ELLIOTTCABLE> but have the get/set/etc object-y-interaction primitives access a different "object" stored on that symbol, depending on context?
<ELLIOTTCABLE> hrm
<ELLIOTTCABLE> ugh no that's changing semantics.
<ELLIOTTCABLE> actually, that could possibly work. here, get this:
<ELLIOTTCABLE> object structure foo -> bar -> baz
<ELLIOTTCABLE> foo and baz are plain objects, hex identifiers DEAD and BEEF respectively, say
<ELLIOTTCABLE> bar is a symbol. content of "ELLIOTTCABLE".
<ELLIOTTCABLE> in your actual storage formats (code-graph and data-graph), store it as the globally-unique symbol reference. Any labels instantiated with "ELLIOTTCABLE" in the code will be the same object *in the object-graph*.
<ELLIOTTCABLE> now, this gets messy, but solves the problem:
<ELLIOTTCABLE> in either a global table (easy), or in the owning object (messier but parallelism-faster), store a relationship between slot-number on that parent, and symbol members.
<ELLIOTTCABLE> ugh won't work 'cuz would have to maintain knowledge of the parent everywhere.
<ELLIOTTCABLE> goddamn this is hard.
<ELLIOTTCABLE> okay.
<ELLIOTTCABLE> god, this one's getting implementation-specific fast.
<ELLIOTTCABLE> but what about some sort of tuple for object-representations *everywhere*?
<ELLIOTTCABLE> that way they can have object-identity, and symbol-ish identity where necessary (labels.) built into the pointer.
<ELLIOTTCABLE> make any sense?
joelteon has joined #elliottcable
<ELLIOTTCABLE> you're probably smarter than me about this. I'm gonna leave you to ponder it.
<ELLIOTTCABLE> so, reminder of the *current* semantic requirements, since the spec is terrible about laying this stuff out:
<joelteon> my ZNC stopped receiving messages...
<joelteon> it was scary
<ELLIOTTCABLE> 1. `infra compare()` should only be truthy when any modification to the first argument will be reflected in the second argument, and vice versa, with no caveats. If they can be independantly modified, it should be falsey.
<ELLIOTTCABLE> 2. `infra label compare()` should be truthy if both arguments have symbolish-data (i.e. "are labels"), and if that symbolish-data is identical. symbolish-data is guaranteed to be immutable; it cannot be added to, removed from, or modified on, any object (label.) If symbolish-data doesn't exist to compare, then they should be compared by object-identity as
<ELLIOTTCABLE> described in 1.
alexgordon has quit [Read error: Connection reset by peer]
<ELLIOTTCABLE> 3. there should exist objects in the system that 2-compare as the same, while still being individually mutable (and thus 1-compare as different.)
prophile has joined #elliottcable
alexgordon has joined #elliottcable
<ELLIOTTCABLE> hi
<purr> ELLIOTTCABLE: hi!
<ELLIOTTCABLE> no purr you aren't even real