flux changed the topic of #ocaml to: Discussions about the OCaml programming language | http://caml.inria.fr/ | Grab OCaml 3.10.2 from http://caml.inria.fr/ocaml/release.html (featuring new camlp4 and more!)
tomh has quit ["http://www.mibbit.com ajax IRC Client"]
hkBst has quit ["Konversation terminated!"]
seafood has joined #ocaml
patrick2 has quit ["Leaving."]
zarvok has joined #ocaml
Morphous_ has joined #ocaml
Associat0r has quit []
Morphous has quit [Read error: 110 (Connection timed out)]
Ched- has quit [Read error: 110 (Connection timed out)]
Ched- has joined #ocaml
zarvok has quit ["Leaving"]
kotarak has quit []
jeffno has joined #ocaml
seafood has quit []
marmotine has quit ["Quitte"]
seafood has joined #ocaml
seafood has quit []
jeffno has left #ocaml []
seafood has joined #ocaml
johnnowak has joined #ocaml
johnnowak has quit [Client Quit]
johnnowak has joined #ocaml
seafood has quit []
seafood has joined #ocaml
seafood has quit [Client Quit]
Tetsuo has joined #ocaml
seafood has joined #ocaml
bluestorm has joined #ocaml
Snark has joined #ocaml
kotarak has joined #ocaml
Mr_Awesome has quit ["aunt jemima is the devil!"]
netx has joined #ocaml
Mr_Awesome has joined #ocaml
<flux> I wonder if people used monads in OCaml if it weren't for Haskell..
<tsuyoshi> I dunno.. what good are monads in ocaml?
<bluestorm> monads have numerous usage, simulating side-effects being only one of them
<tsuyoshi> why do you want to simulate side-effects?
<bluestorm> they're used for paralellism and concurrency in Lwt and STM
<tsuyoshi> I see
<bluestorm> yoric use them for exception management
<bluestorm> and i think i've seen some ocaml monadic parser project
<tsuyoshi> gah, ocsigen.org is down
johnnowak has quit []
netx has quit ["Leaving"]
<bluestorm> tsuyoshi: STM is at http://cothreads.sourceforge.net/doc/stm , but the documentation is down too
LordMetroid has joined #ocaml
hkBst has joined #ocaml
seafood has quit [Read error: 104 (Connection reset by peer)]
seafood has joined #ocaml
<flux> I've used monads for lwt-like concurrency and handling database transactions
<flux> (no need to pass explicit database connection or database connection state around)
coucou747 has joined #ocaml
kotarak has quit []
filp has joined #ocaml
filp has quit ["Bye"]
kotarak has joined #ocaml
Kopophex has quit ["Leaving"]
<cpfr> hey is there anyway to type something with multiple variables
<bluestorm> what do you mean "multiple variable" ?
LordMetroid has quit ["Leaving"]
<cpfr> like say type 'a 'b foo = Foo of 'a , 'b
<bluestorm> type ('a, 'b) foo = Foo of 'a * 'b
<bluestorm> or, revised syntax : type foo 'a 'b = [ Foo of 'a and 'b ]
<cpfr> how do i specify the revised syntax to the compiler
<bluestorm> you have to use camlp4, and hm.
<bluestorm> if you're not familiar with it (there are other changes as well that may be surprising at first) you should document yourself before considering using it
<bluestorm> (but it's about an earlier version of camlp4, the syntax was slightly modified since that tutorial)
<cpfr> is it worth checking out camlp5
<bluestorm> depends
<bluestorm> as it is not included in the standard distribution, i assume it is less likely to be used by future extension writers
<bluestorm> on the other hand, it may have its own qualities (i've never used pre-3.10 camlp4 or camlp5 so i couldn't say), and certainly has a value for pre-3.10 camlp4 compatibility (interesting for projects like Coq maybe)
bluestorm has quit ["Konversation terminated!"]
kotarak has quit []
Associat0r has joined #ocaml
seafood has quit []
seafood has joined #ocaml
Linktim has joined #ocaml
ofaurax has joined #ocaml
kotarak has joined #ocaml
Linktim has quit [Read error: 104 (Connection reset by peer)]
RobertFischer has joined #ocaml
<RobertFischer> Anyone here good with Unix sockets? I'm having an issue and wondering what it is.
kotarak has left #ocaml []
<flux> robertfischer, what kind of problem?
<RobertFischer> flux: Getting a Unix error 12 on accept.
<flux> robertfischer, maybe the socket you're accepting is closed
<flux> or not listening
<flux> or (I'm not sure if this can lead to it..) not bind to and address
<flux> oh right, and the obviousone: perhaps the file descriptor doesn't belong to a socket :)
<RobertFischer> flux: It's definitely a socket (I open it the line above). And if the socket I'm trying to talk to is closed, I get a different error (had that one before).
<xevz> Error number 12 = ENOMEM.
<RobertFischer> xevz: Yeah, so I'm out of memory? My RAM monitor disagrees.
<xevz> Should be triggered when there aren't enough resources to create the socket.
<xevz> Mm, thought so.
<RobertFischer> That's the part that's confusing me.
<flux> xevz, how did you end into that result?
<xevz> flux: Reading asm-generic/errno-base.h
<RobertFischer> function errcodes {
<RobertFischer> perl -MErrno -e 'my %e= map { Errno->$_()=>$_ } keys(%!); print grep !
<RobertFischer> +/unknown error/i, map sprintf("%4d %-12s %s".$/,$_,$e{$_},$!=$_), 0..
<RobertFischer> +127'
<RobertFischer> }
<flux> ok, but ocaml and unix error numbers are different
<flux> because they are just exception tag numbers
<RobertFischer> The Unix error number isn't the number of the Unix error?
<flux> I'm thinking robertfischer got an exception with that number, right?
<flux> instead to seeing it through strace or some other system-level tool
<flux> (Obj.magic 12 : Unix.error) works
<pango> # ((Obj.magic 12) : Unix.error) ;;
<pango> - : Unix.error = Unix.EINVAL
<pango> (but could be different on another platform, you have to check)
<RobertFischer> This is the error that's dropping onto my screen: "Thread 1 killed on uncaught exception Unix.Unix_error(12, "accept", "")"
<flux> (or you could just look the documentation and count till you reach from 0 to 12 in the sum type's values)
<flux> so it's EINVAL
<RobertFischer> It's being run on JoCaml.
<flux> probably ;)
<xevz> Ah, EINVAL then. :)
<RobertFischer> Which means what?
<xevz> Invalid argument.
<RobertFischer> xevz: Granted. What's that mean?
<flux> pango, does that really differ from installation to installation? does the list of errors change?
<xevz> The file descriptor opened with socket might be invalid?
<flux> I think I enumerated all the possibilities: not a socket, closed socket, socket not in proper state (listening)?
<pango> flux: I remember people getting different errors for the same number, but I don't remember the details
<pango> flux: could have been different ocaml versions, or Win32, I'm not sure
<RobertFischer> Definitely a socket, and I have no idea how it would be getting closed (there's no "close" in the whole program). Now, the not listening thing is interesting.
<xevz> At least for sockets in C:
<xevz> EINVAL Unknown protocol, or protocol family not available.
<RobertFischer> I just added "Unix.listen s 10;", but that just delayed the explosion until a client attempts to connect.
<flux> robertfischer, maybe you could put some code on the web
<RobertFischer> flux: Sure.
bluestorm has joined #ocaml
<RobertFischer> Here's the server: http://robertfischer.pastebin.com/d36afdab2
<RobertFischer> Here's the client (Perl): http://robertfischer.pastebin.com/d509ce2af
<flux> robertfischer, you're reusing s in the second line of accept
<flux> hm, no, wait
<flux> what is accept?
<flux> right, itself
ofaurax has quit ["Leaving"]
<flux> so yes, that's the issue?
<RobertFischer> flux: Sure. Once I accept a connection, I kick off a new thread which calls Unix.accept.
<flux> at that point you'll end up calling accept on a socket you've received from the previous call to accept?
<RobertFischer> No.
<flux> no?
<RobertFischer> I should be calling accept on the same socket which I just accepted.
<RobertFischer> Is that not what's going on?
<RobertFischer> Oh, damn it.
* RobertFischer headdesk.
<RobertFischer> I override the definition of "s".
<RobertFischer> Stupid being clever.
<xevz> :P
<flux> yeah, it's almost as good as imperative programming bugs ;)
<RobertFischer> flux: Tell me about it. The more I program in OCaml, the more strict I wish it was.
<xevz> Hm, where do the 'def' come from? Never seen that before. :P
<flux> it comes from jocaml
<bluestorm> RobertFischer: sometimes i'm dreaming of a purity analysis stage that would enable godlike optimizations of ocaml programs
Yoric[DT] has joined #ocaml
<xevz> flux: Ah. :)
<flux> jocaml is a joint-calculus based concurrency system for ocaml
<RobertFischer> xevz: Yeah, it's JoCaml. I'm playing around with building a server in it.
<RobertFischer> bluestorm: Sometimes I dream of an OCaml Purity Test. :)
<bluestorm> hm
<bluestorm> that would not be so difficult, with a combined library and syntaxic support
<Yoric[DT]> I believe that an improved OcamlExc could do the job, too.
<bluestorm> Yoric[DT]: flux and tsuyoshi were asking about monad uses in OCaml this morning
<Yoric[DT]> ok
<Yoric[DT]> Well, I'm using monads in Extrapol and the next version is bound to use the error monad, too.
marmotine has joined #ocaml
<bluestorm> RobertFischer: have you tried CoThreads too ?
<RobertFischer> bluestorm: Nope. Got cite? Does it offer intraprocess communication like JoCaml?
<bluestorm> (iirc you're the "let's test every parallelism solution out there" guy)
<RobertFischer> I'm not exactly that guy.
<bluestorm> RobertFischer: it's basically a module compatible with the Thread interface, but using processes instead
<bluestorm> with extended functions and an appealing STM module
<RobertFischer> Interesting. Available through Godi?
<bluestorm> hm
<bluestorm> seems it isn't
<RobertFischer> I've got a problem which requires concurrency (parallelism would be nice, but is not necessary) and trans-machine communication: http://forge.ocamlcore.org/projects/cloudproxy/
<RobertFischer> So I'm looking at a variety of solutions.
<RobertFischer> CoThreads seems promising, but not quite there yet.
<RobertFischer> Of course, JoCaml might not be there anymore, so that's not exactly better.
<bluestorm> STM is an interesting approach, you might want to read the canonical Haskell paper about it ("Beautiful Concurrency", iirc)
<flux> it is still under debate if stm 'works' though, in high contention situations
<flux> but I suppose in general it will lead to much fewer locking-related bugs
<mfp> RobertFischer: have you considered going event-based?
<flux> I personally believe message passing is the way to go, though ;), but then again message passing doesn't compose either, so perhaps you need something like that
* Yoric[DT] likes message-passing.
<RobertFischer> flux and bluestorm: I'm not deeply concerned about locks. I've basically just got one point of contention: a queue where slaves register themselves as "available" to the master.
<mfp> flux: hadn't you written some libev binding (ocaml-ev?)
<flux> mfp, yes, but they don't work
<RobertFischer> mfp: Please explain what you mean by "going event-based". That's a bit of an ambiguous term.
<mfp> oh heh what about ocaml-event then?
<flux> ocaml-event is written by an other guy, but they don't work either ;)
<flux> unless the situation has changed recently
<xevz> :P
<flux> don't work in both cases means they get into disagreement with the memory management of ocaml and eventually crash..
<mfp> RobertFischer: instead of multiple processes/threads, using I/O event notification facilities like epoll/kqueue etc.
<flux> for ocaml-ev I have no idea what's wrong, and believe me I've debugged it
<RobertFischer> mfp: Yeah, I've considered that, but I'd have to write a lot of infrastructure around those low-level pieces of functionality. Or use libraries that don't work.
<flux> ocaml-event should basically be possible to make workable
<flux> I suppose ocaml-ev too, but it might mean changing the approach to be less efficient
<flux> (to side-step the mm issues)
<mfp> RobertFischer: I didn't know that they don't work :)
^authentic has joined #ocaml
<RobertFischer> mfp: Got one that does? Mostly, I've heard comments like flux's.
<flux> it's a shame, because libev is quite a neat library (for a c-library ;))
<mfp> IIRC Core included some epoll stuff
<mfp> Linux-specific of course
<RobertFischer> By Linux-specific, is BSD/OS-X close enough?
<mfp> those have kqueue, I think
<RobertFischer> Where's the epoll stuff in Core? I went looking for it, but didn't find it.
<mfp> linux_ext.ml
<Associat0r> guys what is your opinion on FRP for games?
* Yoric[DT] would like to try that.
<mfp> Linux_ext is very low-level; the C part takes ~120 lines
marmotine has quit ["Quitte"]
<mfp> with another ~120 lines for kqueue, something like libev might be relatively easy to implement in OCaml
<RobertFischer> I don't have an epoll man page. That doesn't bode well for Linux_ext working my box.
<mfp> Lwt + such a libev written in OCaml would be pretty cool
<mfp> do you have man kqueue?
<RobertFischer> mfp: Yup.
<mfp> kqueue doesn't seem too different from epoll_wait:
<mfp> int kevent(int kq, int nchanges, struct kevent **changelist, int nevents, struct kevent *eventlist, struct timespec *timeout)
<RobertFischer> No, but I don't think kqueue is going to satisfy #include <sys/epoll.h>
bzzbzz has quit [Read error: 110 (Connection timed out)]
<RobertFischer> (From "linux_ext_stubs.c" in Core.)
<mfp> int epoll_pwait(int epfd, struct epoll_event *events, int maxevents, int timeout, const sigset_t *sigmask);
<mfp> surely not, I just meant that building an abstraction on top of epoll/kqueue seems quite doable
<RobertFischer> Yup. And an awful lot of work for what limited functionality I'm looking for.
<RobertFischer> There's Unix.select, too, which is probably a more direct approach.
<mfp> Lwt uses Unix.select too; might be more convenient than doing it directly
<RobertFischer> I don't suppose there's a way to get around the blocking-ness of Unix.accept, is there?
<mfp> I don't know which scales worse w/ the number of connections (e.g., streaming), Unix.select or processes/threads
authentic has quit [Connection timed out]
^authentic is now known as authentic
<bluestorm> probably processes
<mfp> Lwt has got a val accept : file_descr -> (file_descr * Unix.sockaddr) Lwt.t
<RobertFischer> mfp: I think it depends on the amount of work being done per Unix.select response. If you're single-threaded and having to compute large primes per response, that's going to just suck.
<bluestorm> mfp: see http://haproxy.1wt.eu/#desi
<mfp> thanks
<RobertFischer> It seems like the best solution would be a hybrid approach: n+1 processes/threads (where n is the number of processors) which each do a lot of work.
bzzbzz has joined #ocaml
<RobertFischer> Lwt looks promising.
<RobertFischer> Might solve my problem *and* be maintained moving into the future. Who knew?
pango has quit [Remote closed the connection]
tomh has joined #ocaml
RobertFischer has quit ["Taking off -- check out http://smokejumperit.com and http://enfranchisedmind.com/blog/"]
marmotine has joined #ocaml
pango has joined #ocaml
qwr has joined #ocaml
Jeff_123 has joined #ocaml
johnnowak has joined #ocaml
Linktim has joined #ocaml
munga has joined #ocaml
kotarak has joined #ocaml
kotarak has left #ocaml []
Mr_Awesome has quit ["aunt jemima is the devil!"]
coucou747 has quit [Read error: 60 (Operation timed out)]
coucou747 has joined #ocaml
Snark has quit ["Ex-Chat"]
munga has quit ["Ex-Chat"]
seafood has quit []
LordMetroid has joined #ocaml
pango has quit [Remote closed the connection]
pango has joined #ocaml
^authentic has joined #ocaml
Linktim_ has joined #ocaml
authentic has quit [No route to host]
^authentic is now known as authentic
Linktim has quit [Read error: 110 (Connection timed out)]
Linktim_ has quit ["Quitte"]
Linktim has joined #ocaml
Axioplase is now known as Axioplase_
qwr has left #ocaml []
coucou747 has quit [Read error: 104 (Connection reset by peer)]
coucou747 has joined #ocaml
<coucou747> strange bug
Yoric[DT] has quit ["Ex-Chat"]
<flux> hm?
kelaouchi has quit [Client Quit]
bluestorm has quit ["Konversation terminated!"]
johnnowak has quit []
Linktim has quit ["Quitte"]
johnnowak has joined #ocaml
seafood has joined #ocaml
johnnowak has quit []
coucou747 has quit ["bye ca veut dire tchao en anglais"]
Kopophex has joined #ocaml
Tetsuo has quit ["Leaving"]
tomh has quit ["http://www.mibbit.com ajax IRC Client"]
johnnowak has joined #ocaml