<HyperMonkey>
hm, it seems to be due to -vmthread ... if I change to -thread it works
sstc has quit [Quit: WeeChat 2.8]
hlisp has quit [Ping timeout: 265 seconds]
dborisog has joined #ocaml
hlisp has joined #ocaml
hlisp has quit [Ping timeout: 272 seconds]
hlisp has joined #ocaml
kark has quit [Ping timeout: 265 seconds]
hlisp has quit [Ping timeout: 264 seconds]
jao has quit [Ping timeout: 272 seconds]
waleee-cl has quit [Quit: Connection closed for inactivity]
hlisp has joined #ocaml
hlisp_ has joined #ocaml
hlisp has quit [Ping timeout: 272 seconds]
hlisp_ has quit [Ping timeout: 256 seconds]
mbuf has joined #ocaml
narimiran has joined #ocaml
madroach has quit [Quit: leaving]
vicfred has quit [Quit: Leaving]
Haudegen has joined #ocaml
olle___ has joined #ocaml
madroach has joined #ocaml
Haudegen has quit [Quit: No Ping reply in 180 seconds.]
Haudegen has joined #ocaml
ferd has quit [Ping timeout: 240 seconds]
t0b0 has quit [Ping timeout: 258 seconds]
t0b0 has joined #ocaml
ferd has joined #ocaml
ferd has quit [Ping timeout: 264 seconds]
kvda has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
hlisp has joined #ocaml
hlisp has quit [Ping timeout: 265 seconds]
jbrown has joined #ocaml
kvda has joined #ocaml
ferd has joined #ocaml
amiloradovsky has joined #ocaml
smazga has quit [Ping timeout: 272 seconds]
eterps has left #ocaml [#ocaml]
Serpent7776 has joined #ocaml
smazga has joined #ocaml
hlisp has joined #ocaml
troydm has quit [Ping timeout: 272 seconds]
Anarchos has joined #ocaml
troydm has joined #ocaml
mfp has joined #ocaml
Anarchos has quit [Quit: Vision[0.10.3]: i've been blurred!]
hlisp_ has joined #ocaml
hlisp has quit [Ping timeout: 256 seconds]
hlisp_ has quit [Ping timeout: 260 seconds]
hlisp has joined #ocaml
kvda has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
hlisp has quit [Read error: Connection reset by peer]
peterbb has quit [Quit: peterbb]
peterbb has joined #ocaml
hlisp has joined #ocaml
hlisp has quit [Ping timeout: 264 seconds]
pigeonv has joined #ocaml
waleee-cl has joined #ocaml
Haudegen has quit [Quit: Bin weg.]
glass has joined #ocaml
glass has quit [Changing host]
glass has joined #ocaml
theglass has quit [Ping timeout: 244 seconds]
<HyperMonkey>
I'm using ppx-jane and I get line/column numbers that are off in the error messages. is there a known workaround?
hlisp has joined #ocaml
pigeonv has quit [Ping timeout: 240 seconds]
zolk3ri has joined #ocaml
jao has joined #ocaml
Haudegen has joined #ocaml
narimiran has quit [Ping timeout: 246 seconds]
<HyperMonkey>
ah I found the problem I was invoking as `-pp ppx-jane` rather than `-ppx 'ppx-jane -as-ppx'`
hlisp has quit [Ping timeout: 260 seconds]
olle___ has quit [Quit: Lost terminal]
hlisp has joined #ocaml
sagax has quit [Ping timeout: 260 seconds]
<HyperMonkey>
what's the best way to declare a type that is basically just a tuple. is a one-case type the best way? type MyType = JustMyType of string*(string list)
<companion_cube>
`type foo = string * string list` works
<theblatte>
or just don't declare it, or declare it as a record to document each element type foo = {bla: string; gorks: string list}
<HyperMonkey>
ok, and what if I want `string list` to be an association list of string -> string. do I make it `(string * string) list` or is there a cleaner way to indicate that it's an association list?
<HyperMonkey>
record sounds good, thanks
<theblatte>
if you're using Base they have List.Assoc.t
sagax has joined #ocaml
<theblatte>
but yeah it's transparently just a (string * string) list
<HyperMonkey>
type Request = { url: string, headers: string List.Assoc.t };; so is this fine for a basic HTTP server?
<HyperMonkey>
assuming it will only handle GET requests
<theblatte>
I didn't know you could define an HTTP server with just a type ;)
<HyperMonkey>
well I'm going to fill in the implementation too, it's my first project with async
<HyperMonkey>
You might wonder how the compiler inferred that our function returns a value of type service_info. In this case, the compiler bases its inference on the field names used in constructing the record. ... oh drats it looks like choosing "simple" field names is a bad idea
zolk3ri has quit [Remote host closed the connection]
<octachron>
With disambiguation, field name collisions is not really problematic
hlisp has quit [Ping timeout: 264 seconds]
<theblatte>
it used to be much more annoying than now :)
hlisp has joined #ocaml
<zozozo>
e.g. you still see codebases with ADT whose constructor names are prefixed to avoid name clashes, and I always find it particularly annoying, ^^
<HyperMonkey>
putting the record type in it's own module looks like an appealing solution though
shmibs has quit [Quit: leaving =o]
<zozozo>
yeah it's become common practice to put each type in its own module (which sort of provides some kind of namespacing in addition)
hlisp has quit []
shmibs has joined #ocaml
FreeBirdLjj has joined #ocaml
<Leonidas>
heh, open a new lobste.rs thread, see the #ocaml crew already there :D
<Leonidas>
> Rust, as an ML in C++ clothing, combines the relevant benefit of the two.
<Leonidas>
after being explained exactly how the differences between Rust and ML make Rust less suited for it
<def>
:D
<def>
I don't really understand what there people are looking for.
<def>
If TSC is slow, it is not because of V8. It is because its design is shit.
<companion_cube>
Leonidas: about using rust to write a compiler?
<def>
You don't improve performance by 3 orders of magnitude by switching to anoter less suited but native language.
<def>
You just fix your implementation (if you aren't able to design a proper typechecking algorithm with a more appropriate language, adding new difficulties is not going to solve your problem magically).
tane has joined #ocaml
<def>
Though the answer you are quoting is correct.
<companion_cube>
I think it's also that TS is hard to typecheck
<companion_cube>
it does a lot of very advanced stuff
<companion_cube>
you can make a typechecker go really fast if you write it in C++ (or rust)
pigeonv has joined #ocaml
<Drup>
you can make a typechecker go really fast if you design the type system to admit fast typechecking
<Drup>
that's 100% the reason
narimiran has joined #ocaml
<Drup>
(ah, def said the same thing :D)
<companion_cube>
it's a conjunction of things
<Drup>
it really isn't though
<companion_cube>
if the typechecker is written in JS, it'll still probably be a bit sluggish
<companion_cube>
(or in python, for what it's worth)
<Drup>
changing implementation langage is going to stay in the same order of magnitude
<Drup>
making a proper design is going to change up to 3 order of magnitudes
<companion_cube>
going from python to rust can buy you 2 orders of magnitude
<Drup>
in general, absolutely. For a typechecker, not so sure
<companion_cube>
pretty sure :D
<Drup>
in any case, Scala/JVM have more than decent perf, their typechecker is slow as shit
<Drup>
(let's not talk about C++. It barely does anything and is still slow)
<companion_cube>
yeah, scala also has too complex a type system
<companion_cube>
"anything" what ? :D
<Drup>
that's ... exactly my point
<companion_cube>
I mean, outside of expanding templates which are turing complete, resolving crazy overloadings…
<Drup>
also, the rust typechecker is also pretty slow ...
<simpson>
"language X is slow" is sort of a reductive and unhelpful meme. All languages are slow; that's the tradeoff for being human-readable. Humans are slow.
<companion_cube>
the typechecker is not that slow
<companion_cube>
`cargo check` is fast
<Drup>
companion_cube: cargo check is fast comparatively to the whole pipeline, but it's not really that fast compared to OCaml/Haskell typing
<Drup>
(OCaml in particular)
<Drup>
(Haskell is also pretty good if you don't enable the crazy extensions)
<companion_cube>
well, OCaml is less ambitious on that I suppose
<Drup>
In all these cases, you can trace their perf to their design pretty easily. It has barely anything to do with the implementation language
<companion_cube>
you still need both a reasonably fast implementation language, *and* a reasonably fast to check type system
<def>
companion_cube: V8 is really fast, especially for dealing with the irregular kind of load that come up with a type checker.
<def>
assuming you do a good implementation in rust (which means at least you give up on dynamic memory management), you can will make it marginally faster.
<companion_cube>
marginally? I'd expect it to be several times faster at least
<def>
but if you are not able to make a decent type checker in a dynamic and quite suitable progamming language (typescript), on a highly optimized platform (v8), it is completely irrational to think you will have a very fast type checker if you reimplement it in a much more complex language.
<companion_cube>
v8 is good, but it remains JS
<companion_cube>
it's not even as fast as lua
Haudegen has quit [Quit: Bin weg.]
<def>
it is much faster than lua.
<companion_cube>
not luajit
<def>
luajit is really good at computing md5
<def>
when you start allocating memory it is much slower than v8
<def>
(damn!!! there benchmark is unsage, it is using md5)
<def>
their*
<def>
unsafe :P...
<companion_cube>
interesting
<companion_cube>
(I remember a time where dedukti was compiling its input to lua… :D)
<def>
:). a few major companies invested insane amount of money in javascript runtimes. Saner revision of the language removed the highly dynamic semantics that prevented optimisations. There is a reason why v8 can be fast :)
<companion_cube>
point taken, especially if you write "mild" typescript that is more or less like what java should have been
<companion_cube>
(I'm curious about deno for several reasons, this being one of them)
<Drup>
for the record, js is faster than bytecode ocaml ... since 2005
<Drup>
v8 has gone much faster nowadays
<companion_cube>
good to know, my knowledge of v8 is limited and from several years ago
<companion_cube>
(that's nice to know wrt. deno! :P)
<simpson>
def: Drup's point about design is recursive and fractal; the kit underneath PyPy is maintained by a half-dozen academic folk and is still competitive with those big corporate teams.
<def>
ugh yes. I agree. But I again, the performance of PyPy is very sensitive to the kind of workload you run.
<companion_cube>
and luajit was only one person
<def>
(most of this conversation is quite pointless, it is fun to talk about, but we are comparing apple and oranges... :])
<Drup>
Pypy doesn't handle everything python ever, but is very impressive at what it does
<def>
I have had the change to attend the presentation by Laurence Tratt.
<def>
chance*
<def>
But thanks for the reference. Anyway I avoid JIT as much as possible. That does not make much sense for the kind of things I do (though I agree that JIT can be very beneficial for some problems)
FreeBirdLjj has quit [Remote host closed the connection]
<companion_cube>
don't we all avoid JITs? :p
Haudegen has joined #ocaml
yomimono has joined #ocaml
chripell has quit [Quit: Leaving]
amiloradovsky has quit [Remote host closed the connection]
amiloradovsky has joined #ocaml
vicfred has joined #ocaml
mengu has joined #ocaml
mbuf has quit [Quit: Leaving]
dborisog has quit [Ping timeout: 256 seconds]
amiloradovsky has quit [Remote host closed the connection]
amiloradovsky has joined #ocaml
HyperMonkey has quit [Remote host closed the connection]
Jesin has quit [Quit: Leaving]
Jesin has joined #ocaml
Hrundi_V_Bakshi has joined #ocaml
smazga has quit [Quit: leaving]
narimiran has quit [Ping timeout: 272 seconds]
Haudegen has quit [Read error: Connection reset by peer]
Hrundi_V_Bakshi has quit [Read error: Connection reset by peer]
Haudegen has joined #ocaml
Hrundi_V_Bakshi has joined #ocaml
<olle>
why can't a web browser connect to a socket by default? instead we have use websocket?
<olle>
bah
nicoo has quit [Ping timeout: 240 seconds]
<olle>
one figures a browser should be able to do a little more than accept html over http
<olle>
what happened to that french version of internet, before internet?
<olle>
i don't like internet
<companion_cube>
are you confusing the web with internet?
<dash>
olle: the technology exists, the problem is the security model of course
<olle>
dash: hm
<olle>
doing some googling...
<olle>
companion_cube: maybe, yes
<olle>
maybe I can integrate my tool with IRC instead.
nicoo has joined #ocaml
<olle>
or maybe i can destroy internet as we know it
<Armael>
:)
<olle>
"this does not spark joy"
<companion_cube>
well the web is a gigantic pile of stuff built over decades, and shaped by huge corporations, ads, and millions of people
<companion_cube>
of course it's not going to be nice and clean :D
<olle>
i think it's the js part that puts me off
<olle>
time to finally use those books about reasonml, i guess
<olle>
i wish css didn't exist
<olle>
can't get all you want, i guess
<olle>
or no, i wish semantic web actually were a thing, don't know why it never took off
<waleee-cl>
what's the options in bucklescript/reasonml-land these days? react or overmind1's TEA-port still?
<companion_cube>
maybe because it was a gigantic mess, olle
<Leonidas>
olle: guess reasonml will not help you much since it is still js and the same browser model underneath
<Leonidas>
and CSS is better than what was there before
<olle>
companion_cube: semantic web was a mess?
<olle>
Leonidas: reasonml will help a lot! because i won't see the js
<Leonidas>
semantic web never existed, so couldn't have been a mess
<Leonidas>
olle: yeah, you tell yourself that.
<olle>
hehe
<companion_cube>
olle: more standards than users
<companion_cube>
crazy notations
<olle>
ah
<companion_cube>
and dubious usefulness overall
<Leonidas>
2 weeks later you realize that you need to figure out what source it compiles to because of some reasons.
<olle>
Leonidas: it compiles to readonable js, or so the ads say
<Leonidas>
yeah, it served a need that (nearly) nobody had
<olle>
readable*
<Leonidas>
like XHTML!
<Leonidas>
and XSLT
<waleee-cl>
It'd be great if someone had done something like stencil, but with bucklescript/reasonml instead of typescript
<olle>
if you wanna make all pages look the same, semantic web works good. sadly, no one but I wants this
<Leonidas>
just disable JS, 45% of the pages are just blank, done.