ELLIOTTCABLE changed the topic of #elliottcable to: a _better_ cult
<vigs>
hay
<joelteon>
hi
<purr>
joelteon: hi!
<joelteon>
shut up purr
* vigs
pets purr
* purr
rrrr
<vigs>
attabot
* joelteon
pets purr
* purr
rrrrrr
<vigs>
what how dare you get more r's than me
<vigs>
you just told purr to shut up
* vigs
pets purr
* purr
rrrrr
<vigs>
LOVE ME, DAMMIT
<joelteon>
:^)
<vigs>
SSL added and removed here :^)
* ELLIOTTCABLE
sighs
<ELLIOTTCABLE>
Willox: I stole that from you, and got a mention on-stage at JSconf about it.
<ELLIOTTCABLE>
also, about a hundred tweets about me so far, random crap like "WTF is wrong with gmail" and "why does @ELLIOTTCABLE's profile break gmail?" and etc etc
<ELLIOTTCABLE>
consistently hilarious.
Sgeo has quit [Remote host closed the connection]
Sgeo has joined #elliottcable
eligrey has joined #elliottcable
eligrey has quit [Client Quit]
eligrey has joined #elliottcable
<devyn>
haha
<vigs>
hella
Willox has quit [Quit: Connection closed for inactivity]
katlogic has quit [Ping timeout: 276 seconds]
katlogic has joined #elliottcable
alexgordon has quit [Quit: My iMac has gone to sleep. ZZZzzz…]
alexgordon has joined #elliottcable
alexgordon has quit [Quit: Computer has gone to sleep.]
<ELLIOTTCABLE>
Off the top of my head, Paws (the one and only) and Tires (new), both my own; Tempus, glowcoil's FRP / temporal work; Furrow, alexgordon's absolutely boring Rut language; errrrr Cascade,
<ELLIOTTCABLE>
at least two others I can't think of the names of right now, … and wasn't cloudhead working on one at one point? can't recall.
<ELLIOTTCABLE>
Cheery: quite a good syntax for what? Anything in particular that you're tackling?
<ELLIOTTCABLE>
And does your work fit into any particular paradigm? Super obviously functional, procedural, objective, etc?
<ELLIOTTCABLE>
(I didn't get time to look in detail.)
Willox has joined #elliottcable
<Cheery>
generic purpose dynamic language, such as javascript or python.
<Cheery>
I don't think it's tied to a paradigm. Except maybe from optimization point of view.
<Cheery>
You're busy with something?
<Cheery>
"good syntax for what" is actually quite good point. I've been working on the syntax by what my interests have been.
<Cheery>
enjoying using coffeescript, but I don't really like about the callback rich javascript that is missing modules.
vil has joined #elliottcable
<ELLIOTTCABLE>
Cheery: re-phrase; whaddya mean by "I don't really like about the callback rich javascript that is missing modules."
<ELLIOTTCABLE>
also, you're a man after my own heart, then. I write a lot of JavaScript. And I grew up in Ruby, so I'm compfortable with CoffeeScript's syntax.
<ELLIOTTCABLE>
that said, I dislike CoffeeScript, and only use it when I have to. /=
<ELLIOTTCABLE>
vil, my fren!
<Cheery>
ELLIOTTCABLE: I don't like to do an XMLHTTPRequest and then attach a listener to it to respond when it completes.
<Cheery>
or use fs. anything else but *Sync
<katlogic>
It's callback hell for short.
<katlogic>
Cheery is from the other camp than js and monads, namely hiding that complexity using cooperative scheduling / coroutines.
<katlogic>
"Its liek threads but without all the horrible locking issues"
joelteon has joined #elliottcable
<Cheery>
also I know I can get modules into javascript easily. browserify, requirejs, whatever. I don't like the setup
<Cheery>
to get into that stage that I can write something.
<Cheery>
also don't like frameworks.
<katlogic>
People don't write JS because they like it, but because of network effect.
<katlogic>
It's hard to stage a coup d'tat in browser world. Google is pushing this Dart thing really hard and it will probably still not happen.
<Cheery>
yeah.
<ELLIOTTCABLE>
yerp
<ELLIOTTCABLE>
JavaScript isn't that bad.
<ELLIOTTCABLE>
Seriously.
<katlogic>
Cheery: Anyhow, how's the gc going?
<ELLIOTTCABLE>
katlogic's statement stands; even *I* don't "write it by choice": if I could write another language, I would.
<ELLIOTTCABLE>
but barely.
<ELLIOTTCABLE>
It's not some horrible hell of evilness, if you have any brains at all when you're working in it.
<katlogic>
Yeah, for a thing designed in 10 days, it's not *that* bad.
<ELLIOTTCABLE>
It's simply mildly inferior, at *most*, to something like Ruby or Rust or Haskell, in terms of developer satisfaction.
<ELLIOTTCABLE>
oh, no, it was absolutely terrible ten years ago.
<ELLIOTTCABLE>
and definitely when designed.
<ELLIOTTCABLE>
but as of *today*? Writing in JavaScript is not nearly as fucking-terrible as people act like it is.
<ELLIOTTCABLE>
a lot of the in-language problems have been solved, or are reaching the end of the process-of-being-solved.
<ELLIOTTCABLE>
as for Cheery's concerns about deployment, build, all that jazz ... that's A) more an artifact of the web, than anything to do with JavaScript, and B) *also* about to be solved
<katlogic>
The moment ES7 introduces hash keys for objects I'll be very happy kat logic
<ELLIOTTCABLE>
(for a Web value of "about". so, five years.)
<ELLIOTTCABLE>
HTTP2 and ES6 modules together will make deployment as we currently think about it, very much a non-issue.
<Cheery>
you're right.
<katlogic>
Cheery: The worst part is, if I had the energy to focus like you I'd make the VM you're designing support JS semantics.
<katlogic>
Because thats the best way to sell it.
<ELLIOTTCABLE>
katlogic: explain
<katlogic>
Write good JS VM, accidentaly add bearable semantics dialect as well.
<katlogic>
Embrace, extend, extuingish.
ELLIOTTCABLE changed the topic of #elliottcable to: Embrace, extend, extuingish.
<Cheery>
katlogic: not sure if it would work. in JS the neat stuff is the APIs, and how they stay quite stable. it's not only that it's relatively safe to navigate to a page and run JS apps.
<katlogic>
Cheery: No, the idea is just VM.
<katlogic>
I'm mostly working with V8 and LuaJIT these days.
<Cheery>
katlogic: on the gc. I've thought out I should have some kind of data structures on top of the C struct model.
<katlogic>
Cheery: Hmm?
<katlogic>
You mean some magic annotation for traversal hints, instead of writing explicit tracing routines?
<Cheery>
the GC should be able to read about a table what kind of structures those are
<Cheery>
yeah. runtime type annotation
<ELLIOTTCABLE>
I replaced Candy Crush with http://vocabulary.com/ in my schedule, and now I'm at least 12% smarter.
<katlogic>
Cheery: Will be slow, and is really worth it only if you actually support creation of such types at runtime.
<katlogic>
ELLIOTTCABLE: You guys rave about theoretical/academic design, so we're going to bore you with engineering points :>
<ELLIOTTCABLE>
not boring!
<ELLIOTTCABLE>
I just don't understand it, and want to. I have much to learn.
<Cheery>
katlogic: if it's slow, can't I JIT it?
<Cheery>
:/
<ELLIOTTCABLE>
Cheery: "katlogic: if it's slow, can't I JIT it?" wat.
<purr>
beep.
<ELLIOTTCABLE>
died died died
<katlogic>
Cheery: No, the idea is if the structures are fixed anyway, there is no reason to have runtime annotation for gc.
<katlogic>
Cheery: It's simpler to just annotate structure in C comments and meta-gen C traversal code from that.
<katlogic>
And even that would be overkill unless the structures are complex enough to demand meta programming or runtime introspection. In Lua, the relevant traversal code is not that big (say 150 lineish).
<katlogic>
V8 took your idea and ran with it though, types of GC annotation in objects is done using C++ template traits.
<katlogic>
(Which simply generate the tracer code, not data, tho)
<Cheery>
for some reason the difference between what you're describing, and what I thought doesn't feel too big. writing the traversal code yourself is just an optimization, or sort of thing a compiler could do for me, but I'm doing by hand for now.
<katlogic>
Cheery: Well, I'm lazy person. For me it's simpler to write one time traversal code rather than whole metadata / metaprogramming gizmo infrastructure.
<Cheery>
I can still compose the data structures I have, from larger components, get the benefits, use hand-written traversal code.
<ELLIOTTCABLE>
I'm missing something, here.
<ELLIOTTCABLE>
What're you trying to do? Summarize for me, you'e got backstory I don't know.
<katlogic>
Cheery: Well, in case you use the metadata for something else, fe. it's generic introspection, then your approach makes perfect sense.
<katlogic>
Since it's component reuse.
<katlogic>
Generally I'm too old for inventing complex generalized component for single use when shorter, to the point direct implementation suffices.
<Cheery>
ELLIOTTCABLE: I'm looking up to getting my language runtime to work properly. I need to give it a simple garbage collector for now.
<Cheery>
but I have to design it such that I can come back and work on the GC problem properly.
<Cheery>
without having to change the whole project afterwards to match.
<ELLIOTTCABLE>
hm.
<ELLIOTTCABLE>
yeah, I completely fucking ignored GC.
<katlogic>
Cheery: The changing afterwards should not be that much of a problem actually.
<ELLIOTTCABLE>
I foolishly treated it as an implementation detail that didn't need any consideration in the semantics' design.
<ELLIOTTCABLE>
so, I really really rally hope that doesn't come and bite me in the ass.
<katlogic>
Cheery: Only references which can be actually followed are interesting for GC anyway, so this is always guaranteed by nature of the beast.
<Cheery>
katlogic: might not be. but I keep thinking of it and getting tressed while doing the remaining stuff. always when I add a line.
<katlogic>
aka you can always write tracer.
<katlogic>
ELLIOTTCABLE: This is generally microoptimization part. Tracing gc will be always just that :>
<ELLIOTTCABLE>
well, it's Paws, yo
<ELLIOTTCABLE>
it's fucking weird.
<ELLIOTTCABLE>
I'm not even sure it *can* be gc'd.
<ELLIOTTCABLE>
like, literally at all.
<Cheery>
on this. I thought I need to rewrite my code such that I won't miss placing a write barrier.
<katlogic>
ELLIOTTCABLE: Refcounting?
<Cheery>
while I'm at it, considering other uses. I don't really like writing C plain.
<katlogic>
Cheery: Write barriers come after you do *incremental* g
<katlogic>
gc
<katlogic>
and yes, its difficult
<ELLIOTTCABLE>
katlogic: the entire object-space of the program is one, large, traversable graph.
<ELLIOTTCABLE>
Extremely simple.
<ELLIOTTCABLE>
there's no such thing as variables, or scope, or ...
<Cheery>
..
<Cheery>
need to read about paws
<ELLIOTTCABLE>
nothing to "hide" some chunk of data (some sub-graph, then) in the system, in a way that's provable
<katlogic>
Cheery: The graph never reduces?
<katlogic>
ELLIOTTCABLE: The graph never reduces?
<katlogic>
dang
<ELLIOTTCABLE>
so, the problem becomes one of design, not implementation.
<katlogic>
Well, as long the input is finite its ok
<ELLIOTTCABLE>
saying "how do we add semantics that allow sections of the graph to become noticeably deprecated".
<ELLIOTTCABLE>
have some ideas, but nothing firm.
<katlogic>
Same as always, if it has references it exists. Parents can disown their child, thus barring their existence.
<ELLIOTTCABLE>
there's several approaches: assuming we *can* make the objective-scoping system a little more rigorous / tight; and thus, allow routines' contents to become unreferenced when they complete, or similar ... then we've got the way paved for a *very* powerful / efficient GC **because** the language is already an extremely simple graph of simple references ...
<ELLIOTTCABLE>
... and on the other hand, I've got ideas of making it completely un-managed, and making clearing of sections of the graph become a low-level operation.
<ELLIOTTCABLE>
it is, after all, supposed to be an intermediate-form tool for abstracting out higher-level languages. It may be possible to *abstract* GC onto a language.
<katlogic>
Depends what the real problem set looks like.
<katlogic>
If upper bounds are known beforehand, no GC is really necessary, everything can be fairly efficient.
<ELLIOTTCABLE>
unlikely; I can't really know the eventual uses or constraints of the system very precisely, *because* it's designed to allow the creation of new languages on top of it.
<katlogic>
s/GC/memory management/
<ELLIOTTCABLE>
different languages assembled on top of Paws may have wildly differing goals; and it's very very rare that I'm willing to restrict the possibilities of those languages ...
<ELLIOTTCABLE>
... basically the only true assumption in place at the moment is that languages targeting Paws are interested in performance-by-asynchronicity, at the expense of performance-in-synchronicity.
<katlogic>
Well, if you're trying to create answer to the meaning of life the universe and everything, obviously tracing gc then
<ELLIOTTCABLE>
i.e. any language whose purpose is suited by being slow, but massively asynchronous.
<ELLIOTTCABLE>
katlogic: wat.
<purr>
beep.
<ELLIOTTCABLE>
that's a good one. :P
<ELLIOTTCABLE>
-what
<purr>
<Cheery> katlogic: if it's slow, can't I JIT it?
<ELLIOTTCABLE>
wait
<ELLIOTTCABLE>
what are the chances of that D:
<ELLIOTTCABLE>
-what
<purr>
<Nuck> Imagine if all porn everywhere just had dolphins over the tits
<ELLIOTTCABLE>
... momentarily terrified that the whatdb got wiped ... >,>
<ELLIOTTCABLE>
Cheery: are you eastern-european as well?
<ELLIOTTCABLE>
-clouds
<purr>
ELLIOTTCABLE: is stuck up in the clouds; hilight 'em if you want 'em.
<ELLIOTTCABLE>
cloudhead: are you that surprised that people know of me? :P
<katlogic>
I think Cheery is a viking or something like that.
<ELLIOTTCABLE>
cloudhead: also, you *just* followed me? so hurt ;_;
<Cheery>
ELLIOTTCABLE: not, unless you turn the map clockwise once.
<cloudhead>
ELLIOTTCABLE: haha I followed you for a long time, but then your output was just too high
<cloudhead>
so I had to unfollow, because I couldn't keep up with my twitter
<ELLIOTTCABLE>
5:37 PM <+alexgordon> joelteon: what about homoglyphs?
<ELLIOTTCABLE>
5:37 PM <+joelteon> what'd you call me
<katlogic>
Did the same, why do you tweet rubbish all the time ELLIOTTCABLE?
<ELLIOTTCABLE>
cloudhead: yeah, I'm sure (=
<ELLIOTTCABLE>
cloudhead: just screwing with you.
<ELLIOTTCABLE>
well what's rubbish by your standards?
<ELLIOTTCABLE>
I use my Twitter as a social network. Most of the devs I know, don't.
<cloudhead>
basically, you tweeted more than all the people I followed put together
<cloudhead>
:D
<ELLIOTTCABLE>
Most of my tweets come from my everyday-life stuff. More like Facebook than how I see most devs using Twitter.
<katlogic>
cloudhead: Yup :)
<cloudhead>
and I read every single tweet on my feed
<cloudhead>
so was a bit much
<alexgordon>
I mainly follow ELLIOTTCABLE for his profile pics
<ELLIOTTCABLE>
quoting friends IRL, photos of shit going on around me, comments on my dogs or friends or ... all that.
<ELLIOTTCABLE>
alexgordon: wat.
<purr>
beep.
<ELLIOTTCABLE>
THREE IN AN HOUR
<ELLIOTTCABLE>
LOVIN' IT
* katlogic
expects twitter to work as a fancy rss
<katlogic>
so its a lot of hit or miss
<ELLIOTTCABLE>
devyn: re: aliens,
<katlogic>
but one can find genuinely interesting folks
<ELLIOTTCABLE>
devyn: it's not spec'd, but it's acceptable to me to make aliens "loop."
<alexgordon>
Cheery: south american?
<cloudhead>
ELLIOTTCABLE: I am a little surprised because I don't know of your "external" persona
<cloudhead>
I only get the view from #elliottcable
<ELLIOTTCABLE>
devyn: that is, if called directly without the call-pattern of clone-stage-unstage, then when they consume their full complement of arguments, they can be called again.
<ELLIOTTCABLE>
devyn: you're welcome to do so if that's more efficient for you.
<Cheery>
alexgordon: how did you turn the map? 8-|
<ELLIOTTCABLE>
katlogic: yah, the people *I* follow are like that
<ELLIOTTCABLE>
my stream is almost entirely consumed by interesting tweets by interesting people:
<Cheery>
alexgordon: and which map?
<alexgordon>
Cheery: south african?
<ELLIOTTCABLE>
dev stuff, linguistics stuff, math stuff, feminist stuff, local / Chicago stuff, and my actual-friends'-stuff
<alexgordon>
ELLIOTTCABLE, the feminist
<ELLIOTTCABLE>
cloudhead: I can't tell which way to parse that sentence
<katlogic>
ELLIOTTCABLE: for all you said reddit is better :(
<katlogic>
I'm looking for OC mostly.
<ELLIOTTCABLE>
cloudhead: as in, you don't know of my IRL self? or my developer-self? or ...?
<ELLIOTTCABLE>
katlogic: like, humour-OC?
<ELLIOTTCABLE>
and reddit is *terrible* for that shit
<katlogic>
anything OC, really
<ELLIOTTCABLE>
because it's a fucking evil place full of fucking evil people.
<ELLIOTTCABLE>
I don't get what you mean by "OC."
<katlogic>
yeah, reddit is worse copypasta-wise than 4chan
<katlogic>
but its a good archive
<ELLIOTTCABLE>
almost everything I see on Twitter is a tweet written by the author of the tweet ...
<Cheery>
alexgordon: I thought I did not do an error on that.
<ELLIOTTCABLE>
I don't see a lot of rehashed links to common shit ..
<ELLIOTTCABLE>
devyn: re: locals, I'm not sure what you mean.
<ELLIOTTCABLE>
devyn: they .. work as they're spec'd. I'm pretty sure that part is entirely spec'd.
<cloudhead>
ELLIOTTCABLE: yea, any self outside of #elliottcable basically
<ELLIOTTCABLE>
*all* locals is, is a Thing, created when the Execution is created, and available at `<exec> locals` and `<locals> locals`,
<katlogic>
ELLIOTTCABLE: OC is literally anything you can put it in google and get no hits. No re-invented/re-posted shit. There are subreddits for *some* kinds of that thing, the other part is following weird people on twitter and perhaps soundcloud :>
<ELLIOTTCABLE>
then, the first combination of any sub-expression within that execution, is combined against that <locals> object
<ELLIOTTCABLE>
not complex.
<ELLIOTTCABLE>
also, miiiiiight be going to change.
<ELLIOTTCABLE>
Eventually, the locals-objects need to be *branching*, intelligent structures, to usefully handle branching execution paths and storing data unique to different branches ...
<katlogic>
OC is the holy goal of every true internet hipster. TIL is just ignorace. OC is staying in the know.
<ELLIOTTCABLE>
cloudhead: we should meet in person. (=
<ELLIOTTCABLE>
cloudhead: any chance you're doing StrangeLoop this year? or did I already ask that?
<katlogic>
ignorace isn't defined.
<katlogic>
Can you define it?
<ELLIOTTCABLE>
cloudhead: in-person me is very different from #ELLIOTTCABLE me.
<katlogic>
Cool, hello UB!
<ELLIOTTCABLE>
in fact, I'm tiring of #ELLIOTTCABLE-me.
<cloudhead>
ELLIOTTCABLE: I was going to submit a proposal but then my friend freaked me out
<ELLIOTTCABLE>
freaked you out? :P
<cloudhead>
he said St-Louis was really dangerous
<cloudhead>
lol
<purr>
lol
<ELLIOTTCABLE>
devyn: ... but for now, I'm hoping that can all be implemented libside, and we can stick to the simplest-possible-semantics (what they are right now) for scoping.
<ELLIOTTCABLE>
cloudhead: ... really? what the fck?
<ELLIOTTCABLE>
idk never been. weird.
* ELLIOTTCABLE
checks if St. Louis has sane carry-laws
<ELLIOTTCABLE>
where was it previously? I've never been.
<cloudhead>
always st louis
<ELLIOTTCABLE>
word.
<cloudhead>
I don't do much conferencing in general
<ELLIOTTCABLE>
because @puredanger lives there, I suspect.
<ELLIOTTCABLE>
neither do I. I've been to three in my life.
<ELLIOTTCABLE>
JSconf was loads of fun, though.
<cloudhead>
I usually find it boring
<cloudhead>
hmm cool
<ELLIOTTCABLE>
RealtimeConf was fucking unbeatable.
<ELLIOTTCABLE>
I can't imagine doing too many, though. Especially the high-energy type like Realtime or Chris's JSconfs.
<ELLIOTTCABLE>
I know Emily went to fucking *twelve* last year.
<cloudhead>
heh
<ELLIOTTCABLE>
like, I'm doing two this year, and was begged to two more, and was like, dude, no. I can't handle four in a year.
<ELLIOTTCABLE>
I already travel too much /=
<cloudhead>
I don't think 4 would be too much, it's just whether it's worth the time/money
<ELLIOTTCABLE>
holy crap cloudhead, you have 11k followers. :D
<cloudhead>
the talks are often very low quality
<ELLIOTTCABLE>
last I'd looked, it was like 6k. O_O
<cloudhead>
lol
<purr>
lol
<ELLIOTTCABLE>
yeah, idk talks. Aren't so bad at the big conferences;
<cloudhead>
yea, it would be a lot more, but I took my twitter off my oss sites
<cloudhead>
cause I was sick of random people following me
<ELLIOTTCABLE>
and it's especially helpful to me, because I'm so buried in my little corner of everything ... weird obscure language-design topics, and shit
<ELLIOTTCABLE>
and I miss a lot of the big stuff.
<ELLIOTTCABLE>
saw like ten talks on WebRTC at Realtime, and I didn't even fucking know it existed.
<cloudhead>
hmm right
<ELLIOTTCABLE>
somehow I'd missed Sweet.js entirely, until I saw three talks mention it at JSconf.
<cloudhead>
haha
<ELLIOTTCABLE>
it's very much a ..........
<ELLIOTTCABLE>
intermixing of knowledge.
<cloudhead>
JS conferences seem to be pervasive
<vil>
hi ELLIOTTCABLE
<ELLIOTTCABLE>
the hallway tracks, if you know the right people, lend you depth ... and the talks and general environment lend you readth.
<cloudhead>
it's too bad cause I don't do js anymore
<ELLIOTTCABLE>
breadth*
<cloudhead>
so I feel a little outcast at those confs
* ELLIOTTCABLE
nods
<ELLIOTTCABLE>
are there no good Haskell confs? c'mmon.
<cloudhead>
not really
<cloudhead>
not like jsconf style
<ELLIOTTCABLE>
Haskell people are like Lisp people, so convinced their way is the way. They've *gotta* band together and mutual-masturbate their way to completion at least *ocassionally*!
<ELLIOTTCABLE>
;)
<ELLIOTTCABLE>
well, Ruby and JS confs are definitely interesting. perhaps even unique. *shrug*
<purr>
¯\(º_o)/¯
<ELLIOTTCABLE>
I really hope StrangeLoop is as good. :x
<ELLIOTTCABLE>
Only the hipster languages get the good confs.
<ELLIOTTCABLE>
Okay, I promise you Ponf will be hipstery and fun and you'll definitely have a good time
<cloudhead>
yea exactly
<cloudhead>
Ponf?
<cloudhead>
lol
<purr>
lol
<ELLIOTTCABLE>
since you'll definitely come and all since you'll definitely be a huge Paws user and everything <3
<ELLIOTTCABLE>
PawsConf.
<cloudhead>
oh haha
<cloudhead>
yea yea
<cloudhead>
looking forward
<cloudhead>
to Ponf
<ELLIOTTCABLE>
I feel like <Lang>Conf is burnt out. I've decided to cut the syllables and abbreviate. ;)
<ELLIOTTCABLE>
also if you add a U it gets very gay-sounding <'3
<ELLIOTTCABLE>
Pounf(tm)
<ELLIOTTCABLE>
(Pawnf? Pounfh?)
<ELLIOTTCABLE>
on a more serious note, actually,
<ELLIOTTCABLE>
would love to chat Paws with you, sometime. As usual, I always value your insight, despite the fact that we disagree on almost everything; Paws itself came a long way, although I work on it very little lately, it's also a more stable and sane Thing(tm) as a whole.
<ELLIOTTCABLE>
"Yes, some of us even have Apple static stickers in the back of our cars, no matter how postively 1985 that may be."
<ELLIOTTCABLE>
"I did similar things when I had an Amiga, way back when having an Amiga was like having a Mac."
<cloudhead>
:D
<cloudhead>
sure thing, I'd love to talk about it
<ELLIOTTCABLE>
"But we'll always be Macintosh first, and Macintosh at heart. The users are consistently more supportive, intelligent, less likely to use ALL CAPS in beta reports, and excited about products."
<ELLIOTTCABLE>
> less likely to use ALL CAPS in beta reports,
<cloudhead>
h
<cloudhead>
a
<joelteon>
h a
<Cheery>
ELLIOTTCABLE: are you a mac user?
<ELLIOTTCABLE>
Cheery: yep yep
<ELLIOTTCABLE>
Mac an *nix
<ELLIOTTCABLE>
but at the moment, I'm on Windows. Have been for a month, ish. Is very strange.
<katlogic>
Summer steam sales binge huh :>
<ELLIOTTCABLE>
devyn: re: API-hashed versioning,
<katlogic>
aka horrible idea perpetuated by c++ :)
<ELLIOTTCABLE>
katlogic: what about it? I know nothing about C++
<ELLIOTTCABLE>
well, I'm not sure how on earth to apply it to Paws, or *many* dynamic languages; but implementation details ignored, I really think we need to stop conflating user-facing "version" (i.e. updates to the concept, new features, things *people* will be interested in) and machine-facing "compatibility."
<ELLIOTTCABLE>
I want to take compatibility-testing out of the versioning system, and return versioning to the user. "Look! A new version of OS X!" "The newest iPhone is great for my needs" "I dislike the latest version of Windows.",
<ELLIOTTCABLE>
and then leave it up to (much smarter than us) computers to determine compatibility between two, well, changesets, basically, of code.
<ELLIOTTCABLE>
katlogic: explain C++'s versioning to me, or whatever you're talking about
eligrey has joined #elliottcable
<ELLIOTTCABLE>
devyn: I can find nothing about this with regards to Rust. Seems they used 0.X for a long time, and then switched to semver? idk.
<katlogic>
ELLIOTTCABLE: Symbol versions encode all types exposed in ABI.
<ELLIOTTCABLE>
well, I want to do something more *granular* than that.
<ELLIOTTCABLE>
and also not focused on types. or at least, not exclusively on types.
<katlogic>
Yeah, not to mention this is just ABI compatibility.
<ELLIOTTCABLE>
it should be trivial, or near-trivial, to know if <changeset DEADBEEF> of project ABC *actually affects* your particular use-case for project ABC.
<katlogic>
API is probably broader term as it involves usage/semantics, not just raw types.
<ELLIOTTCABLE>
yeah.
<ELLIOTTCABLE>
type signatures for external functions are a good start, though.
<ELLIOTTCABLE>
what I'd like to see is a specification, semver-style, for a *hash* function (idk if using that word appropriately) that predictably compresses versioning information into a comparable (upwards, downards, equal) string.
<ELLIOTTCABLE>
just a thought.
<ELLIOTTCABLE>
bbl
akshatj-c has quit [*.net *.split]
eligrey has quit [*.net *.split]
katlogic has quit [*.net *.split]
vigs has quit [*.net *.split]
joelteon has quit [*.net *.split]
ELLIOTTCABLE has quit [*.net *.split]
ag_dubs has quit [*.net *.split]
manveru has quit [*.net *.split]
eligrey has joined #elliottcable
ag_dubs has joined #elliottcable
katlogic has joined #elliottcable
akshatj-c has joined #elliottcable
manveru has joined #elliottcable
ELLIOTTCABLE has joined #elliottcable
joelteon has joined #elliottcable
vigs has joined #elliottcable
irclogger_com has quit [*.net *.split]
sammcd has quit [*.net *.split]
sammcd has joined #elliottcable
glowcoil has quit [Ping timeout: 252 seconds]
glowcoil has joined #elliottcable
irclogger_com has joined #elliottcable
akshatj-c has quit [*.net *.split]
akshatj-c has joined #elliottcable
<cloudhead>
hm why not use git sha for that?
<cloudhead>
major.minor-sha
<joelteon>
what a nasty version number though
<joelteon>
"yeah you'll need at least version 1.3.2-f1d2d2f924e986ac86fdf7b36c94bcdf32beec15
<joelteon>
"
<cloudhead>
short sha
<cloudhead>
not the full one
<joelteon>
oh
<cloudhead>
it's the 1st 7 chars
<joelteon>
f1d2d2f
<joelteon>
that's actulaly pretty close to being a palindrome
TheMathNinja has joined #elliottcable
Sorella has quit [Quit: Ex-Chat]
oldskirt_ has joined #elliottcable
oldskirt_ has joined #elliottcable
oldskirt_ has quit [Changing host]
<ELLIOTTCABLE>
not the same thing.
<ELLIOTTCABLE>
that's a changeset hash of *the entire codebase*.
<ELLIOTTCABLE>
including, by the way, documentation, comments, meaningless meta-data like merges ...
<ELLIOTTCABLE>
additionally, git hashes are non-directional: you need the *object* referred to by the hash, to see what its parent is.
<ELLIOTTCABLE>
I don't mean a SHA1-style, base-16 "hash" like that ...
<ELLIOTTCABLE>
I mean in the CS term; taking some data, and reducing it to a minimal format that conveys the particular aspect of the data we care about.
<ELLIOTTCABLE>
hashes often have particular characteristics with respect to eachother, desirable under certain conditions as outlined when the algorithm was designed.
oldskirt has quit [Ping timeout: 255 seconds]
<ELLIOTTCABLE>
I'm talking about an algorithm that, given some set, M, of lessay API "endpoints" (not necessarily the same thing as function signatures.", each of which has "properties", can express changes in those properties *relationally*.
<ELLIOTTCABLE>
that is, given hash A of changeset X, and hash B of changeset Y, there's an expressive relationship between A and B that can be analyzed to predictably determine that the X 'foo' endpoint's 'argument-one' property is "greater then" (in terms of codebase advancement, somehow) the same property for changeset Y.
<ELLIOTTCABLE>
in my head, the system would have to be as general as possible: I don't want to make assumptions about systems' structure.
<ELLIOTTCABLE>
perhaps we can even steal some approach from one of the generic RPC-ey call-systems? I'm sure the work of analyzing different programming environments for "what does a mutable-over-time API endpoint look like" has already been done.
<ELLIOTTCABLE>
for some languages and environments, this state would be completly determinable by static analysis, both for the API producer and the consumer of that API ... meaning versions, suddenly, don't matter, at all, to anyone. If a version of a library you depend on changes the semantics of an argument you call it with, then the version you "depend on" could be
<ELLIOTTCABLE>
automatically updates. tests could then be run, in dynamic languages; or further static analysis for correctness applied.
alexgordon has quit [Quit: My iMac has gone to sleep. ZZZzzz…]
<oldskirt_>
just a tuple of versions? all properties have a version assigned, bigger tuple means more properties
oldskirt_ is now known as oldskirt
<joelteon>
omg, dude
<joelteon>
the new safari devtools pretty-print javascript
Sgeo has joined #elliottcable
alexgordon has joined #elliottcable
<ELLIOTTCABLE>
oldskirt: well, duh, that's the basic data-structure.
<ELLIOTTCABLE>
oldskirt: I want a way to encode that into the shortest-possible, generic, and transport-safe format.
<oldskirt>
what is "transport-safe"
<oldskirt>
(1,13,190,19) seems pretty short and generic
<ELLIOTTCABLE>
uh
<ELLIOTTCABLE>
short for a library with one function that takes four arguments.
<ELLIOTTCABLE>
for a lot of systems, "properties" are going to involve more than the function arguments, too.
<ELLIOTTCABLE>
any variable element of a function that's *invariant* on the other elements.
<ELLIOTTCABLE>
i.e.: function's name, function's return type (if relevant) or number-of-return-values, or a coroutine's entry and exit points; each branch in the semantics that stands alone and could be changed seperately;
<ELLIOTTCABLE>
there's probably far more in a statically-analyzed system, too, than there would be in a somewhat-dyanmic/managed one.
<ELLIOTTCABLE>
so.
<ELLIOTTCABLE>
each "version" could basically be a 'diff' between two of those tuple-sets as you put it
<oldskirt>
well it seems pretty hard to think of any possible way of encoding all information about some code without giving the code itself
<ELLIOTTCABLE>
(although it's a tuple of tuples, because there's the additional dimension of "breakingness")
<ELLIOTTCABLE>
but that's just it, it's not *all* information. Just changedness.
<oldskirt>
ah
<ELLIOTTCABLE>
(so it's more like `(0.1, 0.13, 3.17, 1.8)`)
<ELLIOTTCABLE>
also, a tuple isn't accurate; it'd have to be a map.
<ELLIOTTCABLE>
if you have the tuple (x, x, 0.1, x) representing foo(int a, int b, float c)
<ELLIOTTCABLE>
and it changes to foo(int a, float widget, float c)
<ELLIOTTCABLE>
you now have v0.1 of "widget", a completely different argument, and the semantics of "b" have been removed.
<ELLIOTTCABLE>
so more:
<ELLIOTTCABLE>
(name 0.1, foo 0.13, bar 3.17, baz 1.8) representing widget(foo, bar, baz)
<ELLIOTTCABLE>
or sommat
<oldskirt>
hmmm operational transforms on the AST?
<ELLIOTTCABLE>
hm
<ELLIOTTCABLE>
actually, possibly, yeah. would need to look at a large sample of languages.
<ELLIOTTCABLE>
at least, that's a starting point, for non-statically-analyzable-languages.
<ELLIOTTCABLE>
human users, or IDEs, or tooling, would have to add to the basic "function-signature" version pulled out from the source.
<ELLIOTTCABLE>
i.e. an endpoint that does completely different things based on the presence or nullariness of the last argument, would need a versionable "property" for that semantic.
<ELLIOTTCABLE>
more of an issue in stateful languages, now that I think about it.
<ELLIOTTCABLE>
could probably do some cool things involving the test-suite, here, in environments that encourage that.
yorick has quit [Read error: Connection reset by peer]
yorick has joined #elliottcable
yorick has quit [Remote host closed the connection]
<devyn>
ELLIOTTCABLE: not Rust itself, but the libraries it compiles; they have some kind of hash. but I think I got confused