<devyn>
really need to write some more utility functions so that doesn't take so much work
<devyn>
lol
<purr>
lol
<devyn>
basically that's creating an Execution { stop() }, defining `stop` on its locals as a simple Alien that stops the machine, queuing the execution and then letting the reactor take over
<devyn>
the test... really should time out to detect failure, haha
<ELLIOTTCABLE>
the one that says yay.
<ELLIOTTCABLE>
that is my anthem.
<devyn>
yeah that's pretty cool
<ELLIOTTCABLE>
oh i'm talking in here
<ELLIOTTCABLE>
hi i am very tired
<ELLIOTTCABLE>
I coded for six hours on the plane
<ELLIOTTCABLE>
will push it in a moment
<ELLIOTTCABLE>
suffice to say, it will make you very happehs
<devyn>
I've been awake for... uhhhhh
<ELLIOTTCABLE>
god am so sleepy
<devyn>
30 hours?
<ELLIOTTCABLE>
need to commit all this work and push it so I can sleeeeep
<ELLIOTTCABLE>
test!
<ELLIOTTCABLE>
I could actually read(ish) that!
<devyn>
API still needs some helpers in that to make it less ugly
<devyn>
but yeah Rust is pretty readable
<devyn>
way better than C++, but fills the same niche
<devyn>
love it
<ELLIOTTCABLE>
:D
<ELLIOTTCABLE>
so
<ELLIOTTCABLE>
exhaust
<devyn>
me too, and I still gotta do some work shit
<ELLIOTTCABLE>
that said: I *would* prefer you not go to that file for answers. If you don't understand how something works from the spec, either make a guess, or come ask me. I'd rather not have any sneaky assumptions I made and forgot about in my implementation leak over into yours :P
<ELLIOTTCABLE>
but nonetheless ... I'm super-proud of my JavaScript API
<devyn>
yeah, I don't, lol; I usually go with asking you, and relying on gut instinct if I don't want to be blocked by asking for you
<purr>
lol
<devyn>
asking you*
<devyn>
so
<ELLIOTTCABLE>
purrfct
<devyn>
what does `return null` do
<devyn>
here
<ELLIOTTCABLE>
Alien.synchronous is a suuuuuuuper-useful, and a little over-engineered, sugary hack
<devyn>
yeah, I know, I've read it
<devyn>
:p
<ELLIOTTCABLE>
it's a handy constructor for several common cases
<ELLIOTTCABLE>
oh ah cool
<ELLIOTTCABLE>
well if the return value of the constructor's argument is null or undefined, then the constructor builds the type of alien that never "returns"
<ELLIOTTCABLE>
(the exact thing we were talking about earlier)
<devyn>
okay
<ELLIOTTCABLE>
I'm really, really happy with how easy it was to implement infra exe branch
<ELLIOTTCABLE>
really really happehrhthaw
<devyn>
haha
<ELLIOTTCABLE>
Paws.js is definitely coming along nicely.
<devyn>
that's a neat solution
<devyn>
kinda what you'd expect from something that's basically fork()
<ELLIOTTCABLE>
I really hope it'll end up being an excellent example of an unoptimized, naive, and super-clean implementation of a non-parallel Paws.
<ELLIOTTCABLE>
mmhmm
<ELLIOTTCABLE>
oh, it's not the implementation that's neat
<ELLIOTTCABLE>
branch is branch is branch *shrugs*
<purr>
¯\(º_o)/¯
<ELLIOTTCABLE>
it's just how easy it was to write in CoffeeScript, and the Paws.js API I've slowly evolved
<ELLIOTTCABLE>
just. yah. proud of how clean that looks, given the complexity of the task you're describing.
<devyn>
:D
<ELLIOTTCABLE>
complex Paws-side asynchronous interactions can be orchestrated from a very synchronous, very dumb language (JavaScript), surprisingly easily.
<devyn>
I need a more sane Alien abstraction too... mine doesn't use arrays of callbacks, for obvious reasons; just a routine coupled with some dynamically-typed data that can change the alien's routine/data
<devyn>
which is going to be SUPER fucking ugly if I don't abstract that away
<devyn>
but it performs well
* ELLIOTTCABLE
node
* ELLIOTTCABLE
nods
<ELLIOTTCABLE>
so, yah, long story short,
<ELLIOTTCABLE>
after putting it off for aaaaages, I knuckled down and completed Paws.js.
<ELLIOTTCABLE>
there's some important stuff missing (`charge: undefined # NYI`)
<ELLIOTTCABLE>
but 99% of it is there.
<ELLIOTTCABLE>
it successfully runs the first two examples. haven't tried the rest, captain was like PUT AWAY UR PAWS
<ELLIOTTCABLE>
and i was like BUT CAPEETAN,
<devyn>
haha
<ELLIOTTCABLE>
and he was like BUT NO. WE R LANDIN.
<ELLIOTTCABLE>
so i was liek fine i won't even commit my work this is dumb planes are dumb OH MY GOD MOUNTAINS
<ELLIOTTCABLE>
I FORGOT ALASKAW AS A THING
<devyn>
so, I'm actually almost caught up to exactly the point you're at, then; I just have to implement the different aliens
<ELLIOTTCABLE>
glowcoil: hi this is pretty you should look
<devyn>
responsibility isn't really in yet
<ELLIOTTCABLE>
devyn: that's where I was this morning, exactly.
<ELLIOTTCABLE>
oh, well, resp was implemented ,but it was trivial for me, so
<ELLIOTTCABLE>
my test suite is behind. quite a bit.
<ELLIOTTCABLE>
I didn't test a single thing I wrote on the plane. <.<
<devyn>
oh where are those Examples from?
<devyn>
not μpaws
<ELLIOTTCABLE>
I'm slowly porting and modifying the ones from upaws
<ELLIOTTCABLE>
01. is 06., and 02. is 07., I think
<ELLIOTTCABLE>
and I don't have **any** integration tests.
eligrey has quit [Quit: Leaving]
<ELLIOTTCABLE>
that's my next task, I believe. changing my testing system so I can start to write some in-Paws-code integration tests.
<devyn>
cool
<ELLIOTTCABLE>
really important stuff /[
<ELLIOTTCABLE>
.= *
<ELLIOTTCABLE>
/= *
<ELLIOTTCABLE>
having all your "testing" be "example code" files is like, the worstest thing.
<ELLIOTTCABLE>
I'd like to chat with you about that, actually.
<devyn>
later though, I'm super tired and I've really gotta get some work done
<ELLIOTTCABLE>
I'd like to start working towards a PSp that all these implementations can start trying to pass.
<ELLIOTTCABLE>
yeah totes, I'm crashing within a minute and a half
<ELLIOTTCABLE>
deadeded.
<ELLIOTTCABLE>
but, basically, I want to come up with a really really really simple-to-implement and sufficiently-powerful "testing library."
<ELLIOTTCABLE>
assertions kinda thing, although a little more Paws-y, and with aspects to handle asynch stuff better.
<devyn>
and all within Paws
<ELLIOTTCABLE>
and then specify that tightly, and that way implementations can "start there."
<ELLIOTTCABLE>
yeah.
<devyn>
awesome
<ELLIOTTCABLE>
like, implement assert () (...) first
<ELLIOTTCABLE>
and then implementation version (), and assert that that equals the label "0.0.1"
<ELLIOTTCABLE>
like literal bare-bones stuff
<devyn>
mmhm
<ELLIOTTCABLE>
and the entire time see progress in the test-suite's output
<devyn>
sounds like a plan
* devyn
afk now
<devyn>
g'night
<ELLIOTTCABLE>
okay i sleeps
<ELLIOTTCABLE>
devyn: sleep soon yo dumb
<ELLIOTTCABLE>
you dumb
oldskirt_ has joined #elliottcable
oldskirt has quit [Ping timeout: 255 seconds]
oldskirt_ is now known as oldskirt
oldskirt_ has joined #elliottcable
oldskirt has quit [Ping timeout: 264 seconds]
<Cheery>
ELLIOTTCABLE: how are you able to code in a plane? All the people and noise around.
yorick has joined #elliottcable
Sgeo has quit [Read error: Connection reset by peer]
vil has quit [Ping timeout: 264 seconds]
vil has joined #elliottcable
prophile has joined #elliottcable
<Cheery>
I need a better way to notate use of write barrier in my system.
<Cheery>
this thing basically just needs to know, which objects connect together
alexgordon has joined #elliottcable
alexgord_ has joined #elliottcable
Rusky has joined #elliottcable
oldskirt_ is now known as oldskirt
alexgord_ has quit [Quit: Computer has gone to sleep.]
<Cheery>
doing stupid things since forever..
<Cheery>
seems I have to revert the stupidity with vm_val, because it's pointless.
<katlogic>
Cheery: The "let's keep every structure together so one can clearly see how it is all interlinked" is interesting
<katlogic>
Sadly most C preachers will tell you how you have to keep each *.h paired with C, what you wrote looks like sensible approach.
<katlogic>
Beware that Lua does that too, lobject.h contains all gc traversed object, however seeing it for *all* structures in a program is rare.
<katlogic>
As for write barriers that stuff is hard, especially if there are fine grained ones ("this object is now being referenced to", "this object now refers additional new object" etc) and not just brute 'something about this object changed'.
<Cheery>
yeah.
<Cheery>
but it seems, to somehow enclose that inside few functions is too tricky
<Cheery>
and causes more mangling than just writing the barrier invoke
<katlogic>
go with general barrier, then fine grain later?
<katlogic>
what does vm_frame 'base' and 'top' do?
<Cheery>
base = the base index to the bunch of slots, where the register window of the frame starts
<katlogic>
ah
<Cheery>
top = where it ends.
<Cheery>
might be redundant that another part.
<katlogic>
inside vm_slot_array i presume
<Cheery>
yup
<katlogic>
this feels very luaesque so far
<katlogic>
though not sure if things like vm_frame_array are really helpful
<Cheery>
I'm unsure about that too.
<katlogic>
I suppose it boils down to
<katlogic>
Are you the type of a guy who designs the data structures of program first
<katlogic>
Or just design structures as-you-go
<katlogic>
I'm the latter type and the results are often catastrophic
<katlogic>
as in, often rewrites because the initial flow was just naive
<katlogic>
the first kind of design is preferable, but be careful to not overdesign :>
<Cheery>
latter type.. you're seeing a rewrite.. my fourth or fifth.
<Cheery>
but I did add few structures that I had not, to make things more convenient.
<Cheery>
actually I'm in middle of in-place rewrite
<katlogic>
Thats why I usually just steal existing code and hack on it
<katlogic>
I'm even too old to write it from scratch using good code as frame of reference as I used to, literally just fork and hack now :)
<Cheery>
I feel I'm getting this good. It's just that I need to figure out what works out.
<Cheery>
one thing is the vm_slot
<Cheery>
depending on the encoding of the value, it may be pointer of some sort.
<Cheery>
thought for a while thinking about it as a struct, but it's more effort.
<Cheery>
katlogic: would you give gc_alloc a context? does it need that, if the gc_step actually steps the gc?
vil has quit [Quit: :qa!]
<katlogic>
Cheery: All of VM context is single structure in Lua (with several sub-structures). There is no need to separate stuff which partains to same stat ...
vil has joined #elliottcable
<Cheery>
working on the stack right now
<Cheery>
though I think I'll keep a break
<Cheery>
katlogic: I wonder.. what functions the stack should have really..
<Cheery>
push, pop is the obvious ones
<Cheery>
I think the push should call a C function if it's passed in.
<katlogic>
The last time I did original stack design
<katlogic>
it was a weird hybrid
<katlogic>
basically, each function had new allocated frame, there was no stack growing.
<katlogic>
to access arguments for function call (and upvalues), it had opcode to reach parent stack
<katlogic>
problem with that was that tail recursion became tricky.
<katlogic>
there were also some cool benefits
<katlogic>
for example, constants were just preloaded stack slots
<katlogic>
and each function prototype just kept freelist cache of stack frames
<katlogic>
ie usually it just reused stack frame, when new was allocated it had to be preloaded with constants
<katlogic>
another fun optimization, closure was always just that stack frame
<katlogic>
so if something deeper kept reference to its upvalue, the whole frame was kept alive
<katlogic>
and unused stack slots were cleared out by gc when it was proven that all references to that stack were just for upvalues, not actually resumable thread
<Cheery>
hmm
<katlogic>
naturally its a tradeoff, a lot of complexity reduced at cost of keeping unused frames around
<katlogic>
however there are not that many of those surprisingly, most of memory is occupied by gc waste anyway
<katlogic>
pathological case would be function with 20000 slots (will that ever happen) being trapped because it holds one upvalue
<katlogic>
thread state was just array (not linked list) of "stack of frames"
<katlogic>
so GET_UPVALUE opcode had argument how many levels upper you want your upvalue from
<katlogic>
function prototype also contained list of upper frames of upvalues it needs for gc
<katlogic>
i might find the vm prototype, it was written in python i believe (lol :)
<purr>
lol
<katlogic>
Cheery: Oh, and function call setup was really weird, like several opcodes. One to allocate frame from prototype, then several to put function arguments into that frame (PUT_UPVALUE with new negative index, ie more like PUT_DOWNVALUE) and then finally opcode which did the frame & pc switch.
alexgordon has quit [Quit: My iMac has gone to sleep. ZZZzzz…]
sharkbot has quit [Remote host closed the connection]
<ELLIOTTCABLE>
so I just read the preface to someone's book, written in .txt files
<ELLIOTTCABLE>
no, Rut theory.
<ELLIOTTCABLE>
as in, "we're stuck in a programming-language rut". or at least, were more-so when we started talking about the topic, and named it.
<ELLIOTTCABLE>
procedural-ish, object-oriented-ish languages, usually with a stack, usually with lexical scope, and usually with closure of some sort.
<ELLIOTTCABLE>
those are what we call Rut, or Oasis, languages.
<ELLIOTTCABLE>
shit that's not of any exotic paradigm. (functional, concatenative / stack-based, logic-based ...)
<ELLIOTTCABLE>
another way to put it is "designed in the vertical" (iterating and improving on common paradigms and approaches), as opposed to something "designed in the horizontal" (coming up with completely new, usually inferor, paradigms or approaches)
<ELLIOTTCABLE>
inferior*
<ELLIOTTCABLE>
Paws is extremely horizontal, Rust is extremely vertical.
<ELLIOTTCABLE>
brb showah and breakfast. I fuckin' love Alaska.
<katlogic>
ELLIOTTCABLE: If you're trying to say 'unoriginal' you're mostly right.
<ELLIOTTCABLE>
that's not necessarily true.
<ELLIOTTCABLE>
Rust is far from unoriginal.
<katlogic>
I wont deny that I'm more interested in implementations than academic designs.
<ELLIOTTCABLE>
when the innovations are in the specifics, instead of the generals, that's a good sign it's design in the vertical.
<ELLIOTTCABLE>
exactly. innovation in implementation, for instance, is almost certainly in the vertical.
<ELLIOTTCABLE>
speaking of implementations ... you should implement a fast Paws. ;)
<katlogic>
Paws, despite how involuntarily vague idea I have about it will be always more of a concept than language.
<katlogic>
You know, like the original lisp.
<katlogic>
People at one point tried really hard to pass it as a legit programming language. Yet the world opted for C++ and Javascript.
<katlogic>
*sigh*
<katlogic>
Silly world.
<joelteon>
well, I do not like lisp
* ELLIOTTCABLE
shrugs
<purr>
¯\(º_o)/¯
<ELLIOTTCABLE>
I don't think that's anything inherent in the sort of language it is. I think that's all in marketing.
<ELLIOTTCABLE>
And much of the point of my efforts is in contributing to slowly convincing people to move *out* of the current oasis.
<ELLIOTTCABLE>
Although I personally hate pure-functional programming, I'm really happy to see the last couple years' hipsterization of functional programming.
<ELLIOTTCABLE>
it's something that isn't Yet Another Java, Reskinned(tm). and that's good for the diversity of our community.
<ELLIOTTCABLE>
... and diversity is health.
<ELLIOTTCABLE>
anyway. I don't want Paws to replace C++ (lol.), but I do absolutely believe it could replace JavaScript, if it's good enough.
<purr>
lol
<ELLIOTTCABLE>
and more importantly, it's not *about* replacing. Languages aren't corporations, market share only matters up to a point. Being The Leading Language is never a useful thing.
<ELLIOTTCABLE>
Hell, if anything, it's a detriment; because that means you get too many people using it just because they vaguely heard that it's The Best, when those people aren't really the target userbase ... and then diverge development resources away from the original userbase.
<ELLIOTTCABLE>
it's better to be popular-*ish*; small enough to be focused on the users it pleases most, but large enough to have a community and libraries and support-structure for newcomers and and and and and aaaaand
<ELLIOTTCABLE>
so.
<ELLIOTTCABLE>
katlogic: did I mention that,
<ELLIOTTCABLE>
-didja @ katlogic
<purr>
katlogic: didja write a paws yet? didja? didja!?
<ELLIOTTCABLE>
I need to write a little library that converts every FIXME and TODO comment into a failing test.
<ELLIOTTCABLE>
they just sort of float around in the code-base, super unhelpful.
<ELLIOTTCABLE>
actually, that'd be trivial. I'm totes gonna do that when I have a little time.
<ELLIOTTCABLE>
devyn: Just letting you know, I'm officially switching Paws.js over from () to [].
<ELLIOTTCABLE>
was talked much about a while back, and I decided on it, but was putting it off until the next spec version
<ELLIOTTCABLE>
but it's muchly looking like we'll be starting to write actual abstractions on top of this, and federating between our impls, quite damn soon
<ELLIOTTCABLE>
so that, and semicolons, I want to get into the implementations right now, even if that's against spec.
<ELLIOTTCABLE>
(semicolons I haven't quite nailed down the semantics of, yet, though.
<ELLIOTTCABLE>
devyn: also, pushing my four examples to GitHub. 04 is rather insane, and I can't believe it functions.
<purr\Paws>
Paws.js/Master ec1ca0a ELLIOTTCABLE: (- fix debug) Truncate output of long expressions
<purr\Paws>
Paws.js/Master 744d3ed ELLIOTTCABLE: (new doc) Adding some example-code!
<purr\Paws>
Paws.js/Master ed28913 ELLIOTTCABLE: (- re API) Re-arranging #find
<ELLIOTTCABLE>
so yeah, some stuff on my immediate roadmap, in no particular order:
<ELLIOTTCABLE>
- PSp
<ELLIOTTCABLE>
- a super-basic IPP for Paws.js, because I'm tiring of cPaws extremely quickly :P
<ELLIOTTCABLE>
need some syntactic abstractions yo :P
<ELLIOTTCABLE>
- some clean-up and test-writing on Paws.js itself, because the unit tests are more than a little behind, *and* I'm getting really itchy, having no automated integration tests to make sure all this shit works
<ELLIOTTCABLE>
and finally, the only one applicable to you ('cept maybe chatting about PSp plans),
<ELLIOTTCABLE>
nailing down libside Unit semantics, so we can both start A) writing semantic abstractions, if not syntactic ones, and storing them in fucking files, lol, and B) FEDERATING BITCH
<purr>
lol
<devyn>
:D :D :D
<devyn>
I'm excited
<ELLIOTTCABLE>
so, I'm thinking for specs, we need the implementation to expose *both* serial objective-results from the code,
<ELLIOTTCABLE>
*and* the data-graph.
<ELLIOTTCABLE>
the latter sound suspiciously similar to the federation API.
<ELLIOTTCABLE>
so perhaps I'll specify the spec-interface as something that talks to your implementation in the same way another implementation would, kinduh.
<ELLIOTTCABLE>
at least, that's half of it.
<ELLIOTTCABLE>
first half is something like the equivalent of assert() / print(), exceedingly simple,
<ELLIOTTCABLE>
that allows testing of order of evaluation and data-flow (and all the other super-basics necessary to get even that far),
<ELLIOTTCABLE>
and then second half is querying the program's state, as represented by the data-graph.
<ELLIOTTCABLE>
a developer starting on an implementation would basically only need the following to pass their very first test, ideally:
<ELLIOTTCABLE>
A) parsing,
<ELLIOTTCABLE>
B) a simple reactor that processes "combinations" given to it, in terms of `a b c`-type stuff,
<ELLIOTTCABLE>
C) a `find` algorithm to process `a b`,
<ELLIOTTCABLE>
D) and an implementation of `spec log()` or something.
<ELLIOTTCABLE>
with the very first test being something like `spec log "success"`
<ELLIOTTCABLE>
I'm thinking of having three completely separate testbases in the test project:
<ELLIOTTCABLE>
one, that attempts to be as one-to-one to the *specification* as possible. Those are the actual conformance specs.
<ELLIOTTCABLE>
two, that provides an incrementing series of tests (a bit like the Examples/ folder right now, actually) with the specific goal that completing the next test means an implementer is closer to a mostly-complete implementation (kind of a 'bootstrapping course' to give somebody specific goals if they get told "hey, write a Paws.")
<ELLIOTTCABLE>
and three, high-level integration-type specifications. Almost-complete programs that we *know* how we want to work, in exactitude. Those would be the most complex and involved spec, with each perhaps spanning over multiple files;
<ELLIOTTCABLE>
any implementation capable of running those can probably run whole abstraction-towers of Paws shit you can throw at it.
<ELLIOTTCABLE>
the actual spec project itself would define the simple API described above, that the implementation must expose; and then implement some sort of bare-bones "runner" that invokes your implementation with code (again, probably via distribution mechanisms), and then checks the results in whatever way is relevant against the specified results.
<ELLIOTTCABLE>
can probably put said runner on a CI server, and generate a nice pretty HTML page with a list of implementations, each one's compliance and speed, and a submission form for adding your own GitHub project.
<ELLIOTTCABLE>
reading up on RubySpec, to see how rubinius solved some of these exact concerns
<ELLIOTTCABLE>
on a related note, I also really like the SRFI system, and am thinking of devising something similar for organizing the potential chaos that is a Paws ecosystem
<devyn>
I like the idea of having all of these inter-implementation specs and stuff
<katlogic>
Scheme is still chaos, despite SRFI.
<katlogic>
Having single BDFL implementation around which others orbit seems to work better.
prophile has joined #elliottcable
<katlogic>
ELLIOTTCABLE: If you will ever become BDFL, can I be your minister of genocide or something?
* katlogic
really likes to opress people
devyn_ has joined #elliottcable
devyn has quit [Ping timeout: 240 seconds]
prophile has quit [Quit: The Game]
Sgeo has joined #elliottcable
alexgordon has joined #elliottcable
devyn_ has quit [Quit: leaving]
devyn has joined #elliottcable
<joelteon>
would it be feasible to implement SQL queries in rust devyn
<joelteon>
in rust macros I mean
<ELLIOTTCABLE>
katlogic: BDFL?
<ELLIOTTCABLE>
devyn: SRFI, or RubySpec?
<ELLIOTTCABLE>
but yeah I really like the idea of a very strict, but very small, core language,
<ELLIOTTCABLE>
like, to the point where I am completely serious that I will probably enforce the Paws trademark against implementations that do not comply, should this ever become a vaguely popular thing,
<ELLIOTTCABLE>
but making that language absolutely as small as possible. Then, absolutely everything else can be collaborative / opt-in amongst the implementations.
<ELLIOTTCABLE>
that's especially important with the whole "multiple-langauge language" thing I'm so desperately trying to make work (the Paws patois)
<ELLIOTTCABLE>
katlogic: you're welcome to be my Master of Genocide.
<ELLIOTTCABLE>
-learn Master of Genocide = katlogic is the official #ELLIOTTCABLE "Master of Genocide."
<purr>
ELLIOTTCABLE: Learned `Master of Genocide`.
<ELLIOTTCABLE>
-forget Master of Genocide
<purr>
ELLIOTTCABLE: Forgot 'Master of Genocide'.
<ELLIOTTCABLE>
-factoid katlogic
<purr>
ELLIOTTCABLE: Error: Factoid not found.
<ELLIOTTCABLE>
-learn katlogic = The #ELLIOTTCABLE Minister of Genocide
<purr>
ELLIOTTCABLE: Learned `katlogic`.
<ELLIOTTCABLE>
katlogic: well, SRFI were after-the-fact
<ELLIOTTCABLE>
katlogic: I intend to do a lot of thinking on this before Paws ever even has a chance to be remotely popular, y'know?
<ELLIOTTCABLE>
katlogic: also, it's a huge part of the goal of paws
<ELLIOTTCABLE>
will explain later, much to do over here,
<ELLIOTTCABLE>
but as I keep saying, Paws implementations are VMs for a class of languages;
<ELLIOTTCABLE>
and it's *intended* that the Paws space be fragmented into multiple languages, that make multiple people happy.
<ELLIOTTCABLE>
however, unlike the Scheme space, it's explicitly intended to be done in a way that's "as inter-compatible as possible" at any point.
yorick has quit [Remote host closed the connection]