<flux>
mrvn, the mknod-system call would also need the node type as an argument - preferably as a variant
pstickne_ has quit [Read error: 60 (Operation timed out)]
johnnowak has joined #ocaml
pstickne_ has joined #ocaml
joshcryer has quit [Read error: 104 (Connection reset by peer)]
benny_ has joined #ocaml
benny has quit [Read error: 60 (Operation timed out)]
bluestorm_ has joined #ocaml
Submarine has quit ["Leaving"]
smimou has joined #ocaml
jlouis has quit [Remote closed the connection]
smimram has joined #ocaml
smimou has quit [Read error: 110 (Connection timed out)]
ulfdoz has quit ["deprecated"]
smimram has quit ["bli"]
love-pingoo has joined #ocaml
<flux>
mrvn, btw, it's great to see someone work on ocamlfuse, I've sometimes too considered using it for something useful ;)
jlouis has joined #ocaml
jlouis has quit [Client Quit]
ulfdoz has joined #ocaml
ulfdoz has quit [Read error: 60 (Operation timed out)]
ulfdoz has joined #ocaml
buluca has joined #ocaml
johnnowak has quit []
joshcryer has joined #ocaml
slipstream has joined #ocaml
slipstream-- has quit [Read error: 60 (Operation timed out)]
bluestorm_ has quit ["Konversation terminated!"]
postalchris has joined #ocaml
a-priori__ has joined #ocaml
cmvjk has quit [Read error: 110 (Connection timed out)]
a-priori_ has quit [Read error: 110 (Connection timed out)]
cmvjk has joined #ocaml
postalchris has quit [Read error: 110 (Connection timed out)]
<flux>
it should be trivial to convert a continuation-based 'multithreading' io-framework to using monads, right?
<flux>
maybe I should study this monad-thing a bit further before attempting that, though, because it doesn't seem to be so easy :)
postalchris has joined #ocaml
<mrvn>
you can use the continuation monad and pass that around as argument instead of the continuation you have now.
<mrvn>
What language are you converting to? Haskell?
<flux>
ocaml
<mrvn>
No monads there
<flux>
there are many monads implementations for ocaml
<mrvn>
non of them powerfull enough to cover monads fully
<flux>
I'm not sure I need full coverage
<flux>
what I'm really after is the syntax candy provided by pa_monad :-)
<mrvn>
You can't do a callcc (unless you consider those hacks that fork) and that would be a reason to switch from continuation to monad.
<flux>
I suppose similar candy could be implemented without monads
<flux>
well, I suppose the candy isn't that important
<mrvn>
Do ou want to write an I/O framework with nice syntax candy?
<flux>
that's one idea
<flux>
maybe the amount of io is so little that candy is not necessary
<flux>
the current program is heavily threaded, but almost all threads spend their time waiting for messages
<flux>
and it doesn't seem very efficient - not surprising considering how ocaml threading works. also the messaging layer could be more efficient - if it were single-threaded, less locking would need to be done
<mrvn>
Do you need to parse the input or convert it from raw binary into structures?
<mrvn>
Or just something as simple as readline or an http header?
<flux>
yes
<flux>
well the threads are interacting with a remote device
<flux>
and they transfer data between the device and the database, plus make sure the device state matches the one in the database, even in the case the device has been disconnected for a while
<flux>
each device can be considered separately without taking the others into account
<flux>
it's not particularly complicated, but it does do big, stateful, things
<mrvn>
I once wrote a framework for epoll with some suggar for converting between binary and ocaml. You would say let format = `U32 `S16 `I64 `U8 `U8 in scan stream format (fun cks str off i j -> ....) and cks would be Int32.t, str string, off Int64.t, i and j int.
<mrvn>
Or print stream format cks str off i j
<flux>
oh, the protocol is text-based, and there's already another module for handling that
<flux>
(currently also n-threaded, but it's on its way to be handled with a single select-loop)
<mrvn>
The scan function would go into the background and call the function once enough data was in the stream. The print would buffer when needed and send the data when possible.
<mrvn>
hmm, so what exactly do you need? Just something that waits for enough data and then forks of a worker thread?
<flux>
there's currently one thread for receiving traffic per each device, and then dispatching registered callbacks (associated with tags)
<flux>
the work could be done by one thread that would select(2) all the devices and handle the buffers etc, and do the dispatching
<flux>
I'm hoping it would be less overhead
<mrvn>
And that thread is blocking when it reads the bits and chunks of the protocol?
<mrvn>
Or is it already continuation style?
<flux>
almost, it handles timeouting etc too, so practically yes
Smerdyakov has joined #ocaml
<flux>
that module is not the one I'm trying to continuaize (a word?-))
<mrvn>
Is it easy to see the boundaries between callbacks? Easy to detect when you have enough input to parse it and call?
<flux>
there's an application that uses the protocol module, and it also spaws a thread per each connected device
<flux>
yes
<flux>
so the receiver can determine whether the message is ready, without knowing the internal structure of the message
<mrvn>
So you could have a single main loop with select that waits for input and buffers output. When input comes it reads it into a buffer till it has enough for a callback and then calls the protocol module.
<flux>
not really, I'm still thinking the protocol-thingy would do all that by itself in its own thread, and the application would run in its own thread
<mrvn>
what would the application do?
<flux>
the callbacks the application registers to the protocol module would be functions that send messages to the application's message queues
<flux>
it connects to the devices, transfers data, uses database, possibly passes external commands to the devices
<mrvn>
You could have one thread for select, one for the app and do IPC between the threads. But why? Only reason to do that would be if handling a single message would take long.
<flux>
because I don't want to change the interface of the protocol module
<flux>
it's quite nice as it is, and some other (much simpler) tools already use it
<mrvn>
Ok, so you are stuck with 2 threads then
<flux>
yes :)
<mrvn>
still works.
<flux>
it's still quite an improvement
<flux>
the number of devices could be hundreds
<mrvn>
Do you have more than say 25 devices?
<mrvn>
ok.
postalchris has quit [Read error: 110 (Connection timed out)]
<mrvn>
Are you working on linux?
<mrvn>
or bsd?
<flux>
yes
<flux>
linux
<mrvn>
Then you could write bindings for epoll instead of select. Better for many connections.
<flux>
yes, definitely, that's going to be a part of this change
<flux>
but, now I'm off to play some badminton
<flux>
thanks for suggestions
<mrvn>
have fun
<mrvn>
and I don't think you need monads.
<flux>
that's the result I've reached during this conversation too :)
buluca has quit [Read error: 113 (No route to host)]
Smerdyakov has quit [Remote closed the connection]
Smerdyakov has joined #ocaml
pango has quit [Remote closed the connection]
chealer has quit ["Konversation terminated!"]
pango has joined #ocaml
gunark has quit [Read error: 104 (Connection reset by peer)]
vorago has quit [Read error: 113 (No route to host)]
love-pingoo has quit ["Leaving"]
postalchris has joined #ocaml
cjeris has joined #ocaml
pango has quit [Remote closed the connection]
pango has joined #ocaml
slacker403 has joined #ocaml
<slacker403>
any improvements in Ocaml in the past 6 months ????
vital303 has joined #ocaml
<jacobian>
none
<slacker403>
any new on a newer version ?
<mrvn>
I think there was recentl<.
<mrvn>
s/</y/
<slacker403>
i see
<slacker403>
i wonder if ocaml will ever get faster :D
bluestorm_ has joined #ocaml
<mrvn>
write an optimizing compiler.
<mrvn>
I always found it fast compared to other languages. even with the poor code quality
<slacker403>
seeems like a bit of work
<mrvn>
Installed: 3.09.2-7
<mrvn>
Candidate: 3.09.2-9
<mrvn>
hmm, just a Debian update.
<slacker403>
my fav langs are ocaml D pascal and lua :D
<mrvn>
You could write a gcc frontend to parse ocaml code into GCCs midelevel syntax and you would get all the optimizing for free.
<slacker403>
hmmm
<slacker403>
interesting
<slacker403>
is that possible ?
<mrvn>
If you know gcc it should be quite simple.
<slacker403>
would that put it up on a level of c and c++ ?
<mrvn>
isn't it there or better already?
<mrvn>
:)
<slacker403>
its close
<slacker403>
:P
<slacker403>
i kow im jus complaining but yea :P
<slacker403>
ocaml is fast
<slacker403>
way fast
<slacker403>
ocaml / lua / d are really good
<mrvn>
Usualy I can write the algorithm better and that probably makes up for the lack of optimizations the compiler could do.
<slacker403>
ocaml can be used for embdded systems right ?
<mrvn>
I don't see why.
<mrvn>
not
<mrvn>
You waste a little ram for the tags for the GC but it is fast.
<mrvn>
And no segfaults and no memory leaks as you would get with C.
<mrvn>
And hey, people want to use java on embedded systems.
<slacker403>
yea
<slacker403>
i am glad i learned ocaml a while back
<slacker403>
even though the way i program it may not be the true way
<mrvn>
remember to use tail recursion
<slacker403>
hmmmmmmmm
<flux>
ocaml could do better with systems with limited resources.. dynamic linking of libraries, for one
<flux>
of course, this is assuming it's not _so_ low-end system in that it does have a dynamic linker :)
<flux>
but otherwise you'll need to do a single multi-call binary with everything you need in it
dark_light has joined #ocaml
Submarine has joined #ocaml
<slacker403>
embedded systems
<mrvn>
Another thing a gcc frontend would give you.
<slacker403>
huh ?
love-pingoo has joined #ocaml
<mrvn>
dynamic libs
<mrvn>
By the way, the ocaml GC is a moving GC. It compactifies the used ram every now and then removing fragmentation. That can save a lot.
<slacker403>
i want to use ocaml on an embedded system of mine
vital303 has left #ocaml []
gunark has joined #ocaml
<flux>
I believe the dynamic linker isn't in ocaml because it cannot be implemented 'perfectly' - well, not atleast it hasn't been by the core team, I think there was some modification (scaml?) that allowed dynamic linking
<mrvn>
You might have to cut out some parts like objects and polymorphic variants.
jlouis has joined #ocaml
zarvok has joined #ocaml
zarvok has quit [Client Quit]
tspier2 has joined #ocaml
Smerdyakov has quit ["Leaving"]
Nutssh has quit [Read error: 104 (Connection reset by peer)]
love-pingoo has quit ["Connection reset by pear"]
Mr_Awesome has joined #ocaml
jlouis_ has joined #ocaml
<tspier2>
Wow, I just have to say something: I used OCaml a long time ago when I was just beginning to program, and I had stopped using it to go to imperative programming languages. Anyway, I recently revisited OCaml, and I have to say, it's amazing. :)
jlouis has quit [Read error: 110 (Connection timed out)]
<Mr_Awesome>
tspier2: have you tried any other functional languages?
pango has quit [Remote closed the connection]
pango has joined #ocaml
<tspier2>
Mr_Awesome, not really - I once toyed around with that functional programming language for games, Clean.
<Mr_Awesome>
tspier2: i recommend trying lisp (scheme, in particular) and haskell
<tspier2>
How come?
<slacker403>
i use ocaml imperativee ly :P
<Mr_Awesome>
ocaml is indeed awesome, but its quite possible youll like those languages even better
<mrvn>
not scheme or lisp
<slacker403>
i wish they would make a DCC frontend for Ocaml
<slacker403>
GCC
<Mr_Awesome>
mrvn: i like scheme better than ocaml
<tspier2>
How is OCaml for GUI apps? I plan on continuing to learn more of this language, provided some good libraries exist for GUI apps.
<slacker403>
which system
<Mr_Awesome>
tspier2: there are different choices for GUIs, they are decent to use
<tspier2>
Linux
<tspier2>
slacker403, good choice, btw.
<slacker403>
gtk?
<tspier2>
Yep
<tspier2>
Or something lighter.
<slacker403>
fltk
<slacker403>
is there an ocaml FLTK?
<slacker403>
never used fltk though
<slacker403>
i like gtk
<slacker403>
but i would prefer something a little lighter
<slacker403>
FLTK i think would be really good i think
<slacker403>
gtk2 is good though i guess
<tspier2>
Mr_Awesome, out of curiosity, do you know of any side-scrollers created in OCaml, Lisp, or Haskell?
bluestorm_ has quit ["Konversation terminated!"]
dark_light has quit [Remote closed the connection]
tspier2 has quit ["Tschau"]
<slacker403>
i really wish ther were better gui toolkits ?
<mrvn>
not just for ocaml
fezsentido has joined #ocaml
* jer
really wishes i could build a cross compiler that targets arm-linux-uclibc
<mrvn>
Ocaml doesn't really compile that long. build native
<jer>
if that was directed at me, difficult to compile ocaml in 13 megs of flash =]
<mrvn>
arm emulator
<jer>
got one that runs on macosx and isn't qemu (it doesn't work right)
<mrvn>
build the interpreter :)
* jer
has been down this avenue before =]
<mrvn>
a while back some did compile debian packages with an arm emulator. So there is one out there that works.
<jer>
i'm not nuking osx just to install linux to have a working arm emulator
<jer>
that's like killing a mosquito with a shotgun
<mrvn>
ever heard of dual boot?
<mrvn>
Or setup an NFS share to mount on your arm.
<jer>
i've got no space left on my hard drive atm (new hard drive is backordered (need a small height to fit in the macbook))
<jer>
hrmm
<jer>
nfs might work, provided there's a mount_nfs
* jer
checks
<mrvn>
hehe, that feeling I know.
<jer>
grr, osx is being a dickhead; won't let me connect bluetooth to the thing... and having a heard issue where i can't load up any new apps
<jer>
(but too lazy to reboot heh)
malc_ has joined #ocaml
Oxylin has joined #ocaml
Oxylin has quit [Client Quit]
nuncanada has quit [Connection timed out]
postalchris has quit ["Leaving."]
fezsentido has quit [Connection timed out]
Smerdyakov has joined #ocaml
momowac has joined #ocaml
<momowac>
helloo
momowac has left #ocaml []
dark_light has joined #ocaml
cjeris has quit [Read error: 104 (Connection reset by peer)]