<artagnon>
Is that an error? Won't it automatically pick plus2?
<artagnon>
That didn't fix it, either way.
<whitequark>
hm, it might, still it looks odd
<whitequark>
wait
<whitequark>
what the hell are you doing?
<whitequark>
you're returning a pointer to alloca'd memory?
<artagnon>
I supplied "" many times (anonymous functions)
<artagnon>
*facepalm*
<artagnon>
That should be malloc.
<artagnon>
Thanks.
<artagnon>
I'll fix it.
sheijk_ has joined #ocaml
<artagnon>
... but why didn't it segfault?
<artagnon>
It just said "plus didn't work".
sheijk has quit [Ping timeout: 245 seconds]
tg has joined #ocaml
<whitequark>
why would it segfault?
<whitequark>
you return a pointer to something on stack, which of course gets overwritten later
<sheijk_>
it probably just read from overwritten stack mem
<sheijk_>
whitequark: do you have any good debugging techniques for the ocaml bindings? i tried to port a compiler for my toy language and found it very tiresome to always switch between gdb to see where llvm asserts and back to ocaml-debug to find how it ended up there
<rfk>
just starting with ocaml - can someone refer me to some good reading that illuminates the difference between type and class? i'm sure it will be revealed to me as i begin to learn but iwas curious about this from the start
<whitequark>
sheijk_: I don't use ocamldebug.
<sheijk_>
so what do you use to debug the ocaml side?
<whitequark>
printf :p
<Drup>
rfk: It's a bit hard to give a comprehensive difference of the two since they don't have much in common
<sheijk_>
ugh.. i think i even prefer c++ in that case :P
<whitequark>
I don't really use debuggers with C++ either.
<rfk>
Drup: i see
<Drup>
but to be short, a class is a specific type + an implementation
<whitequark>
read code to make a mental model, use printfs to fill in the blanks of this particular run
bezirg has quit [Ping timeout: 272 seconds]
<Drup>
rfk: you'll learn quickly as you go ;)
<struktured>
rfk: type and class are rarely the same in any language..java primitives are not classes, for instances. in ocaml loosely speaking, everything is a type, including classes (as well as variants, records, tuples, etc).
<rfk>
ah, so ocaml uses 'types-as-interfaces' so to speak?
<sheijk_>
whitequark: well, that won't work for me in this case. have a compiler that compiles up to 15k loc programs and need to trace bugs there. unfortunately too many steps in there for a mental model in many cases
<rfk>
ok
ygrek has joined #ocaml
<whitequark>
sheijk_: with a compiler I find it helpful to make it emit a readable IR, similar to LLVM IR but higher level
<rfk>
speaking of C++ for example, since htat just came up, types and classes are regarded as the same right? or not?
<whitequark>
that's how I debugged my compiler, for example
<whitequark>
bonus points if you can modify the IR and feed it back
<Drup>
rfk: not, types are not interface
<Drup>
rfk types are just "what data you put in it"
<Drup>
(mostly)
<Drup>
you can of course hide the data, to provide abstraction
hugomg has joined #ocaml
<sheijk_>
whitequark: yep, that works for most codegen issues. but unfortunately i'm also having macros, so i'm getting crashes during macro expansion etc.
<Drup>
an abstraction still talk about the code that is running, by saying which functions should be available, a type alone doesn't talk about that
<Drup>
an interface*
<rfk>
thanks, i'll read up
<Drup>
the thing is, the types expressed by classes are a very restricted subset of all the available types :p
Thooms has quit [Quit: WeeChat 1.0.1]
zpe has quit [Remote host closed the connection]
<struktured>
rfk: I recommend not using or reading about classes at all until you learn the ocaml fundamentals
zpe has joined #ocaml
<Drup>
I understood "classes" as the general concept in OO, not specific ocaml classes.
<artagnon>
I have no intuition about what list the error is talking about.
jao has joined #ocaml
jao has quit [Changing host]
jao has joined #ocaml
<whitequark>
artagnon: what is the gdb backtrace?
<artagnon>
I was about to ask: how do I get the binary?
<whitequark>
oh, it's in test/Bindings/OCaml/Output/
<whitequark>
executionengine.ml.tmp
<artagnon>
I tried OCAMLPATH=~/src/llvm/Debug+Asserts/lib/ocaml:$OCAMLPATH ocamlfind ocamlopt -g -warn-error A -package llvm.executionengine -linkpkg -o ee
<whitequark>
you've tried to call Llvm.entry_block on an empty function
<whitequark>
see how it asserts inside "llvm::iplist<llvm::BasicBlock, llvm::ilist_traits<llvm::BasicBlock> >::front"
<artagnon>
Oh.
tokenrove has joined #ocaml
tg has quit [Ping timeout: 244 seconds]
<artagnon>
Damn it. All 13 tests pass :\
<artagnon>
My compiler is doing some nonsense.
<whitequark>
most likely
<artagnon>
whitequark: Do you want me to contribute some bit of what I wrote? Is it useful to test?
rgrinberg has joined #ocaml
<whitequark>
doesn't seem so
hausdorff has joined #ocaml
<artagnon>
ok; looks like it belongs in the ctypes test suite.
ygrek has quit [Ping timeout: 265 seconds]
dsheets has quit [Ping timeout: 264 seconds]
tg has joined #ocaml
shinnya has quit [Ping timeout: 265 seconds]
oriba has quit [Quit: Verlassend]
artagnon has left #ocaml [#ocaml]
darkf has joined #ocaml
rwmjones_hols has quit [Read error: Connection reset by peer]
zpe has joined #ocaml
rwmjones_hols has joined #ocaml
badkins has joined #ocaml
jprakash has quit [Ping timeout: 245 seconds]
zpe has quit [Ping timeout: 245 seconds]
q66 has quit [Quit: Leaving]
ygrek has joined #ocaml
<struktured>
argh...I somehow accidentally changed a riak request header from '\0B' to '\0E'. sigh..what a waste of 2 hours of debugging
seggy is now known as segmond
hausdorff has quit [Remote host closed the connection]
hausdorff has joined #ocaml
yomimono has joined #ocaml
<struktured>
whitequark: fwiw, seems like orbitz's int32_opt function encodes as varint, while ppx_deriving_protobuf encodes int32 option as bits32 (=sfixed32) by default. [@encoding `varint] did the trick though. surprised they don't behave the same however.
hausdorff has quit [Remote host closed the connection]
<whitequark>
struktured: int32 encodes as sfixed32, int encodes as varint
<whitequark>
option is independent and composes with each
<struktured>
whitequark: yeah I know, just didn't expect that the monadic int32_opt would encode differently than ppx_protobuf_derived equivalent
hugomg has quit [Ping timeout: 245 seconds]
hugomg has joined #ocaml
rgrinberg has quit [Quit: Leaving.]
hausdorff has joined #ocaml
sheijk_ has quit [Quit: .]
typedlambda has quit [Ping timeout: 250 seconds]
cespinoza has quit [Quit: Saliendo]
typedlambda has joined #ocaml
demonimin has quit [Ping timeout: 244 seconds]
hausdorff has quit [Remote host closed the connection]
demonimin has joined #ocaml
badkins has quit [Remote host closed the connection]
samrat has joined #ocaml
zpe has joined #ocaml
samrat has quit [Ping timeout: 240 seconds]
zpe has quit [Ping timeout: 272 seconds]
Submarine has joined #ocaml
cthuluh has quit [Ping timeout: 245 seconds]
cthuluh has joined #ocaml
dav_ has joined #ocaml
cthuluh has quit [Ping timeout: 245 seconds]
dav has quit [Quit: leaving]
dav_ is now known as dav
dav has quit [Client Quit]
WraithM has joined #ocaml
hugomg has quit [Quit: Leaving]
girrig has quit [Ping timeout: 250 seconds]
girrig has joined #ocaml
cthuluh has joined #ocaml
samrat has joined #ocaml
yomimono has quit [Ping timeout: 244 seconds]
ggole has joined #ocaml
<mcc>
Sometimes I wish ocamlopt gave a more verbose message than "Syntax error"
<whitequark>
mcc++
<whitequark>
there is ongoing work to make error messages much better, let me see if you can actually use it
<mcc>
"here are some examples of valid characters at this moment" would be a good first step D:
<whitequark>
wow, xleroy actually sends PRs on github
<Drup>
mcc: use merlin™
<mcc>
Also, after the—
<mcc>
Well, what I was about to say is
<mcc>
I would like to express displeasure that the vim setup instructions for merlin *literally* begin with an admonition to do "a bunch of stuff"
<struktured>
whitequark: sweet victory, I did a full swap out of orbits/protobuf with whitequark/ppx_deriving_protobuf in ocaml-riakc. still a few kinks left but works great.
<whitequark>
mcc: a code formatter thing
<whitequark>
struktured: cool
<whitequark>
now, swap async for lwt :p
<Drup>
a *customizable* indentation engine.
<whitequark>
or rather functorize it
<Drup>
which is nice, because you can customize on a project basis
<Drup>
and everyone using ocp-indent and your project will indent the same way
<mcc>
hm
<whitequark>
Drup: does it still use ocp-build to build? D:
<Drup>
yes :<
<whitequark>
burn
<mcc>
strutured: out of curiosity, what does "execute pathogen#infect()"
<Drup>
unfortunately, you're not going to change that.
<whitequark>
Drup: should just submit my OASIS-ified build to opam
<struktured>
mcc: its not a virus. I swear
<Drup>
mcc: it's a pathogen, obviously it infect things :O
<whitequark>
Drup: yay for hostile forking.
<mcc>
oh ,that's syntastic
<Drup>
I'm very eager to see your first IRL interaction with fabrice lefessant
<struktured>
whitequark: async for lwt? uh yeah at some point I need to right some application code, not just middleware fiddling :) . I'm kind of waiting for an api that abstracts both lwt and async away. Besides, I will have to refactor my riakc impl again if orbits ever gets around to making his monadic protobuf version dependent on your new lib
<struktured>
*right/write
<whitequark>
(an api that abstracts both lwt and async away) oh god please no
<struktured>
whitequark: lol I think it's already in the works
<Drup>
struktured: cohttp has such "middleware" api
<whitequark>
that's a horrible idea.
<Drup>
and somebody that I will not name implemented lwt-over-async
<whitequark>
lwt-over-async is not as bad, it keeps the API count at 2
<struktured>
I would probably d something like this, if I always wanted to use async (maybe there's a lwt equivalent?) : https://github.com/janestreet/lwt-async/
<whitequark>
but abstracting them both? it's literally the case of "oh, these two solutions suck, let's make a third one because we have too fucking much free time on our hands"
zpe has joined #ocaml
<struktured>
inception middleware abstractions, the movie no one would watch
<Drup>
hey dawg, I put your concurency monad into a concurency monad ... >_>
rgrinberg has joined #ocaml
<mcc>
Merlin seems to have just said a bunch of stuff about "Require vim compiled with +Python"
<mcc>
is that surprising
zpe has quit [Ping timeout: 258 seconds]
bytbox has quit [Remote host closed the connection]
<struktured>
mcc yeah I had same error initially, but I use vim-qt, so I just recompiled with the extensions
<mcc>
okay...
<struktured>
mcc: is it mac or linux? in ubuntu I think it's easy to install or already is
<mcc>
it's a really old mac... i'll just get a new vim out of macports
<struktured>
mcc: good call
<mcc>
"Installing vim @7.4.258_0+huge" well that's reassuring
<struktured>
mcc: huge is really only appropriate terminology for emacs :)
<whitequark>
Drup: did anyone ever try to make opam use aez?
<Drup>
no, for various reasons
<Drup>
well, maybe they tried
<Drup>
but it's going to make a bad job anyway
<whitequark>
why so?
<Drup>
No optimisation
<Drup>
it gives *a* solution
<Drup>
not *the best solution* according to some criteria
<whitequark>
oh
<Drup>
also, aez doesn't have model extraction, afair
<mcc>
*sudo port install vim +python27* ... ... oh. it's installing m4. of course it is.
<Drup>
which is slightly necessary for a package manager ..
<Drup>
I think alt-ergo has model extraction, but alt-ergo's situation is just plain weird
<Drup>
(and still no optimisation)
<Drup>
whitequark: did you read di cosmo's paper about package manager preferences ?
<mcc>
how do i instruct it to attempt to compile then run
<whitequark>
oh, in merlin
<struktured>
Drup: I don't drink free coffee. my tastes are too snobbish :) I hear ya though. damn NP space
<Drup>
oh no, the issue is not NP
<Drup>
the issue is that your algorithm sucks :D
<mcc>
oh dear
<Drup>
struktured: to make an enlightened comparison, it's like trying to find the boundary of a polygon by trying each integer points, one by one.
<Drup>
we can do slightly better than that.
<mcc>
I... think the merlin file should contain S src \n B _build
<mcc>
maybe a package reference for sedlex?
<Drup>
oh, sedlex.
<mcc>
do i put all the packages in here?
<Drup>
yes
<mcc>
like, collections isn't in my _tags
<Drup>
PKG sedlex
<Drup>
also, you need S src/* and B _build/*
<mcc>
i have that
<mcc>
errr
<mcc>
well i didn't put in the * but i can
<Drup>
the /* are important
<struktured>
Drup: k-Sat is np complete for unrestricted k, right? anyhow, you saying the algorithm is brute forcey but shouldn't be?
<Drup>
yes.
<mcc>
once i have this file
<mcc>
.... what do i do?
<struktured>
mcc: drop it in your project root directory, just like the paths are implied in the file
<Drup>
I don't know the vim interface, so can't help you with that.
<mcc>
yes, it's there
<struktured>
mcc: ok, just run vim from the directory, hopefully it will work.
<struktured>
mcc: and save the buffer once
<mcc>
save the *buffer*?
<mcc>
i mean
<Drup>
I doubt you need to run vim from the directory.
<mcc>
...oh. i see.
<struktured>
Drup: I think u do. it needs to reference the .merlin file
<mcc>
huh.
<struktured>
mcc: do :wq once
<whitequark>
... why do I have a highlight on :wq
<whitequark>
oh, right.
<struktured>
mcc: not wq, just write sorry
<mcc>
yeah, i got that far
<Drup>
struktured: at least, you don't in emacs, launch from where you want, it will find the .merlin from the file.
<ggole>
Hmm, it'd be nice if while true were typed as 'a
<struktured>
Drup: you may be right but I don't recall the vim version being quite that intelligent
<mcc>
okay so... some things i'm noticing. what my build script does is it ocamlbuilds main.ml, and it goes and finds all the other .mls to load...
<Drup>
duh, emacs > vim :]
<mcc>
if i :w in execute.ml, it finds the errors
<struktured>
mcc: cool. thats a good start
<mcc>
if i :w in main.ml, it says "Unbound module Execute"
<mcc>
is this surprising?
<Drup>
did you compile your project once ?
<mcc>
yes.
<Drup>
it needs other file to be compiled to be able to see them
<Drup>
it=merlin
<mcc>
let's say execute.ml is failing
<mcc>
does that mean it would be "not compiled"?
<Drup>
yes.
<mcc>
okay. next question, kind of workflowy... i will probably not be editing in vim. i will be building, and then if there's a problem, wanting to bounce in vim into the file with the problem.
<mcc>
is there anything in the merlin/vim interface to encourage this? like letting me just build "everything" and then automatically skip to the file with the issue?
<whitequark>
you're going to use ST *and* vim?
<Drup>
you like to make your life complicated, don't you ? :p
<mcc>
i... well, i don't particularly want to write code in vim?
<Drup>
merlin is interactive in nature
<Drup>
if you don't want the interaction, there is no point.
<mcc>
i just want to be able to see my compile error messages.
<Drup>
for compile error messages, use the compiler =')
<mcc>
i usually don't want interaction
* mcc
sighs
<mcc>
the compiler gives messages like "error on character 56"
<Drup>
Hum, right.
<Drup>
I can't say it's a common workflow, so, sorry, no idea.
<mcc>
ok.
<struktured>
mcc: ultimately u can do emacs, sublime, or eclipse + ocaide , afaik. with vim, you could consider adding a repl plugin, or just doing something as simple :"!omake" to build the project and see the errors. I usually rock multiple terminals (some people use tmux to make it really slick)
<mcc>
i'd really like to be using sublime+merlin and i'll be doing that as soon as i can.
<Drup>
personally, I just run everything in emacs and I have a jump to error command, when I'm compiling
<mcc>
struktured: is there a "jump to next error within file" directive for merlin/vim?
<struktured>
Drup: oh that's nice. does it jump to any file too?
<Drup>
sure
<Drup>
it parses the output of ocamlopt and jumps to it
<Drup>
well, your make script is not doing anything, it's just calling ocamlbuild
* nicoo
runs mcc in BSD Make
<Drup>
it could as well be a shell script.
* mcc
thinks
<mcc>
I'm not sure if the motorola c compiler ever ran on UNIX.
<mcc>
Drup: i don't want shell anywhere in my project! that's the *problem*! make is shell!
<whitequark>
mcc: which of them? :D
<mcc>
Fair question.
<whitequark>
debian even had an m68k port.
<mcc>
wait, what? that's news to me
<whitequark>
until about 2012 or so, which makes you question the life choices of the people who maintain that
darkf has quit [Ping timeout: 240 seconds]
<mcc>
targeting macs or embedded?
<Drup>
Are you going to treat me of fanatic if I tell you that I consider python not much better than shell scripts ? :p
<whitequark>
yup. gcc still has m68k support
<whitequark>
mcc: I... don't know actually, I've never ran it
<whitequark>
naturally. but I think it's not just macs
<mcc>
TI still ships calculators with 68k :P
<whitequark>
welp, not enough ram to run linux
govg has joined #ocaml
<mcc>
maybe you could solder some more… um… in.
<mcc>
anyway basically i'd be surprised if it was macs because i know for a fact there was no orthodox linux distro available for 68k macs at the time the PPC was released.
<mcc>
just the deeply weird mklinux.
<whitequark>
mcc: this reminds me, I've seen people soldering a 64mb SDRAM chip inside a $30 router which only has 32mb of RAM
<tokenrove>
mcc: sun3, atari falcon iirc. probably some macs as well.
<whitequark>
which is funny for several reasons, not the last one being the fact that a 64mb SDRAM chip costs about $45 where I could find it
<nicoo>
whitequark: Been there, done that (soldering RAM in cheap routers)
<mcc>
i've never even heard of the atari falcon
<mcc>
geez
kdef has quit [Ping timeout: 255 seconds]
<whitequark>
nicoo: hardcore
<nicoo>
whitequark: Oh, scavenged RAM from ooooold RAM sticks
<whitequark>
do you do a lot of embedded work?
<nicoo>
0€
<mcc>
... wow this thing is WEIRD.
<nicoo>
And no, I just dabble
<whitequark>
I mean, that's SMD rework and a custom kernel
<whitequark>
pretty advanced in my book
<mcc>
"Atari Corp. created a number of prototypes of the Falcon040 (based on the more capable fully pipelined, integrated-FPU, Motorola 68040, and using a "microbox" case), but canceled it in order to focus developers on the Atari Jaguar." keen business sense those dudes
kdef has joined #ocaml
<nicoo>
whitequark: If you are running OpenWRT, the “custom kernel” part is a one line config change, then rebuild
<nicoo>
(The rebuild is actually kinda painful)
<nicoo>
whitequark: Actually, porting OpenWRT to a new device was way harder :3
claudiuc has quit [Remote host closed the connection]
<mcc>
"Syntax error inside let after unclosed [, expecting `:=', `&&', `&', `||', `>', `<', `=', `%', `*', `-.', `-', `+=', `+.', `+', `::' or `,'"
<mcc>
Whelp merlin is earning its keep immediately
cesar_ has joined #ocaml
<Drup>
:D
cesar_ is now known as Guest69272
<struktured>
mcc: nice. I'm happy you made me dig up that merlin documentation. forgot about some of those commands
zpe has joined #ocaml
<mcc>
haha
<mcc>
is there a way to make a few lines in a vimrc only apply for one kind of file, say a .ml file?
<Drup>
at least by doing a complete implementation.
<Drup>
and we will worry about the write up after.
samrat has quit [Quit: Computer has gone to sleep.]
jao has quit [Ping timeout: 250 seconds]
Submarine has quit [Quit: Leaving]
rgrinberg has quit [Quit: Leaving.]
darkf has joined #ocaml
<mcc>
here are two related questions
<mcc>
1. let rec a b = let c d = a (d - 1) in match b with 0 -> 0 | e -> c e;; (* is this tail recursive? like, the invocation of c e, the invocation of a (d -1), the whole loop
<mcc>
2. in general, is there a way to tell whether TCO is being successfully applied to any one place in an ocaml program?
<whitequark>
yes, it is: both c and a calls are in tail position
<ggole>
There's a (proposed?) ppx thing for 2
<mcc>
lovely
<whitequark>
yes
<whitequark>
generally, it is almost always visible syntactically
<mcc>
ggole: i'm not sure i understand that
<ggole>
But usually you just eyeball it
<whitequark>
if the function call is the last thing executed, it is a tail call.
<mcc>
'k
<whitequark>
watch out for try..with blocks though
kdef has quit [Quit: peace]
<whitequark>
naturally, they break tailcalling
<mcc>
i have yet to use an exception. i am hoping i can continue that record.
<ggole>
But we have exception matching now <3
<whitequark>
mcc: exceptions in ocaml aren't as bad as in other languages.
<ggole>
So it can often be worked around.
<mcc>
erm-- if i was calling a stdlib function that can throw an exception, would i know it?
<whitequark>
mcc: it's literally longjmp.
<whitequark>
so it has no runtime cost
<ggole>
mcc: not from the type
<mcc>
'k
<ggole>
You have to look at the documentation
<mcc>
whitequark: do you have something like finally {} ?
<whitequark>
mcc: no, there is no finally
<mcc>
ok. what happens if an exception is thrown and it is not caught?
<whitequark>
there is a toplevel handler that will print backtrace, if any, and abort
<mcc>
(like, segfault, error message printed to stderr?)
<mcc>
ok
<whitequark>
in a thread, it will not exit, I think, just print and kill the thread
<whitequark>
segfault, haha
<ggole>
You have to ask for the backtrace -_-
<whitequark>
ocaml developers *hate* segfaults
<mcc>
is there exactly one thread library for ocaml then?
<whitequark>
there are green threads, but I don't think anyone uses them
<whitequark>
it's pthread, essentially
<whitequark>
i.e. technically you can switch to green threads instead of pthreads, but it is only maybe useful on platforms without pthreads and win32 threads
<whitequark>
however, threads in ocaml do not provide parallelism
<whitequark>
multicore ocaml is in works, but it's not merged yet
<mcc>
by "parallelism" do you mean automatic parallelism of code?
<mcc>
can memory be shared across threads? if so, do mutable stdlib structures such as Hashtable tend to tolerate simultaneous access attempts from multiple threads?
<whitequark>
no, I mean two threads running in parallel
<mcc>
oh. i
<mcc>
… … … wait.
<whitequark>
no, mutable stdlib structures are not threadsafe
<mcc>
i don't understand how you can have multiple pthreads but they're not running in parallel
<whitequark>
a global mutex
<mcc>
yikes
<mcc>
well ok then
<whitequark>
it's released for I/O
<mcc>
how does it decide when to switch control of the single mutex between threads? random?
<whitequark>
I think it uses SIGVTALRM
<whitequark>
essentially, it guarantees that one thread will not starve others, but I don't remember how exactly
<whitequark>
let me look in the sources
<mcc>
ok.
<mcc>
does multicore just run threads in parallel as one normally expects?
<whitequark>
yeah
* mcc
names a local function "return", then calls it at the end of the function
* mcc
giggles a bunch
<struktured>
mcc: by no means should you try this, but just an fyi. there's a backdoor approach to multicore via ocamljava. if you disable the global lock (via command line flag), it basically delegates all the GC and concurrency to the jvm layer
<whitequark>
ocamljava is not compatible with ppx, ctypes, ...
<mcc>
hm, ok
<whitequark>
mcc: so I checked, it uses sigvtalrm indeed.
<whitequark>
at first I couldn't find the scheduler! I assumed it was in C code
<whitequark>
in fact, it was in OCaml
<mcc>
no offense but i think if i was comfortable living in a jvm i might be learning scala right now instead :)
<whitequark>
mcc: do you love C++ that much?
<struktured>
mcc: yeah just an FYI, I do some know guys that use it run to spark + ocaml effectively
<mcc>
look unless you can find me a commercial-quality 3d rigid body physics engine written in pure ocaml, i need c++ :P
<mcc>
and what i REALLY love is being able to write my own live pcm synthesis :P
<whitequark>
mcc: no I mean, scala
<whitequark>
it's basically the c++ of fp
<whitequark>
the same kind of design ... process
<mcc>
also, honestly, i mostly just dislike the jvm. I think about jumping ship to CLI languages all the time
<mcc>
whitequark: huh, that's interesting. you mean, "any feature anyone asked for, we added"?
<whitequark>
mcc: yes. it is incredibly convoluted, and most features interact with each other
<whitequark>
and the stdlib is very reminiscent of stl.
<whitequark>
*interact with each other badly
<mcc>
fun!
<mcc>
anyway, i'm not looking at scala
<mcc>
but it does work in Unity, which means i would consider it very seriously even if it were terrible D:
<ggole>
Subtyping and inference aren't the best match.
<mcc>
oh, one more question while everyone's online-- does anyone know, in sedlex, if fields like "lexeme_end" provide position relative to byte index or position relative to unicode lexime index? the name seems to imply the latter, but the documentation definitely doesn't seem unambiguous to me
<whitequark>
(most people in #ocaml are european, btw, so "while everyone's online" doesn't quite apply like you'd expect)
<whitequark>
sedlex operates in codepoints
<whitequark>
it doesn't even know bytes exist, by most part
<mcc>
nice
<mcc>
i've definitely noticed this is the relatively more active time of day.
<whitequark>
(yes, it's morning here, i just have a weird schedule)
zpe has joined #ocaml
zpe has quit [Ping timeout: 244 seconds]
samrat has joined #ocaml
reynir is now known as reynir_
reynir_ is now known as reynir
ygrek has quit [Ping timeout: 264 seconds]
<mcc>
rrrrg now Merlin is doing the "Unbound module" thing again . for Token, where token.ml is in the same directory
<whitequark>
you need to compile it first
<whitequark>
merlin doesn't get the information from sources
<whitequark>
(except the very current one)
<mcc>
i feel very certain it did
<mcc>
well, wait, i dunno
<mcc>
define "compile"
<whitequark>
you have a B whatever entry in your .merlin?
<whitequark>
token.cmi should be in that "whatever"
<mcc>
token.ml is failing build right now. just ocamlbuild isn't reporting that for some reason.
<mcc>
bailed out early i guess
<whitequark>
yeah, it only shows one error
Guest69272 has quit [Remote host closed the connection]
govg has joined #ocaml
<mcc>
ok
<ggole>
Hmm, that could be annoying for merlin use
<whitequark>
yes, ideally I think merlin should typecheck all sources by itself
<whitequark>
like intellisense and the like do
<mcc>
the problem is with vi you're typically only one thing open at a time.
MercurialAlchemi has joined #ocaml
<whitequark>
aren't there, like, tab things for vi
<mcc>
by the way, drup said to use for example S src/* in the .merlin, but the .merlin docs say just to use "S src", and it seems to work the same regardless of which i use
<mcc>
is there a difference
<whitequark>
I actually have S src/**
<mcc>
probably? i don't tend to use vi as a full ide, just a single-file editor :O
<mcc>
geez
<whitequark>
it might make a difference if you have subdirectories there
<mcc>
i do, such as _build/src
<whitequark>
_build/* probably includes _build/src, but not _build/src/foo
<whitequark>
(I'm just guessing here)
<mcc>
it makes sense, but _build/*, _build, and _build/** seem to have the same effect
<whitequark>
interesting
<mcc>
which is that I get "Unbound module Token" when compiling Execute
<mcc>
this is so odd, this worked a moment ago
<whitequark>
I ... what
<mcc>
ok, so there's still no token.cmi
<whitequark>
hm
<mcc>
my understanding is if i edit token.ml, then save
<mcc>
that it should build token
<whitequark>
what "it" ?
<mcc>
my understanding is that when vi writes a file, merlin does a build and check
<mcc>
i could be wrong
<whitequark>
no, merlin never builds anything
<mcc>
huh
<mcc>
ok
inr has joined #ocaml
<whitequark>
(because there is a dozen buildsystem and no way to query most of them programmatically, for instance)
<whitequark>
(like make.)
<mcc>
...okay
<mcc>
this is silly as heck
<mcc>
but if i explicitly ocamlbuild -no-links -use-ocamlfind src/token.native
<mcc>
then THAT makes it build the cmi, and then i'm fine
<whitequark>
you can call it with "src/token.cmi"
<whitequark>
.native is silly indeed
<mcc>
ok
<mcc>
still, it seems like this is not a workflow problem other people are having. do you suppose it is a quirk of vi?
<mcc>
or the merlin-vi interface rather
<whitequark>
doesn't sound related to either
<whitequark>
I think this is just a flaw of merlin as currently present
<whitequark>
oh, well, you can't really fix that
<whitequark>
I just realized
<whitequark>
remember the part about a dozen buildsystems? you can't, in general, compile a file, you don't know what packages it depends on
<mcc>
i feel like specifying this is what the .merlin is for
<whitequark>
hm, good point actually
<whitequark>
then this can be fixed. can you file an issue?
<mcc>
ok. on the-lambda-church/merlin?
<whitequark>
yep
<mcc>
'k
<mcc>
or… hm. what am i asking for. forcing builds?
<whitequark>
I think not
<mcc>
i'll just describe my high-level problem.
<whitequark>
yes
<whitequark>
good idea
<ggole>
What's the problem? That merlin is unreliable if the build isn't run after saving a file?
<whitequark>
yes. and that ocamlbuild doesn't always build all possible cmis if there's an error somewhere else
<mcc>
the problem is that ocamlbuild can fail to build some of the .ml files if there is an error,
<ggole>
Mmm.
<mcc>
but then in order for merlin to correctly report the error all the dependencies have to be built
zpe has joined #ocaml
<ggole>
I haven't run into this problem - I think because I have a habit of running make very often
<ggole>
Funny how habits make you blind to these problems.
zpe has quit [Ping timeout: 265 seconds]
<mcc>
conversely, i think what hurt ME here is i have a habit, whenever things get even a little odd, of running make clean
<whitequark>
haha
<whitequark>
ocamlbuild fixes the problem of outdated dependencies
<whitequark>
it uses md5 sums to track freshness
<whitequark>
unless you're doing something odd such as adding your own ocamlbuild rules (and even then it's not trivial), or switch compilers underneath it, you shouldn't ever run into a case where you have to clean the tree before it builds
<mcc>
well, the reason i keep doing it actually
<mcc>
is that this is the only way to see warnings in files previously successfully compiled
<whitequark>
it turns all the warnings worth bothering about into errors
<whitequark>
it's better than @A, because ... you know what -Wall -Werror does to production C code
<mcc>
oh my
<ggole>
Yeah, I did that too
<whitequark>
I went a bit on the aggressive side, like it errors out on all unused variables not prefixed with _
<whitequark>
but overall I think it's balanced and not as annoying as @A, too
<ggole>
It'd be nice if ocamlbuild had a warning cache though
<ggole>
eg when you compiled, it shows you the saved warnings for files it already compiled
<whitequark>
I think the build system should integrate the compiler frontend, anyway
<whitequark>
(which brings me to my buildsystem idea... must... resist... temptation)
<ggole>
Oh, do tell?
<ggole>
(It's not "burn all the build systems", I take it.)
<whitequark>
integrate ocamlc, ocamlopt, toplevel, everything into a single multi-call binary that reads the configuration from ml/mli files themselves
<ggole>
Hmm, so you'd put things like package dependencies in a .ml(i)?
<whitequark>
yes
<ggole>
I can see the advantages of that.
<whitequark>
and there'd be one overall file with global configuration, like source directories, and additional ruless
<whitequark>
so it will *never* fork
<whitequark>
(well, okay, it will still fork to call as/ld, but it's less forking overall)
<whitequark>
concerned programmers for eliminating software fornication
<ggole>
rofl
<whitequark>
if I ever finish my LLVM backend, however...
<ggole>
Might be good for portability too
<whitequark>
actually, I wonder if I can just call LLVM's integrated-as :D
<ggole>
Not that I care deeply about windows
<whitequark>
yeah, it's more portable
<mcc>
i'm a big fan of build systems not forking
<mcc>
as an abstract concept
<whitequark>
mcc: wanna join me in building this abomination
<whitequark>
(it is an abomination, of course, it is a buildsystem after all)
<mcc>
wellllllllll
<mcc>
actually, i'm kinda thinking about emily
<mcc>
which is supposed to be a language designed for short scripts
<whitequark>
... like perl ...
<whitequark>
oh hahaha, want to hear a fun story
<whitequark>
http://mail.ru is running almost entirely on perl
<mcc>
...but with an intentionally small core library and functionality such that a minimal interpreter could be very simple...
<mcc>
...and which is also a language which, in intent, eventally is meant to be set up such that bits of code can be run at compile time, and this is normal and desirable.
<mcc>
so i don't see any reason emily can't be it's own build system
<MercurialAlchemi>
whitequark: the BBC still runs at least partly on Perl - booking.com runs *entirely* on Perl
<mcc>
although designing a interface for a build system sounds terrifying
<whitequark>
MercurialAlchemi: yeah, I know about booking. it's one of the last big perl strongholds, isn't it?
<mcc>
many people probably smarter than me have tried this and come up with only abominations
<MercurialAlchemi>
yeah, I guess
<whitequark>
mcc: you need to stop worrying and embrace the fact that you will produce an abomination :3
<mcc>
i think you have probably seen enough of my language design by now to know i'm not going to let the possibility of an abomination stop me.
<whitequark>
well, actually, I like a good chunk of your design
<mcc>
haha
<whitequark>
which can't be said for most languages
<mcc>
well thank you
<mcc>
did i mention emily's typesystem is such it's in principle possible for a run-time typecheck to go into an infinite loop? and possibly a compile-time one although i imagine those will have timeouts?
* whitequark
← did not talk to someone for several months because their pet language was just really, really terrible
<whitequark>
hm
<mcc>
hahaha
<mcc>
and, i mean, it's simple-- i'm *intending* for there to be rich/dependent types which the "is this value a member of the type?" is determined by "call this function and find out"
<mcc>
so if you pass "while true {}" into this function...
<whitequark>
the compile-time typecheck doesn't sound *too* bad, I actually think OCaml functors support unbounded recursion
<whitequark>
that's not dependent types.
<mcc>
okay, "some kind of magic type which evaluates a property of the value, like x > 10". I think there's a word for that.
<whitequark>
that's... missing the point of types entirely
<mcc>
it's possible emily's typesystem isn't checking types at all.
<whitequark>
I mean, it's not a type, then, it's something like a contract
<mcc>
sure.
<MercurialAlchemi>
Is emily your creation?
<reynir>
there was a student talk at icfp 2012 that reminds me of this discussion
<ggole>
mcc: that's tough to do (if I understand what you're aiming at, which I may not)
<ggole>
You have to get into presburger arithmetic and all that jazz
<whitequark>
mcc: design by contract is an interesting direction which not many languages support
<whitequark>
proper dependent types are *hard*.
<whitequark>
you need an automated theorem prover with a sane interface to make it work
<mcc>
it's checking assertions about code. however it's presented through the same ux as something which is behaving like a conventional typesystem
<whitequark>
I don't think they exist at all.
<ggole>
mcc: so you're running predicates at execution time?
<whitequark>
I mean, yeah, Idris and Agda, neither of which is ready for production
ygrek has joined #ocaml
<whitequark>
mcc: that totally sounds like contracts
<mcc>
mercurialalchemist: yeah. it is the reason i'm using ocaml.
<whitequark>
that also was present in early rust versions but they ripped it out because it was unusable
<mcc>
ok! every time i've had someone describe a language which advertises itself as having contracts it's sounded really nice.
<whitequark>
(typestate thing)
<whitequark>
it's possible you can explore another facet of the same design and it'll work, but I'm not holding my breath
<mcc>
whitequark: yeah! an ex rust dev was describing that to me, it sounded REALLY interesting.
<MercurialAlchemi>
mcc: ah, you're building emily in ocaml, right
<mcc>
yes
<whitequark>
mcc: basically they replaced it with linear types, which are WAY simpler, but almost as expressive
<mcc>
hm
<mcc>
and it might not work! but i think it will work as long as i'm willing to accept very poor notions of "work"
<whitequark>
mcc: I had some PL folks describe rust as "not interesting at all anymore" after it lost typestate :D
<whitequark>
(@psnively)
<MercurialAlchemi>
whitequark: doesn't let you ensure that all the integers in a given list are > 10, though
<whitequark>
MercurialAlchemi: why not?
<mcc>
ggole: and, yes. the idea is basically anytime something is typed, it will run a predicate at runtime to make sure it works. and all that happens at compile time is, if it can prove that the predicate is always satisfied, it removes the check.
<MercurialAlchemi>
I don't see how you'd do that in Rust
<ggole>
mcc: righto, that's not so hard (and is easy for the user to understand).
<whitequark>
MercurialAlchemi: oh, linear types
<whitequark>
you can do this without linear types, just with smart constructors
<whitequark>
mcc: my educated guess on what will happen:
<mcc>
ggole: yeah. and i feel like telling the user "well, if you use a really complicated type, it's gonna maybe be inefficient. are you sure you wouldn't rather just never type anything?"
<ggole>
Things like common lisp offer similar features already
<MercurialAlchemi>
I mean, you could newtype your way to it, but I don't see how linear types help here
<mcc>
is something they can understand
<ggole>
Right.
<whitequark>
mcc: 1) users discover that the compiler is too dumb to remove the check
<whitequark>
2) they only use a subset of the language
<mcc>
...and this is the *plan*. i'm actually pretty terrified about this element of it. it is the part of designing a language i feel the least confident about, 90% of what i know about functional/inferred/dependent whatever type systems is hearsay.
<whitequark>
2a) they use dynamic typing part, which is also too slow.
<mcc>
i'm planning to target, like, python and lua users.
<ggole>
mcc: that's all part of the fun, isn't it?
<ggole>
If you knew what you were doing it would be boring.
<mcc>
so "too slow" is probably still a performance win!
<whitequark>
mcc: I had an almost exactly same feature in my language, and this is why I ditched it
* mcc
nods
<whitequark>
lua has luajit.
<mcc>
anyway, the current interpreter has *no types*, so...
<MercurialAlchemi>
well, Lua can be fast, as far as I know
<ggole>
Even the luajit interpreter is damn fast
<MercurialAlchemi>
Python, yeah, not so fast
<whitequark>
tbh using types for "fast" is a wrong way to use types
<whitequark>
if you want "fast", write it in pypy or something
<whitequark>
well, generally, get a good jit.
<ggole>
Mostly because Mike Pall is unusually competent, is my impression
<mcc>
whitequark: and if i can build on top of Haxe, then I can transpile to lua, and i'll have luajit too :D
<mcc>
yeah the Luajit Guy is apparently amazing
<MercurialAlchemi>
I think there are less things in Lua's design which prevent it from being fast compare to Python
<whitequark>
mcc: I bet you'll have fun porting your stdlib to every platform you transpile to
<mcc>
which is why i'm writing my own language rather than trying to extend luajit. i don't want to be working on a codebase that exactly one busy genius understands D:
<whitequark>
and then your users will have fun debugging the emitted code, Lua doesn't even have sourcemaps
<mcc>
whitequark: haxe/lua get by with very small standard libraries.
<whitequark>
yeah, that's one reason I can't stand lua
<reynir>
*transpile*
<whitequark>
the stdlib is useless and package management is even more of a pain than usual
<reynir>
mcc: maybe take a look at typed racket
<mcc>
what i'm more interested in is having the package system be very smart about keeping you from accidentally incorporating non-portable libraries in...
<MercurialAlchemi>
"the stdlib is useless", this reminds me of another language...
<mcc>
reynir: i have had several people recommend this thing to me. i guess i should look. i'm allergic to s-exps tho :(
<whitequark>
mcc: they have a predicate system that is probably something you will want to incorporate
<whitequark>
let me grab the paper that describes these
<mcc>
@bobpoekert from twitter seems to think it's viable as a day-to-day language...
<ggole>
Julia might be worth looking at too
<mcc>
Julia looks *VERY* interesting.
<mcc>
Julia has a lot of the same ideas as Emily.
<mcc>
...which amuses me, a little.
<ggole>
They allow quite expressive annotations
<reynir>
yea I meant the papers
<whitequark>
Typed Racket is great in that its design is now cloned all over.
<mcc>
renir/whitequark: but you don't recommend using it?
<whitequark>
Python's future typechecker will be based on Typed Racket, which means that maybe we'll finally have one worthwhile mainstream lang with optional types
<whitequark>
all attempts I've seen before are garbage
<whitequark>
mcc: I never actually used Racket, I just read the theory behind it :D
<mcc>
When I first posted the proposed Emily language description, I got a lot of two suggestions: "You should check out Io, this is a lot like that" and "You should check out Julia, this is a lot like that"
<ggole>
Mmm. Most of the language design space has been covered pretty densely by now.
<mcc>
But Io's maintainer seems to have gone into outer space and Julia doesn't support my paleolithic home OS, so i never actually got to use either >_>
<whitequark>
what ggole says, yeah
<reynir>
my TA wrote a tool to "check" .d.ts files (typescript type definition files)
<MercurialAlchemi>
mcc: what OS is that?
<MercurialAlchemi>
Plan9?
<mcc>
MercurialAlchemist: Mac OS X 10.6
<reynir>
or rather it tries to find bugs in your type definition files
<MercurialAlchemi>
bah, way too mainstream
<mcc>
In macintosh world, four years old is "you are from the stone age adn nothing works"
<MercurialAlchemi>
VMs are your friens?
<mcc>
ggole: yeah, although i think we're to a large extent searching near a couple big islands
<mcc>
Hm. Maybe I could run a linux vm day to day now that I've upgraded the RAM...
<whitequark>
mcc: it's a great paper, and it also is not too heavy on notation
<mcc>
whitequark: neat, thank you!
<mcc>
"Refinement types". I don't even know what that means, and I already like it.
<whitequark>
lol
<mcc>
it just sounds good
<ggole>
A friend of mine who works at $hugecorp shut down their last AIX box recently.
<mcc>
reynri: also i just wanna say i absolutely love the word "transpiler" and i am still trying to introduce the terminology of same-language recompilers like Google Closure being "cispilers"
<mcc>
ggole: was it a sentimental moment
<ggole>
Now that's paleolithic.
<ggole>
They had to sweep the stone shavings away afterwards.
<MercurialAlchemi>
Lots of vacuum tubes to recycle
<ggole>
Heh, cispilers. Haven't heard that one before.
<whitequark>
mcc: there is an argument that transpilers don't exist as a separate class of programs from compilers
<whitequark>
and I support it, to be honest
<ggole>
It's a bit more catchy than source-to-source.
<ggole>
Compiler is the wrong word, really.
<whitequark>
ggole: OCaml is a transpiler in your terminology.
<whitequark>
ocamlopt.
<mcc>
it's an extremely sensible argument.
<ggole>
It dates to when compilers simply aggregated machine code
<mcc>
however, my argument would be that transpilers are a class *of* compilers
<whitequark>
and, say, emscripten is totally a compiler.
<ggole>
When translators were introduced/invented, people kept using the word.
<whitequark>
it doesn't even emit "source" in any useful sense of the word "source"
<mcc>
which happen to use a recognizable other programming language as an intermediate compilation step.
<mcc>
or target, in the emscripten case, i guess
<whitequark>
mcc: well, it then goes to say that this is not a useful classification
<whitequark>
i.e. what could you infer from it? practically nothing
<mcc>
i guess it might be useful to have a terminology difference to distinguish something like JSIL from something like emscripten...
<whitequark>
"a compiler targeting javascript"
<whitequark>
"a compiler targeting x86"
nojb has joined #ocaml
<mcc>
"javascript transpiler" are fewer syllables
<whitequark>
"a compiler targeting CIL"
* whitequark
shrugs
<reynir>
mcc: I absolutely hate "transpiler" etc
<mcc>
haha
<ggole>
I don't think the terminology is deeply important.
<mcc>
what i'd say is that there are tools/integration consequences to something being a transpiler rather than a compiler (i.e. not emitting machine code as a final step)
<ggole>
Although people get strangely defensive about some of it.
<whitequark>
not deeply important, I agree
<mcc>
and that there are deployability implications to a language having a transpiler (i.e.: may be deployable in situations where machine code / bytecode-vm languages are not, may be able to bypass the inefficiencies of an interpreter for some deployment situations)
<ggole>
mcc: well, there are lots of possibilities that aren't source and aren't machine code
<mcc>
there are, but there are specific benefits in certain circumstances to the existence of tha tsource possibility
<ggole>
Something like scalac translates source into an internal IR, optimizes, and emits a produce (Java bytecode) that is quite distant from and somewhat hostile to the original source.
<mcc>
so i think it's useful to be able to express the category somehow *shrug*
<ggole>
That's *a lot* like the operation of a "real" compiler.
<whitequark>
I bet you can even build a JVM in silico
<whitequark>
silicon*
<mcc>
whitequark: i thought they were trying, at one point in the 90s?
<ggole>
Agreed, but I'm not sure if people are going to reliably infer the category from the term.
<whitequark>
I mean, there's Jazelle, but it's not really a JVM
<mcc>
it is a marketing term
<ggole>
Might be best to just say the thing if the difference matters.
<mcc>
it is part of a larger attempt to communicate something
<whitequark>
mcc: oh, apparently Azul had it in silicon
<ggole>
whitequark: there are embedded chips that run bytecode in hardware, afaik
<whitequark>
ggole: Jazelle.
<whitequark>
but it's not a full JVM
<ggole>
Isn't Jazelle that silly ARM thing?
<whitequark>
it's just not profitable to build a JVM completely in silicon, too many moving parts
<ggole>
I was thinking of Javacard and that stuff
<whitequark>
it is
<whitequark>
oh
<whitequark>
it's not Java.
<whitequark>
it's like asm.js version of Java.
* mcc
thinks
<whitequark>
it's completely castrated, even more so than J2ME
<mcc>
any of these ever try to take another crack at hardware support for GC?
<ggole>
Azul has a barrier in hardware iirc
<whitequark>
well, Azul had hardware assisted GC with quite good results
<ggole>
(And some OS support to go along with it.)
<mcc>
cool :O
<ggole>
There are historical machines, too: Lisp machines, for instance
<ggole>
Although those are even more paleolithic than AIX
<whitequark>
mcc: Azul migrates to commodity hardware now, though
<whitequark>
I guess the costs don't justify themselves
<mcc>
They have a lisp machine at the computer history museum near here!
<whitequark>
wow, aJile has OSGi in silicon.
<mcc>
I wished so badly there was some way to turn it on and try it
<ggole>
(Although weirdly advanced - more like the lost city of atlantis in some ways)
<whitequark>
mcc: people built a bunch of FPGA-based lisp machines
<ggole>
Apparently all the source for *everything* was available for inspection
<whitequark>
ggole: software monoculture brings a lot.
<whitequark>
it also takes a lot...
<ggole>
So you could jump-to-definition all the way into the microcode
<ggole>
That would be *something*.
<mcc>
Yeah, i've heard :O
<mcc>
whitequark: *really*
<ggole>
But yeah, it was a walled garden and rapidly died.
<whitequark>
mcc: lisp machines? of course, lisp machines are such an incredibly hipster thing to obsess about, I won't be surprised if there are dozens
<whitequark>
like forth implementations.
<mcc>
hmmmmm
<ggole>
Haha
<mcc>
at least i've encountered forth in the owld.
<mcc>
wild.
<ggole>
Everybody writes a forth (I've lost the source to mine, thankfully).
<whitequark>
I mean, first page in google lists three.
<whitequark>
if you have spare $10k, you can even make yourself an ASIC.
<whitequark>
ASICs are very cheap at this point, in university pools and such
<whitequark>
" For low volume systems, the flexibility of an FPGA can be of more importance then the slightly higher cost compared to conventional processors."
<whitequark>
>slightly higher cost
<whitequark>
we have a radically different definition of "slightly"
<mcc>
type w = A | B | C;; let x = A;; match x with B -> 1 | _ -> match x with A -> 2 | C -> 3;; ... Warning: this pattern matching is not exhaustive
<mcc>
I'm not surprised, but a little irritated * _ *
nicoo has quit [Remote host closed the connection]
<ggole>
Usually (not always) you can use or-patterns to avoid that
<mcc>
how so?
<mcc>
i mean, i don't know what that means
<reynir>
you mean to put it all in one match?
nicoo has joined #ocaml
<ggole>
You can write more than one pattern leading to a single clause
<mcc>
oh!
<ggole>
Eg match x with B -> 1 | (A | C) -> 2
<whitequark>
A | C is actually a single pattern
<whitequark>
e.g. compare with X (A | C)
<mcc>
it's a simplified example. my actual situation is - match on w - is it A? if so, bail out immediately - do a bunch of other complex checks - potentially, later on, match on w again
<whitequark>
well, in this case you do | _ -> assert false, for the cases which you know can never happen
nojb has quit [Quit: nojb]
<mcc>
the thing that's interesting to me is reaching that point in the code with "x" equal to B is impossible, but i still need to cover the case. it doesn't seem obvious the compiler actually can check tha ttho.
<mcc>
yeah, that is what i am doing
larhat has quit [Quit: Leaving.]
<whitequark>
it's not possible to check that, in general case.
<whitequark>
and it complicates the compiler a *lot*.
<whitequark>
I mean, think of deeply nested matching.
jgjl has joined #ocaml
<mcc>
yeah
<ggole>
Are the checks in the form of a guard?
<ggole>
You can, eg, match x with A arg when some_property arg -> ... | A arg -> ...
<mcc>
"when" this is actual ocaml syntax?
<whitequark>
yes
<mcc>
interesting
jgjl has quit [Client Quit]
<ggole>
This is usually useful when the match involves more than just looking at the A
<mcc>
i'll see if i can express it like that
<mcc>
i don't think so because it partially revolves around whether or not to try to iterate over a list, sort of
mcc has quit [Quit: sleep!]
psy_ has joined #ocaml
Kakadu has joined #ocaml
emery has quit [Ping timeout: 250 seconds]
zpe has quit [Remote host closed the connection]
zpe has joined #ocaml
zpe has quit [Ping timeout: 245 seconds]
jgjl has joined #ocaml
nojb has joined #ocaml
nojb has quit [Client Quit]
sgnb has joined #ocaml
clog has quit [Ping timeout: 250 seconds]
clog has joined #ocaml
emery has joined #ocaml
arj has quit [Quit: Leaving.]
psy_ has quit [Ping timeout: 265 seconds]
_5kg has quit [Ping timeout: 255 seconds]
zpe has joined #ocaml
clog has quit [Ping timeout: 245 seconds]
clog has joined #ocaml
thomasga has joined #ocaml
_5kg has joined #ocaml
clog has quit [Ping timeout: 245 seconds]
nojb has joined #ocaml
ygrek has quit [Ping timeout: 250 seconds]
nojb has quit [Client Quit]
ygrek has joined #ocaml
ollehar has joined #ocaml
avsm has joined #ocaml
hausdorff has quit [Remote host closed the connection]
ikaros has joined #ocaml
AltGr has joined #ocaml
c74d has quit [Remote host closed the connection]
c74d has joined #ocaml
thomasga has quit [Quit: Leaving.]
vogler has quit [Quit: WeeChat 1.0.1]
_andre has joined #ocaml
vogler has joined #ocaml
jonludlam has joined #ocaml
bezirg has joined #ocaml
serge has quit [Ping timeout: 265 seconds]
avsm has quit [Quit: Leaving.]
Simn has joined #ocaml
ebzzry has quit [Read error: Connection reset by peer]
ebzzry_ has joined #ocaml
thomasga has joined #ocaml
larhat has joined #ocaml
samrat has quit [Quit: Computer has gone to sleep.]
<companion_cube>
o/
_5kg has quit [Ping timeout: 264 seconds]
dsheets has joined #ocaml
samrat has joined #ocaml
ikaros has quit [Quit: Ex-Chat]
jgjl has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
clog has joined #ocaml
AltGr has left #ocaml [#ocaml]
dmiles_afk has quit [Quit: Read error: 110 (Connection timed out)]
_5kg has joined #ocaml
ikaros has joined #ocaml
hausdorff has joined #ocaml
Kakadu has quit [Quit: Konversation terminated!]
hausdorff has quit [Ping timeout: 240 seconds]
samrat has quit [Quit: Computer has gone to sleep.]
ygrek has quit [Ping timeout: 272 seconds]
samrat has joined #ocaml
jgjl has joined #ocaml
ingsoc has joined #ocaml
dsheets has quit [Ping timeout: 265 seconds]
<Leonidas>
whitequark: btw, we have a few ocaml binding patches at work, do you have experience upstreaming this stuff?
jonludlam has quit [Ping timeout: 272 seconds]
<whitequark>
Leonidas: I'm the maintainer at upstream.
<whitequark>
so, you could say, I do
jonludlam has joined #ocaml
<Leonidas>
whitequark: so I can throw diffs at you? ;)
<whitequark>
you must.
Thooms has joined #ocaml
<Leonidas>
good to know, maybe I'll get to update them for the current SVN version. They are currently for 3.4.2
johnelse has quit [Ping timeout: 256 seconds]
<whitequark>
shouldn't be too hard
samrat has quit [Quit: Computer has gone to sleep.]
<Leonidas>
I thought it might be convenient. i ripped out many parts that I don't need but now I think it would've been easier to just write my own script
<ingsoc>
what made you choose Ocaml ? what other tools/languages did you consider ?
<ingsoc>
why did Ocaml win out over the other options
<adrien>
Drup: defnitely not!
<Drup>
ingsoc: the logo is much cooler and half of the library in the ecosystem have punny names. :]
<ingsoc>
(I am currently evaluating my next language choice)
psy_ has joined #ocaml
<ingsoc>
Drup: you have to do better than that :)
<MercurialAlchemi>
OCaml is not a programming language, it's a standard library generator
<Drup>
ingsoc: sorry, but the question is a big vague, you don't tell what you are looking for, nor which thing you are doing usually :)
<Drup>
and people will answer seriously anyway, I might as well give non serious answers :3
arj has joined #ocaml
<MercurialAlchemi>
I can seriously promise non-serious answers
<ingsoc>
I spose it was just a general query as to what led you to the language and why
<Unhammer>
MercurialAlchemi, haha =D
<MercurialAlchemi>
strong type system, readability, speed
<adrien>
I went for ocaml for these because: I already knew the language well enough, I didn't have a need for the absolute best performance and with ocaml I could make something quickly and have it stable at once
<MercurialAlchemi>
also, Haskell is way too mainstream nowadays
<Drup>
ingsoc: in my case, I learned programming with OCaml, then I learned quite a different number of languages, and I can split in 2 category : their type system sucks or they are hard/annoying to use efficiently
<Drup>
OCaml is in the middle.
<ingsoc>
e.g. My first foray into functional programming was erlang. I was looking for ways to create network servers and I tried the typical multi-threaded (c#), then python and async programming (twisted networking library) and in the end stumbled across erlang and even though it was very different to what I knew already, I stuck with it and am very pleased I went through some pain
<Unhammer>
ingsoc, I make spell/grammar checkers at work and am a bit sick of python bugs that it seems ocaml would've caught (also, though pypy is fast, equivalent ocaml stuff seems to use less memory, and our dictionaries are huge)
bezirg has joined #ocaml
<ingsoc>
I was expecting someone to say, performance but without the pain of c/c++
<ingsoc>
ok
<adrien>
if you want to squeeze the last % of performance from your CPUs, you still need something like C
<adrien>
ocaml is roughly under twice as slow as C
<adrien>
which is way faster than most languages and implementations
<MercurialAlchemi>
I'd say that compared to something like Python, OCaml is considerably faster, you get a program with a comparable line number, and it typechecks
<MercurialAlchemi>
of course, provided you can find the right libraries
<adrien>
and it gives you room to think about higher-level optimizations which can give much bigger benefits
<ingsoc>
java v Ocaml ?, Java seems to be touted as REAL fast nowadays, although running a JVM it will be a much larger memory footprint than Ocaml I expect
Sim_n has joined #ocaml
<MercurialAlchemi>
Java is fast
<Drup>
Java is not much faster than OCaml
<Unhammer>
java is boring
<Drup>
and that.
<MercurialAlchemi>
but it suffers from slow startups and give-me-all-your-RAM syndrom
Simn has quit [Disconnected by services]
Sim_n is now known as Simn
<Drup>
I mean, it's the most painful language to program in I know
<ingsoc>
MercurialAlchemi: This is an interesting comment. I would consider python code bases very concise (compared to c#/java) so to get a similar code size and the benefits you list it sounds compelling
<serge>
forget Java the Language. The JVM, on the other hand is a piece of art!
<MercurialAlchemi>
I assume that Java=JVM, which supports a large number of languages
<Drup>
ingsoc: I advise you to read that.
<Drup>
ah yes
<Drup>
so, if we are talking about things like Ceylon
<Drup>
I agree, it's nice.
<MercurialAlchemi>
but it still eats all your RAM
<ingsoc>
I have been tinkering with clojure
<ingsoc>
no pattern matching though afaict (unless there is a macro lib somewhere that does this)
<Drup>
not statically typed anyway :p
<ingsoc>
also it is not single assignment (which I am accustomed to now with erlang)
<Drup>
"single assignment" ?
<Drup>
you mean immutable by default ?
<rom1504>
well java is oo, you need to get used to oo, just as you need to get used to functionnal style in ocaml
<rom1504>
(not sure how java is painful)
<MercurialAlchemi>
Java's problem is not OO
<MercurialAlchemi>
Java's problem is that it's unusable without an IDE because boilerplate
<serge>
give scala a try then
<panini>
Java's problem is is Java it self. :p
<Drup>
scala is over complicated.
<Drup>
and not even fast
<ingsoc>
Drup I agree on that, it has too many concepts
<panini>
try golang then !!
<MercurialAlchemi>
I think the compiler has gotten faster
<MercurialAlchemi>
but it used to be the slowest thing ever
<Drup>
panini: no, thanks.
<ingsoc>
do you guys find pattern matching a killer feature ?
<Drup>
yes
<Drup>
:)
<ingsoc>
comnpared languages without it ?
<ingsoc>
I do since erlang
<rom1504>
MercurialAlchemi: well yeah I agree an IDE helps. But when you get used to an IDE (like intellij) and then get back to non-ide (possibly for some other language) you miss the ide functionnalities
<MercurialAlchemi>
a bug-killer feature
<MercurialAlchemi>
rom1504: I use an IDE with Java
<whitequark>
Drup: oh, refresh scrolling thing
<whitequark>
please file an issue
<whitequark>
github.com/whitequark/irclogger
q66[lap] has quit [Read error: Connection reset by peer]
<ingsoc>
I tried Ocaml Dev Tools for eclispe
<MercurialAlchemi>
I use vim + Merlin for OCaml, and I don't really miss it apart for a few things
<ingsoc>
not sure it is getting much love though
<ingsoc>
eclipse*
<MercurialAlchemi>
the strong point of the JVM ecosystem is that there are libraries for everything, and they're often really solid and documented
<ingsoc>
keep hearing about polymorphic variants that are supposed to be quite unique to Ocaml
<rom1504>
oh yeah merlin seems nice, well that's the kind of functionnalities you get used in an IDE (autocompletion, and other magic stuff)
<MercurialAlchemi>
OCaml has few libraries (but many stdlibs) and 'documentation' is a dirty word
<rom1504>
(like auto reformating of the code, and static analysis)
q66[lap] has joined #ocaml
<MercurialAlchemi>
(ok, you do have well-documented libs, but you have an unfortunate amount where the doc is a readme of 3 lines)
<ingsoc>
MercurialAlchemi: I think erlang official docco is kinda assuming you know what you are doing and is referenced based
<ingsoc>
is this similar to OCaml ?
BitPuffin has joined #ocaml
<Drup>
MercurialAlchemi: I don't agree with the remark on Java libraries
<Drup>
I mean, java documentation is terribly under-specified
<MercurialAlchemi>
ingsoc: hm, depends what you mean - the default stdlib and the language are documented, but third-party libs you can find in Opam often aren't
<Drup>
I hear people saying that all the time
<MercurialAlchemi>
Drup: Java-the-language, Java's stdlib or Java third party libs?
<Drup>
all the three ?
<MercurialAlchemi>
hm
<Drup>
sure, they have some vaccum feeling general description of the function, but since their typing is so weak, you don't know half what you would like to know
<MercurialAlchemi>
I haven't looked at Java-the-language's documentation in a long while, but IMHO, the stdlib documentation is pretty good
<Drup>
about OCaml library, I think that people are traumatized by the ocasional badly documented library, while the average documentation is not that terrible.
<MercurialAlchemi>
You can find stuff you rarely find in OCaml's doc, like, you know, examples
<Unhammer>
ah, examples … *sigh*
<Drup>
MercurialAlchemi: in Java's stdlib ?
darkf has quit [Ping timeout: 255 seconds]
<ingsoc>
OK, from a practical POV, would you say Ocaml is lacking in libraries or are most of the usual suspects like serialisation libs (JSON msgpack etc.) and http clients etc. all there
<Drup>
it's lacking some libs yeah
<Drup>
or, more precisely, some area are unexplored :)
<MercurialAlchemi>
I'm not sure how much better "there is support but it is crap and you can't have it as a dependency of your opam package" sounds compared to "there is no support"
sepp2k has joined #ocaml
<whitequark>
arguably, it's not
<MercurialAlchemi>
whitequark: I know, I'm contributing to the next version
<MercurialAlchemi>
write support for the people
nojb has joined #ocaml
<MercurialAlchemi>
doesn't help if you need to work with legacy apps using ini files, though
ivg has joined #ocaml
samrat has joined #ocaml
<ingsoc>
btw, I think the tool Opam is cool, erlang needs something like this badly
<MercurialAlchemi>
don't have XSL support either, and the ical lib looks flimsy
<MercurialAlchemi>
opam is pretty nice
shinnya has joined #ocaml
<ingsoc>
So, it looks like Ocaml will be a nice robust alternative to python to run fast sequential functional code and with potential more reliability at the expense of library support
<ingsoc>
i asked this before and it seems Ocaml and Python share the same kind of issues with regard to multicore parallelism
psy_ has quit [Ping timeout: 264 seconds]
<MercurialAlchemi>
There is a multicore runtime in the works, which will be done when it's done
<ingsoc>
Unhammer: interesting to hear about your use of pypy, never tried it myself
<MercurialAlchemi>
For now, lwt works
<ingsoc>
it seems to promise a lot with regard to performance but there is still the issue of 3rd party (C/C++) library support
sgnb has quit [Read error: Connection reset by peer]
arj has joined #ocaml
hausdorff has joined #ocaml
<MercurialAlchemi>
Typically, you're going to spend more time getting something that you can run with OCaml compared to Python, but once it does run, you'll find a lot less errors, even without unit tests (unless you work in a domain where you do a lot of stringly-typed things, for instance)
<ingsoc>
I mean 3rd party python extensions written in c (which a large proportion of them are)
<MercurialAlchemi>
and you'll be a lot less scared of changing something trivial and having your app blowup
<MercurialAlchemi>
wrt to ocaml-to-c, I don't know, haven't really tried
<ingsoc>
Looks like Ocaml was a really good fit for his use case
lordkryss has joined #ocaml
<ingsoc>
I am intrigued by him saying the gui development code was easier than in python
arj has quit [Ping timeout: 245 seconds]
hausdorff has quit [Ping timeout: 256 seconds]
axiles has joined #ocaml
<ia0>
In "let x = !a in ...", is the content of "a" copied to "x" or is there some copy on write on "a"?
<ia0>
oh wait, it's just a link
<ia0>
forget what I said, there's no copy
<MercurialAlchemi>
modifying 'a' won't change 'x'
<MercurialAlchemi>
if that's what you're asking
<mrvn>
but changing !a will modify x
<whitequark>
it's a shallow copy though
<whitequark>
yeah
<mrvn>
(in case !a is mutable)
<mrvn>
In ocaml trivial types (int, bool, variants without args) are stored directly. Everything else is a pointer internally. "let x = !a in ..." copies the contents of a. MEaning a verbatim copy for trivial types or the pointer for everything else.
<mrvn>
And trivial types are never mutables. So it makes no difference that they are a full copy.
jgjl has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
<ivg>
oh, this is not a correct way of saying. Let binding just creates a binding between name and a value. The thing on the left is not a variable in a imperative sense of view, it is just a name, that is linked to the value on the right. And since all values in OCaml are represent with the same way, it doesn't really matter, whether it is an immidiate value or a boxed one
<ivg>
and we're talking about references, we shouldn't forget, that ref is just a record, i.e., type 'a ref = {mutable contents : 'a}, nothing more.
zozozo has quit [Read error: No route to host]
<MercurialAlchemi>
asking if a let binding to something mutable will change when the thing it bound to changes is a good question
<ivg>
the binding will never change
<ivg>
it is the value that changes
<mrvn>
you can pretent everything is passed by reference in ocaml. The exception are trivial types, which are immutable, so it makes no difference wether they are passed by value or reference.
zozozo has joined #ocaml
<ggole>
You can tell with == :)
<ivg>
Well, every OCaml value occupies exactly one word. So passing anything to a function involves "copying" one word. There is never actually deep copying of anything.
arj has joined #ocaml
jgjl has joined #ocaml
nicoo has quit [Ping timeout: 250 seconds]
<MercurialAlchemi>
"war... war never changes"
bezirg has quit [Ping timeout: 245 seconds]
badkins has joined #ocaml
serge has quit [Remote host closed the connection]
serge has joined #ocaml
<ia0>
thanks for the explanation
panini has quit [Quit: Leaving]
<Unhammer>
in tuareg-mode, is there a function to go "up" one form? like if I've got "let () = M.f 1▮ 2" (where ▮ is point) and want to get to "let () = ▮M.f 1 2" ?
travisbrady has joined #ocaml
<ggole>
merlin has something a bit like that
<ggole>
merlin-enclosing-expand
<Unhammer>
oh nice
<ggole>
It sets the region though
<Unhammer>
well, it's exactly what I wanted :)
<ggole>
And there are some things that it doesn't quite handle as you would like (I need to bother def about that...)