julm has quit [Read error: 60 (Operation timed out)]
julm has joined #ocaml
julm is now known as register
register is now known as julm
jeddhaberstro has joined #ocaml
jeddhaberstro_ has joined #ocaml
ergodick1 has joined #ocaml
jeddhaberstro has quit [Read error: 110 (Connection timed out)]
alexyk has quit []
alexyk has joined #ocaml
seafood has joined #ocaml
ched_ has quit [Read error: 110 (Connection timed out)]
ched_ has joined #ocaml
ulfdoz has quit [Read error: 60 (Operation timed out)]
jeddhaberstro_ has quit []
elehack has quit ["Leaving"]
alexyk has quit []
alexyk has joined #ocaml
jknick has joined #ocaml
jknick has quit [Read error: 110 (Connection timed out)]
jknick has joined #ocaml
kaustuv_ has joined #ocaml
m3ga has quit [anthony.freenode.net irc.freenode.net]
kaustuv has quit [anthony.freenode.net irc.freenode.net]
nimred has quit [anthony.freenode.net irc.freenode.net]
nimred has joined #ocaml
m3ga has joined #ocaml
ched_ has quit [Read error: 110 (Connection timed out)]
ched_ has joined #ocaml
seafood has quit []
Camarade_Tux has joined #ocaml
ergodick1 has quit ["Leaving."]
flx_ is now known as flux
jeanbon has joined #ocaml
jeanbon has quit [Client Quit]
Camarade_Tux has quit ["Leaving"]
angerman has joined #ocaml
pants1 has joined #ocaml
Alpounet has joined #ocaml
m3ga has quit ["disappearing into the sunset"]
<det>
mrvn, ping
rwmjones_ has quit ["Leaving"]
ikaros has joined #ocaml
sporkmonger has quit []
jmou has joined #ocaml
julm has quit [Read error: 110 (Connection timed out)]
ikaros has quit ["Leave the magic to Houdini"]
jknick has quit ["Lost terminal"]
Yoric[DT] has joined #ocaml
_zack has joined #ocaml
hkBst has joined #ocaml
barismetin has joined #ocaml
jeanbon has joined #ocaml
barismetin has left #ocaml []
barismetin has joined #ocaml
Lomono has quit []
ergodick has joined #ocaml
ergodick has left #ocaml []
_zack has quit ["Leaving."]
rjack has joined #ocaml
Snark has joined #ocaml
angerman has quit []
rwmjones_ has joined #ocaml
_zack has joined #ocaml
verte has joined #ocaml
Jedai has joined #ocaml
<Yoric[DT]>
Does anyone know of a way to do green threads in ocaml, with native compilation?
<Yoric[DT]>
Variant on the question: does anyone know if there's a way of inspecting the stack in native OCaml?
<mrvn>
green threads?
<totom>
mrvn: threads managed by the process itself, not by the OS
<mrvn>
If you use CPS that is trivial.
<mrvn>
Yoric[DT]: On most systems there is some library to do stack backtraces. You could write some stubs for it.
jeanbon has quit ["EOF"]
<flux>
green threads with native compilation would indeed be interesting, from the performance point of view. well, as long as ocaml doesn't have proper concurrent processing :)
<mrvn>
There are userspace thread libraries out there. Shouldn't be too hard to link against one instead of kernel threads.
<mrvn>
flux: when would you trigger thread switches though?
<flux>
mrvn, dunno, but I suppose some solutions to that problem do exist
<flux>
mrvn, for example with SIGALRM
<mrvn>
one thread holds the global ocaml lock and only that can run ocaml code. All other threads will be waiting on that lock.
<mrvn>
But ocaml must already have some point where it voluntarily gives up the lock.
Israel has joined #ocaml
Lomono has joined #ocaml
<Israel>
Hi everybody. I'm starting out with OCaml and have building foundation knowledge on lamba calculi in order to deep understand it. Im trying to reimplement the very basic structures but got somewhat stomped on substitution. I know what exactly is happening: the type inferring rules of the language restrict the return value of my function but I dont want it. The code is here: http://pastebin.com/d5ca0346b
<Israel>
the defect occurs on line 17 which the interpreter shows:
<Israel>
Error: This expression has type termo but is here used with type var = string
<Israel>
so how do I force it not to restrict the return type while evaluating line 16?
<Israel>
Thanks, bump me if anybody reads..
<mrvn>
Israel: you can never return different types from a function.
<Israel>
the they are the same type trough a sum type
<mrvn>
Line 15 returns string, Line 16 returns var
<Israel>
i wanted it to be interpreted as type term
<mrvn>
And Line 17 returns term, which is completly different
<Israel>
because a string is a term
<Israel>
and a var is a term
<mrvn>
Then you need Const c -> Const c
<mrvn>
no, var is a string
<mrvn>
or Const _ -> m
<Israel>
owell Var is a term
<mrvn>
Var v -> it v = x then Var t else Var v
<mrvn>
or is t a term?
<Israel>
OH, I can cast types like it was Java
<Israel>
Omg, thanks
<mrvn>
No, you can construct values.
<Israel>
Hmm I see how it differ, I'm actually using the a Type constructor
<mrvn>
Var v -> if v = x then t else m is better because it doesn't construct a new Var v.
<mrvn>
(andt is a term I see)
<Israel>
you enlighted me
<Israel>
thanks alot :D
<mrvn>
np
ulfdoz has joined #ocaml
_andre has joined #ocaml
Israel has quit []
seafood has joined #ocaml
Israel has joined #ocaml
schme has joined #ocaml
<Yoric[DT]>
mrvn: well, stack backtraces might not be quite sufficient for wht I have in mind.
<mrvn>
damn, I forgot to box doubles in my C stubs and years later that segfaults when I try to unbox them in some other C stubs.
jamii has quit [Read error: 110 (Connection timed out)]
Axioplase has joined #ocaml
jeromeg has joined #ocaml
<jeromeg>
hello
<jeromeg>
does anyone know if there is an equivalent of #print_length n (ocaml) that can be used in caml light?
<jeromeg>
I tested with set_print_length but it does not work
<jeromeg>
ok, it was set_print_depth, sorry :(
seafood has quit []
itewsh has joined #ocaml
verte has quit ["~~~ Crash in JIT!"]
ergodick has joined #ocaml
itewsh has quit [Connection timed out]
itewsh has joined #ocaml
itewsh has quit [Read error: 60 (Operation timed out)]
itewsh has joined #ocaml
ergodick has left #ocaml []
sgnb has quit [Read error: 104 (Connection reset by peer)]
sgnb has joined #ocaml
jeanbon has joined #ocaml
komar_ has quit [Remote closed the connection]
komar_ has joined #ocaml
Spiwack has joined #ocaml
Alpounet has quit [Remote closed the connection]
Israel has quit [Read error: 104 (Connection reset by peer)]
Israel has joined #ocaml
ikaros has joined #ocaml
ahnfelt has joined #ocaml
<ahnfelt>
how come a * b * c is neither (a * b) * c nor a * (b * c) ?
<ahnfelt>
(the tuple/product type, that is)
<olegfink>
yes, * isn't associative
<Spiwack>
Because it has no reason to be.
<olegfink>
I think you'd agree that a 3-tuple isn't the same as a tuple of tuple and something else
jeromeg has left #ocaml []
<Spiwack>
In mathematics they are usually identified because they are isomorphic sets.
<Spiwack>
Which is cool and all
<Spiwack>
But not all there is to say about tuples.
<ahnfelt>
I'm not sure what the need for 3+ tuples are
<Spiwack>
Well, they are 3+ tuples
<Spiwack>
It so happen that you can represent them as iterated pairs
<olegfink>
tuples in ocaml are just polymorphic arrays
Ched has joined #ocaml
itewsh has quit [Success]
<Spiwack>
But there is a more "primitive" representation.
<Spiwack>
at least a representation that isn't a pair of anything.
itewsh has joined #ocaml
<Spiwack>
This is much in the same spirit as unbiased algebraic structures.
<Spiwack>
(though motivated really differently)
<Spiwack>
(the motivation being speed and space of execution)
<ahnfelt>
ok
<Axioplase>
(and common sense?)
dest has quit ["Lost terminal"]
mishok13 has quit ["Stopping IRC chat... [OK]"]
ched_ has quit [Read error: 101 (Network is unreachable)]
<ahnfelt>
I think the iterated pairs model is more intuitive, but oh well :)
<ahnfelt>
Anyway, I'm building a library for parallelism where it'd be nice to treat tuples generically.
<ahnfelt>
For example: let (x, y) = run_in_parallel_until_done f1 f2 in ...
<ahnfelt>
let (x, y, z) = run_in_parallel_until_done_3 f1 f2 f3 in ...
<ahnfelt>
etc., is a bit tedious to define
<olegfink>
ahnfelt, given the current implementation, the difference is only syntactic
<mrvn>
ahnfelt: let x = (1,2) in let y = (x, 3) in let z = (x, 4)
LeCamarade|Away is now known as LeCamarade
<mrvn>
ahnfelt: y and z will share the x.
<ahnfelt>
ah, so you suggest let (x, (y, z)) = ...
<mrvn>
ahnfelt: if you make (a * b) * c and a * (b * c) equivalent to a * b * c then theycan't share.
<Spiwack>
well, anyway, the difference is that between the types 'a * 'b * 'c (ternary product) and 'a * ('b*'c) (iterated pair)
<ahnfelt>
I'd only make a * b * c = a * (b * c)
<mrvn>
ahnfelt: let y = (3, x) and z = (4, x)
<ahnfelt>
(or only the other way around, it doesn't matter)
<Spiwack>
I feels little boilerplate to use parentheses to specify your tuples, doesn't it?
<ahnfelt>
mrvn: why is that a problem?
<mrvn>
ahnfelt: not a problem, but if a * b * c and a * (b * c) are the same then they can't share x.
<ahnfelt>
why not_
<ahnfelt>
(sorry if I'm slow)
<mrvn>
ahnfelt: well, aehm, because pointers (values) may not point into the middle of a block or the GC gets confused.
<ahnfelt>
Oh, with the array model
<ahnfelt>
that makes sense
<mrvn>
ahnfelt: int * int * int is a block of 3 int. int * (int * int) is a block of int and a pointer to int * int
<mrvn>
Only with the pointer you can share data.
<ahnfelt>
Well I understand that it does not fit with the array representation
<mrvn>
Do you want to represent tuples like lists?
<ahnfelt>
I don't mind the OCaml representation
<Spiwack>
That's basically what he was suggesting.
<ahnfelt>
But not exactly like a list
<mrvn>
That would make let (_,_,_,_,_,_,_,_,_,_,x) = ... rather slow.
<ahnfelt>
It's linear either way
<mrvn>
tuple access is O(1), list is O(n)
<ahnfelt>
But assigning n variables takes O(n) time either way
<ahnfelt>
oh
<ahnfelt>
yeah with _
<ahnfelt>
But that's a contrived example, I think ;-)
<Spiwack>
Well
<Spiwack>
Complexity is not all there is
<Spiwack>
The iterated pair representation
<Spiwack>
Does much more pointer-chasing
<Spiwack>
(this is costly, because not cache-friendly)
<mrvn>
If you don't mean (a, (b, c)) then don't write it
<Spiwack>
Or
<Spiwack>
If you don't mean (a,b,c) then don't write it ;-)
<ahnfelt>
Spiwack: I'm not sure about the OCaml GC, but I'd assume allocation is just incrementing a pointer
<mrvn>
ahnfelt: yep
<ahnfelt>
so tuples would probably be represented sequentially either way
<ahnfelt>
making it cache friendly
<Spiwack>
well
<Spiwack>
you've got a large overhead
<mrvn>
ahnfelt: You can define run_in_parallel to take a variable number of arguments and return an array of right size.
<Spiwack>
and you always face fragmentation troubles.
<ahnfelt>
But the return values may differ in their type
<mrvn>
ahnfelt: polymorphic
<ahnfelt>
mrvn: hmm, polymorphic arrays?
<mrvn>
ahnfelt: You need a phantom value to encode the number of function to run. Kind of like printf format strings do.
hzzhang has joined #ocaml
<ahnfelt>
mrvn: I will look into prinf, thank you!
<mrvn>
ahnfelt: nah, that won't help you. Too different. I just mean that the format for printf determines how many fuerther args it takes.
<mrvn>
Hmm, a few days ago someone posted an url for fixed size arrays but I can't find it again.
<Yoric[DT]>
And, of course, there's the additional issue of the limitation on the number of threads.
<mrvn>
ahnfelt: did you see my paste?
<ahnfelt>
yeah :)
<Yoric[DT]>
(on my station, ocaml dies at 382 threads)
<Yoric[DT]>
mrvn: not sufficient, I'm afraid.
<Spiwack>
382 threads is really little... that's a bit weird
<mrvn>
Yoric[DT]: can your write your code in continuation passing style?
<Yoric[DT]>
mrvn: Thread.select might be better.
<Yoric[DT]>
No, I can't.
<Yoric[DT]>
(that was my first choice :))
<mrvn>
Yoric[DT]: but you are willing to patch ocamlopt?
<Yoric[DT]>
I'm considering it.
<Spiwack>
( I guess lwt isn't an option either? )
<Yoric[DT]>
(but no, I'm not going to implement call/cc in ocamlopt :))
<Yoric[DT]>
Spiwack: no, it isn't.
<mrvn>
Yoric[DT]: you could take for example the entry point for the GC and do some set_jmp/long_jmp magic there.
Camarade_Tux has joined #ocaml
<mrvn>
Yoric[DT]: i.e. every time a thread allocates you (potentially) schedule.
<ahnfelt>
mrvn: it doesn't seem to return tuples or the like though
<mrvn>
ahnfelt: no, lists in my case.
<Yoric[DT]>
mrvn: yes, I was considering set_jmp/long_jmp magic, but with possible hints based on patching [Thread.create].
<ahnfelt>
mrvn: but with lists, I might as well do parallel [f1, f2, ...]
<mrvn>
ahnfelt: the define $ differently.
<Yoric[DT]>
Spiwack: actually, I think it's improving. It used to be around 100, iirc.
<mrvn>
Yoric[DT]: Thread.create would create a new register set and add it to the ring of threads.
<ahnfelt>
mrvn: I think I'm missing something, what is the benefit of doing it wiht begin and end?
<mrvn>
ahnfelt: that you can define it so that let ((a, b), c) = (parallel_begin f1 $ f2 $ f3 )parallel_end
* Yoric[DT]
is wondering whether libc's getcontext/setcontext/... would work with OCaml.
<ahnfelt>
Oh, but then I think it's simpler to define let (|||) f1 f2 () = Csp.parallel f1 f2
<ahnfelt>
(as in the link I pasted)
<mrvn>
works too
<ahnfelt>
But somehow, from the users point of view, it might be easier to use parallel42 anyway
<mrvn>
Yoric[DT]: certainly.
<ahnfelt>
anyway, I gotta go
<ahnfelt>
thank you for the input
ahnfelt has quit ["leaving"]
<Yoric[DT]>
Well, anyway, time to go.
<Yoric[DT]>
Cheers everyone.
Yoric[DT] has quit ["Ex-Chat"]
LeCamarade is now known as Away|LeCamarade
<mrvn>
hmm, truncate, unlink and rmdir left to implement and then I think my fuse bindings are usable.
rwmjones_ has quit [Read error: 110 (Connection timed out)]
<mrvn>
I need Hashtbl.filter tbl fn : ('a, 'b) Hashtbl.t -> ('a -> 'b -> bool) -> unit remove all elements from tbl where fn returns false.
<mrvn>
Can I call Hashtbl.remove from inside a Hashtbl.iter?
<flux>
good question. I usually side-step such issues, with some loss of performance.
komar_ has quit [Read error: 110 (Connection timed out)]
<mrvn>
I made the table mutable now and use Hashtbl.fold. Elements I want to keep I insert into the new one.
<flux>
you sure you don't want to use Map?-)
_zack has quit ["Leaving."]
<mrvn>
Map has O(log n) access, right?
<flux>
yes.
_zack has joined #ocaml
<Spiwack>
Map is bleeding efficient.
<mrvn>
That would make filtering O(n log n) worst case.
<Spiwack>
No, feeding an empty map with n values has amortized cost O(n)
<Spiwack>
There is some loss compared to hash tables of course.
<mrvn>
how so?
<flux>
whether Map or Hashtbl is more efficient depends on the number of elements and the size of the key
<Spiwack>
Well, I'm not skilled enough to do the amortized analysis of AVL :p
<Spiwack>
But I'm pretty sure it's true
<mrvn>
A Map is a balanced tree and inserting n keys costs O(n log n)
<Spiwack>
Mmmm... you probably are right actually
<mrvn>
Building a tree given an array of n sorted keys is probably O(n)
<flux>
and I suppose the distribution of the keys. if the keys are wildly different and huge, Map's compares can finish earlier than creating a hash of the key
<Spiwack>
And how fast you can compare objects too
<mrvn>
I have an (int, int) Hashtbl.t. Each entry maps a logical 1MB block of a file to a physical 1MB block on disk.
<flux>
mrvn, benchmark?
<flux>
but, off to a walk before sauna ->
<mrvn>
If it weren't for sparse files I would use an array.
<mrvn>
And access is the most common operation, so O(1) there is important.
travisbrady has joined #ocaml
itewsh has quit [Connection timed out]
<Spiwack>
How large a set do you expect ?
itewsh has joined #ocaml
<mrvn>
File size is usualy a few k, 15MB, 50MB, 350MB, 1150MB, 4000MB or 8000MB
<mrvn>
i.e. nfo file, small rar chunk, big rar chunk, avi, mkv, single laayer dvd, dual layer dvd
<mrvn>
Hashtbl has problems with sets >16 million keys, right?
<Spiwack>
dunno
<Spiwack>
Depends on the array limit on your architecture I guess
<mrvn>
Afaik it uses an array internaly and that is limited to 16 million.
<mrvn>
on 32bit
<Spiwack>
Well, it's an array of lists
<Spiwack>
so you can approx double it with no trouble.
<brendan>
my recollection is that hash burns 8-16 bytes per entry on top of the actual data anyway
<mrvn>
bernardofpc: Each entry in the array is a list. so 4-8 or 8-16 depending on arch.
<mrvn>
Anyway, 8000 entries would be about maximum.
<Spiwack>
and it's fairly small
<mrvn>
I should test the performance with Hashtbl and plain array.
<mrvn>
Growing an array just sucks.
<mrvn>
well, truncate() works.
<Spiwack>
(log of 8000 is 13, that's a maximum in pointer chasing Maps, in hashtable you would have a twice or three times faster worst-case access possibly ? )
sporkmonger has joined #ocaml
<mrvn>
array would be truely just ptr + offset
<Spiwack>
yes indeed
<Spiwack>
I wasn't talking about arrays
<Spiwack>
They have different caveats
<mrvn>
I guess Hashtbl calculates a hash and then div size
<mrvn>
Or is it optimized to nice array sizes that don't need an expensize div?
<Spiwack>
Dunno
<Spiwack>
Source code is open ;-)
<mrvn>
yeah, I just don't have the time to memorize it all :)
<mrvn>
hashing + div could cost the same as a few pointer followings.
<Spiwack>
it might include a few pointers too
<Spiwack>
depending on what you are hashing
<mrvn>
well, the slow part will be disk I/O so it probably won't show
<Spiwack>
(but then again, on Maps you have comparison to take into account, can be bad)
<Spiwack>
Well
<Spiwack>
Disk I/O is slow :p
<mrvn>
50MB/s sequentially
jamii has joined #ocaml
ulfdoz_ has joined #ocaml
<flux>
Disk I/O keeps getting better - SSDs..
<flux>
and I can easily imagine consume-grade raid-solution giving 200M/s
<flux>
(given just a single disk can give 100M/s)
rjack_ has joined #ocaml
travisbrady has quit [Read error: 104 (Connection reset by peer)]
travisbrady has joined #ocaml
_zack has quit ["Leaving."]
<Camarade_Tux>
ssd aren't that great currently RAID arrays of usb keys usually beat them ;p
<flux>
camarade_tux, you think we've seen the top of SSD performance already?-)
<flux>
(while disk IO doesn't keep getting dramatically better)
<flux>
(mm, rotating media disk that is)
<Camarade_Tux>
flux, nah, I don't think so, but I've used non-intel SSDs and they really freeze the whole system from time to time ><
ulfdoz has quit [Read error: 110 (Connection timed out)]
ulfdoz_ is now known as ulfdoz
rjack has quit [Read error: 110 (Connection timed out)]
<mrvn>
Camarade_Tux: there suposedly is a huge difference between SSDs and intel being the good end with truely 170MB/s random access.
ergodick has joined #ocaml
ergodick has left #ocaml []
Spiwack has quit ["Leaving"]
komar_ has joined #ocaml
Snark has quit ["Ex-Chat"]
jamii has quit [Read error: 60 (Operation timed out)]
Amorphous has quit [Read error: 110 (Connection timed out)]
Amorphous has joined #ocaml
itewsh has quit [Read error: 60 (Operation timed out)]
itewsh has joined #ocaml
jeremiah has quit [Read error: 104 (Connection reset by peer)]
Yoric[DT] has joined #ocaml
travisbrady has quit [Read error: 104 (Connection reset by peer)]
<mrvn>
hmm, performance truely sucks. 8MB/s write, 14MB/s rewrite and 14MB/s read on a 16MB file.
travisbrady has joined #ocaml
<Camarade_Tux>
but right now you can get a raid for less than an SSD :)
<Camarade_Tux>
(for ssd that is)
<mrvn>
For a laptop resistance to acceleration and for a desktop noise is a factor.
<Camarade_Tux>
hard drives are mostly silent as long as the case doesn't vibrates
jeremiah has joined #ocaml
<mrvn>
Camarade_Tux: they are getting better and better but I can still hear them
<mrvn>
SSD still need to become a factor 5-10 cheaper though.
<Camarade_Tux>
I find the noise more annoying on my laptop, it's distinct and quite high-pitched (not so high but higher than the other parts)
<mrvn>
The cpu fan makes noise too on my laptop. More than the disk
<mrvn>
I don't get where all my performance goes to.
<Camarade_Tux>
the fan also makes noise here but it I think the graphic card heats more than anything else (geforce 8600M GS), I tried underclocking it a *lot* (75MHz for gpu and mem) but it doesn't change anything, probably because I can't change the voltage
<mrvn>
I want a mips based laptop with a plain 2D card.
<Camarade_Tux>
if you find one, don't forget to tell me ;)
<mrvn>
hmm, Unix.read and Unix.lseek seem to be realy slow.
<mrvn>
Does Unix.read read into a C buffer and then copy the data into the ocaml string?