Amorphous has quit [Read error: 104 (Connection reset by peer)]
willb has joined #ocaml
jamii has quit [Read error: 104 (Connection reset by peer)]
jamii has joined #ocaml
Amorphous has joined #ocaml
det has quit [Remote closed the connection]
s4tan has quit []
det has joined #ocaml
dira has joined #ocaml
<dira>
I`m new to functional programming , I wonder why there is object oriented style in functional programming since there is no state in functional programing , what do classes encapsulate ?
<totom>
object oriented is not functional
<mattam>
Object-oriented is not necessarily imperative.
<totom>
well, not necessarily, but most of the time it is
<mattam>
Yes.
<totom>
ocaml provides object-oriented constructs as a convenience, but I think it is considered part of the imperative kernel
<totom>
the functional way is to use modules and functors, dira
<totom>
that's what's nice about ocaml, you can use it as a functional language most of the time but fall back to imperative when you need it
<dira>
so we don`t have something like class in OCAML ?
<dira>
just modules and functors ( function with state ) ?
<totom>
you have classes
<Alpounet>
we have classes, objects in OCaml
<totom>
but they are not part of the "functional" kernel stricto sensu
<Alpounet>
but the usual way and the most "fonctional oriented" way is using modules and functors
<totom>
yes
<dira>
so there is two kernels in OC , one for tracking pureness and functional features and another for imperative constructs?
<totom>
pureness ?
<dira>
without side effect
<totom>
you might say so
<totom>
for example ocaml has references (updatable variables)
<totom>
and mutable variables in records
<dira>
is there something like Haskell monoids in OC ?
jober has joined #ocaml
jeanbon has joined #ocaml
<thelema>
dira: not built in, but you can build them.
<dira>
thanks
<Alpounet>
you can do it very easily
<Alpounet>
you just have to declare a datatype and define an operation on it
<Alpounet>
a stable binary operation
thelema_ has quit [Read error: 104 (Connection reset by peer)]
<Alpounet>
dira, Haskell hasn't invented everything.
<Alpounet>
Monoids are a very basical part of the set theory
<Alpounet>
Monads are (much less basical :-p) part of category theory
<Alpounet>
both theories are mathematical... but they have many applications in computer science
brendan has quit [calvino.freenode.net irc.freenode.net]
brendan has joined #ocaml
barismetin has quit [Remote closed the connection]
filp has quit ["Bye"]
slash_ has joined #ocaml
<mrvn>
Damn. my code segfaults and I don't see why.
<mrvn>
It segfaults when I create a second buffer and Unix.read into it.
<Alpounet>
shouldn't you allocate sizeof(value)*len*PAGESIZE ?
<mrvn>
No. a value for the tag, len for the buffer itself and PAGESIZE because of the alignment.
<Alpounet>
oh ok
<Alpounet>
just misunderstood the "semantic" of this allocation
<mrvn>
Only problem I can think of is that somehow the GC gets hold of my unsafe_string and keeps it past the time the first buffer is freed. Then on the Unix.read the GC runs and BOOM.
<Camarade_Tux>
tried changing the Gc verbosity or nearly disabling it ?
<mrvn>
Camarade_Tux: how do I do the first?
<mrvn>
nm
Snark has joined #ocaml
<mrvn>
let _ = Gc.major (); main Sys.argv
<mrvn>
Major GC cycle requested
<mrvn>
<>Starting new major GC cycle
<mrvn>
Marking 9223372036854775807 words
<mrvn>
That doesn't look right.
rhar has joined #ocaml
<Camarade_Tux>
he, it's bigger than a 64 bit int ;p
Narrenschiff has joined #ocaml
<mrvn>
It is -1
sporkmonger_ has joined #ocaml
Camarade_Tux has quit ["Leaving"]
sporkmonger_ has quit []
<mrvn>
String.length might be broken for my unsafe_string. Lets see if that is the problem.
<flx_>
hm, why would gc care about string length?
<mrvn>
Unix.read might.
sporkmonger has quit [Read error: 110 (Connection timed out)]
_zack has quit ["Leaving."]
<thelema>
flx: gc cares about string length because it has to know how much memory is used by that value.
<thelema>
so it doesn't scan inside that memory for more pointers.
Narrenschiff has quit []
<thelema>
and so it can generation that value properly
<mrvn>
thelema: it never scans inside a string.
<thelema>
and it knows what part of memory is string by the length.
<thelema>
the gc has to know the length (in words) of every value.
<mrvn>
thelema: For scanning the size will be irelevant. When moving the string that is another matter.
hastake_ has joined #ocaml
<mrvn>
String.length = 4096
<mrvn>
Now my length is right.
<Alpounet>
Great.
<thelema>
? how can it avoid scanning inside strings if it doesn't know how big they are?
<mrvn>
thelema: because it just plain never ever scans inside a string
hastake has quit [Read error: 104 (Connection reset by peer)]
<mrvn>
It knows there are no pointers inside the string.
<thelema>
strings are allocated in the same memory everything else is.
<thelema>
it knows something is a string by its tag
<mrvn>
The GC does not scan memory, it scans values.
<thelema>
and it has to read the length of that string so it can find where the next value is.
<mrvn>
thelema: I think me or you are confused about how the GC works.
<thelema>
entirely possibly me.
sporkmonger has joined #ocaml
<mfp>
seems to me the block length is needed in the sweep phase
<thelema>
Especially for the minor heap, there's no index.
<mfp>
not when marking
<thelema>
How do you find all the values in the mark phase?
<mfp>
(so, only in the major heap)
<mrvn>
You have a root set of active values that grows and shrinks as the code goes up and down the stack. From there it follows all pointers to marks values as alive. Alive valuesare copied when it does compaction and everything else is freed.
<mfp>
start w/ the roots
<mfp>
forward pointers & follow, etc.
* thelema
was confused.
<mfp>
it doesn't mark the values as alive AFAIK, it copies them right away to the major heap
<thelema>
for some reason I thought the GC walked memory, using lengths to find the next value
sporkmonger has quit [Client Quit]
<mrvn>
Maybe when compacting it walks the memory and moves all values that are marked.
kaustuv_ has joined #ocaml
<thelema>
but yes, of course there's roots, and it traverses pointers starting at the roots
sporkmonger has joined #ocaml
<thelema>
because there's no pointers from major heap to minor, minor collection can stop when there's no more minor pointers left to check (?)
<thelema>
what about mutable values... hmmm
<thelema>
auto-promotion?
* thelema
needs to read the code.
<mfp>
thelema: the remembered set is an array of pointers
<mfp>
caml_modify is used when you change a ref or a mutable field, and checks whether you're pointing to a value in the minor heap from a block residing in the major one
<mfp>
if so, it adds it to the remembered set (and enlarges the array first if needed before storing the pointer)
|jedai| has joined #ocaml
<mfp>
the remembered set is used along with the other roots when emptying the minor heap
AxleLonghorn has joined #ocaml
<mfp>
so foo := x is compiled to a call to caml_modify, which might add x to the remembered set
<mrvn>
% cat tmp/version
<mrvn>
MooseFS V0.0
<mrvn>
Now it works.
<mrvn>
So the problem wasn't the GC after all. Must have been String.length being called by Unix.read with a totaly bogus size on the block.
<mrvn>
String.length reads the last byte of the block and my block was 8 times too large.
thelema_ has joined #ocaml
<mrvn>
Ocaml strings are an ugly trick.
<thelema>
ocaml everything is an ugly trick. But that's what makes it fast
Yoric[DT] has joined #ocaml
<thelema>
31-bit integers!?!
<mrvn>
String.length = size of block in words * sizeof(value) - last byte of block
<mrvn>
thelema: nah, 31bit integers is normal.
<mrvn>
The GC stats still bug me:
<mrvn>
Marking 9223372036854775807 words
<mrvn>
Marking 9223372036854775807 words
<olegfink>
could you recommend some (imperative) data structure for implementing simple O(1)-indexed lists?
<mrvn>
array?
<olegfink>
I know about 2-3-trees and splay trees, anything else?
<olegfink>
array doesn't support split/append
<mrvn>
If the index is not continious then hashtbl
<mrvn>
olegfink: split/append in arrays is O(n)
<olegfink>
s/doesn't support/has slow/
<kaustuv_>
You can either have O(1) access or O(1) append. Pick your poison.
<mrvn>
you can't have it all.
<olegfink>
i can, amortized O(1)
<mrvn>
O(1) append usualy means O(n) access
<mrvn>
olegfink: amortized arrays have O(1) append.
<mrvn>
I would just use a Hashtbl.t. It does the resizing of the array for you.
<mrvn>
and you don't need an int to index.
<kaustuv_>
take a look at finger trees, but I doubt you can find anything that will beat a good balanc{ed,ing} tree
<olegfink>
kaustuv_: so I should just take something like a 2-3 tree?
<mrvn>
you can only be better when you can predict the access pattern
<olegfink>
mrvn: seems I forgot to insert an [offtopic] comment.
<mrvn>
olegfink: what is wrong with hashtbl?
<olegfink>
...that it isn't in the standard c library.
<olegfink>
(that where the offtopic goes)
<mrvn>
There is a pretty simple and pretty standard hash lib for C.
<olegfink>
i want to write a few simple functions for c for dealing with vector data in the style of j/k just to get some idea of the constraints. so for a start, i need something simple which would support both list and array operations.
<mrvn>
those are quite opposing data structures.
tarbo2_ has quit [No route to host]
<olegfink>
indeed they are, but i was wondering what are the best approximations to that.
<mrvn>
trees are in the middle
<kaustuv_>
A dynarray is trivial to implement and is O(1) amortized.
<kaustuv_>
especially as you don't care about persistence
<olegfink>
nope, this should be imperative, at least for now.
<olegfink>
kaustuv_: i don't get the difference between dynarray and a stereotypical vector.
<kaustuv_>
I bunked my stereotype theory classes. What's a st. vector?
<olegfink>
a dynamically allocated array which resizes to provide an amortized O(1) append and O(n) storage?
<kaustuv_>
Ah, then there is no difference, as that's how I understand dynamically resizing arrays
<olegfink>
but that's not amusing. i can't insert something in the middle, nor can I split a dynarray.
Camarade_Tux has joined #ocaml
<Alpounet>
has anyone played with the -dlambda option ?
AxleLonghorn has left #ocaml []
bzzbzz has quit ["leaving"]
itewsh has quit ["There are only 10 kinds of people: those who understand binary and those who don't"]
Delemas has joined #ocaml
seafood has joined #ocaml
* Delemas
beats on unison and tried to figure out how to properly implement directory mtimes preservation.
<flx_>
delroth, were you the guy who wondered about the same issue some weeks ago?
<flx_>
delemas, even
<Delemas>
flx_, yes unfortunately the patch we came up with had some undesirable side effects... It worked properly for the first sync but afterwords any updated file would also get it's parent directory's mtime changed, which isn't correct behaviour.
seafood_ has joined #ocaml
<Delemas>
So now I'm trying to figure out how to tweak it. I think either I need to figure out how to create a file without changing the parent directory's mtime or I need to figure out a way to capture and restore the mtime of a parent directory...
thelema_ has quit [Read error: 104 (Connection reset by peer)]
seafood has quit [Connection timed out]
<flx_>
while you're at it, make it support hard links also.. ;)
<Delemas>
lol would be nice but my ocaml is weak...
<mrvn>
Delemas: stat, sync, touch
schmx has joined #ocaml
<flx_>
delemas, so is it indeed an ocaml library issue and posix provides something for this?
<flx_>
I mean, if posix has something to deal with this, it should not be difficult to call it from ocaml?
<Delemas>
hmm I'm still digging through the code trying to wrap my mind around it. I've got a cold so that isn't working well :P
<mrvn>
man utime
<Delemas>
In a shell if you copy a new file the parent directory mtime changes. If you touch a file the parent directory mtime does not change.
schme has quit [Read error: 110 (Connection timed out)]
<mrvn>
Delemas: file creation adds the file to the data of the directory so it changes.
<mrvn>
touch/write/... only alters the files inode itself, not the dir.
<Delemas>
I think a patch where one checks to see if -times was specified and then stores the parent dir mtime, writes a file and then restores the parent mtime should work.
<mrvn>
Delemas: only that will work
<Delemas>
mrvn, So all I have to do if figure where in the code to try to implement that and learn more ocaml :)
<flx_>
how about if there are other processes dealing with files in the same directory at the same time?
<mrvn>
yes
<mrvn>
flx_: then you have race conditions
<flx_>
some kind of check to detect that would be nice.
<flx_>
not unlike the 'file changed while syncing' logic
<mrvn>
flx_: impossible in posix
<Delemas>
well something that works on it's own would be better than nothing...
seafood_ has quit []
* Delemas
's brain is sore
<mrvn>
We can help you with that. We can remove it.
<Delemas>
oooh! Are there new models available? I always wanted more cores :P
<mrvn>
You can trade in your one core for a Model Z.
<mrvn>
Zero core.
tarbo2 has joined #ocaml
<Delemas>
boo
Snark has quit ["Ex-Chat"]
dira has quit ["ChatZilla 0.9.84 [Firefox 3.0.7/2009021910]"]
jlouis has quit ["Lost terminal"]
jober has left #ocaml []
sporkmonger has quit [Connection timed out]
smimou has quit [Remote closed the connection]
smimou has joined #ocaml
marmottine has joined #ocaml
jlouis has joined #ocaml
smimou has quit [Read error: 110 (Connection timed out)]
jlouis has quit [Remote closed the connection]
mttobks has joined #ocaml
mttobks has quit [K-lined]
Mr_Awesome has quit ["aunt jemima is the devil!"]
itewsh has joined #ocaml
jlouis has joined #ocaml
jlouis has quit ["brb, will screenify"]
jlouis has joined #ocaml
willb has quit [Connection timed out]
marmottine has quit ["mv marmotine Laurie"]
thelema_ has joined #ocaml
thelema_ has quit [Read error: 104 (Connection reset by peer)]