<dan2>
I just built a top with -thread -package threads threads.cma and I can't seem to get Thread.* at all
<dan2>
oh, I see whats going on now
<dan2>
Event will give me an event without waiting
<dan2>
then I have to run sync to get that event
vezenchio has quit ["\o/ python _o--|_"]
cryptilox has quit ["liberal elitists unite!"]
<dan2>
mrvn_: ping
cryptilox has joined #ocaml
mfurr has joined #ocaml
gim has quit []
<dan2>
anybody have any information about using the ocaml event system
<Riastradh>
Why don't you just ask your question?
<vincenz>
curry curry curry
<mfurr>
hmmm curry
<vincenz>
is it schorfinkel?
<dan2>
how do you pass information over the event system without locking up your entire program
<dan2>
I mean, lockup communicating threads
CosmicRay has joined #ocaml
<Riastradh>
I think you probably need to give a little more information than that.
<dan2>
Riastradh: the only way to pass information over the Event module and its channels is to run (sync (send chan "foo")) and on the other end (sync (receive chan))
<dan2>
Riastradh: however, if the other is not available your thread is turned into blocking
<dan2>
Riastradh: its really sucky to use
mrvn_ has quit [Read error: 60 (Operation timed out)]
<Riastradh>
Uh. It would seem that the Event module is less like CML in functionality than I had previously assumed.
<dan2>
Riastradh: hmm
<dan2>
Riastradh: whats CML?
<Riastradh>
Concurrent ML. It is a high-level asynchronous-event-driven framework designed by John Reppy originally for SML. It is implemented in both SML/NJ and MLton; there are also several frameworks similar to CML, such as OCaml's Event module and an upcoming proposal for a Scheme version of it.
<dan2>
Riastradh: I don't know SML
<Riastradh>
OCaml's Event module, however, seems to be restricted to synchronous channels, which is rather silly; such a restriction is of course not the case with 'real' CML.
<Riastradh>
The differences between OCaml & SML are mostly syntactic & trivial.
<dan2>
Riastradh: whats the difference between Mlton/SML to ocaml
<Riastradh>
MLton is an implementation of SML based on a whole-program compiler; OCaml is both a dialect of ML and its single implementation.
det has quit [Remote closed the connection]
det has joined #ocaml
<dan2>
Riastradh: async IO is the only way to take my issue appropriately
<dan2>
Riastradh: I really do need use of the aio stuff in C
<Riastradh>
There are only a couple significant semantic differences, such as in the record systems; other than that, they're pretty much the same language.
<dan2>
Riastradh: but ocaml is different from MLton
<Riastradh>
Why do you need to write C?
<dan2>
Riastradh: because nothing is offering me the aio style functions I need
<dan2>
Riastradh: otherwise I guess I'll have to learn mlton
<dan2>
Riastradh: you said mlton has its own cml right?
<Riastradh>
(The language is SML; MLton is only an implementation of it.)
<Riastradh>
MLton provides a CML library.
<dan2>
how do I learn SML
<dan2>
how much different is it from ocaml
<Riastradh>
It is hardly different at all from OCaml, as I have said several times already.
<dan2>
Riastradh: does it have the let function
<dan2>
let foo = blah
<dan2>
let foo a b = (a,b) kind of thing
<Riastradh>
'let' is not a function.
<dan2>
fine, does it have let?
<monochrom>
some people use the word "function" Englishly, not mathematically.
<monochrom>
they mean "feature"
<monochrom>
val x = 1
<monochrom>
fun f x = x + 1
<Riastradh>
Yes. I suggest that you look at a page that compares SML & OCaml; there is one that Google can find quite easily.
<dan2>
hmm. SML doesn't have let
<Riastradh>
Yes, it does.
<dan2>
the site doesn't show it
<Riastradh>
What site are you referring to?
<dan2>
the comparison site
<dan2>
I can't define functions with let
<dan2>
or atleast it doesn't show I can
<Riastradh>
Functions are defined with 'fun' or 'val'.
<Riastradh>
What comparison site in specific are you referring to?
<Demitar>
xav_, what additional libraries are you unable to compile in what?
<dan2>
Demitar: looks easy, but don't know how to make the file_descr compatible with the unix ones that ocaml uses
<dan2>
Demitar: hmm, I wonder if I can assign the type, Unix.file_descr
<Demitar>
dan2, I think you need to figure out what those Unix.file_descr actually look like.
<dan2>
Demitar: iirc its an integer as it is in C
<xav_>
Demitar, it would be very nice if you or someone else could look directly at the problem by dling the archive and trying to compile the whole thing : ftp://sunsite.icm.edu.pl/pub/programming/caml/cl75unix.tar.gz
<Demitar>
If there is no additional wrapping code you can probably just say it's a Unix.file_descr in the interface, better check with the actual ocaml implementation to be sure though.
<Demitar>
xav_, unfortunately I'm not going to spend any time reviving a dying language. You might want to check on caml-list though.
<xav_>
I understand. thanks
yakker has quit [Read error: 113 (No route to host)]
<dan2>
Demitar: I am just having a wonderful time with camlidl claiming syntax errros on the includes
<dan2>
Demitar: hmm, whats the best way to go about porting a library with camlidl
<Demitar>
dan2, you might be better off just copying the relevant functions and data structures into the .idl.
<dan2>
Demitar: k
<dan2>
whats wrong with this
<dan2>
volatile void *aio_buf;
<Demitar>
I'd try removing volatile.
<Demitar>
It's not going to make a difference in the code camlidl generates anyway.
<dan2>
Demitar: btw, whats the typedef for size_t
<mrvn>
dan2: depends
<dan2>
is size_t an int?
<mrvn>
dan2: no
<dan2>
mrvn: short?
<Demitar>
dan2, include the typedef in camlidl.
<mrvn>
size_t is an integer type large enough to store sizes.
<dan2>
mrvn: so a long?
m3ga has quit ["Client exiting"]
<mellum>
dan2: if it was always a long, it would be pretty pointless, wouldn't it?
<dan2>
yeah it would
<mrvn>
On systems where long happens to be what size_t needs it could be long.
<dan2>
mrvn: well, whats it on i386 and amd64
<Demitar>
dan2, check you C headers.
<mrvn>
long, or more specifically int and long
<mrvn>
/usr/include/asm/posix_types.h:typedef unsigned long __kernel_size_t;
<mrvn>
/usr/include/i386-linux/asm/posix_types.h:typedef unsigned int __kernel_size_t;
<dan2>
Demitar: whats the best way to create a blank instance of a type
<dan2>
Demitar: (from structure)
mfurr has joined #ocaml
cmeme has quit [Read error: 54 (Connection reset by peer)]
cmeme has joined #ocaml
cmeme has quit [Remote closed the connection]
cmeme has joined #ocaml
xav_ has quit ["Leaving"]
CosmicRay has quit [Read error: 113 (No route to host)]
niels^ has quit ["damn the man"]
CosmicRay has joined #ocaml
<dan2>
ok, whats the best way to implement non-blocking io
cryptilox has quit ["leaving"]
zzorn is now known as zzorn_afk
<Demitar>
dan2, there are a number of ways, the standard unix way is to use a select() loop. (You might also want to have a look at the equeue Unixqueue)
<dan2>
Demitar: ok, I was planning on using it with sockets, assuming sockets are fd, this should work the same
<mfurr>
dan2: yes, those will work fine
<dan2>
Demitar: wouldn't it make more sense to use poll instead of select so it doesn't block
<dan2>
Demitar: or just set select's timeout to 0
<mfurr>
dan2: there is no poll in the Unix module
<mrvn>
You don't want to poll, you want to block till something happens.
<dan2>
mrvn: ok...
<mfurr>
mrvn: unless, of course your app has other things it could be doing...
<Riastradh>
...in which case you have it do them in other threads.
<mrvn>
as Riastradh says
<dan2>
mrvn: ok, I see the part in Unix Network Programming where he uses select and tries to figure out what the type of data is and spew it elsewhere
<dan2>
mrvn: btw, module Event just plain sucks
<Demitar>
dan2, I assume you have a reason for disliking Event, no? :)
<dan2>
Demitar: the idea behind sync is stupid
<Riastradh>
dan2, you might want to _write_ more carefully, not just read more carefully, too! It is not the framework that sucks, and I am led to believe by your comments that you don't even really understand CML very well; what sucks is the absence of more synchronization mechanisms than synchronous channels.
<dan2>
Riastradh: fair enough
<dan2>
mfurr: so the idea is use a UnixQueue and keep processing the events?
<Riastradh>
Please consider the thoughts that go through your head & the words in front of you more before you make such egregiously uninformed assaults.
<mfurr>
I'm not terribly familiar with the equeue stuff(that was Demitar), but I have had a lot of success with just plain old O_NONBLOCK and Unix.read/write
<Riastradh>
If you don't understand the architecture of CML, you might politely ask why it is designed thus & how it is to be used.
<Demitar>
dan2, unixqueue is simply an abstraction of the common select() loop. It may or may not be useful.
<Riastradh>
It is generally not within reasonable etiquette to assert suckiness on the basis of your lack of understanding, and you are lucky I have continued to clarify & correct things repeatedly for you at all.
<Demitar>
Riastradh, is there a nice page explaining the reasoning behind it all? (I'm using it but surely don't have much clue as to why it's structured as it is.)
<Riastradh>
Demitar, are you familiar with CML's architecture already?
<Demitar>
Nope. Unless I know it under another name.
<dan2>
Demitar: I really do like the current design, but the IPC Event interface is sucky and I am not ready to implement extra functionality of it
quamaretto has quit ["Chatzilla 0.9.66 [Mozilla rv:1.7.5/20041107]"]
<Demitar>
dan2, I still haven't heard a specific complaint out of you.
<Riastradh>
dan2, please, I implore you to consider more carefully what you are saying before such blatancy.
<Riastradh>
Demitar, OCaml's Event module is an OCaml implementation of CML's core.
<Riastradh>
It is not that the 'IPC interface is sucky.' It is rather that the module lacks functionality; it is _not_ something inherent in the design of the event system.
<Demitar>
Riastradh, I'll go read up on Concurrent ML then, thanks.
<dan2>
Riastradh: fine it last functionality, but that doesn't help me now does it?
Submarine has joined #ocaml
<Riastradh>
No, but you could point this out to the mailing list or something (if it hasn't already been pointed out), offering constructive criticism of the OCaml library, rather than attacking it on a completely uninformed basis due.
<dan2>
Riastradh: no offense or anything, I don't have time to implement it either
<Riastradh>
Please, I _implore_ you to read more carefully what I said.
<Riastradh>
I _never_ suggested that you implement more synchronization abstractions for the Event module.
<Riastradh>
s/due//1
cryptilox has joined #ocaml
cryptilox has quit ["leaving"]
smimram has joined #ocaml
smimou has quit [Read error: 110 (Connection timed out)]
monochrom has joined #ocaml
<Demitar>
Is it just me or could a CML mailbox trivially be implemented using the current event module and the mailbox containing a thread internally?
<Riastradh>
It is not just you. It would be nice, however, if OCaml provided such a facility already.
<monochrom>
what is a mailbox? is it just like an event queue?
<dan2>
Demitar: if you do it I'll send you $15
<Demitar>
Yes, but that's not the way development happends, at least not with the current selective inclusion into the StdLib.
<Riastradh>
monochrom, an asynchronous channel.
<Demitar>
dan2, right now I have higher priorities I'm afraid. The first one being to get some sleep. :)
<dan2>
Demitar: if you can get it done tomorrow let me know
<dan2>
Demitar: then we can setup a deal maybe
<dan2>
:)
mlh has joined #ocaml
karryall has joined #ocaml
CosmicRay has quit ["Client exiting"]
smimram has quit ["?"]
<Demitar>
dan2, http://purple.worldforge.org/~demitar/ocaml_event_mailbox-20041209.tar.gz (untested, minor misfeatures (noted in the source), and no, I did this because it's fun and will be useful to me too. Oh, and the reason it took so long is that I couldn't quite decide on what container to use internally. :) )
<dan2>
Demitar: thanks
<dan2>
Demitar: I'll test it soon, need to eat and will send you the cash if it works, whats your paypal account
<Demitar>
That was the "no" part. :) Give it to someone who needs it instead. :)