<maufred>
Ah yes, I saw something like this in the archives
mcclurmc has quit [Ping timeout: 256 seconds]
hkBst has quit [Remote host closed the connection]
hkBst has joined #ocaml
hkBst has quit [Changing host]
hkBst has joined #ocaml
<flux>
if you're using fork with marshal, you may just go ahead and give the Closures flag to the marshalling functions
<flux>
but yeah, that seems pretty simple&nice :)
<anderse>
i'm interested in reading some high quality ocaml source code, is there any project which source you would suggest?
zpe has quit [Ping timeout: 245 seconds]
<companion_cube>
not mine! :D
rwmjones has joined #ocaml
<flux>
not sure about the quality, but atleast mldonkey is quite large
<toolslive>
unison is not that big, but very nice.
weie has joined #ocaml
<anderse>
tooslive, perfect, a colleague was looking into using unison in our quite large production but didn't because of unfamiliarity with ocaml. Thanks for the suggestion!
weie_ has quit [Ping timeout: 264 seconds]
<flux>
unison used to have a problem with big deltas. but that solved itself when switching to 64 bit platforms :)
<toolslive>
I remember a bug where one tier was on 32 bit and the other on 64 bit
<toolslive>
but the big delta problem originates in the rsync strategy they use.
<toolslive>
(the performance problem that is)
zpe has joined #ocaml
weie has quit [Read error: Connection reset by peer]
ulfdoz has quit [Ping timeout: 252 seconds]
weie has joined #ocaml
Neros has joined #ocaml
zpe has quit [Ping timeout: 276 seconds]
mye has joined #ocaml
<sgnb>
anderse: why would it matter? you don't need familiarity with ocaml to use unison...
ulfdoz has joined #ocaml
<anderse>
sgnb: when something breaks for us - we have 1.5 million angry users that are expecting live sports data at a 10 second precision, so we try to use stuff we can understand/fix or at least whose idiosyncrasies we've ran into before - ofc that is not always possible
mcclurmc has joined #ocaml
<toolslive>
@anderse, which product would that be?
<toolslive>
(curious)
<anderse>
Live Score Addicts (iphone and android live soccer mobile app)
ollehar1 has joined #ocaml
<adrien_oww>
well, you could apply the same thought process to assembly and x86_64 assembly (for instance) is certainly more difficult to master than ocaml ;-)
<flux>
adrien_oww, do you think they would want to have an application that's written directly in x86_64 assembly?-)
<anderse>
adrien_oww: sure, im sure you understand they basic reasoning though - even though taking it to de extreme in either direction would be silly
<toolslive>
@adrien, intel asm is indeed more difficult, but that's an insult to asm.
<flux>
(and the language a tool is written in is the level where fixes usualyl occur as well; at times it could be its runtime (C) or libraries (C))
<adrien_oww>
anderse: yeah, I was partly kidding; you can expect unison to be very reliable :-)
<anderse>
sounds good, ill try to get inspired to port some stuff to ocaml by reading it source as well :)
<ggole>
intel assembly isn't too bad
<ggole>
No odd stuff like modulo scheduling to mess you up
cdidd has joined #ocaml
yacks has quit [Quit: Leaving]
yacks has joined #ocaml
hkBst has quit [Ping timeout: 245 seconds]
hkBst_ has joined #ocaml
q66 has joined #ocaml
hkBst_ has quit [Excess Flood]
hkBst_ has joined #ocaml
hkBst_ has quit [Changing host]
hkBst_ has joined #ocaml
zpe has joined #ocaml
_andre has joined #ocaml
jpdeplaix has quit [Ping timeout: 255 seconds]
hkBst_ has quit [Remote host closed the connection]
hkBst_ has joined #ocaml
zpe has quit [Ping timeout: 276 seconds]
<toolslive>
it's too darn irregular (intel asm)
hkBst_ has quit [Ping timeout: 245 seconds]
hkBst_ has joined #ocaml
hkBst_ has quit [Changing host]
hkBst_ has joined #ocaml
zpe has joined #ocaml
jbrown has joined #ocaml
<ggole>
True
<ggole>
But the basics are acceptable
<ggole>
And the really odd stuff doesn't apply most of the time
<ggole>
The encoding is pretty hairy, but most people don't have to deal with that
anderse has quit [Quit: anderse]
groovy2shoes has joined #ocaml
zpe has quit [Ping timeout: 245 seconds]
<toolslive>
there's too many syntaxes ;)
<toolslive>
and gcc integration is awful
<toolslive>
I'm quite glad I don't have to descend often.
<ggole>
It would be nice if AT&T syntax went away, yeah
<toolslive>
the problem is that C does not define asm bindings, and every compiler vendor build its own thing
<toolslive>
I'm wrong: not the problem, but one of them.
<ggole>
Surely that's not, itself, an x86 problem
<ggole>
Although it does lead to annoying duplication of various constructs
<ggole>
Vector types, rotate operations, etc
<ggole>
All slightly different
<ggole>
But you can't blame Intel :)
groovy2shoes has quit [Quit: Computer has gone to sleep]
zpe has joined #ocaml
mye_ has joined #ocaml
mye_ has quit [Client Quit]
mye has quit [Ping timeout: 264 seconds]
ollehar has quit [Ping timeout: 245 seconds]
zpe has quit [Ping timeout: 245 seconds]
mort___ has joined #ocaml
zpe has joined #ocaml
ollehar has joined #ocaml
mcclurmc_laptop has joined #ocaml
mcclurmc has quit [Ping timeout: 256 seconds]
ollehar has quit [Ping timeout: 264 seconds]
jpdeplaix has joined #ocaml
_eko_ is now known as _eko
awm22 has quit [Ping timeout: 264 seconds]
darkf has quit [Quit: Leaving]
awm22 has joined #ocaml
Neros has quit [Read error: Operation timed out]
<ollehar1>
is there a good way to simulate a linear type system in ocaml?
<ollehar1>
e.g., I want some Lua functions to be called only when a table is on top of the lua stack
<flux>
well, monads maybe, but it can be more restrictive than linear types
<ollehar1>
adt could be one way, like type lua = Table_on_top state | Nothing_on_top state ...
<flux>
maybe monads, some way to escape them and runtime checks
amaloz has joined #ocaml
Neros has joined #ocaml
cago has left #ocaml []
ocp has quit [Ping timeout: 245 seconds]
dwmw2_gone is now known as dwmw2
ottbot has joined #ocaml
mfp has joined #ocaml
Snark has quit [Ping timeout: 246 seconds]
Snark has joined #ocaml
ccasin has joined #ocaml
PM has quit [Ping timeout: 246 seconds]
PM has joined #ocaml
hkBst_ has quit [Quit: Konversation terminated!]
tianon has quit [Ping timeout: 260 seconds]
tianon has joined #ocaml
yroeht has quit [Read error: Operation timed out]
yroeht has joined #ocaml
sken has joined #ocaml
<sken>
hi
<ollehar1>
hi yourself
Neros has quit [Read error: Operation timed out]
oriba has joined #ocaml
zpe has quit [Remote host closed the connection]
adahlberg has joined #ocaml
djcoin has quit [Quit: WeeChat 0.3.9.2]
srcerer_ is now known as srcerer
Neros has joined #ocaml
Kakadu has quit []
sken has quit [Quit: Page closed]
<ollehar1>
is there a way in ocaml to check at compile time boundaries of an argument? e.g. n > 0
<thelema>
ollehar1: how would it know the value at compile time?
<ollehar1>
thelema: by looking at how the function is used?
<thelema>
ollehar1: probably turing complete to do this
awm22 has quit [Quit: Leaving.]
<def-lkb>
you can always enforce custom invariants using smart constructors (with private types for convenience)
<thelema>
def-lkb: yes, this is a good way to do this.
<thelema>
but it's not at compile time; it's just distinguishing between already checked and not yet checked using the type system
ttamttam has quit [Quit: ttamttam]
<ollehar1>
def-lkb: ok
<ggole>
You can do that kind of type checking with dependent types
<ggole>
Becomes pretty painful imo
adahlberg has quit [Remote host closed the connection]
Yoric has quit [Ping timeout: 252 seconds]
anderse has joined #ocaml
kaustuv has joined #ocaml
<flux>
I suppose a golden middle road is a research topic
<thelema>
flux: between dependent types and run-time checking?
<flux>
yes. and generating proofs :)
mika1 has quit [Quit: Leaving.]
Kakadu has joined #ocaml
<kaustuv>
OPAM has really made my life tremendously less dreary. Well done to all the devs!
ttamttam has joined #ocaml
<avsm>
are you on a mac?
<orbitz>
opam is tops
<ggole>
I've wondered a bit about a "middle road" for types
<avsm>
here's an easter egg: export OPAMUTF8MSGS=1 on a mac and opam install something
<avsm>
and it'll be even less dreary ;-)
<ggole>
I've often wanted to be able to have error be, instead of a runtime failure, something that would constrict types such that the error was statically prevented
<ggole>
But I don't think it's possible without annotations everywhere
<flux>
maybe something that would work with the editor and indicate dubious points, places needing annotation to avoid runtime checks
<flux>
I really should look into ATS some day, maybe the only practical(?) language with those features
<ggole>
I have it installed: never really dove into it though
<flux>
yeah, it isn't sufficient to just have it installed :-)
<orbitz>
doublec's blog has soem godo stuff for ATS
<orbitz>
I find the language pretty hard to grok though
<ggole>
Yeah
<flux>
I think the sadest part of ATS is that it seems even more verbose than C
<flux>
but maybe that's only my untrained eye :)
<ggole>
ATS isn't trying to be concise
<orbitz>
I'd really love Ocaml to get linear types, I think they coudl be great for resources
ontologiae has quit [Ping timeout: 245 seconds]
<flux>
orbitz, indeed, but that kind of feature would affect all levels
<orbitz>
yes
<kaustuv>
Linear types are a massive pain in the neck in any language that has closures. Be careful what you wish for.
<orbitz>
:)
<ggole>
Doesn't Rust do something like that?
<orbitz>
I think Rust went the C++ path with just a bunch of different pointer types
<kaustuv>
It has ownership, which is not quite the same thing as linear
<kaustuv>
And in any case, Rust completely punts on the question of hiding owned values in closures (by making it impossible)
<ggole>
C++ has no safety whatsoever though
<ggole>
Which allows for pointers to be simple and straightforward
<flux>
I think RAII is a safety feature of sorts..
<ggole>
But also allows for dangling, double free, and other fun
<flux>
it's much easier to leak operating system resources in ocaml than in c++, I think
<orbitz>
ggole: with raw pointersi nC++, yes, but there are a bunch of extra pointer types built around RAII that are fairly safe
<ggole>
If you have a vector of ints, take the address of one, and resize the vector
<ggole>
The pointer is live, but garbage
<ggole>
Pointer types do nothing for this problem
<orbitz>
ggole: that would be using raw pointers, i'm talking about the other pointer types
mort___ has quit [Quit: Leaving.]
<ggole>
They don't help either
<orbitz>
no they don't, but doing that is somewhat frowend upon i nC++
<ggole>
Unless you make the vector be a vector of pointers
<flux>
well, just don't use pointers then :)
<ggole>
Which is expensive
<kaustuv>
"resize the vector"? What memory models support resizing in place?
<flux>
(I suppose the same issues affect references as well, and in some sense they are worse)
<orbitz>
kaustuv: C++'s
<ggole>
kaustuv: for resize read "any operation which might relocate the vector's memory"
<ggole>
The standard mentions which ops might lead to iterator invalidation, I think
<ggole>
Those
<orbitz>
it does
<kaustuv>
obvioulsy if you relocate you also have to update pointers to inside a block
<ggole>
And if you don't
<orbitz>
yes, which is ggole's point :)
<ggole>
You have a use after free
<flux>
there would need to be special new kind of pointer type to support pointer-to-container-that-is-resized
Yoric has joined #ocaml
<kaustuv>
Just point to the start of the block and keep an offset in a tuple
<ggole>
Clean and performant are goals that are somewhat at odds since indirection allows nice semantics but is expensive
<orbitz>
what if the start changes?
<ggole>
You need a reference to the location which points to the start
<kaustuv>
then the gc would update the pointer. You do have a GC that updates pointers, right?
<ggole>
Which means a double dereference to access an element.
<kaustuv>
Or use read barriers, whatever
<ggole>
A gc won't update objects unless *it* moves them
<kaustuv>
If anything but the gc does relocation, then your language is silly
<kaustuv>
and you should feel silly
<ggole>
...
<orbitz>
we are talking about C++...
<ggole>
No relocations has nice semantics
<ggole>
But all the introduced indirection is hell on cache effects
<ggole>
Like I said: fast or clean
osa1 has joined #ocaml
<osa1>
do we have a bottom value like Haskell's "undefined" in OCaml ?
<osa1>
for type checking purposes
<thelema>
osa1: not at all
<thelema>
I guess you can define uninhabited types
Cyanure has joined #ocaml
<ggole>
osa1: er, for type checking?
<ggole>
You want an expression that will type check, but isn't of a particular type? To fill in temporarily, say?
<kaustuv>
(failwith "undefined")
<kaustuv>
(note: not a value)
<ggole>
I usuall go with failwith "implement" or something, yeah
<osa1>
great
<osa1>
thanks
* ggole
would like a version that mentioned line numbers
<thelema>
ggole: you'll have to pre-process your source code to get that at the moment
<kaustuv>
You can get it easily with -ppx
<ggole>
I guess assert false; failwith "blargh" would do
<ggole>
But that is not exactly convenient
<thelema>
ggole: just `assert false` suffices
mcclurmc_laptop has quit [Ping timeout: 256 seconds]
<thelema>
I think...
<ggole>
Has type unit.
eikke has quit [Ping timeout: 260 seconds]
<ggole>
Not type 'a.
<thelema>
:( oops. I thought I had done this before.
<thelema>
you're right then.
<kaustuv>
I thought assert false was special cased in the type checker to have type 'a
<ggole>
What, really?
* ggole
checks
<thelema>
# let f _ = assert false;;
<thelema>
val f : 'a -> 'b = <fun>
<ggole>
!
<ggole>
Why did I not know of this
<ggole>
kaustuv: thanks, that is handy to know
<kaustuv>
for a real brain bender, assert false has type 'a even if you compile with -noassert
<thelema>
kaustuv: assert false isn't removed by -noassert
<kaustuv>
meaning that assert false always fires
<flux>
kaustuv, does it still fail?
<thelema>
assert false is special.
<flux>
man, no secret loophole for undefined behavior :(
<kaustuv>
but assert false and assert (not true) have different runtime behavir
<ggole>
That's quite a disgusting little hack :)
<ggole>
flux: if you want Obj.magic, you know where to find it
<flux>
ggole, disgusting, beatiful, depends on who's looking at it ;)
<flux>
ggole, but that's not a secret loophole!
<kaustuv>
I will go with "convenient"
ousado has quit [Read error: Connection reset by peer]
Uvs has joined #ocaml
ousado has joined #ocaml
<kaustuv>
By the way, back on the topic of relocating pointers, the same issue happens with concurrent mutators and collectors in a parallel gc.
mfp has quit [Read error: Connection reset by peer]
eikke has joined #ocaml
awm22 has joined #ocaml
ottbot has quit [Ping timeout: 256 seconds]
mfp has joined #ocaml
tonyg has joined #ocaml
<tonyg>
Hi all. Is it possible (even easy?) to make ocamlbuild produce a binary that is completely statically linked? No shared library dependencies at all?
<adrien>
that's the default mode of operation
<adrien>
libc is another, more complicated, matter
<tonyg>
adrien: not true, I don't think. ldd on my binary shows deps on libpthread, libm, libdl, libc
<adrien>
sorry, meant "for ocaml libraries"
<tonyg>
:)
<tonyg>
yeah, i'd noticed and appreciated that already
<adrien>
need to check some syntax
<tonyg>
i mean to say, i think it's cool that ocaml is already mostly-static
<adrien>
/opt/ocaml/lib/ocaml/std-lib/libasmrun.a(unix.o): In function `caml_dlopen':
<adrien>
unix.c:(.text+0x2f1): warning: Using 'dlopen' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking
<adrien>
19:52 ~/t/ooo % ldd a.out not a dynamic executable
<tonyg>
oh cool! heh... now i wonder how to get ocamlbuild to do that
<adrien>
I have an invocation of ocamlbuild which is: ocamlbuild -cflags -rectypes foo.native
<tonyg>
hmm the "-cflags '-cclib -static'" didn't work
<tonyg>
no errors; just produced a dynamically-linked executable
<tonyg>
(i should say i'm also using opam and lwt...)
<tonyg>
"-cflags -cclib -cflags -static" didn't work either: no effect at all
<tonyg>
hmm.
<tonyg>
so running "ocamlbuild -use-ocamlfind -X scratch -cflags '-cclib -static'" produced a binary indistinguishable from that same command-line without the -cflags part.
<adrien>
invoke ocamlbuild with -classic-display
<thelema>
tonyg: have a look at the _build/_log file to see what command it ran