hcarty has quit [Read error: Connection reset by peer]
maskd has quit [Quit: eaving]
ztfw has quit [Remote host closed the connection]
enthymene has quit [Quit: rcirc on GNU Emacs 23.1.1]
iratsu has quit [Ping timeout: 265 seconds]
_unK has quit [Remote host closed the connection]
joewilliams_away has joined #ocaml
joewilliams_away is now known as joewilliams
elehack has quit [Quit: Goodbye...]
julm has quit [Quit: Changing server]
julm has joined #ocaml
threeve has quit [Quit: threeve]
sgnb has quit [Read error: Connection reset by peer]
sgnb has joined #ocaml
joewilliams is now known as joewilliams_away
thrasibule has quit [Ping timeout: 240 seconds]
jeddhaberstro has quit [Quit: jeddhaberstro]
jcaose has joined #ocaml
Associat0r has quit [Quit: Associat0r]
submarine has joined #ocaml
mutew has joined #ocaml
jcaose has quit [Ping timeout: 240 seconds]
Submarine_ has joined #ocaml
mutew is now known as mutweit
mutweit is now known as mutewit
mutewit has quit [Quit: leaving]
mutewit has joined #ocaml
avsm has joined #ocaml
tmaedaZ is now known as tmaeda
mutewit has quit [Quit: leaving]
Submarine_ has quit [Quit: Leaving]
pimmhogeling has joined #ocaml
monadic_kid has joined #ocaml
pimmhogeling has quit [Read error: Connection reset by peer]
pimmhogeling has joined #ocaml
* mrvn
needs a nice universal type that is sortable and enumerable.
<mrvn>
enumerable == iterate over all entries of a certain type
slash_ has joined #ocaml
jcaose has joined #ocaml
maattd|away is now known as maattd
pimmhogeling has quit [Quit: Ik ga weg]
ygrek has joined #ocaml
tmaeda is now known as tmaedaZ
derdon has joined #ocaml
sgnb has quit [Remote host closed the connection]
monadic_kid has quit [Quit: Leaving]
Alpounet has quit [Ping timeout: 248 seconds]
tmaedaZ is now known as tmaeda
Alpounet has joined #ocaml
avsm has quit [Quit: Leaving.]
sgnb has joined #ocaml
maattd is now known as maattd|away
seafood has joined #ocaml
Drk-Sd has joined #ocaml
ulfdoz has quit [Ping timeout: 258 seconds]
ttamttam has joined #ocaml
ulfdoz has joined #ocaml
maskd has joined #ocaml
pimmhogeling has joined #ocaml
seafood has quit [Quit: seafood]
_unK has joined #ocaml
ztfw has joined #ocaml
Associat0r has joined #ocaml
slash_ has quit [Quit: Lost terminal]
maattd|away is now known as maattd
<mrvn>
Can I have a signature functor?
<ygrek>
in 3.12
<mrvn>
I have a bunch of modules that have a common interface with different types and I would like to define one polymorphic signature and instantiate that for each of them.
<mrvn>
module T : S with type t = int = struct .... end
<mrvn>
or something like that
boscop_ has joined #ocaml
boscop has quit [Ping timeout: 240 seconds]
boscop_ has quit [Client Quit]
<derdon>
``+5.6`` throws a syntax grammar oO
<derdon>
a plus before a floating point literal is not allowed, but a minus is.
<derdon>
*syntax error
<mrvn>
should be -.1.0
<mrvn>
+1 is a sytax error too. So no change there.
Snark has joined #ocaml
<derdon>
mrvn: is it not included in the grammar because the plus sign is not necessary there?
Snark has quit [Client Quit]
<mrvn>
derdon: it is kind of pointless.
<derdon>
and ``-3_._4_5_6`` works :D
<derdon>
funny grammar
Snark has joined #ocaml
<derdon>
strings can be empty, but characters not. why?
Yoric has joined #ocaml
<flux>
derdon, hmm, what would an empty character be?
<mrvn>
-3 works too
<derdon>
flux: an instance of the type character which has no content
<mrvn>
derdon: char option?
<derdon>
flux: like 0 for integers, 0.0 for floats, "" for strings, false for booleans, ...
<derdon>
mrvn: what is char option?
<mrvn>
derdon: 0 is a perfectly fine int
<mrvn>
derdon: None | Some c
<flux>
derdon, well, Char.chr 0 is not an empty charcater in my opinion. neither is 0 an empty number. is just is non-empty number 0.
<flux>
if you want to differentiate between empty and non-empty values, then the option type is the key
<derdon>
so why are empty strings possible whereas empty characters are not? why not making empty strings impossible, too?
<mrvn>
derdon: because a string can have a length of 0
<flux>
derdon, what would it mean to concatenate 10 empty characters? it would produce an empty string?
<derdon>
flux: no, it would still be an empty string
<derdon>
*empty character, even!
<mrvn>
ans s.(3) = c when c is the empty char?
<flux>
derdon, so what would it mean to concatenate 10 non-empty characters then?-o
<flux>
it produces a 10-character character?
<derdon>
flux: it makes the universe explode
<derdon>
flux: you convinced me
<mrvn>
derdon: what you want is really met by the option tpye.
<derdon>
mrvn: but then I have None instead of an empty character. EOD
<mrvn>
None is the empty char then
<derdon>
ok
<derdon>
next question: why are both ' ' and '\ ' supported to create a character containing a space?
<derdon>
' ' should be enough I think
<mrvn>
should be.
<derdon>
but ...?
<flux>
an oversight? backwards compatibility?
<derdon>
hm
<flux>
hey, I found out a 'plausible' reason
<derdon>
good
<flux>
' ' and ' ' (with a tab inside) look the same
<flux>
'\ ' with a tab in place of the space is illegal
<mrvn>
# '\t';;
<mrvn>
- : char = '\t'
<derdon>
for humans, but not for computers
<flux>
well, obviously humans write and read the programs
<mrvn>
# ' ';;
<mrvn>
- : char = '\t'
<flux>
programs are meant for humans to read that they are useful with computers is a nice side effect ;-)
<flux>
(actually I don't remember who said that originall, and better..)
<mrvn>
\<tab> is illegal.
<derdon>
but tabs inside scripts are bad style anyway
<flux>
well, you still cannot know for sure
<flux>
if you read code with ' ' it could always be suprsising tabs in it!
<mrvn>
I would always write tabs as '\t' and spaces as ' '.
<flux>
and I don't think it's bad style if you are producing multi-line strings for example, with a certain layout you want to represent
<flux>
perhaps a bit obscure if you're talking about a single literal :)
<flux>
but really, if we have one reason to support '\ ', shouldn't there be just as well or even better reason not to support them, if we wouldn't want to have it?
<flux>
I imagine the cost to support that feature is extremely low..
<mrvn>
totaly trivial.
<derdon>
yeah, I was just a bit surprised
<thelema>
derdon: strings are sequences of characters, just like a list can be empty, a string can be empty
<derdon>
thelema: good argument
Yoric has quit [Ping timeout: 260 seconds]
<mrvn>
Now where is my List.iteri?
<flux>
it's in batteries
<Camarade_Tux>
in your own code =/
<Camarade_Tux>
or batteries of course ;-)
<mrvn>
Will use List.fold_left (fun i x -> ...; i+1) 0 list
<mrvn>
That actualy works out great since I need to return the count at the end
ulfdoz has quit [Ping timeout: 248 seconds]
ulfdoz has joined #ocaml
Drk-Sd has quit [Quit: {'EXIT', Drk-Sd, "bye"}]
<thelema>
releasing bat 1.1.0
<mrvn>
thelema: Interested in adding IO functions for Bigarrays?
<mrvn>
Ideas how to write a good 'val hash : string -> int64'?
<mrvn>
Anything better than (Digest.string str) and then using 8 bytes to make an int64?
avsm has joined #ocaml
Drk-Sd has joined #ocaml
<thelema>
mrvn: IO for bigarrays? Don't the existing byte/int32/64 functions handle that fairly well with an iterator?
<flux>
thelema, well, if you already have a Bigarray and want to efficiently dump it down a pipe?
boscop has joined #ocaml
mutewit has joined #ocaml
<thelema>
yes, use an iterator with the appropriate printing function for a single element
<flux>
that would copy all the data in the process, no?
maattd is now known as maattd|away
<thelema>
yes, there'd be at least an extra copy of the data made.
<thelema>
you want to take an arbitrary bigarray and dump it without making a copy?
<thelema>
no matter the layout?
<flux>
I guess he wants to write the binary representation of the data in memory, akin to C's read. I'm guessing it's 8-bit data.
<thelema>
batteries 1.1.0 released.
<flux>
did the Gc/Genlex-fix get in?
<mrvn>
Whatever type bigarray it is you should be able to write it to disk or read it.
<mrvn>
Plus there is BatIO.input_string but no BatIO.input_bigarray
<mrvn>
Bigarray have a huge advantage ove string for IO. They don't get moved by the GC so you don't need to copy them.
<flux>
that's a good point
<flux>
actually doesn't that work both ways? during reading and writing?
<flux>
with regular strings it's two copies right there?
<mrvn>
flux: one copy. You read into a char* and then blit into the string.
<mrvn>
Well, two if you count the kernel copying as one too.
<flux>
I mean Unix.read uses its internal buffer for reading, no?
<mrvn>
yes
<flux>
and Unix.write must do the same
<flux>
due to the gc issues and not wanting to block everything
<mrvn>
Since the Unix.read/write drops the ocaml mutex the GC can run while it reads/writes and move the string.
<flux>
so two copies when in a read/write-sequence in ocaml-land
<thelema>
flux: of course it got in.
<flux>
thelema, :)
<flux>
versus 0 when using bigarray and theoretical input/output_bigarray
<mrvn>
flux: one versus 0
zhijie has quit [Read error: Connection reset by peer]
<mrvn>
flux: or does input_string make another copy?
<thelema>
If anyone is interested in implementing this (or maybe finding it in Core - the jane street people seem smart enough to have already invented this), it'd be welcome in batteries.
<mrvn>
thelema: I would like a Bigarray with variable type too. One where you can pull any integer/float type from given a byte offset. But that should be in the compiler in Cmm form.
zhijie has joined #ocaml
<mfp>
thelema: Bigstring module in Core --- requires stubs
smimou has quit [Ping timeout: 246 seconds]
smimou has joined #ocaml
smimou has quit [Changing host]
smimou has joined #ocaml
avsm has quit [Quit: Leaving.]
ulfdoz_ has joined #ocaml
ulfdoz has quit [Ping timeout: 245 seconds]
smimou has quit [Ping timeout: 265 seconds]
smimou has joined #ocaml
ttamttam has quit [Quit: Leaving.]
pimmhogeling has quit [Remote host closed the connection]
threeve has joined #ocaml
ttamttam has joined #ocaml
threeve has quit [Quit: threeve]
_unK has quit [Remote host closed the connection]
threeve has joined #ocaml
thrasibule has joined #ocaml
pimmhogeling has joined #ocaml
<thelema>
mfp: I'm not opposed to having some C in batteries.
* thelema
updates docs on website
maattd|away is now known as maattd
<flux>
infact, an enhanced C-interface for dealing with ocaml would be great
<flux>
but perhaps it enlarges the scope of batteries too much
<flux>
infact a C++-one would be nice as well, but perhaps so few would prefer c++ over c for this kind of work that having it would not be that useful
<thelema>
flux: more than the simple macros provided by the compiler?
<mrvn>
Exporting more of the C stubs ocaml has.
<flux>
that too, and at the moment things like handling lists or records is somewhat error prone and tedious in C - partially C's fault of course, but perhaps it could be made easier :)
<mrvn>
e.g. the helper stubs to create a sub-array of a Bigarray.
<thelema>
that'd be an interesting project, but probably not part of batteries' mission
<mrvn>
completing the module interface seems to be quite the same as completing the C interface
<flux>
completing the ocaml-interface is not the same as completing the non-ocaml-interface :)
<flux>
anyway, some of those would better be fixed in the upstream.. simply by non-staticin (I don't know if they are static) or atleast by publishing the signature in a header file
<flux>
I remember having a related problem when dealing with Unix.error in C
<mrvn>
flux: bug with patch in the BTS. upstream is not interested in fixing things
* thelema
is going to need some good multi-process parallelism in the near future for his work
<flux>
now how to integrate that with Lwt and an Event-like module..
* flux
likes the CML interface :)
Alpounet has quit [Ping timeout: 276 seconds]
<flux>
I wonder if you can pass camlboxes over camlbox..
ulfdoz_ has quit [Quit: Reconnecting]
ulfdoz has joined #ocaml
smimou has quit [Ping timeout: 265 seconds]
Alpounet has joined #ocaml
smimou has joined #ocaml
pimmhogeling has quit [Ping timeout: 265 seconds]
joewilliams_away is now known as joewilliams
mutewit has quit [Quit: leaving]
enthymene has joined #ocaml
<Camarade_Tux>
if I create an in_channel and then a file descriptor with file_descr_of_in_channel, how should I close them? closing the file_descr and then the in_channel doesn't seem ok (raise Invalid file descr or something like that)
<thelema>
I think closing the in channel should suffice.
<thelema>
Don't use the file_descr afterwards
<Camarade_Tux>
it seems I can close one of hem but not both
<Camarade_Tux>
anyway, wanted to be sure, thanks =)
jeddhaberstro has quit [Quit: jeddhaberstro]
inkbottle has joined #ocaml
inkbottle has quit [Quit: Leaving]
inkbottle has joined #ocaml
pimmhogeling has joined #ocaml
Snark has quit [Quit: Ex-Chat]
jeddhaberstro has joined #ocaml
hkarim has joined #ocaml
jao has quit [Ping timeout: 245 seconds]
joewilliams is now known as joewilliams_away
enthymene has quit [Quit: brb]
ztfw has joined #ocaml
ygrek has quit [Ping timeout: 245 seconds]
maattd|away is now known as maattd
hkarim has quit [Read error: Connection timed out]
hkarim has joined #ocaml
enthymene has joined #ocaml
hkarim has quit [Read error: Connection timed out]
pimmhogeling has quit [Ping timeout: 265 seconds]
inkbottle has quit [Quit: Leaving]
submarine has quit [Quit: Leaving]
maattd is now known as maattd|away
ztfw has quit [Remote host closed the connection]
Amorphous has quit [Read error: Operation timed out]