<thelema>
yup, this is the trouble with polymorphic variants too - it's too easy to make new types up accidentally, and the ocaml type system doesn't tell you where the new type was created.
<thelema>
which is why most languages require explicit typing of everything, so you can't accidentally make up new types. Or you get a runtime error where the wrong type/call is being used which tells you where the mismatch is.
<mrvn>
The disturbing thing is that the bad type is not listed in the error
<mrvn>
Why doesn't is say "the first has no method named get_wigets_at" or something?
jeddhaberstro has quit [Quit: jeddhaberstro]
_unK has quit [Remote host closed the connection]
ccasin has joined #ocaml
ccasin has quit [Quit: Leaving]
enthymeme has joined #ocaml
oc13 has joined #ocaml
Shoggoth has joined #ocaml
ttamttam has joined #ocaml
ygrek_ has joined #ocaml
ftrvxmtrx has quit [Quit: Leaving]
Yoric has joined #ocaml
enthymeme has quit [Quit: rcirc on GNU Emacs 23.1.1]
waterChip has joined #ocaml
Yoric has quit [Quit: Yoric]
Associat0r has joined #ocaml
spearalot has joined #ocaml
ftrvxmtrx has joined #ocaml
ftrvxmtrx_ has joined #ocaml
ftrvxmtrx has quit [Ping timeout: 252 seconds]
waterChip has quit [Quit: waterChip]
ftrvxmtrx_ is now known as ftrvxmtrx
Jedai has quit [Quit: KVIrc Insomnia 4.0.0, revision: 3900, sources date: 20100125, built on: 2010-02-15 08:27:55 UTC 3900 http://www.kvirc.net/]
ygrek_ has quit [Ping timeout: 245 seconds]
Associat0r has quit [Ping timeout: 265 seconds]
Yoric has joined #ocaml
ygrek_ has joined #ocaml
<gildor>
thelema: "thelema> derdon: as far as I can tell, OASIS is for people who write ocaml libraries to integrate into the distribution of their library."
<gildor>
thelema: not exactly, basically OASIS helps you generate a build system (i.e. ocamlbuild + autoconf like system) and has been designed to allow easy distribution of the resulting library/software (eg. through Debian or GODI)
<gildor>
thelema: the distribution side is only a consequence
<gildor>
thelema: I am working on v0.2.0 which corrects things reported during OCaml Hacking day
Associat0r has joined #ocaml
<Yoric>
hi
<gildor>
Yoric: hi
avsm has joined #ocaml
Jedai has joined #ocaml
munga has joined #ocaml
Yoric has quit [Read error: Connection reset by peer]
Yoric has joined #ocaml
ulfdoz_ has quit [Quit: Reconnecting]
ulfdoz has joined #ocaml
avsm has quit [Quit: Leaving.]
ztfw has joined #ocaml
spearalot has quit [Quit: Computer has gone to sleep]
Associat0r has quit [Quit: Associat0r]
ikaros has joined #ocaml
avsm has joined #ocaml
spearalot has joined #ocaml
leino has joined #ocaml
jonludlam has left #ocaml []
slash_ has joined #ocaml
sepp2k has joined #ocaml
munga has quit [Ping timeout: 264 seconds]
schmx has quit [Ping timeout: 276 seconds]
schmx has joined #ocaml
mrvn has quit [*.net *.split]
kg4qxk has quit [*.net *.split]
jimmyb2187 has quit [*.net *.split]
svenl has quit [*.net *.split]
thomasga has quit [*.net *.split]
nejimban has quit [*.net *.split]
mrvn has joined #ocaml
kg4qxk has joined #ocaml
jimmyb2187 has joined #ocaml
svenl has joined #ocaml
thomasga has joined #ocaml
nejimban has joined #ocaml
oriba has joined #ocaml
drk-sd has quit [Ping timeout: 245 seconds]
drk-sd has joined #ocaml
Shoggoth has quit [Read error: Connection reset by peer]
mutewit has joined #ocaml
Yoric_ has joined #ocaml
Yoric has quit [Read error: Connection reset by peer]
Yoric_ is now known as Yoric
th0br0 has joined #ocaml
<th0br0>
Hello. Is it possible to call c from ocaml / ocaml from c without actually linking them but somehow executing the bytecode later on from c? (c is the main application here)
<mrvn>
you can probably link in and call the toplevel
<mrvn>
And you can call C from bytecode. Not sure about how to go the other way around.
<th0br0>
I know how to go the other way round.
<th0br0>
I'm only wondering whether I can skip the linking part but load them dynamically.
<mrvn>
That is what the toplevel does when you use something with C stubs
<mrvn>
or any bytecode
avsm has quit [Quit: Leaving.]
<th0br0>
mh ok, is there any tutorial on it?
<mrvn>
the manual or any packaged library
<th0br0>
ok
<mrvn>
Never given it any though. It just works[tm].
<th0br0>
:)
<th0br0>
Thanks for the help
Yoric has quit [Read error: Connection reset by peer]
Yoric has joined #ocaml
<th0br0>
well, I guess one solution would be to write up some minor ocaml interface which uses Dynlink and call that from c where needed for loading the various bytecode files and later on calling the newly loaded stuff from c
<mfp>
sdschulze: OCaml's GC is already good at quick allocation and prevents fragmentation
<gildor>
sdschulze: why because they are allocating too much ?
<mfp>
the reason why OCaml is relatively slow there is the small default size of the minor and major heaps
<mfp>
compare to GHC's binary trees, which is run with +RTS -H300M -RTS (major heap set to 300 MB)
<mfp>
and then notice how the line that sets the minor heap size in the OCaml solution was commented out by the admin > (* Gc.set { (Gc.get()) with Gc.minor_heap_size = 1024 * 1024; max_overhead = -1; }; *)
<mfp>
dunno why GHC can get away with that: preventing any heap resizing in an allocation benchmark (!)
<adrien>
mfp: official reason is that, gasp, forgotten, but it's how it's set: at compile-time, or at runtime
<mfp>
it could be set at runtime in OCaml site OCAMLRUNPARAM=... too
<mfp>
and in the JVM and most impls I'd assume
<th0br0>
uhm, Dynlink is not available on windows, right?
<adrien>
mfp: I think that one could work but I haven't asked
<sdschulze>
mfp: I noticed -- I was able to speed up the example by 4 using GC tuning.
<mfp>
th0br0: IIRC it's only available for some(?) ports (there's mingw, cygwin and msvc)
<th0br0>
thanks, mfp. We'll, I don't want to go with !msvc so I guess I'll have to thing of some other way.
<mfp>
th0br0: I think it might be actually available w/ msvc in fact. I remember a bug about flexdll linking against some dll included in the msvc devel env. but not in a base windows install
* mfp
looks for it
<th0br0>
mfp: mh, I can't find the dynlib library on windows; or how was this solved here?
<sdschulze>
mfp: No doubt that OCaml's GC is really good, but GC'ing is always expensive (*unless* you tolerate a very large heap, of course).
<adrien>
re-reading things, ghc shouldn't be able to change its default heap size
<adrien>
... BUT
<adrien>
I don't even remotely feel like hearing haskell fanboys complain
<adrien>
"For many language implementations the binary-trees programs are all about GC and GC work can be evaded by setting a larger initial heap, hinting that the heap will be in some size range, controlling when GC happens etc We've taken an arbitrary approach - just default settings for all language implementations. Maybe there's a better (rather than different arbitrary) approach? Nothing persuasive has been suggested yet."
<mfp>
th0br0: http://caml.inria.fr/mantis/view.php?id=5014 "I confirm that executables produced by ocamlopt >= 3.11, MSVC port, are linked against the dynamic C runtime library (msvcr80.dll or msvcr90.dll). This is needed to support dynamic linking..."
<mfp>
suggests that dynamic linking _is_ available in the MSVC port
<th0br0>
mfp: just taking a look, i can find the dynlink.mli lib
<th0br0>
sorry :D
<th0br0>
it's just that it's only present as dynlink.mli
<th0br0>
which the shell didn't show in Open
Guest60603 has joined #ocaml
<mfp>
adrien: my feeling is that they're willing to use about any trick to make GHC's figures look good
<th0br0>
yep, mfp, it's working fine here, too.
<adrien>
mfp: agreed, a heap of 300M is a kind of optimizations you'll only see in benchmarks, at least ocaml's 1MB or 2MB sound better
<adrien>
mfp: but I'm already having nightmares at the thread that would be started if the shootout removed -H300M from ghc's command-line, at least it looks like some can manage to get pissy with a very high performance...
<mfp>
I fact, I think I already posted on the forum about that very issue
<adrien>
yeah, I remember that, but really the rules are there and are not completely ill-founded, and it should be ghc which is changed, not ocaml (I probably wouldn't mind ocaml use a bigger minor heap by default on 64bit though)
<flux>
doesn't that -H300M however appear in the memory measurements, though?
<sdschulze>
One problem about the OCaml benchmark is that it fork()s quite heavily.
ftrvxmtrx has quit [Quit: Leaving]
sdschulz` has joined #ocaml
sdschulze has quit [Ping timeout: 265 seconds]
_unK has joined #ocaml
sdschulz` has left #ocaml []
sdschulze has joined #ocaml
<sdschulze>
Hm, so I could relatively easily implement pools as custom objects, but the problem is that they would be using off-heap memory.
<sdschulze>
Can I tell the GC: "Hey, this apparently small object actually holds 100 MB of data"?
elehack has joined #ocaml
<flux>
yes
<flux>
when allocating it
<flux>
I cannot see how to do that purely in ocaml, though
<sdschulze>
but how?
<sdschulze>
By using `used' and `max', I set up my own heuristics, rather than using OCaml's.
<adrien>
ancient?
_unK has quit [Read error: Connection reset by peer]
elehack has quit [Ping timeout: 265 seconds]
leino has quit [Remote host closed the connection]
elehack has joined #ocaml
elehack has left #ocaml []
elehack has joined #ocaml
boscop_ has quit [Ping timeout: 265 seconds]
boscop_ has joined #ocaml
slash_ has quit [Quit: leaving]
slash_ has joined #ocaml
<th0br0>
mh, any ideas here? I've got a c program up and running which links against an ocaml obj (.so) file. now in this .so file I dynlink a plugin. however, this fails due to unresolved symbols. if i call the .so file (ofc, differently compiled) directly, however, it works fine. any ideas here?
ftrvxmtrx has joined #ocaml
albacker has joined #ocaml
<th0br0>
oh, I'm using native code
<th0br0>
and furthermore, do I see this correctly?
<th0br0>
say I've got a class in ocaml. now i want to call a method of it via c. Can I do this with caml_callback(caml_get_public_method(obj, caml_hash_variant(name)), obj) ?
ygrek_ has quit [Remote host closed the connection]
ygrek_ has joined #ocaml
gl has joined #ocaml
<gl>
hello
Yoric has quit [Quit: Yoric]
neorab has joined #ocaml
mutewit has left #ocaml []
joewilliams_away is now known as joewilliams
joewilliams is now known as joewilliams_away
derdon has joined #ocaml
jonafan_ has joined #ocaml
jonafan has quit [Ping timeout: 245 seconds]
<th0br0>
Right, so the problem seems to occur regardless of how I try to link the appliation... if I call Dynlink via c (c -> ocaml function -> dynlink.loadfile) it fails with unresolved symbols ...
<th0br0>
any idea there?
fschwidom has quit [Remote host closed the connection]
<th0br0>
ofc, when I don't call any other library it works out just fine but that's not really my favourite choice
<hcarty>
th0br0: Are the outside libraries being linked properly? (For some definition of "properly" that I don't know...)
<th0br0>
well, I'd guess so... I mean, when I take a look at the symbols of the c application, I do find those that dynlink fails to resolve.
<th0br0>
that's the output and the way I'm building the files
<th0br0>
my goal is to be able to freely exchange the ocaml library
<th0br0>
without recompiling the c application
sepp2k has quit [Quit: Leaving.]
<th0br0>
that's why i am using dynlink there
ftrvxmtrx has quit [Quit: Leaving]
ttamttam has joined #ocaml
bacam has quit [Ping timeout: 240 seconds]
gl has left #ocaml []
ulfdoz has quit [Ping timeout: 258 seconds]
joewilliams_away is now known as joewilliams
ftrvxmtrx has joined #ocaml
<hcarty>
Does anyone here have an OCaml-friendly .emacs file handy? I would like to take a look at the new Tuareg release and haven't used emacs in a long time
<hcarty>
mehdid: I did, but didn't find anything beyond the default/example .emacs lines included in the distribution
<hcarty>
Which I see is what you have in your file :-)
<derdon>
debugging *.mly files can be hard :S
<hcarty>
I've used vim for a long time, and wanted to give emacs another shot
<derdon>
hcarty: I gave emacs already 3 shots :D
<derdon>
sil ldevelopping with vim
<ulfdoz>
And it is still alive.
<derdon>
*still
<derdon>
ulfdoz: yes, damn emacs! :P
<hcarty>
derdon: I'm pretty happy with vim + OCaml in general. There are some indentation things I wish it would handle better, but it does well enough
<hcarty>
derdon: Still, learning new tools can be useful even if they aren't kept around
<derdon>
hcarty: said more detailed, I am developping with PIDA with vim as the editor