sepp2k has quit [Remote host closed the connection]
Associat0r has quit [Ping timeout: 244 seconds]
reynir has quit [Ping timeout: 252 seconds]
abdallah has quit [Quit: Ex-Chat]
sebz has quit [Quit: Computer has gone to sleep.]
morolin has joined #ocaml
Cyanure has quit [Ping timeout: 240 seconds]
sebz has joined #ocaml
sebz has quit [Quit: Computer has gone to sleep.]
sebz has joined #ocaml
sebz has quit [Client Quit]
tomprince has joined #ocaml
sebz has joined #ocaml
sebz has quit [Client Quit]
sebz has joined #ocaml
sebz has quit [Client Quit]
sebz has joined #ocaml
sebz has quit [Client Quit]
Associat0r has joined #ocaml
Associat0r has quit [Changing host]
Associat0r has joined #ocaml
astertronistic has quit [Read error: Operation timed out]
hto has joined #ocaml
Associat0r has quit [Quit: Associat0r]
oriba has quit [Quit: oriba]
astertronistic has joined #ocaml
cafesofie has joined #ocaml
sebz has joined #ocaml
sebz has quit [Client Quit]
sebz has joined #ocaml
cafesofie has quit [Remote host closed the connection]
Kakadu has joined #ocaml
yroeht has quit [Ping timeout: 260 seconds]
yroeht has joined #ocaml
ygrek has joined #ocaml
ygrek has quit [Ping timeout: 248 seconds]
schme has quit [Read error: Operation timed out]
ttamttam has joined #ocaml
schme has joined #ocaml
schme has quit [Changing host]
schme has joined #ocaml
ygrek has joined #ocaml
edwin has joined #ocaml
ttamttam has quit [Remote host closed the connection]
fschwidom has joined #ocaml
ikaros has joined #ocaml
ulfdoz has quit [Quit: kernel upgrade]
ulfdoz has joined #ocaml
Derander has quit [Ping timeout: 258 seconds]
Derander has joined #ocaml
testcocoon has quit [Quit: Coyote finally caught me]
ulfdoz has quit [Quit: NOCHMAL!]
spinotop has joined #ocaml
everyonemines has joined #ocaml
ulfdoz has joined #ocaml
JdpB42 has quit [Quit: JdpB42]
everyonemines has left #ocaml []
everyonemines has joined #ocaml
everyonemines has quit [Client Quit]
everyonemines has joined #ocaml
spinotop has quit []
Anarchos has joined #ocaml
testcocoon has joined #ocaml
reynir has joined #ocaml
linshuai_irc has joined #ocaml
linshuai_irc has left #ocaml []
Cyanure has joined #ocaml
testcocoon has quit [Quit: Coyote finally caught me]
testcocoon has joined #ocaml
sebz has quit [Quit: Computer has gone to sleep.]
sepp2k has joined #ocaml
sebz has joined #ocaml
raichoo has joined #ocaml
avsm has joined #ocaml
Anarchos has quit [Quit: Vision[0.9.7-H-090423]: i've been blurred!]
<hcarty>
thelema: Do you know if the Batteries v2 branch has an updated BatMap.S to match the OCaml 3.12.x stdlib updates to Map.S?
hto has quit [Quit: Lost terminal]
<hcarty>
thelema: Are you still thinking of Batteries v3 as a time to move to using OCaml 3.12 features in Batteries itself?
<thelema>
hcarty: I think it has; I'll double check now
hto has joined #ocaml
<thelema>
probably not - I think batteries can carry independent implementations of the standard libraries
<thelema>
I think batteries v2 can implement all 3.12 features
<hcarty>
thelema: Sorry, I meant features like "module type of" and first class modules
<thelema>
ah, those are still v3
<thelema>
requiring 3.12 to compile batteries
<hcarty>
Ok, that's what I thought. Thanks.
testcocoon has quit [Quit: Coyote finally caught me]
<thelema>
hcarty: were you wanting to use them for something?
testcocoon has joined #ocaml
<hcarty>
thelema: Just that they could make interface management simpler. "include module type of Stdlibfoo" in batFoo.mli reduces code duplication and (more closely) matches the Batteries API to the underlying OCaml stdlib
<hcarty>
That may or may not be considered a good thing...
<thelema>
quite true
<hcarty>
I've used this for my own local Batteries-derived stdlib. myArray.mli = include module type of Array include module type of BatArray val ...
mejalx has quit [*.net *.split]
haelix has quit [*.net *.split]
hyperboreean has quit [*.net *.split]
dsheets1 has quit [*.net *.split]
tlockney has quit [*.net *.split]
Pepe_ has quit [*.net *.split]
zmoazeni has quit [*.net *.split]
othiym23 has quit [*.net *.split]
snarkyboojum has quit [*.net *.split]
haelix has joined #ocaml
Pepe__ has joined #ocaml
othiym23 has joined #ocaml
hyperboreean has joined #ocaml
mejalx has joined #ocaml
snarkyboojum_ has joined #ocaml
zmoazeni_ has joined #ocaml
tlockney_ has joined #ocaml
dsheets has joined #ocaml
testcocoon has quit [Ping timeout: 252 seconds]
avsm has quit [Ping timeout: 244 seconds]
testcocoon has joined #ocaml
<hcarty>
thelema: Additions from Ulib might be nice, but those can presumably happen during the 2.x release cycle
testcocoon has quit [Client Quit]
<thelema>
hcarty: from ulib? ulib is in v2
sebz has quit [Quit: Computer has gone to sleep.]
<hcarty>
thelema: Ulib as in the stdlib extensions from the OCaml CVS/SVN repository, not Ulib for Camomile replacement
<hcarty>
The only modifications, IIRC, were to the build system
testcocoon has joined #ocaml
Anarchos has joined #ocaml
<everyonemines>
So there's no win64 binary? I'm gonna compile on cygwin, maybe I could try and make one.
<hcarty>
everyonemines: I think ocamlpro or ygrek provides a Win64 binary of some sort
<thelema>
everyonemines: yup. It's not too bad to compile, as long as you have all the cygwin deps worked out.
<thelema>
hcarty: I've tried those, and couldn't get them to work right
* ygrek
not (at least currently)
<hcarty>
thelema, ygrek: Ok, I haven't tried any Windows builds yet.
<adrien>
there shouldn't be many problems if at all with mingw-w64 currently
<adrien>
and there's a bug tracker entry about it too
<everyonemines>
Well cygwin is useful anyway, so...
<everyonemines>
it's just that I think an easy binary for windows would be good for ocaml.
<everyonemines>
I mean for getting new users.
<thelema>
everyonemines: it would. if you make such, consider including odb.ml in the distribution
<everyonemines>
oasis db?
avsm has quit [Quit: Leaving.]
<everyonemines>
is that better than godi now?
<hcarty>
everyonemines: It's different. It is lighter and arguably easier to package for. GODI still has more features, particularly with respect to upgrading libraries and OCaml itself.
avsm has joined #ocaml
<thelema>
hcarty: I'm working on odb-from-github, but don't have a good solution for the metadata needed to connect packages to where to get them
<hcarty>
thelema: That's may be something that would fit more easily into oasis-db
<everyonemines>
thelema: Hmm, what else would you want? Findlib I guess...
<hcarty>
thelema: A source list to go along with the rest of the package metadata
<hcarty>
everyonemines: OCaml + findlib is already a large improvement over OCaml on its own :-)
<hcarty>
thelema: Would you be interested in some or all of these additions: http://vpaste.net/y5NAH
<thelema>
everyonemines: yup, just that.
<thelema>
hcarty: yes, although I'm not so sure about verify and unless going into default namespace
<hcarty>
thelema: What about verify_arg/verify_argf?
<hcarty>
unless and ( |? ) could live in BatOption
<hcarty>
I use ( |? ) fairly often, although it does bite me when I forget that it doesn't short circuit.
<thelema>
verify_arg can go in std (low identifier collision chance), but might want to stay with verify for consistency
<hcarty>
"might want to stay with verify for consistency" - I'm not sure what you mean
<hcarty>
thelema: Should I fork master or v2 for these additions?
<thelema>
v2
<thelema>
verify* should probably go in the same module
<thelema>
I guess this could be batstd
<hcarty>
Understood
<thelema>
n/m, just put it in batpervasives
<thelema>
I'm going to merge batstd into batpervasives - no sense duplicating interfaces
<thelema>
batpervasives includes batstd for some unknown reason
<hcarty>
thelema: Maybe an extlib-ism
<thelema>
yes
<hcarty>
Do you think it's worth adding both verify_arg and verify_argf?
<hcarty>
verify could be renamed to verify_exn to help avoid naming collisions
<hcarty>
But your proposal could be useful in some cases too
<thelema>
is plain verify more useful than an if statement + raise?
<everyonemines>
hcarty: I actually don't really use findlib. If I need to use a library in multiple places I make a symbolic link.
<thelema>
everyonemines: frown
* adrien
spanks everyonemines
<everyonemines>
yeah yeah
<thelema>
everyonemines: you should give it another chance - it's much better than symlinking
<adrien>
(well, as far as I'm concerned, I've copied files on windows, including .o and .a files directly to ocamlbuild's _build/ folder...)
<hcarty>
thelema: I use verify_arg quite often. I only use verify in a few places, so if it went away I wouldn't be horribly upset.
<everyonemines>
thelema: What are the advantages from your pov?
<hcarty>
thelema: That said, I have found "verify ...;" to be more quickld readable than "if expr then raise ...;"
<thelema>
everyonemines: mostly on the packaging side - consistent installation and removal of packages, although the automatic dependency handling is a very nice one.
<hcarty>
s/quickld/quickly/
testcocoon has quit [Quit: Coyote finally caught me]
<everyonemines>
thelema: ah, I've only sent executables to other people.
<everyonemines>
hcarty: Not everyone will agree with you there.
<thelema>
hcarty: it gets brevity points, but for me loses on clarity - if/then raise is quite clear, verify could do anything.
<everyonemines>
what he said
<everyonemines>
^^^
<thelema>
but it does make good semantic sense, and reads pretty well, and the reader can guess easily what it does
<everyonemines>
experience has got me to not trust functions do what you think their name means :-(
<hcarty>
everyonemines, thelema: That's true. Like I said, if it went away I wouldn't miss it too much. I wrote it originally to act as a more general form of verify_arg;
<hcarty>
verify_arg came first, then the more general verify
<everyonemines>
Why not just use "assert" ?
<hcarty>
assert <> invalid_arg
Anarchos has quit [K-Lined]
<hcarty>
everyonemines: Primarily for readability and ease of deducing the intent of code.
<everyonemines>
?? assert is a inter-language standard for that
<hcarty>
everyonemines: As you said, that's not always safe when reading function names. But once you know/trust some code it helps.
<hcarty>
Assertions go away if they are disabled. Raising Invalid_argument does not go away.
<everyonemines>
That's why assert false is a special case.
<hcarty>
Raising Invalid_argument is also something of a language and library standard. It makes it clear that the arguments provided are not valid.
<everyonemines>
right...
<hcarty>
I think of assertions as being more useful for catching local logical errors
<hcarty>
Rather than logical errors on the part of the caller
<hcarty>
That may be inconsisten with how other people perceive them
<hcarty>
inconsistent. I can't type the last letter of words properly today.
<thelema>
yes, invalid_arg is usually better for preconditions, Failure / assert for internal failures
<hcarty>
thelema: Well put
everyonemines has quit [Quit: Leaving.]
testcocoon has joined #ocaml
sebz has quit [Quit: Computer has gone to sleep.]
lamawithonel_ has quit [Remote host closed the connection]
sebz has joined #ocaml
sebz has quit [Client Quit]
sebz has joined #ocaml
sebz has quit [Client Quit]
<hcarty>
thelema: Should operators in BatFoo.Infix be included in BatFoo?
<hcarty>
thelema: Also - is BatFoo.Infix the proper submodule naming scheme?
<thelema>
yes, BatFoo.Infix should be included in BatFoo
<hcarty>
thelema: Would unless be more useful if it took an optional list of exceptions to ignore?
<hcarty>
Or perhaps a list of exceptions to propagate
<hcarty>
That could be a separate function - Option.wrap_exn : ('a -> 'b) -> 'a -> 'b option. Option.wrap_exn f x returns None if (f x) raises an exception.
testcocoon has quit [Quit: Coyote finally caught me]
testcocoon has joined #ocaml
<thelema>
float -> float
<thelema>
although we could also hav a rounding to_int
testcocoon has quit [Client Quit]
testcocoon has joined #ocaml
testcocoon has quit [Client Quit]
testcocoon has joined #ocaml
testcocoon has quit [Client Quit]
testcocoon has joined #ocaml
<hcarty>
I have "let round_to ~precision x = ...". How would you like to handle those two arguments?
testcocoon has quit [Client Quit]
<hcarty>
That function may be a bit fragile in its current state
testcocoon has joined #ocaml
testcocoon has quit [Client Quit]
testcocoon has joined #ocaml
<thelema>
what about the arguments?
<hcarty>
Named or not, and the best order if they are not named.
<thelema>
named, I think
<hcarty>
And how should the precision be specified. It could be used as "round_to ~precision:0.1 0.555" or it could be "round_to ~precision:~-1 0.555"
<thelema>
as is.
<thelema>
I thought about giving the log10 exponent, but it doesn't read as well
<thelema>
although it does eliminate the question of ~precision:0.33
<hcarty>
That's the fragile part :-)
<thelema>
I'd test for power of 10, but ... floats...
testcocoon has quit [Quit: Coyote finally caught me]
testcocoon has joined #ocaml
testcocoon has quit [Client Quit]
testcocoon has joined #ocaml
raichoo has quit [Quit: leaving]
<hcarty>
thelema: Indeed. I'm off for a bit, we can pick this up later if you are around.
JdpB42 has joined #ocaml
Snark has joined #ocaml
Drakken has joined #ocaml
fschwidom has quit [Ping timeout: 244 seconds]
fschwidom has joined #ocaml
mcclurmc has quit [Read error: Connection reset by peer]
mcclurmc has joined #ocaml
sepp2k has quit [Read error: Connection reset by peer]
dnolen has joined #ocaml
sepp2k has joined #ocaml
thelema has quit [Remote host closed the connection]
avsm1 has joined #ocaml
avsm has quit [Read error: Connection reset by peer]
Sysop_fb has joined #ocaml
sebz has joined #ocaml
<samposm>
compiling to library objects has surprisingly many steps :-/
<adrien>
"ocamlbuild foo.cma foo.cmxa" <- done :P
<samposm>
I mean, when some C is involved
<adrien>
use oasis or OCamlMakefile
<adrien>
although ocamlmklib should make it much shorter already (both of the tools I've mentionned will use ocamlmklib actually)
<samposm>
is there difference between ocamlmklib and ocamlopt -a ?
<adrien>
ocamlmklib will take care of C stuff (better)
<adrien>
a few days ago, I used ocamlopt -a instead of ocamlmklib for C bindings and I got a number of undefined refs iirc
<adrien>
ocamlmklib is actually a thin wrapper around a few other tools
<adrien>
but it makes it easier to handle bindings
<samposm>
hmm, ocamlmklib generates a .so but I guess I should want a .cmxa, right?
<adrien>
you want a .so for bytecode
<adrien>
rather
<adrien>
you want a .so and a .cma
<samposm>
so I need both?
<adrien>
for native code, you get a .a and a .cmxa iirc (it's been a quite long time I've done it by hand instead of relying on tools to help me with this)
<samposm>
as far as I understand, for linking when generating netive code, I'd need a .cmxa(?)
<samposm>
and then I need somethins elde for the use with repl?
<samposm>
else*
<adrien>
for native code, you need to specify a .cmxa or .cmx file(s) but it'll also use other files which are pulled in automatically, like .a files
<adrien>
for bytecode (which is what is used for the repl), you have .cma files
<adrien>
or .cmo
<adrien>
cmxa and cma are libraries while cmx and cmo are object files ; like .a and .o for C
<sgnb>
samposm: dll*.so -> loaded by the bytecode runtime
<samposm>
yes, have, but very thoroughly
<samposm>
but not*
<sgnb>
lib*.a -> to make native or custom executables
<sgnb>
%.{a,cmxa} -> native lib for ocaml code
<sgnb>
%.cma -> bytecode lib for ocaml code
<sgnb>
dll%.so and lib%.a contain the C code
sebz has quit [Quit: Computer has gone to sleep.]
<samposm>
so, for native code, the .cmxa file alone alone is not sufficient, but it need some other file to accompany it, which contains the C parts?
<sgnb>
the .cmxa contains OCaml meta-data
<sgnb>
and it should always be accompanied by a .a file that contains the code that is fed to ld
<sgnb>
(compiled OCaml code)
<samposm>
so out.cmxa and out.a contain the ocaml parts of my library, and libout.a contains the C parts?
<sgnb>
yes
<samposm>
and all these three are needed for further native code work?
<sgnb>
indeed
<samposm>
ok, thank you
<samposm>
and out.cma contains the bytecode for the ocaml part of my library, and this needs what, only the dllout.so(?) for further bytecode work?
<adrien>
samposm: also, watch out: ocamlmklib might overrid some files depending on what you give for -o; that's why people generally prepend something like "_stubs"
sebz has joined #ocaml
<sgnb>
dllout.so is needed by pure bytecode executables
<sgnb>
but you'll need libout.a if you link a bytecode executable using -custom
<samposm>
hmm, actually when I run ocamlmklib (like I said above), it outputs *nine* files
<sgnb>
a.{cmi,cmo,o,cmx}, I guess
<samposm>
yes
<samposm>
so those four are not needed anymore?
<sgnb>
a.cmi is needed if you want to use module A elsewhere
sebz has quit [Quit: Computer has gone to sleep.]
<sgnb>
and a.cmx is then useful, too
<sgnb>
a.{cmo,o} a probably not useful anymore
<sgnb>
a.cmi is a compiled interface (used by bytecode and native)
<sgnb>
a.cmx is another kind of compiled interface, used only by native
<samposm>
so, when people write libraries for others to use, which files they make the makefile to generate?
<samposm>
all the 9, or almost 9 files, just to let others to use a library?