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>
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>
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.
<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?