sponge45 changed the topic of #ocaml to: Discussions about the OCaml programming language | http://caml.inria.fr/
shawn has joined #ocaml
smimou has quit ["bli"]
tsuyoshi has quit ["Lost terminal"]
tsuyoshi has joined #ocaml
mbishop has quit [Remote closed the connection]
danly has quit [Read error: 60 (Operation timed out)]
m3ga has joined #ocaml
danly has joined #ocaml
slowriot has quit []
danly_ has joined #ocaml
danly has quit [Read error: 110 (Connection timed out)]
pango has quit [Remote closed the connection]
pango has joined #ocaml
b00t has joined #ocaml
Smerdyakov has quit ["Leaving"]
shans__ is now known as shans
bzzbzz has quit ["leaving"]
mbishop has joined #ocaml
shawn has quit [Read error: 110 (Connection timed out)]
pants1 has joined #ocaml
johnnowak has quit []
b00t has quit [Read error: 104 (Connection reset by peer)]
b00t has joined #ocaml
Skal has joined #ocaml
Skal has quit [Remote closed the connection]
Skal has joined #ocaml
Mr_Awesome has quit ["and the Awesome Level drops"]
pants1 has quit ["Leaving."]
jlouis has quit [Remote closed the connection]
shawn has joined #ocaml
_velco has joined #ocaml
m3ga has quit ["disappearing into the sunset"]
pango has quit ["Client exiting"]
delamon has joined #ocaml
love-pingoo has joined #ocaml
pango has joined #ocaml
smimou has joined #ocaml
pango has quit [Remote closed the connection]
pango has joined #ocaml
smimou has quit ["bli"]
love-pingoo has quit ["Connection reset by pear"]
gaja has quit [Remote closed the connection]
love-pingoo has joined #ocaml
pango has quit [Remote closed the connection]
pango has joined #ocaml
<dark_light> if I use mutex for protecting shared data structures, I should lock at every access at the structure or only when modifying the structure? I am unsure
<ulfdoz> Depends on needs. Often it is enough to lock on modification, sometimes, constraints are harder to prevent errornous reads.
<dark_light> i am not sure what is my needs
<ulfdoz> I can't tell you. When in doubt, use the stricter requirement.
<ulfdoz> essentially, this means to lock on every access and possibly to define a strict order of accesses.
<ulfdoz> The advantage of this approach is, that it is easy to implement, because you need not to distinguish between read and write.
<dark_light> i was using events to handle this, but the approach was very confuse to me, i think i am using it wrong
<dark_light> ulfdoz, actually i do not really know why mutexes are needed for me. ocaml can't really execute two things at once and i am using only atomic operations (like sharedstructure.field <- newvalue)
<dark_light> ... i am quite confused :D
<ulfdoz> dark_light: The problems arise, when one thread is interrupted between a read and write and another thread modifies the shared structure.
<dark_light> i gave a vacation to this code (because it's becoming very annoying) but when i returned to it, i am unsure what i should do
<dark_light> ulfdoz, in that case, i should lock before the read and unlock after the write, right?
<ulfdoz> dark_light: Yes.
<ulfdoz> and the lock-operation must be atomic.
<dark_light> i am unsure if i will ever have a situation like that
<dark_light> i am working in a thing like this: http://nopaste.llamah.org/140 , i think these locks are really unecessary for the operations i defined in let change_player ..
<ulfdoz> I'd keep it, for correctness, at least it is not much overhead.
<dark_light> hmmmm...
<dark_light> but if i need to do this for reading too, there is no point in mantaining a record (i am using a shared record just to easly do player.name ..)
<ulfdoz> Im currently thinking about, whether the locking is done in the right place. Assume you have a player value and two threads concurrently changing the player-structure. Are you sure the values are consistent afterwards?
love-pingoo has quit ["Leaving"]
<ulfdoz> i.e. I think, it is typical, that several fields of the player structure are changed at once, which would be several operations, which can interleave, when having different threads.
<dark_light> ulfdoz, i created a example where i have a shared record with x and y values and thread A were changing only the x field, and thread Y changing only y, it seemed that i need no lock in that case
<dark_light> ah
<dark_light> hmmm
<dark_light> several fields changed at once?
<dark_light> Hmmmmmmmmm maybe i need something like a.. "nonatomic_change" that locks the entire player and executes a list of changes
<ulfdoz> For example: If you change the field player.name, than the field player.title is likely to be changed in near future, too.
<dark_light> hmm i understand your point
<dark_light> but, i need to lock while reading too? :( eg: if i am changing name and title, i need to lock while reading the name? or: i need to lock while reading the access?
<dark_light> i am thinking i will never need to lock while reading (that is what i want to believe, for my own sanity:)
<ulfdoz> I'd lock the whole structure to prohibit modification until the read is finished.
<ulfdoz> Imho, most often it is not necessary, to limit the number of concurrent reads, but as long as any read is in progress, no modification should be done.
<dark_light> it's like.. i will read A and B, and i want a consistent value of A and B, but if someone change B and then A, i can read the old A and the new B, and i am with inconsistent data?
<ulfdoz> yes.
<dark_light> i give up of shared structures.
<dark_light> :(
<dark_light> maybe with events i will be happy.. then :(
<dark_light> my current code has a channel that hears for things like Db_list_players of player list Event.channel
<dark_light> and the db thread read the event, and reply with a list of players
<dark_light> that isn't very intersting because the players has mutable fields
<dark_light> ulfdoz, you think it's ok to have a database thread that blocks while doing every operation?
<dark_light> i wanted to make the calling threads do the operations to ensure that the db will be free, but it's beginning to become impossible
<ulfdoz> dark_light: For best performance I'd do non-blocking reads and blocking writes. The most complicated thing left to implement is the scheduling of the reads/writes. ;)
<dark_light> it's too stupid creating a new thread every read?
b00t has quit [Remote closed the connection]
<dark_light> well, for the time i will make blocking reads
Submarine has joined #ocaml
<delamon> ulfdoz: and how do you managed shedule them?
<ulfdoz> delamon: Usually, I allow reading, until a write-request is triggered, then I wait until all reads are finished. After this, I do the actual write lock, the write and finally unlock the structure.
Skal has quit [Remote closed the connection]
Submarine has quit [Remote closed the connection]
ikaros has quit [Read error: 110 (Connection timed out)]
ikaros has joined #ocaml
klapmuet1 has joined #ocaml
klapmuetz has quit [Read error: 60 (Operation timed out)]
Smerdyakov has joined #ocaml
metaperl has joined #ocaml
<metaperl> does Ocaml's oo mesh well with its functional core?
<Smerdyakov> Yes. The OO system has some fundamentally imperative features, but it's easy to avoid them systematically.
<dark_light> methods can be treated as functions, if it's what you asked metaperl
<metaperl> i see - there was a huge war (and still is) in #haskell - the author of Factor is there because someone started railing on it
<dark_light> factor?
velco has joined #ocaml
batdog|gone has joined #ocaml
Aradorn has joined #ocaml
Golden_boy_06 has joined #ocaml
<Golden_boy_06> hi everyone
<Golden_boy_06> i'm a beginner and i've a few questions to ask about some programs
<Golden_boy_06> if someone could help me
<Golden_boy_06> i've tried to simulate map function on caml but this one ain't run
<trurl__> how does it look like?
velco has quit ["Ex-Chat"]
shawn has quit ["This computer has gone to sleep"]
_JusSx_ has joined #ocaml
Aradorn has quit ["Leaving"]
<Golden_boy_06> well multiply a b time
<Golden_boy_06> a exposant b
<Golden_boy_06> bu with a dichotomique methiood
_velco is now known as velco
Aradorn has joined #ocaml
<Golden_boy_06> someone can help me with my cps function plz ?
e_e_coli has joined #ocaml
pango has quit [Remote closed the connection]
pango has joined #ocaml
<delamon> Golden_boy_06: can you show it?
<Golden_boy_06> well i've jut solve it
<Golden_boy_06> lol
<Golden_boy_06> # let rec k_puis a b f =
<Golden_boy_06> if b=0 then (f 1.0)
<Golden_boy_06> else k_puis a (b - 1) (fun x -> f a*.x);;
<Golden_boy_06> val k_puis : float -> int -> (float -> float) -> float = <fun>
<Golden_boy_06> # k_puis 2.0 4 (fun x -> x);;
<Golden_boy_06> - : float = 16.
<Golden_boy_06> #
<delamon> Golden_boy_06: you are creating closure in each recurison loop, do you know it?
<Golden_boy_06> i don't get what you say
<Golden_boy_06> i've just tryed to apply cps on caml
<delamon> yes. that is cps
<delamon> but branch "else k_puis a (b - 1) (fun x -> f a*.x)" creates closure every time it's executed.
<delamon> this can be memory and cpu consuming.
<Golden_boy_06> so what's the good way to write it ?
<delamon> well, you can't avoid it, doing cps, AFAIK
velco has quit ["I'm outta here ..."]
Aradorn has left #ocaml []
love-pingoo has joined #ocaml
descender has joined #ocaml
_JusSx__ has joined #ocaml
_JusSx_ has quit [Read error: 110 (Connection timed out)]
_JusSx__ has quit [Client Quit]
love-pingoo has quit ["Connection reset by pear"]
e_e_coli has left #ocaml []
m3ga has joined #ocaml
shawn has joined #ocaml
Golden_boy_06 has quit [Read error: 131 (Connection reset by peer)]
smimou has joined #ocaml
<mattam> let rec kpuis' a b acc f = if b = 0 then f acc else kpuis' a (pred b) (a * acc) f is still in cps isn't it ?
Mr_Awesome has joined #ocaml
<pango> mattam: tail recursive, not cps
<mattam> it's the cps transform of the tail rec version, how is that a problem ?
delamon has quit ["WeeChat 0.2.1"]
metaperl has quit [Connection timed out]