<Alpounet>
but actually, you should be able to do it too
<Alpounet>
gildor, I think the channel isn't registered anymore. Or someone has given me the rights without telling me... The former is more likely to be true.
BigJ2 has joined #ocaml
<BigJ2>
can anyone tell me the shortcut to start the ocaml top level in emacs?
jonafan_ has joined #ocaml
<jules>
M-x run-caml
<jules>
or just evaluate something (C-x C-e) and emacs will ask you if you want to start a toplevel (assuming you're using tuareg mode)
<BigJ2>
jules: thanks
<BigJ2>
it's a lot easier running them both to check code
tmaedaZ is now known as tmaedaZ0
<gildor>
Alpounet: thanks
jonafan has quit [Connection timed out]
tmaedaZ0 is now known as tmaeda
h3r3tic has quit [Read error: 104 (Connection reset by peer)]
h3r3tic has joined #ocaml
<Camarade_Tux>
='(
verte has quit ["~~~ Crash in JIT!"]
hyperboreean has quit [Read error: 110 (Connection timed out)]
hyperboreean has joined #ocaml
seanmcl has quit []
nimred has quit ["leaving"]
nimred has joined #ocaml
seanmcl has joined #ocaml
nimred has quit [Remote closed the connection]
<kaustuv_>
ocamlbuild is unmaintained?
<kaustuv_>
(seen on caml-list)
<Camarade_Tux>
"(unofficially)"
BigJ2 has quit []
<Camarade_Tux>
but it's a bit hard to believe ocamlbuild would be unmaintained, it's the build system for ocaml now, I mean ocaml as the one downloaded on caml.inria.fr
<Camarade_Tux>
(ocaml-gir update btw, progressing and can now bind functions using out-parameters too, was testing on dbus-glib but there is a problem I really don't understand [ at least right now ])
<kaustuv_>
I don't believe (but could be wrong) they've officially decided to switch from Makefiles to ocamlbuild yet. They're just maintaining two parallel build systems for OCaml.
<Camarade_Tux>
well, when I run "make" in ocaml source, I clearly see ocamlbuild running (I think it's a mix of ocamlbuild and make)
<kaustuv_>
I think that's only used for ocamlbuild and camlp4, not for the rest
<Camarade_Tux>
hmmm, actually it may be hard to have ocamlbuild running while ocaml isn't available yet...
<Camarade_Tux>
I just saw some use of ocamlbuild during "make opt"
<Camarade_Tux>
not sure actually but I'm too tired, I'd better just slack off now :)
jonafan_ is now known as jonafan
* thelema
wonders how much trouble he'll get into by extending ocamlbuild
<thelema>
would it be sufficient for ocamlbuild to have an ocamlbuild.d that it looked in for extensions?
munga has quit [Remote closed the connection]
<thelema>
i.e. a bunch of myocamlbuild.ml files, one for each project wanting to add tags?
<flux>
ocambuild.d/hookname/filesthatareconcatenatedtogether.ml ? (I don't know much of ocamlbuild)
<flux>
(a smart system similar to ocamlfind with predicates would be cool)
<thelema>
I worry a bit about compiling all of them each time, but I expect that's not a big deal - once per project
<flux>
I've noticed that I can't simply concatenate myocamlbuild.ml-files and expect it to work
<thelema>
yes, they'd all have to be compiled separately and included in sequence (dynlink?)
<flux>
how is it that different from concatenating?
<kaustuv_>
everyone keeps telling me to just use omake, but if that is also as moribund as ocamlbuild then I'd rather bite the bullet and write a vanilla makefile
<gildor>
kaustuv_: ocamlbuild works in most situation
<thelema>
flux: ... hmm, what specifically is the problem when you concatenate?
<thelema>
I use a makefile to call ocamlbuild properly
<gildor>
kaustuv_: it is not paritcularly moribund
<flux>
thelema, I don't remember, but the gist of the problem was that I had a file that did let _ = dispatch ( .. | After_rules -> .. flag [...]) stuff and I needed to add some additional flags
<flux>
thelema, I needed to manually integrate the dispatch code inside that dispatch, instead of adding another call to dispatch
<flux>
didn't really research why :)
<thelema>
ah, you only get one dispatch... so a minor modification - ocamlbuild.d/*.ml need to provide two functions: [before_options] and [after_rules]
<thelema>
and the modified ocamlbuild would merge these all together into a single dispatch
<gildor>
thelema: or you have the solution adopted by ocaml-autobuild
<gildor>
each ocamlbuild.d/*.ml ship a file containing a single module (to allow concatenation without problem)
* thelema
wants something which just uses _tags, and drops the merging
<thelema>
if you can dynlink the single file, you can dynlink multiple modules and build the proper dispatch function, no?
<kaustuv_>
_tags always struck me as a bad idea because I like to keep my build instructions in one single place
<kaustuv_>
also they are a bitch to debug
<thelema>
kaustuv_: what's the other place from _tags?
<kaustuv_>
there's myocamlbuild.ml, _tags, *.mlpack, *.mllib, etc., etc.
* thelema
plans to remove myocamlbuild from the picture by making it site-local
<thelema>
as to *.mlpack, *.mllib... these don't seem too unreasonable to me
<thelema>
simple text files saying what modules to pack together into the library...
<thelema>
flux: actually, I don't see any problem with multiple calls to dispatch...
<thelema>
flux: (according to the docs, at least)
<kaustuv_>
thelema: I guess I have been spoilt using mlb from standard ml, because ocaml's build system(s) seem like such a hack in comparison
<thelema>
kaustuv_: can you give a 15 second summary of mlb?
<thelema>
flux: ah, but the implementation doesn't allow multiple calls to dispatch - later ones override earlier ones.
<kaustuv_>
It's basically let ... in for compilation units + a small amount of magic to deal with compiler flags
<thelema>
flux: It'd not be difficult to modify this to have ocamlbuild merge dispatch functions instead of overwriting
_unK has joined #ocaml
<thelema>
kaustuv_: I believe that as many compiler flags as possible should be in the start of the source code.
<thelema>
kaustuv_: sml just lets you do [let ... in] to both open a module and have the compiler include that module at compile time?
<kaustuv_>
thelema: SML allows local scoping for modules in compilation units, yes, but MLB is a bit more general than SML's module system. You can think of it as a way of specifying how modules are assembled together using high level constructs. In SML module names and file names are not synchronized, so you have to give a little more instruction (i.e., where to find the files).
<thelema>
kaustuv_: ok, so you give filenames for where to find modules (in the source code, I assume), and then you say "mlb_build foo" and it goes and finds all the dependencies, compiles them, and then compiles foo?
<kaustuv_>
thelema: No, there's no magic spidering of the source tree like ocamlbuild.
<kaustuv_>
It's anyway a matter of taste how magical you want your build systems to be.
<gildor>
thelema, kaustuv_: sorry telephone call
<gildor>
thelema, kaustuv_: ocaml-autobuild include multiple module in myocamlbuild.ml
<gildor>
each have their own dispatch
<gildor>
and produce a function that just call each dispatch in turn
<gildor>
but basically the problem of ocamlbuild is that it compiles myocamlbuild.ml
<thelema>
gildor: how is this a problem?
<gildor>
ideally myocamlbuild.ml should be a ml script that use "# load"
<thelema>
kaustuv_: so you use a Makefile to build in sml?
<gildor>
thelema: this is a problem because it is a sort of bootstraping the compilation problem
<gildor>
you begin by trying to compile the compile program
<gildor>
if it was a simple ml script, without compilation, it will be easier
<gildor>
(no first compilation)
* thelema
wouldn't mind explicit "require ModuleFoo" statements at the beginning of source files
<thelema>
yes, batteries has to deal with this as it can't use its own functions in the myocamlbuild without copy/paste
<gildor>
with a simple ml script you can even do "#use "topfind";; #require "pkg";;" which will be very powerful
<thelema>
but this doesn't seem a big problem for the average project
* thelema
still thinks there's just one problem - ocamlbuild overwriting previous [dispatch]es
<thelema>
by solving that problem, you allow multiple myocamlbuild files (or concatenation), and allow projects to "include" their own myocamlbuild file
<thelema>
the benefit from not compiling the myocamlbuild file is... being able to use non-stdlib modules in it?
<gildor>
thelema: you can also use the "#load" directive to include your own module
<gildor>
thelema: there is more than one benefits
<gildor>
benefit
<thelema>
which helps people write myocamlbuild files easier, but I really think that should only be the job of library authors
<thelema>
and the average person should *not* write ocamlbuild plugins
<gildor>
if you can "#use "topfind";;" you can even load pre-compiled external modules written by other and managed through findlib
<gildor>
thelema: but you cannot do it when compiling
<thelema>
what do you need other modules for in your myocamlbuild plugin?
<gildor>
example: ocamlify create a rules to transform .mlify -> .ml
<gildor>
I don't want to copy and paste this in every project
<gildor>
#require "ocamlify.ocamlbuild";; should be enough
<gildor>
(it loads the plugin explaining .mlify -> .ml and register its dispatch function)
<thelema>
instead put it in ocamlbuild.d/ocamlify.ml, and let ocamlbuild include it for every project (activated by tags)
<thelema>
or activated by whatever
<gildor>
thelema: this is another solution
<thelema>
I think mine is much simpler
<thelema>
I could probably implement it in an hour or so of hacking on ocamlbuild
<thelema>
"create ocaml source code by including a whole file into ocaml string or string list"? i.e. mapping a file containing "foo\nbar\n" into "let data = ["foo"; "bar"]"?
<gildor>
thelema: this is the description of ocamily, i think
<gildor>
thelema: this is a very basic tools
mishok13 has quit [Read error: 110 (Connection timed out)]
marmottine has joined #ocaml
<ttamttam>
Hello
<ttamttam>
Just reading the last exchanges... where is this ocamlbuild.d/ you are speaking about?
<ttamttam>
And how is used?
<ttamttam>
s/And how is used?/And how is it used?/
smimou has joined #ocaml
Snark has joined #ocaml
<ttamttam>
Sorry… leaving
ttamttam has quit ["Leaving."]
<gildor>
thelema: I propose something similar to your solution to N. Pouillard at first OCaml Meeting, and he answer me that he prefer exploring multiple plugin using dynamic loading, especially with native dynlink
<gildor>
thelema: thelema: but I agree that is probably the most simple solution
<thelema>
gildor: on platforms with dynamic loading, libraries could provide pre-compiled ocamlbuild plugins that would be loaded
<thelema>
I just hope no priority system is needed to load them in the right order.
<thelema>
it'd probably suffice to load them in alphabetical order, and use the init-style priority system if it were needed.
<gildor>
I will probably implement the myocamlbuild.d solution in ocaml-autobuild
<thelema>
do you think it futile to send n. pouillard patches?
<gildor>
(the concatenation will be done once, when creating myocamlbuild.ml)
<gildor>
for the concatenation stuff ?
<gildor>
patches for the concatenation stuff ?
<thelema>
concatenation or dyn-loading - either way to have a system-wide ocamlbuild.d/
<gildor>
thelema: as I said, I think 2 years ago he was not interested by the concatenation stuff
<gildor>
thelema: I think a dyn-loading solution will draw his interest
<thelema>
so a patch that did dynloading of ocamlbuild.d
<thelema>
grr. I'll have to learn how dynloading works now...
<gildor>
thelema: but you can try providing a more simple concatenate patch
* thelema
will probably create the solution in stages
<gildor>
thelema: begin with myocamlbuild.d, this is a simple and clean solution
* thelema
also wants to patch out all uses of bash in ocmalbuild - it shouldn't require a command prompt
<thelema>
but that's later
<gildor>
thelema: I will vote +10 to removing various invocation of useless bash command
<gildor>
to -> for
<thelema>
:)
<gildor>
(and another +10 if your perform removing Unix module from ocamlbuild)
<thelema>
that second one will likely be tricky
<gildor>
ok +100 then ;-)
<thelema>
yes, +100 is needed. :)
Alpounet has quit ["Leaving"]
h3 has joined #ocaml
h3r3tic has quit [Read error: 104 (Connection reset by peer)]
onigiri has joined #ocaml
kaustuv_` has joined #ocaml
ozzloy_ has joined #ocaml
ozzloy has quit [Remote closed the connection]
ttamttam has joined #ocaml
BigJ2 has joined #ocaml
BigJ2 has quit [Client Quit]
julm_ has joined #ocaml
<Camarade_Tux>
can anyone sum up what has been said? I got disconnected and now the length of the backlog really scares me :P
morse has quit [Remote closed the connection]
lutter has quit ["Leaving."]
ulfdoz has joined #ocaml
onigiri has quit []
<thelema>
Camarade_Tux: "It'd be really nice if ocamlbuild used an ocmalbuild.d/ to store site-wide myocmalbuild.ml files
kaustuv_ has quit [Read error: 110 (Connection timed out)]
robocop has joined #ocaml
julm has quit [Read error: 110 (Connection timed out)]
marmottine has quit ["mv marmotine Laurie"]
nimred has joined #ocaml
tmaeda has quit [Read error: 60 (Operation timed out)]
tmaeda has joined #ocaml
tmaeda is now known as tmaedaZ
<flux>
that's great in principle, but I'm not sure if it helps redistribution of packages
<flux>
if you personally choose to use them, you could always symlink stuff in?
<thelema>
what's the problem with packages putting myocamlbuild plugins into a site-wise directory?
<thelema>
*site-wide
<flux>
so in addition to 'real' dependencies you need to install system-wide packages to compile stuff?
<flux>
..or alternatively hunt the .ml-file somewhere else to put to your ocamlbuild.d directory
peddie has quit [Read error: 110 (Connection timed out)]
<thelema>
I don't understand the distinction between 'real' dependencies and non-real dependencies
<thelema>
the ocamlbuild plugin would be part of what gets installed when you install a package
<thelema>
you're worrying about the transition - right now packages don't provide this, right?
<flux>
well, say there was a module for ocamlfind
<flux>
I can compile stuff fine, because I have /etc/ocamlbuild.d/ocamlfind.ml
<thelema>
sure.
<flux>
then when the source is passed to someone else, he might not be able to compile it, even though he has ocamlfind
<thelema>
probably /usr/lib/ocaml/ocamlbuild.d, but wherever
<flux>
but the problem would easily be fixed if I just put a copy of ocamlfind.ml to go
<thelema>
if he has a new enough version of ocamlfind installed, he'll have the same ocamlfind.ml plugin
<thelema>
of course you could include in your project all the ocamlbuild plugins needed for your project, but that's equivalent to including a myocamlbuild.ml file
<flux>
I suppose I'm just thinking situations when the main package doesn't have its own ocamlbuild support
<thelema>
I want to obselete myocamlbuild.ml as much as possible
<flux>
in principle it's the same situation as it is with ocamlfind, except META-files have actually found their way into packages
<thelema>
when the main package doesn't have ocamlbuild support, most likely it'll be installed with ocamlfind, which will have ocamlbuild support enough to use that package.
<flux>
how would the user know which ocamlbuild.d-file he is missing during the build?
seanmcl has quit []
<thelema>
we only have to get ocamlfind to use the ocamlbuild.d directory, and most projects will automatically have support.
<thelema>
he'd get the same errors as if he were missing the library itself.
<flux>
so the package itself would have explicitly listed the ocamlbuild.d-files it needs for the compilation to succeed?
<flux>
(because if so, I think it's better than implicitly just using all of them)
<thelema>
no, without the needed ocamlbuild.d file, it'd be unable to find that library, and ocaml would give "cannot find xxx" error
<thelema>
I'm in the "use all of them implicitly" camp at the moment
<flux>
so libraries and ocamlbuild-files go hand-to-hand?
<flux>
is it conceivable there'd be a ocamlbuild-file without a package to go?
<thelema>
what would it do?
<flux>
say, an extension for helping to integrate c-libraries somehow
<flux>
or if ocamlbuild lacked some new ocaml building feature, an extension could address that
<thelema>
would it be an external dependency of other packages?
<flux>
no
<flux>
doesn't ocamlfind itself go into this category?
<thelema>
ocamlfind is an external dependency of other packages, and gets installed before the other packages.
<flux>
all packages depend on ocamlfind?
<flux>
I don't think that's true for, say, debian?
<thelema>
all packages that use it for installation, yes.
<thelema>
I guess it'd be possible to install them and use them without ocamlfind
<flux>
which distribution other than godi uses ocamlfind for installation?
<thelema>
I'll check, but I think all my ocaml libraries depend on ocamlfind
<thelema>
yes, there's a whole ton of packages that depend on ocaml-findlib
<thelema>
libocamlnet, libsexplib, even oscigen
<flux>
I wonder why? don't they work just fine without ocamlfind?
<thelema>
they could, I suppose, but they're designed to use ocamlfind
<flux>
yet there is a group of people who don't, for whatever reason :)
<thelema>
there is.
blackdog_ has joined #ocaml
tmaedaZ has quit [Read error: 110 (Connection timed out)]
ozzloy_ is now known as ozzloy
Submarine has joined #ocaml
Snark has quit ["Ex-Chat"]
aggiejy has joined #ocaml
aggiejy has left #ocaml []
<Camarade_Tux>
thelema: thanks :)
<thelema>
for working on this? I haven't started...
* Camarade_Tux
wishes he had a real internet connection
<thelema>
oh, for the summary.
<Camarade_Tux>
it's raining outside... (yes, that's probably the reason I'm being disconnected)
<Camarade_Tux>
thelema: he ;p
<thelema>
that was an hour and a half ago - talk about lag.
<Camarade_Tux>
I'm almost giving up trying to connect to the internet (I really hate wifi)
<thelema>
outside rain affects your indoor wifi?
seanmcl has joined #ocaml
eldragon has joined #ocaml
<Camarade_Tux>
it's not my indoor wifi, it's an isp "hotspot" (it's actually a home isp router turned into a hotspot for customers of that same isp)
ttamttam1 has joined #ocaml
<thelema>
ah.
<Camarade_Tux>
when I get a real internet access here, I'll use good old ethernet :)
ttamttam has quit [Read error: 110 (Connection timed out)]
seanmcl has quit [Client Quit]
mpwd is now known as xcthulhu_afk
seanmcl has joined #ocaml
<thelema>
Camarade_Tux: or you'll set up your own base station without rain interference
<thelema>
inside your place
<Camarade_Tux>
well, I'll probably have both but I'll still use ethernet whenever possible
<Camarade_Tux>
when playing on network with a friend, if we use wifi (ad-hoc connection), we often get lags and deconnections, ethernet is always perfect
<thelema>
ethernet is always much better. try running your cat5 parallel to unshielded power lines for long distances and see how perfect it is.
_andre has quit ["Lost terminal"]
<thelema>
ethernet *isn't* always much better
<eldragon>
should use cat9 using better cables
<eldragon>
all shielded
<thelema>
lol.
<eldragon>
more purity of the copper
<eldragon>
more fine grained
<thelema>
cat9 is a water-cooled amplifier as far as I can find.
<gildor>
flux: honestly using ocaml without ocamlfind is really a pity
* thelema
wonders if ocamlbuild.d could replace much of ocamlfind
<gildor>
flux: Fedora, Debian and GODI provides META data when they are missing
<gildor>
thelema: ocamlfind works since years and has convinced quite a few people
<gildor>
thelema: the real question is "how to make ocamlfind and ocamlbuild cooperate the best way"
<hcarty>
thelema: Maybe, but wouldn't it be better to just use the ocamlfind API directly?
<thelema>
I use ocamlfind, but I look at my build system (make + ocamlbuild + ocamlfind) and think it a bit byzantine
<thelema>
gildor: what does ocamlfind do that ocamlbuild couldn't do as well?
<Camarade_Tux>
thelema: cables don't enjoy being outside, mice enjoy them however ;-)
<gildor>
ocamlfind is a wrapper around 1 ocamlc/ocamlopt process
<gildor>
ocamlbuild run several ocamlc/ocamlopt to build a project
ygrek has quit [Remote closed the connection]
<gildor>
thelema: of course you can integrate a bit of ocamlbuild in ocamlfind to have rules et al, but basically it is two different tools
<gildor>
thelema: ocamlfind help to manage libraries and their dependencies
<gildor>
thelema: ocamlbuild don't
<gildor>
thelema: because it is not his job
<thelema>
ocamlbuild does manage dependencies.
xcthulhu_afk is now known as xcthulhu
<thelema>
it doesn't do the nice "install" and "remove" and "list" commands
<gildor>
ocamlbuild manage dependencies of a project
acatout has quit [Read error: 54 (Connection reset by peer)]
<thelema>
yes. libraries are projects too.
<eldragon>
who understand the VSIDS heuristic for DPLL?
<gildor>
thelema: for example, when a library A use a library B,
<hcarty>
thelema: But ocamlbuild doesn't track anything outside of the project
<gildor>
thelema: you have use_A and use_B
Narrenschiff has joined #ocaml
<gildor>
thelema: but does use_A implies use_B ?
<thelema>
ocamlbuild can enable one tag based on another.
<gildor>
(in ocamlbuild)
acatout has joined #ocaml
<thelema>
at least an ocamlbuild plugin can do this.
<gildor>
thelema: how ?
<thelema>
Ocamlbuild.PLUGIN.tag_file
<thelema>
val tag_file : Pathname.t -> Tags.elt list -> unit
<thelema>
tag_file filename tag_list Tag the given filename with all given tags.
<thelema>
or even [tag_any] : tag_any tag_list Tag anything with all given tags.
<gildor>
thelema: ok i know this command
<thelema>
the plugin for library A can auto-add the "use_B" tag
<gildor>
bbut say that I have a _tags: "toto.byte": use_A
<thelema>
I guess it can't use tag_any
<gildor>
does toto.byte been also tagged use_B ?
<gildor>
(with std ocamlbuild)
<thelema>
no, with no plugins it doesn't have "use_B" tag.
<thelema>
but also with no plugins, "use_A" is a useless tag.
<gildor>
ok, but ocamlfind typically can do that
<thelema>
so you need a plugin to define behavior on "use_A", and I imagine it's possible to enable "use_B" at that time.
<gildor>
with ocamlfind a simple require = "B" is enough
<thelema>
true, but then you're using one more system - one more level of indirection, one more level of complexity.
<thelema>
ocamlfind isn't bad for a single file with many library dependencies, but it doesn't help with a multi-file project
<thelema>
I think there's enough overlap between ocamlbuild and findlib that one could take over the functionality of the other. And I see ocamlbuild doing that easier than findlib.
<hcarty>
thelema: I don't understand why you would want to recreate findlib functionality in ocamlbuild, rather than just using findlib
<hcarty>
META files are much simpler than trying to create a plugin-per-library
<gildor>
hcarty: agreed
<thelema>
it's just an idea - I'm trying to see how far it can be pushed.
<thelema>
I agree that for the forseeable future, ocamlbuild + findlib is best.
<gildor>
thelema: I think for now ocamlfind has a much wider adoption
<hcarty>
It would be very nice to be able to use the findlib API from myocamlbuild.ml or, better, have findlib as a part of the default OCaml install so that it's part of stdlib and integrated by default with ocamlbuild.
<gildor>
thelema: ocamlbuild remains a young project
<thelema>
true, and I want to help it grow up.
<thelema>
not much is happening to ocamlbuild, and it needs some love
<gildor>
myocamlbuild.d + removing useless bash call + removing Unix module is a quite good first step
<thelema>
hcarty: as to findlib in default ocaml install, that's the job of packages.
<thelema>
hcarty: a "community" distribution of ocaml with all sorts of things built in and just working.
<hcarty>
thelema: Agreed. But better to use findlib, which exists and is well tested, rather than recreating the same functionality in a new tool.