<dj_ryan>
lets say i wanted to write a memory intensive database product
* pierre_m
doesn't go low level
<flx_>
dj_ryan, you can use mmap and you have the posix functions from the Unix-module at your disposal
<dj_ryan>
hmm
<dj_ryan>
lets say i dont have the option of using mmap
<flx_>
shared memory.. I don't remember existing primitives for that, but I suppose you could write them. finding a way to use them safely can be interesting..
<flx_>
(other than mmapping /dev/zero that is for shm, but that requires parent-child relationship)
mwhitney__ has quit [Read error: 110 (Connection timed out)]
<tsuyoshi>
you can mmap /dev/shm
mwhitney__ has joined #ocaml
<tsuyoshi>
ocamlnet also has a posix shared memory hash table
<dj_ryan>
hmm
<dj_ryan>
interesting
<flx_>
in any case, I don't see a problem in writing a database server in O'Caml
<tsuyoshi>
I am working on one myself.. but I just wrote c stubs for a lot of stuff
<dj_ryan>
intersting
<dj_ryan>
so you hve to write certain memory primitives in C
<tsuyoshi>
the locking is pretty hard to do in pure ocaml
seafood has joined #ocaml
<tsuyoshi>
you can use fcntl locks, but it's a little slow
<dj_ryan>
yeah you wouldnt want to do that
<dj_ryan>
you probably want pthread-based locks
<tsuyoshi>
yeah, that's what I did
Yoric[DT] has joined #ocaml
Yoric[DT] has quit ["Ex-Chat"]
seafood has quit [Read error: 110 (Connection timed out)]
verte has joined #ocaml
_zack has joined #ocaml
Alpounet has joined #ocaml
seafood has joined #ocaml
_zack has quit [Read error: 104 (Connection reset by peer)]
mwhitney__ has quit [Read error: 110 (Connection timed out)]
seafood has quit []
<pierre_m>
after parsing with ulex+ocamlyacc, do I have to do something special to clean everything ?
<pierre_m>
right now I Parsing.clear_parser and close_in my_channel
<pierre_m>
but after having parsing lots of files, my program freeze on a that it can parse when I ask it to parse only this one
mwhitney__ has joined #ocaml
<pierre_m>
raaah le con
<pierre_m>
(forg(et|ive) my last question)
<Alpounet>
ne t'en veux pas à ce point :-)
<Alpounet>
btw, what was the problem ?
_zack has joined #ocaml
Camarade_Tux has joined #ocaml
seafood has joined #ocaml
s4tan has joined #ocaml
<pierre_m>
Alpounet: the problem was actually in the next file but my output had not been flushed. And it was because I commented the wrong line in my grammar :D
<gildor>
flx_: yes, the mirror is under construction by httracker, availability depends on the state of httrack (mirroring software)
<gildor>
flx_: but the date is not better, you just have another archive
kaustuv_ has quit [Read error: 110 (Connection timed out)]
OChameau has joined #ocaml
pierre_m has left #ocaml []
mwhitney__ has quit [Read error: 110 (Connection timed out)]
mwhitney__ has joined #ocaml
Mr_Awesome has quit [Read error: 110 (Connection timed out)]
Mr_Awesome has joined #ocaml
Yoric[DT] has joined #ocaml
hkBst has joined #ocaml
jeanbon has joined #ocaml
mwhitney__ has quit [Read error: 110 (Connection timed out)]
jamii has quit [Read error: 110 (Connection timed out)]
<Jeff_ober>
It looks like it did connect, but then got rejected. Is there some sort of required handshake you must pass back for IRC to retain your connection?
<Alpounet_>
send the authentification strings
<flx_>
jeff_ober, I wonder, have you taken a look at the IRC RFC?
<Alpounet_>
and sometimes answer to the initial PING request
<flx_>
jeff_ober, btw, did you try out the ocaml-irc module?
<Jeff_ober>
fix_: No. I am completely guessing. My experience with IRC is xchat.
flx_ is now known as flux
<flux>
well, I highly recommend looking at the RFC
<Jeff_ober>
Alpounet_: well, flux highly recommend looking at the RFC
<Jeff_ober>
:)
<Alpounet_>
flux, I've taken a look at ocaml-irc, but it would need too much time and doesn't exactly fit my needs
<Alpounet_>
But I still don't understand why this doesn't work...
<flux>
oh I messed up who was talking about the problem :)
<Jeff_ober>
:)
<Alpounet_>
(too much time for learning)
<flux>
well, it is indeed likely that you need to respond to the initial ping from the server
<Jeff_ober>
He is PONGing back.
<Alpounet_>
flux, the given code should do it... ?
mwhitney__ has quit [Read error: 110 (Connection timed out)]
thelema has quit [Remote closed the connection]
mwhitney__ has joined #ocaml
slash_ has joined #ocaml
Yoric[DT] has quit ["Ex-Chat"]
thelema has joined #ocaml
Yoric[DT] has joined #ocaml
<rwmjones>
what exactly does TYPE_CONV_PATH do in sexplib/type-conv? It seems very undocumented, but you have to have it set to _something_ ...
<Alpounet_>
well, I've a bot connected.
<hcarty>
thelema: There seem to be a lack of consistency in the choice of exceptions thrown in Batteries modules
<hcarty>
thelema: Should this be raised as a bug report, or some other way?
<thelema>
hc: There's some debate about the exceptions raised in extString, what specifically are you thinking of
<hcarty>
(example: List.hd [] would raise Empty_list, but List.reduce [] would raise Invalid_argument "List.reduce: empty list")
jlouis has joined #ocaml
jeanbon has quit ["J'y trouve un goût d'pomme."]
jeanbon has joined #ocaml
<mrvn>
I wonder if that shouldn't raise List.empty?
<hcarty>
The (very) newly checked in Seq module seems to use the Failure exception in a few places. I was going to suggest or submit a patch with a different choice. But when I checked List I saw that there doesn't seem to be a clear standard
<thelema>
I'm not certain about the Empty_list exception myself...
<hcarty>
mrvn: I would think so too, or Empty_list should go and be replaced by Invalid_argument "..."
<mrvn>
Would be nice to have a exception hierachy.
<thelema>
If it's not too much trouble, submit these as bugs - this kind of thing is important to me.
seafood has joined #ocaml
<thelema>
as to an exception heirarchy... I think that's over-categorizing.
<thelema>
*way* too much work for what it's worth.
<hcarty>
thelema: Ok, will do. I just wasn't sure of the preferred way to report something like this
<mrvn>
thelema: I mean that is should be possible to keep exceptions from 2 modules apart even if theyir meaning overlaps.
<hcarty>
mrvn: Invalid_argument includes a string, but that may be considered too fragile
<mrvn>
hcarty: yeah. I would hate to have to match the string.
<thelema>
maybe I don't get to that phase of programming very often (the catch-every-error-to-make-my-program-bulletproof phase), but rarely do I have try..catch without a good plan of where the exception is raised.
<mrvn>
Also the string wouldn't work for functors.
<thelema>
hcarty: Thanks for the bug report.
<Alpounet_>
flux, how can I send a message with ocaml-irc ? :-p
<thelema>
mrvn: if it was important, you could have an additional value in the functor's argument that contains the necessary string to match.
<hcarty>
thelema: You're welcome. With the upcoming 1.0beta more-or-less freeze, this could turn problematic later on
jeanbon has quit ["J'y trouve un goût d'pomme."]
<mrvn>
thelema: List.Empty, Array.Empty, Set.Empty,... would allow a functor to catch M.Empty instead of Invalid_argument _. M.Empty would be more readable.
jeanbon has joined #ocaml
<hcarty>
mrvn: Is it possible to create an exception hierarchy in OCaml?
<hcarty>
Or, rather, is it possible without extra modules or boilerplate
<mrvn>
hcarty: you could throw objects.
rhar has joined #ocaml
<Yoric[DT]>
But you can't cast them...
<Yoric[DT]>
(well, you could with some Camlp4 boilerplate)
jonafan_ is now known as jonafan
mwhitney__ has quit [Read error: 110 (Connection timed out)]
Alpounet_ is now known as Alpounet
Snark has quit ["Ex-Chat"]
<Alpounet>
good night all
Alpounet has left #ocaml []
<mfp>
Yoric[DT]: I've realized there's a very strong reason to allow access to modules outside the Batteries.* hierarchy: circular dependencies
<mfp>
i.e., a library that builds on Batteries.xxx cannot be integrated in Batteries because it'd create a circular dependency
<thelema>
mfp: we deal with that often in developing abtteries
<mfp>
thelema: it's different though
<thelema>
There's many instances of code copy-and-pasted from extList to other modules
<mfp>
the modules in batteries refer to each other directly, not through Batteries.*
<mfp>
but 3rd party code wouldn't be able to --- if external access (not under Batteries) isn't allowed
<thelema>
yes, we'd have to unplug batteries in order to integrate that.
<mfp>
that means importing the source tree into batteries' git
<Yoric[DT]>
mfp: interesting remark.
<mfp>
instead of just merely wrapping it in Batteries' modules
<thelema>
FWIW, I'm kinda for not maintaining all the heirarchies of modules that we maintain
<mfp>
(as done e.g. with Camomile and friends)
<Yoric[DT]>
But I don't think there's *any* solution which doesn't require splitting Batteries in at least two packages.
<thelema>
one problem is that ocaml doesn't do submodules through subdirs.
<mfp>
have you seen Jérémie's latest msg?
<Yoric[DT]>
(and I mean packages as in Debian/GODI/etc., not as in modules)
* thelema
wonders how difficult it'd be to fix ocaml build so that modules in subdirs would be viewed as sumbodules of that directory...
<thelema>
except we don't really need that anymore - batteries is flat.
mwhitney__ has joined #ocaml
<mfp>
except for the toplevel Batteries prefix
<mfp>
hmm I don't see why 2 packages are needed
rodge has left #ocaml []
<Yoric[DT]>
Because of circular dependencies *between packages*.
<Yoric[DT]>
Still, I'm too tired to discuss this tonight.
<Yoric[DT]>
I'm going to wish you all a pleasant night.
<mfp>
night Yoric[DT]
<Yoric[DT]>
And retreat to a cup of herbal tea.
<Yoric[DT]>
Cheers.
<kaustuv>
The right answer is to adopt the MLBasis system from MLton. </bait>
hkBst has quit [Read error: 104 (Connection reset by peer)]
hkBst has joined #ocaml
<mrvn>
-I /foo and Bar.Baz.t wouldn't check for /foo/bar/baz.mli?
<thelema>
mrvn: if it does, I'm going to restructure batteries to use this.
<mrvn>
thelema: it does in .
hkBst has quit [Read error: 104 (Connection reset by peer)]
Waleee has joined #ocaml
<thelema_>
mrvn: what if foo/bar.mli exists?
Yoric[DT] has quit ["Ex-Chat"]
willb has quit [Read error: 110 (Connection timed out)]