rckts has quit [Remote host closed the connection]
rckts has joined #elliottcable
rckts has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
rckts has joined #elliottcable
rckts has quit [Client Quit]
devyn has quit [Read error: Connection reset by peer]
devyn has joined #elliottcable
<joelteon>
SO
<joelteon>
can curl fake the hostname it is requesting
<joelteon>
oh, that's easy
<joelteon>
fuck me
<joelteon>
why am I such an idiot
<joelteon>
why don't I ever think of anything
<devyn>
lol HTTP Host: header
<purr>
lol
<devyn>
I'm thinking I should call my ISP tomorrow
<devyn>
before I went on vacation I was getting 30 Mbps and I just shrugged it off as a bad day
<devyn>
but I'm still only getting 30 Mbps
<devyn>
and we pay for 100 Mbps
<devyn>
:|
<devyn>
normally I /do/ get nearly 100 Mbps
<joelteon>
yeah, i know devyn
<joelteon>
i thought of that
<joelteon>
RIGHT after i asked that question
<joelteon>
and after 2 days of adding hostnames to /etc/hosts for tests
<joelteon>
i think asking questions on freenode somehow galvanizes my brain into action
<devyn>
haha
<joelteon>
i need either a rubber duck, or an empty channel of my own
<joelteon>
that should be easy
eligrey has quit [Quit: Leaving]
<devyn>
I think I may have fed a smoking troll
<devyn>
this guy was like "it's just as much my right to smoke as it is yours to not smoke" which is perfectly okay I guess but then he was like "second-hand smoke may be unpleasant to non-smokers but it won't hurt you"
<devyn>
._.
<devyn>
and he got all ridiculous about banning smoking in public places
<devyn>
saying that was infringing upon his rights
<devyn>
lol
<purr>
lol
<whitequark>
tell him you like to release asbestos dust in public places
<whitequark>
it's fluffy and kinda fun
<devyn>
he's demanding I dig through research papers to prove him wrong because he's "seen them before and they all use testing methodologies that can be easily shown to be flawed"
<devyn>
:/
<whitequark>
that's easy, go to pubmed.com, pick random paper, let him explain how exactly it is flawed
<devyn>
even easier, Wikipedia page has 180 references on the subject, most of which are academic papers
<devyn>
I linked him to that but "Wikipedia can be edited by anyone so it doesn't matter"
<devyn>
*count
<devyn>
(paraphrasing)
<whitequark>
tbh he does have a point, there's a *ton* of shitty studies out there, with tiny sample groups or clearly biased ones or something
<whitequark>
but not on smoking, that has been studied rather extensively
<devyn>
that's bound to happen with any popular research subject though
<whitequark>
this happens more to unpopular ones due to lack of funds
<devyn>
okay, how about "politically popular but unfunded"
<devyn>
:p
<whitequark>
can't afford testing ten thousand people? sure, testing twenty is just as well
<whitequark>
everything by Fabrice Bellard, in general
<whitequark>
but yeah, I liked that blog post quite a bit
<whitequark>
cuttle: "// not all fields are used by all instruction types." is why one shouldn't probably use go
<devyn>
qemu is fucking awesome
<devyn>
whitequark: does Go not have unions, or something? I haven't looked yet
<whitequark>
devyn: nope, not even parametric types
<devyn>
oh ew
<whitequark>
"parametric types do not you need" *wave* -- rob pike
<whitequark>
cuttle: the most interesting part of that article is how it handles indirect jumps
<whitequark>
frankly
<whitequark>
that's really the most contentious point for dynamic recompilation
<whitequark>
or static. it also demonstrates why the static one is more cool than practical :p
<cuttle>
devyn: it has polymorphism though so effectievly unions
<cuttle>
one-argument polymorphism but still that's as much as most langauges
<cuttle>
also it does have static duck typing
<cuttle>
so yeah parametric is a big missing spot etc.
<cuttle>
but it's not that bad
<cuttle>
it has the exact equivalent of unions
<cuttle>
and i mean c has no parametric types either
<cuttle>
i'd much rather use go if i didn't have to use c
<cuttle>
like come on, goroutines
<cuttle>
those are fucking useful
<devyn>
sure, if you've already got an entire fucking OS under you
<cuttle>
compare a goroutine lexer-parser-etc. to like a reentrant one in C
<cuttle>
devyn: exactly fucking when I said I would use it...
<devyn>
:p
<cuttle>
"if I didn't have to use c"
<cuttle>
like, have you ever tried to write a reentrant parser in c from scratch
<devyn>
well, there are other languages that can run that low level
<cuttle>
or looked at lua's
<cuttle>
it's fucking gross
<cuttle>
well like i feel like rust's linear typing isn't ready for prime time
<devyn>
I have seen the output from ragel parsers in C
<cuttle>
and go has *tons* of support
<devyn>
it is yucky
<devyn>
but that could just be ragel
<whitequark>
devyn: I find it okay
<whitequark>
not worse than say bison
<devyn>
I've only ever attempted to write a fairly minimal parser in C, for a FORTH-like language
<whitequark>
note that ragel has like seven modes for generating C parsers
<cuttle>
look at lua's parser soruce
<cuttle>
it's awful
<whitequark>
with varying level of yuckiness
<cuttle>
if it were in go it would be much better
<whitequark>
cuttle: says more about lua
<cuttle>
whitequark: not at all
<cuttle>
whitequark: if it weren't reentrant it wouldn't be nearly as bad
<whitequark>
don't tell me how a language without ADTs is good for writing parsers
<cuttle>
goroutines and other coroutine/continuationey/generator things
<whitequark>
just... don't
<cuttle>
just let you write reentrant things that don't look ugly
<cuttle>
whitequark: go effectively has them
<cuttle>
it's more verbose than haskell's notation for sure but
<whitequark>
you mean casting everything to interface{} ?
<cuttle>
no I do not mean that
<cuttle>
you can do things like
<cuttle>
define a polymorphic function prettyprint
<cuttle>
and stuff
<whitequark>
what I'm talking about is invariants. how do you represent type option = None | Some a in go ?
<cuttle>
idk
<whitequark>
*facepalm*
<whitequark>
yeah, idk, right.
<cuttle>
i didn't say idk to your question
<whitequark>
oh
<whitequark>
okay then
<cuttle>
I can think of plenty of ways
<cuttle>
like
<cuttle>
interface with an isNone function or something
<cuttle>
yknow
<devyn>
cuttle, do you really think that's acceptable
<cuttle>
not the most beautiful ways but it's possible
<devyn>
:p
<cuttle>
yes in fact I do
<cuttle>
it's better than the way in C
<cuttle>
or at least as good
<whitequark>
lolwhat?
<purr>
lolwhat
<devyn>
we're not talking about C
<whitequark>
in C you can have a tagged union
<whitequark>
which beats your isNone at any time of day
<cuttle>
I would disagree
<whitequark>
sure, it's unsafe, but that's how C is in general
<cuttle>
I would say they're just as unfun to handle
<cuttle>
and with all of go's other benefits
<cuttle>
over c
<cuttle>
for general purpose application stuff
<cuttle>
I would rather use go
<cuttle>
for a compiler than C
<cuttle>
any day
<whitequark>
case(TYPE(ast)) { case TYPE_op: ast.op.lft + ast.op.rgt }
<whitequark>
that's pretty convenient
<whitequark>
it goes without saying that I'd use something *suitable for writing compilers*
<cuttle>
whitequark: I'm saying given the choice of the two
<cuttle>
I would rather use Go
<cuttle>
sure Go isn't perfect
<cuttle>
but I place a very high value on goroutines/other generatorey/coroutine things
<whitequark>
the problem with go isn't its imperfection, it's that it has had how much, forty years to learn?
<whitequark>
and it has not
<whitequark>
s,learn,improve,
* cuttle
sighs
<whitequark>
thirty, ok, same idea
<cuttle>
i'm not arguing for go's perfection, i'll cop to its imperfections as easily as anyone
<cuttle>
i'm just arguing writing a compiler in go is an infinitely less painful exercise than doing it in c
<cuttle>
jesus christ
<devyn>
perhaps
<devyn>
honestly I'd probably go with C/++ anyway because I've now realized how important mature libraries are
<devyn>
support-wise
<whitequark>
though the things you need mature libraries *cough*boost*cough* in other languages are for free
<devyn>
:p
<devyn>
yeah I haven't really touched C++ much
<devyn>
I'm kind of afraid of it honestly
<devyn>
it seems like a beast
<devyn>
in the bad way
<devyn>
but, you know, things like being able to use LLVM directly, instead of having to rely on someone's potentially shitty wrapper that they refuse to fix
<devyn>
are worth it
<whitequark>
fork it
<cuttle>
c++ is easy, just painful
<cuttle>
if i need to write something in c++ I can do it
<whitequark>
you'll need to fork it anyway
<whitequark>
(easy) lol. yeah.
<purr>
lol
<whitequark>
C is also easy.
<cuttle>
devyn: go's wrapper is direct
<cuttle>
like, practically just the c api
<devyn>
ok
<cuttle>
for llvm
<devyn>
maybe LLVM is a bad example then
<devyn>
:p
<whitequark>
especially if you don't try to write correct code
<cuttle>
like, i'd rather use llvm from go than haskell because haskell's bindings are a one man weekend project without support for fucking structs
<cuttle>
or there might be now but I can't fucking find out
<devyn>
that's the kind of thing I'm talking about
<whitequark>
cuttle: llvm-general?
<devyn>
:p
<whitequark>
devyn: see, there are *still* features in LLVM which are not present in its C API
<whitequark>
I've made some patches but didn't pull through with integration
<whitequark>
because frankly that's a bit of pain in the ass
<whitequark>
even with commit rights lol
<whitequark>
cuttle: llvm-general bindings are actually better than ocaml's in several ways
<whitequark>
I've updated ocaml bindings based on llvm-general ones
<whitequark>
and I'm pretty sure it has support for structs
<devyn>
that seems like a pretty big deal
<devyn>
it's not impossible to use LLVM without structs
<devyn>
but
<devyn>
it makes it easier
<whitequark>
devyn: it's just not true, firstly
<cuttle>
whitequark: ok
<cuttle>
the blog post announcing it said it had no support for structs
<cuttle>
and it was several years old but
<cuttle>
there was no documentation anywhere on the interent otherwise
<cuttle>
it's hard to figure out how to sue
<cuttle>
use
<whitequark>
read the fucking source
<whitequark>
even if the binding was documented, that's how you work with LLVM in general
<cuttle>
oh that sounds fun
<cuttle>
jesus christ
<devyn>
okay
<whitequark>
seriously, 3/4th of my time working on LLVM were spent reading C++, C++, and more C++
<whitequark>
I don't even know Haskell and it's rather clear how to use them
<cuttle>
i don't disbelieve there are structs
<devyn>
cuttle: it's likely that immediately at release it didn't have structs
<cuttle>
just the only fucking blog post on the planet about using haskell and llvm
<cuttle>
said it didn't
<devyn>
which is what you're talking about
<cuttle>
so at release it didn't
<cuttle>
i know
<cuttle>
i fucking konw
<cuttle>
the poitn is
<cuttle>
there is zero documentation
<cuttle>
not even fucking hackage definition lists
<devyn>
well a) you can generate those yourself very easily
<devyn>
(haddock)
* whitequark
just wrote `def schedule_schedule_delivery`
<whitequark>
we need to go deeper
<devyn>
and b) you shouldn't really expect docs for a fairly simple wrapper
<whitequark>
kids these days!
<cuttle>
devyn: it's not fairly simpe
<cuttle>
haskell to c is not straightforward
<devyn>
true, but in this case it's not so bad
<devyn>
the wrapper is fairly readable
<devyn>
as far as Haskell goes
<devyn>
(most people aren't very good at writing Haskell readably, though)
<cuttle>
the point is i really don't want to read the source of a library to use it
<whitequark>
cuttle: with LLVM, you *have* to
<whitequark>
always
<whitequark>
even if it's LLVM itself
<whitequark>
unless maybe you're only doing super trivial stuff which is never ever backend-specific or touches floating point or calling conventions or anything
<devyn>
it's also a pretty damn useful skill to have, to be able to understand others' code even if it's not that great
<devyn>
LLVM is so gigantic that there are a lot of people working on it
<whitequark>
it's just 2.5MLOC
<devyn>
I'm sure they have people going around as janitors, but you can't clean up everything perfectly
<devyn>
sometimes it just matters that it works and doesn't cause any problems with anything else
<whitequark>
LLVM devs are actually a bit on the cavalier side here
<whitequark>
if it makes code better but breaks something, they do the change pretty much always
<devyn>
you would know; I don't really contribute all that much to anything but my own projects :p
<whitequark>
there's a reason you need, quote, 1-2 people full-time for the inclusion of your backend into *mainline*
<devyn>
whitequark: by the way, since I'm back home, we should get back to working on ocamltrader maybe tomorrow
<whitequark>
devyn: yeah
<cuttle>
change of topic: want to design a syntax with me?
<cuttle>
a good one for multimethods
<cuttle>
there's always just prefix ones
<cuttle>
but i kind of want to see if there's a good smalltalk-esque one
<cuttle>
that like doesn't have infixes as a special case
<whitequark>
as a special case?
<cuttle>
yeah idk if it's possible and maybe infixes have to be special cased, or you need context sensitive syntax like apl/j
<whitequark>
examples?
<cuttle>
idk like
<cuttle>
you know smalltalk's syntax
<cuttle>
i want something that's not prefix syntax like either f(x,y) or (f x y) but still doesn't privilege one argument over the others
<cuttle>
or alternatively can privilege any one argument
<cuttle>
like it'd be sweet to do something like
<cuttle>
3 (+ 3) sqrt (^ 2)
<cuttle>
like, chain messages
<cuttle>
but it's multidispatch so you can chain with any of the arguments