suhaza_ has quit [Read error: 104 (Connection reset by peer)]
TychoBrahe has joined #ocaml
Snark has joined #ocaml
<flx>
is there a way to tell that a Bigarray object can no longer be accessed?
<flx>
I'm thinking of converting a pointer to a library data block into a Bigarray, but if the data later goes away, I would like the ocaml Bigarray object stop messing around with it..
<flx>
the other option would be to copy the data twice
<flx>
and the third one wold be to have linear types in ocaml :-)
asmanur has quit [Read error: 110 (Connection timed out)]
alexyk has quit [Read error: 110 (Connection timed out)]
alexyk has joined #ocaml
alexyk_ has joined #ocaml
alexyk__ has joined #ocaml
Yoric[DT] has joined #ocaml
<Yoric[DT]>
hi
alexyk___ has joined #ocaml
alexyk has quit [Read error: 110 (Connection timed out)]
alexyk_ has quit [Read error: 110 (Connection timed out)]
Linktim_ has joined #ocaml
bluestorm has joined #ocaml
alexyk__ has quit [Read error: 110 (Connection timed out)]
Linktim has quit [Read error: 110 (Connection timed out)]
alexyk has joined #ocaml
Yoric[DT] has quit ["Ex-Chat"]
alexyk_ has joined #ocaml
alexyk__ has joined #ocaml
alexyk___ has quit [Read error: 110 (Connection timed out)]
Linktim_ is now known as Linktimaw
jlouis has joined #ocaml
asmanur has joined #ocaml
alexyk_ has quit [Read error: 110 (Connection timed out)]
alexyk has quit [Read error: 110 (Connection timed out)]
naufraghi_ has joined #ocaml
naufraghi has quit [Read error: 113 (No route to host)]
naufraghi has joined #ocaml
naufraghi_ has quit [Read error: 104 (Connection reset by peer)]
Linktimaw is now known as Linktim_
naufraghi_ has joined #ocaml
naufraghi has quit [Read error: 113 (No route to host)]
comglz_ has joined #ocaml
<tsuyoshi>
flx: there is, kinda..
<flx>
tsuyoshi, with monads? but if I wanted to use Bigarray.set etc directly with it, I would need to write quite a lot..
<tsuyoshi>
there's a flag you can set so it doesn't free the memory on collection iirc
<flx>
oh, that's not the problem actually: it is _me_ who is releasing the memory
naufraghi has joined #ocaml
<flx>
infact at the moment I'm just giving a pointer to stack back to ocaml :)
<tsuyoshi>
exactly.. you don't want the bigarray code to release it
guyzmo_ has joined #ocaml
<flx>
it doesn't. but I have a need to release it. because the third party library (sdl in this case) will do it at some undetermined point anyway.
ulfdoz has quit [leguin.freenode.net irc.freenode.net]
comglz has quit [leguin.freenode.net irc.freenode.net]
guyzmo has quit [leguin.freenode.net irc.freenode.net]
palomer has quit [leguin.freenode.net irc.freenode.net]
orbitz has quit [leguin.freenode.net irc.freenode.net]
acatout has quit [leguin.freenode.net irc.freenode.net]
unfo- has quit [leguin.freenode.net irc.freenode.net]
<flx>
but yes, now I can generate audio with SDL's Mixer interface in ocaml \o/
<flx>
I wonder the OCamlSDL guys (after finishing the patch..) are interesting in updates. the last release was from year 2005..
acatout has joined #ocaml
<flx>
not like ocamlsdl had broken down or anything, but it doesn't support for example that effect mixer interface, not does it support panning
comglz has joined #ocaml
palomer has joined #ocaml
ulfdoz has joined #ocaml
orbitz has joined #ocaml
unfo- has joined #ocaml
<tsuyoshi>
what do you mean by linear types?
<flx>
instances of that type cannot be copied
<tsuyoshi>
huh? why would you want that?
<flx>
let's say I have a callback: val callback : value -> unit
<flx>
I want to make sure it doesn't make a copy of that value
<tsuyoshi>
why?
<flx>
because it might be a pointer to stack or something, and will cause unimaginable horrors if it is accessed afterwards
<tsuyoshi>
oh.. then you should copy it off the stack
<flx>
also resources can make use of it
<flx>
it can statically guarantee you will not write to a closed file
<flx>
with_output_file doesn't do that, because you can copy the file descriptor from the function
<tsuyoshi>
oh, I guess that would be useful
<flx>
I could copy the stuff, yes, but there can be cases where copying can become slow, due to large amounts of data
<tsuyoshi>
large amounts of data on the stack is usually a bad idea to begin with
<flx>
well, it might not be in stack
<flx>
let's say you have a pointer to network card buffer, which is being fed at one gigabyte/s ;)
<tsuyoshi>
hmm.. uncopyable.. I am thinking of how to implement that
<flx>
it would need to be an extension to the type system
<tsuyoshi>
yeah
<flx>
I think another thing with linear types is that they cannot go out of scope
<flx>
unless the return type is the linear type, naturally
<flx>
so if you have a function (linear -> unit), it must call some function that accepts linear in, but returns unit
comglz has quit [Connection timed out]
<flx>
so it may even be able to guarantee the file is closed
<tsuyoshi>
hrm.. so I guess you have 2 operations that you have to check
ikaros has joined #ocaml
<tsuyoshi>
there's assignment (arrays, structures, objects) and then returns
<tsuyoshi>
and the returns can't contain anything uncopyable
yminsky_ has joined #ocaml
<flx>
perhaps it will be helpful to read a paper on linear types first
<flx>
it would be helpful to me :)
<tsuyoshi>
doesn't seem that complicated really
<tsuyoshi>
why do they call it "linear"?
<bluestorm>
i think they come from "linear logic"
naufraghi_ has quit [Read error: 113 (No route to host)]
<tsuyoshi>
maybe I better implement it myself before someone decides to use the confusing "linear" keyword
<flx>
unique typing is related, but they say there's a difference :)
comglz has joined #ocaml
<flx>
ok, what am I doing wrong when my program stalls at caml_leave_blocking_section?
<flx>
the whole fragment would be caml_enter_blocking_section(); SDL_SemWait(mixer_callback_init); write(1, "!", 1); caml_leave_blocking_section(); write(1, "c", 1);, so I know I can see '!' but not 'c'
comglz_ has quit [Read error: 110 (Connection timed out)]
m3ga has joined #ocaml
<flx>
hm, sdl's mutex/semaphore system seems weird: they have SDL_SemPost and SDL_SemWait, but SDL_mutexP and SDL_mutexV
<flx>
I've always associated P and V being operations on semaphores
yminsky_ has quit []
middayc has joined #ocaml
middayc_ has quit [Read error: 110 (Connection timed out)]
yminsky_ has joined #ocaml
yziquel has joined #ocaml
structured has quit ["This computer has gone to sleep"]
Linktim_ has quit [Read error: 110 (Connection timed out)]
nuncanada has quit ["Leaving"]
naufraghi has quit []
naufraghi has joined #ocaml
Mr_Awesome has quit ["aunt jemima is the devil!"]
mattam has quit [Read error: 113 (No route to host)]
Optikal_ has joined #ocaml
mattam has joined #ocaml
<flux>
tsuyoshi, there's some discussion mentioning linear typing in a passing on comp.lang.functional, subject "Re: Combining mutable objects with const references"
<flux>
(I'm at <5272f6cd-47c8-47b1-a467-bb36c281654e@i76g2000hsf.googlegroups.com>)
<flux>
(reading, that is)
naufraghi has quit []
jdroid- has joined #ocaml
<orbitz>
hai
Optikal_ has quit ["Leaving."]
<jdroid->
hai, i can haz programmar fwens!?
<orbitz>
noes
<palomer>
it works!
<orbitz>
finally!
<orbitz>
your polymorphic variance nonsense?
<orbitz>
variants*
<orbitz>
the toilets here are too high, my feet pracicly dangle which makes relaxing difficult
asmanur has quit [Remote closed the connection]
Linktim_ has joined #ocaml
structured has quit [Read error: 110 (Connection timed out)]
* palomer
high fives orbitz
* orbitz
does a jumping chestbmp with palomer
Linktim has quit [Read error: 110 (Connection timed out)]
<jdroid->
i have a friend who's feet do dangle. i noticed when he used a stall next to me once. i check shoes to see if i have poopy friends around.
<jdroid->
on this wonderful topic, i like talking about perl with friends at work in the bathroom. conversations about perl belong there, you know?
<bluestorm_>
quite theoretical-minded and quick to the subject
<mgsloan>
oh, cool. that does look good, thanks
<orbitz>
jdroid-: amy smart movies is on
<jdroid->
boners
* palomer
also came from a haskell background, about 4 months ago
<mgsloan>
ah cool. I don't think I'm really going to move from haskell, in truth, but it'd be cool to know ocaml. I'm also interviewing at MS in a few days, and I figured it'd be cool to have some F# exp, :P
<jdroid->
MS?
<orbitz>
does Jon Harrop work for MS?
<orbitz>
or is he just in lov with F#
<orbitz>
jdroid-: Microsoft, you might ahve heard of them
<jdroid->
orbitz: you haven't been out of finance that long. MS = Morgan Stanley too, foo.
<mgsloan>
yeah, not exactly my company of choice, but it's just a summer internship
<orbitz>
jdroid-: but MS made F# :)
<bluestorm_>
orbitz: Jon Harrop seels F# material
<jdroid->
guess i was just too optimistic of firms adopting neat languages.
<orbitz>
bluestorm_: he prevents people from seeign F# material?
<bluestorm_>
he has sold OCaml before, and still do, but F# has a much wider audience (ugly C# users wanting to taste the functionnal goodness) so promoting F# was clearly a good commercial choice
<bluestorm_>
hmm
<bluestorm_>
orbitz: sells :]
<orbitz>
that makes more sense
<orbitz>
well let's hope MS doenst turn F# into a pile of junk
<orbitz>
i've heard anumber of peopel comment htat their plans already seem to be too ambitious
hehe has joined #ocaml
<orbitz>
the GC on .net is supposed to be superior to INRIA's ocaml inter though right?
<bluestorm_>
hm
<orbitz>
(that's why jane st is financing the concurrent gc project?)
<jdroid->
i thoguht jane st. was sponsoring the creation of a new gc for ocaml
<jdroid->
oh.. haha
<bluestorm_>
hm
<bluestorm_>
you shouldn't think so imho
<orbitz>
the mailing list seems dividing on teh subject
<bluestorm_>
Jane St. is sponsoring a pair of students interested in getting their hands dirty with the GC mechanism, with a long-term project to allow the use of a new (parallel ?) GC
<orbitz>
concurren tand parrallel GC teh same?
<bluestorm_>
i don't know this topic enough
<bluestorm_>
i think it isn't
Optikal_ has joined #ocaml
<bluestorm_>
orbitz: actually
<bluestorm_>
John Harrop (the main proponent for a parallel/concurrent GC now) himself said that forking was a quite good strategy in some (quite common) situations
<orbitz>
strategy for what?
<bluestorm_>
to have good performances with multicores computer
<orbitz>
well single cores probably won't exist much longer
<mbishop_>
Why does the OCaml Forge's snippet section not include "OCaml" as an option for the language? :/
<jdroid->
orbitz: what about portable devices?
<orbitz>
that would be a new ocaml impl
RobertFischer has joined #ocaml
RobertFischer has left #ocaml []
<jdroid->
ok
<orbitz>
like you don't run your concurrent gc hotspot jvm on yoru cellphoen
<bluestorm_>
hm
<bluestorm_>
most cellphones are quite capable these days (in terms of CPU/memory)
<orbitz>
i mean, i don't know if a concurrent gc is good and why. but if is good because it work sbetter in multicore i don't think an impl that does not take advantage of multicore cpu's has much life left in it
<bluestorm_>
i don't see why you couldn't use the main ocaml impl. on them
<Optikal_>
There might a shift from multi-core into having separate processors, like NVidia Tesla
<jdroid->
bluestorm_: an iphone is running os x after all. people crack it and run terminals with ssh and everything
<bluestorm_>
orbitz: if you use fork(), you can have numerous processes at the OS level, and let the OS run them on every core/processor you've got
<jdroid->
an iphone ocaml implementation would be pretty neat.
<bluestorm_>
jdroid-: iirc there is work ongoing in that direction
<bluestorm_>
(i've heard of an iphone port some months ago)
<orbitz>
bluestorm_: if that is the best solution then that is fine, i'm simply saying if people think a concurrent gc has a lo of advantages that it is wroth making perhaps it is better to make it the main branch, then you can use processe if yous o desire and hav ea concurrent gc
<orbitz>
jdroid-: sweet
<jdroid->
i wonder if the jail breaks are still needed now that the dev kit is released
<Optikal_>
OCaml for scientists is $165 yikes
<jdroid->
huh?
<bluestorm_>
orbitz: wich ones ?
<orbitz>
which ones what?
<bluestorm_>
with Unix.fork (), each process use it's own GC
<bluestorm_>
wich advantages
mattam has joined #ocaml
<orbitz>
bluestorm_: i don't know. i'm not saying there are any, but that peopel in the mailing list seem to think there are, and if they are right perhaps a branch is no the best startegy
<bluestorm_>
and actually, having one GC per process is quite good because the GC is simpler that a parallel/concurrent GC, thus simpler, less overhead, and the performances scale very well
<orbitz>
bluestorm_: i don't know enough to comment much mor ethan i halready have
<mbishop_>
doesn't coThreads also avoid the problem?
<orbitz>
is th eunderlying jocaml impl threads or doing some multiplexing trick?
<flux>
bluestorm_, but you can't really use fork a lot
Optikal_ has quit ["Leaving."]
<flux>
most system administrators wouldn't be happy with 1000 processes
<flux>
and it takes waay more time than approaches that don't need to deal with the OS
<bluestorm_>
why do you need 1000 processes anyway ?
<flux>
perhaps you want to have 1000 separate flows of control.
<flux>
not that unreasonable to me.
<bluestorm_>
then you can use threads
<bluestorm_>
you could, say, use 10 processes of 100 threads each
<flux>
yes, well if it's all the same, I'd rather have it abstracted away :). but yes, ocaml too could theoretically do massive amounts of threads with its self-implemented threading (that works only with byte code, though)
<bluestorm_>
as mbishop_ said, coThreads may ease that by virtually making the difference between threads and processes transparent to the programmer
<flux>
how does cothreads work anyway?
<flux>
isn't it essentially a fork with message passing anyway?-o
<jdroid->
i need hot fries
<orbitz>
andy's?
<jdroid->
yup
<jdroid->
bbiab :) o_O HAPPY
<mbishop_>
cothreads uses the regular Threads module, but you can change it's "engine"
<orbitz>
doe sit use OS threads?
<bluestorm_>
and use processes under the hood
<bluestorm_>
orbitz: you can
<bluestorm_>
i'm not sure however that you can use a mix of threads and processes right now
<flux>
in theory one program would only need n threads from the os, where n would be the number of hardware threads
<bluestorm_>
but that should be doable
<flux>
is cothreads still being developed?
<bluestorm_>
ask Zheng Li
<orbitz>
coming from erlang, i like a lot of 'threads' that do very little, is that possible currently in ocaml?
<orbitz>
by a lot i mean thousands
<flux>
orbitz, you could have cps based platform, so it would use no "real threads" at all
<flux>
(I am actually writing something like that at work)
<orbitz>
cool
<flux>
it appears to handle atleast four thousand "threads"; most of the time everything is blocking, of course
<bluestorm_>
i think Lwt can do that too
<flux>
yes, I think it's a similar approach
<orbitz>
perhaps the mdoel isn't needed in ocaml
<flux>
using such an approach means that if you hog the cpu, nothing else can have it
* orbitz
simply finds a lot of threads of execution easier to mentally manage
<bluestorm_>
orbitz: depends on the problem you're trying to solve, probably
<flux>
but there's a flip side to the matter: everything is atomic