<gildor>
it will run ocamlbuild ... -classic-display which will give you a more precise output
<joelr>
gildor: so what will it tell me?
<joelr>
gildor: if seems that nothing was rebuilt indeed but that operation (printed) takes time
<gildor>
joelr: it will give you all the command executed
<gildor>
joelr: but chances are that you have a lot of files (even big files) that just takes time to scan for ocamlbuild, which is maybe why it is taking time
<flux>
ocamlbuild sucks for that.
<joelr>
gildor: it seems to rebuild
<flux>
even its checks take some non-zero amount of time
<flux>
afaik it uses checksums, not timestamps?
<flux>
of course, the upside is that it's more robust, but..
<gildor>
joelr: are you using git/hg or any VCS ?
<joelr>
gildor: git, yes
<gildor>
joelr: you must know that in this case ocamlbuild will go through all the file in .git
<gildor>
joelr: give me 5 minutes, someone open a bug in oasis about that
<joelr>
gildor: ouch! any ways to improve that?
<f[x]>
".git": exclude
<gildor>
AFAIR, _tags: ".git": -traverse, but I need to check
<f[x]>
pagecache makes checksum calculation not measurable for the hot working dir
<joelr>
gildor: i maybe be able to do the work if you can guide me
<gildor>
joelr: the idea is to add rules that make a dependency from foo to Main.byte (if Exec foo MainIs: Main.ml)
<gildor>
and this rule will just copy Main.byte to foo
<joelr>
gildor: where foo is "Executable foo", right?
<gildor>
joelr: yes
<joelr>
gildor: i'll take a look.
<gildor>
you can work on this outside OASIS_START/OASIS_STOP with a list of exec/mainIs and a function (and a dispatch function)
<gildor>
at the end you should be able to invoke: ocamlbuild foo
<gildor>
without the help of oasis
<joelr>
gildor: is that the way to go, though? i don't want to run ocamlbuild foo, i want to run 'make'
<joelr>
the one that oasis generates
<joelr>
it seems like this functionality should really be part of oasis
<gildor>
thomasga: did you solve the SSL error ?
<joelr>
rather than maintained manually
fourier has joined #ocaml
<joelr>
for every executable
<gildor>
joelr: this is just a start, if the function you'll code by hand will end up in the part generated by oasis, when it works
<joelr>
gildor: what file should this be in? myocamlbuild.ml?
<gildor>
joelr: yes
<joelr>
gildor: makes sense. i'll poke you if i have any questions.
<thomasga>
gildor: no … I'm looking at the links you sent to me
<gildor>
thomasga: just realized that the error is not about the SSL cert of the server, but the SSL client cert
<gildor>
thomasga: you need a SSL client cert to access the admin interface (including the login)
<gildor>
thomasga: send me your comment (pastebin or mail), I'll post it myself
<thomasga>
Well I just wanted to say that the point of being on github is that it is not only ocaml related - so I can watch other projects as well and more importantly people which are not ocaml hackers (or casual ones) can watch for some ocaml project and being more interested in the language. There is no point on staying in our little corner.
<thomasga>
(and the entry bar to watch/fork/contribute on github is very low)
<thomasga>
(compare to the forge)
Modius_ has quit [Quit: "Object-oriented design" is an oxymoron]
<joelr>
thomasga: +1 for github
Modius has joined #ocaml
<joelr>
i appreciate the work that gildor is doing on ocamlforge but i think it can serve as a collection of pointers to github
<joelr>
github has both issue tracking, comments on commits and source code, pull/for queues, etc. etc. etc.
<joelr>
no sense to re-implement that in ocamlforge
<thomasga>
I appreciate his work as well, but github have a whole team of hackers working on having a nice interface to make social coding easier … so it's better to focus our effort in other directions instead of trying to copy them
<gildor>
thomasga: the post is not really about the fact that people should go to the OCaml Forge rather than github
<joelr>
i don't see myself using the ocamlforge as i despise the interface back from when it was sourceforge. i love github and continue using it. and i'm not alone.
<gildor>
thomasga: it is more about "well github is nice, how we can make it cooperate with the forge"
<joelr>
sylvain, i would make it "how can we make ocamlforge cooperate with github" :D
<joelr>
ah, yes
<joelr>
that one
<gildor>
thomasga: should I copy/paste "Well ... our little corner." ?
<thomasga>
would it be possible to create an ocamlforge ccount on github and mirror all the forge project in there ?
<joelr>
+1
<thomasga>
gildor: up to you, just wanted to discuss of that with you. But yea, why not :-)
<gildor>
thomasga: that is a great idea, (point 3 in the solutions: "create a github umbrella project that gather all OCaml projects")
<rproust>
thomasga: the github account with automatic copy technique is used by vim.org to maintain vim plugins
<thomasga>
yea but I was saying creating a github account, not a gitub "team"
<gildor>
thomasga: I just published your comment
<thomasga>
gildor: thanx!
<gildor>
thomasga: I am not really used to github account/team/project, AFAIR avsm told me a "team", that is the reason why
<thomasga>
a team is a collection of account users
<gildor>
thomasga: if you have time to spend on this issue, you are more than welcome (BTW, better name it "ocaml.org" on github than ocamlcore.org, I woul like to make it more vendor neutral)
<thomasga>
well not have much time currently, but I will think about it :-)
<gildor>
joelr: FYI, the forge is just an instance of fusionforge, I didn't make a lot of coding on it (apart theme and some plugins)
<joelr>
gildor: i'm not talking about your coding changes, undoubtedly awesome. i'm talking about the design and structure.
<joelr>
github is light years ahead and it makes no sense for you to try to catch up with github.
<joelr>
i think it makes no sense, i'm not sure what your goals are and whether there's a more productive use of your time
<gildor>
thomasga: you can talk about this with avsm and protz (Jonathan Protzenko)
<gildor>
they seemed very interested in github wrt ocaml
<joelr>
gildor: they should probably undertake the task then
<joelr>
gildor: but ultimately, i think it falls on your shoulders. people will just keep using github
<gildor>
joelr: the forge started before github (early 2008), at this time github was not an option
<joelr>
gildor: again, i appreciate the work you have done and i understand the underlying reasons.
<joelr>
i think that ocamlforge is becoming obsolete, though, however slowly
<gildor>
but as long as maintaining the forge doesn't eat all my time, I will maintain it, it remains an alternative for people who don't use git e.g.
<gildor>
the forge, even with is bugs/misfeatures/bad design, is a better situation than before (i.e. all ocaml code scattered around the web)
<gildor>
e.g. I am not sure that ocaml presence on SourceForge, Savannah, Google code made any differences for years
<gildor>
(Launchpad et al)
_andre has joined #ocaml
<joelr>
gildor: i would suggest a poll of ocaml users to see how many actually use ocamlforge for project hosting
<gildor>
joelr: and if there is less than 20 people, what should I do ?
<joelr>
i'm not talking about people who grab projects from source forge but those who actually commit their changes there, e.g. use it for source control, etc.
<joelr>
gildor: you should compare it to many people use github and then, perhaps, migrate the 20 source forge users to github
<gildor>
joelr: and if this people use mercurial or bzr ?
<gildor>
or svn ?
seafood has quit [Read error: Connection reset by peer]
<joelr>
gildor: i have no idea
seafood has joined #ocaml
<gildor>
e.g. Xavier Leroy is using the OCaml Forge and svn (in particular)
<joelr>
gildor: i'm in now way trying to tell you what to do, i'm simply expressing my opinion
<gildor>
for what is worth, at least every people listed have one day commited something (the -ctime -60 should only list file changed in the last 2 months, but I am not sure it applies correctly)
<pdhborges>
damn I can't do it
<gildor>
joelr: no pb at all, I am open to all alternatives, I would like to have less work and all opinions are welcome
<joelr>
pdhborges: there, see! i didn't spend a day or two on this for just no reason.
<gildor>
so for the stat
<pdhborges>
it would be nice to eliminate the kind type and let users create sockets with
<pdhborges>
socket ctx `Pub;;
<joelr>
pdhborges: i thought you needed the kind for the c bindings
<gildor>
12 people use bzr, 8 people use cvs, 14 use darcs, 37 use git, 8 use hg, 79 use svn
<f[x]>
so much for perceived git dominance!
<pdhborges>
the kind think is only needed to constraint the set of possible parameters
<pdhborges>
s/think/thing
<gildor>
that is no surprise that svn dominate, it remains an historical VCS
<joelr>
pdhborges: well, it's nice to know the set of possible parameters
<gildor>
but I am not 100% confident into this stat
<gildor>
at least the stat about darcs make sense to me (I know that most of the people listed are indeed darcs users)
<rproust>
pdhborges: phantom types disapear at runtime (hence the phantom) and no check is performed about them… using socket ctx `Pub would probably make value `Pub be carried around during the execution
<rproust>
not that speed is the most important aspect of programming, but I don't really see a huge benefit in code clarity for using socket ctx `Pub
<pdhborges>
rproust: internally zmq will carry that value anyway
<rproust>
ok
<f[x]>
gildor, I think you should use xargs -n 1?
<gildor>
indeed, and -printf0 | xargs -0, but this is just a 2 minutes command ;-)
<pdhborges>
joelr: do you really use oasis?
<joelr>
pdhborges: all the way!
<joelr>
pdhborges: it's super-convenient
<flux>
what's great about it?
<joelr>
note i didn't say it was great, i said it was super-convenient ;-) i love it anyway
<joelr>
makes it easy to throw together a project with libraries, executables, unit tests.
<joelr>
runs unit tests for you with just 'make test;
joelr_ has joined #ocaml
<joelr_>
makes creating c bindings or linking against c libraries trivial
<joelr_>
makes it easy to throw together a project with libraries, executables, unit tests.
<joelr_>
runs unit tests for you with just 'make test;
<joelr_>
pdhborges: zmq will carry the value but phantom types won't slow down ocaml code
<gildor>
flux, pdhborges, joelr: and upload the result to oasis-db
<gildor>
and be able to distribute it easily ;-)
<flux>
is oasis-db for applications as well?
<gildor>
flux: yes
<gildor>
you even have the bundle command that allow you to create a tarball with the applications + all its dependencies
<pdhborges>
joelr: what do you think of this solution
<pdhborges>
I'll add the oasis file and ignore the rest
<gildor>
i.e. you build an application that use batteries, fileutils and gettext, it create a tarball + build script for all of them
<rproust>
gildor: any ETA on oasis-db?
joelr has quit [Ping timeout: 252 seconds]
<flux>
I guess I should give it a try sometime.
joelr_ is now known as joelr
<gildor>
rproust: I stop giving ETA :-(
<gildor>
rproust: the dev version is already working online though
<gildor>
flux: one day, you will be able to add topics in "Categories: " field of _oasis
<f[x]>
gildor, doing it :)
<flux>
gildor, yeah, I was just looking at it, and the packages didn't seem to have such entries
<gildor>
flux: the categories field has still undecided purpose/format, I am thinking how to use it
<gildor>
e.g. Categories: topic::Cryptography, kind::BigApplication (as suggested by Maxence Guesdon)
<gildor>
or Categories: Cryptography
<flux>
actually one app I might consider adding to oasis would be a file tagging utility, but I imagine it's not suitable for this :)
<gildor>
(and ignore its kind)
<flux>
in any case my tagging system also has key-value pairs. such as license:gpl.
<gildor>
flux: why do you think it is not suitable ?
<flux>
because it is a command line tool for managing meta information in an sqlite database
<flux>
it is very directory-oriented in the sense that each directory has its own database etc
<pdhborges>
joelr: you still there?
<joelr>
pdhborges: yes
<flux>
whereas oasis tagging would be something very different. I guess the 'tagging language' could be the same.
<gildor>
flux: the DB backend of oasis is sqlite, and if you want to adapt your tool, you are welcome
<flux>
(there is a small query language as well)
<joelr>
pdhborges: umm... you can do anything you want, it's your repository.
<pdhborges>
joelr: what if I keep the oasis file and ignore the generated ones?
<flux>
it allows queries such as 'license:gpl && rating>=3 && rating<=5'
<joelr>
pdhborges: i think that's a good solution but gildor is the guru
<gildor>
flux: we already implements rating
<joelr>
pdhborges: i think the reason to check in generated files is so that users of the library don't have to install oasis
<gildor>
pdhborges, joelr: just keeping _oasis should be ok (but no benefits from the generated build system) and you should run "oasis setup" when you build the tarball
<joelr>
pdhborges: from that perspective you ought to check in the generated files
<joelr>
gildor: that means i, as a user of the library, have to install oasis as well
<pdhborges>
gildor: currently I'm using make files
<joelr>
as a user i may not care
<joelr>
will likely not care
<pdhborges>
joelr: I would keep the makefiles
<pdhborges>
contributors have no problem editing them
<joelr>
pdhborges: it's not just the makefiles, it's _tags, myocamlbuild.ml, setup.ml, library meta files, etc.
<gildor>
pdhborges: keeping makefiles and _oasis would make you work twice, but that is up to you
<pdhborges>
and the guys that use oasis would still be able to use it
<thelema>
my current version compare code in odb is pretty slick - Str.full_split (regexp "[^0-9]+"), map numbers to ints and compare component by component
<gildor>
the version comparator in OASISVersion is a code stolen from dpkg (debian package program)
<thelema>
then you better fix that code too. I wonder what assumption I broke with "2.0beta"
<gildor>
thelema: nevermind, this is probably an error in my translation of C to OCaml code
<thelema>
mfp: mind if I upload your current ocaml-sqlexpr to oasis-db?
dnolen has joined #ocaml
<f[x]>
btw, using patches from mantis ocamlbuild nothing-to-rebuild for batteries goes down from 1.6 to 1.2 cpu seconds
<thelema>
f[x]: yay. I'm always happier when batteries takes less time to build. Is that make all or make test?
dnolen has quit [Quit: dnolen]
dnolen has joined #ocaml
<f[x]>
all
<f[x]>
excluding .git doesn't give any noticeable impact
<thelema>
f[x]: it's possible that your git is already packed, meaning there's few files to be scanned
<f[x]>
hm, maybe
<thelema>
I have O(3K) files in my batteries/.git
<thelema>
my build-nothing time drops from 1.9 to 1.0 cpu seconds by excluding .git
<gildor>
thelema: if you have also built the documentation, you can exclude also the directory .docdir !
<thelema>
I find myself rarely building the documentation - usually only when I make a new release
<gildor>
thelema: you can retry uploading batteries 2.0beta, the bug should be fixed now
<thelema>
ok, thanks
<joelr>
did someone call ?
<joelr>
pdhborges: thanks
<thelema>
gildor: what's the relationship between the name of a library and its findlib name for odb?
ankit9 has quit [Remote host closed the connection]
dnolen has quit [Quit: dnolen]
Snark has joined #ocaml
<thelema>
I'm not sure how to feel about ocaml stdlib adding String.iteri, List.iteri/mapi, etc.
<thelema>
On one hand, it takes away the usefulness of stdlib extensions
joewilliams is now known as joewilliams_away
Cyanure has quit [Remote host closed the connection]
<thelema>
on the other hand, it validates the need for those extensions
joewilliams_away is now known as joewilliams
<gildor>
thelema: if there is an _oasis file, there will be executable_name info files + (root library_findlib_name) info files
<gildor>
e.g. ocaml-fileutils provides fileutils and fileutils.str and there should be a fileutils info file in odb
<thelema>
okay, what if I have: "Library foo \n\tFindlibName bar"
seafood has joined #ocaml
mcclurmc_home has joined #ocaml
emmanuelux has quit [Ping timeout: 255 seconds]
<gildor>
thelema: the info file will be named bar
<thelema>
and without the findlibname, it'll be named foo?
<gildor>
yes
<thelema>
ok, great
joelr has quit [Quit: joelr]
fourier has quit [Ping timeout: 255 seconds]
joelr has joined #ocaml
lopex has quit []
ankit9 has joined #ocaml
<joelr>
gildor: where does setup.ml invoke ocamlbuild?
<joelr>
gildor: never mind, found it
<joelr>
sorry for the noise
sergio1 has joined #ocaml
<sergio1>
Hi Ocamlers!
<sergio1>
I'm not extremely familiar with all libs...
<sergio1>
How can I print an arbitrary term (there is "print_string", "print_float"..., but no "print_term")
<thelema>
sergio1: ocaml doesn't have enough information at runtime to print an arbitrary value
<sergio1>
this *is* an explanation! Thanks!
<thelema>
there's Std.dump in extlib and batteries that does as best as possible with what information exists, but it is far from perfect
<thelema>
and probably not what you want.
<sergio1>
Basically, I'd just need the equivalent of what Ocaml's REPL does
<thelema>
ocaml's REPL cheats, as it has access to type information that's not available at runtime
<sergio1>
(I'm not very familiar with the REPL, so I directly write programs, then compile and run them...)
<thelema>
not available in a compiled program (bytecode or native code)
sergio1 has quit [Remote host closed the connection]
<thelema>
:( ocamlfind doesn't work as a normal user, as it needs to update the ocaml/ld.conf file
ulfdoz has joined #ocaml
<gildor>
joelr: it should be possible, and it was done in early version of oasis
<gildor>
joelr: but depending on the availability of ocamlopt, oasis choose to invoke the targets .cmxa or not
* thelema
is reinstalling his whole ocaml system (minus ocaml itself and findlib) using odb.ml
pdhborges has quit [Quit: Leaving.]
<gildor>
joelr: + it allows to flag something to build which is not possible with itarget
<f[x]>
thelema not unless you have stublibs subdir in destdir
<thelema>
f[x]: really? I'll try that, then.
<joelr>
gildor: what do you mean by flag something to build?
<thelema>
f[x]: but that stublibs subdir still has to be added to ocaml/ld.conf
<gildor>
joelr: Library foo Build$: flag(bar)
<joelr>
gildor: oh, yes, conditional build. how do you trigger that from the command line, btw? -bar?
<f[x]>
thelema, yes, once
<gildor>
ocaml setup.ml -configure -enable-bar
<joelr>
enable-bar, right
<thelema>
f[x]: I'll have to document this and explain how to do it nicely.
<f[x]>
I think it should be done by ocamlfind install
<thelema>
now to debug why sqlexpr isn't building...
<thelema>
f[x]: it is done automatically if there's no stublibs dir, except if you're not root...
<joelr>
gildor: why can't setup.ml generate *.itarget and then invoke ocamlbuild? then all dependencies will be indeed loaded once.
<f[x]>
I mean by ocamlfind installation process
<joelr>
gildor: it will take all of a few milliseconds to write the itarget file on the fly, depending on the build settings and availability of ocamlopt
<joelr>
gildor: and it can be removed at the end
ygrek has joined #ocaml
pdhborges has joined #ocaml
<thelema>
f[x]: You mean when ocamlfind is installed?
<gildor>
joelr: indeed, it is possible, just that writing a file vs invoking a command line with the right flag was not an option when you'll have to copy executable in between
<gildor>
joelr: if you are able to build executable with the right name and put it in the .itarget, it would be better
<joelr>
gildor: you first invoke a command line with the right flag. once you have collected your list of targets, instead of iterating through the list and invoking ocamlbuild for each target, you write .itarget and run ocamlbuild once.
<joelr>
gildor: would that work for you?
<thelema>
joelr: you don't need an .itarget to do that
<f[x]>
thelema, yes
<joelr>
thelema: to do what?
<thelema>
joelr: just put all the targets on the ocamlbuild command line. Speeds up batteries' build process lots
<joelr>
thelema: i usually run make and oasis does not put all my targets in make, it keeps them in setup.ml
<joelr>
thelema: also, i'm not about to run setup.ml with 13 targets on the command line, if that was possible even :D
<joelr>
thelema: that said, i think i'll try to modify setup.ml to do what you are saying and see what happens
<thelema>
joelr: instead of "echo foo\nbar\nbaz\n > all.itarget; ocamlbuild all.itarget", you can do "ocamlbuild foo bar baz"
<joelr>
gildor: what do you think of thelema's suggestion
willb has joined #ocaml
<thelema>
f[x]: ocamlfind doesn't know about ~/.odb/lib/stublibs to put it in ld.conf when it's installed
<thelema>
echo $HOME/.odb/lib/stublibs | sudo tee -a `ocamlc -where`/ld.conf
<gildor>
thelema solution is what is currently done, I think
<thelema>
Does anyone have a system where this wouldn't work?
<gildor>
joelr: ^^^
<joelr>
gildor: then ocamlbuild is already run once. should be run once but i don't think that's what's happening. let me verify...
<gildor>
joelr: honnestly, I think it is not worth working on .itarget right now, the single invocation with executable named correctly is a big enough feature
<f[x]>
~/.odb/lib/stublibs is a bad idea anyway
<f[x]>
it should be local to ocaml installed
<gildor>
joelr: oasis compute a possible merge of targets, but it stops on executable, because it have to rename it
<joelr>
gildor: is the executable named incorrectly now? i thought you just said ocamlbuild is invoked once
<thelema>
f[x]: what's the best I can do without root?
<gildor>
joelr: but with the rules we talked about this morning, we should be able to have a single ocamlbuild call
<joelr>
gildor: ah, right, this is the part where it compares executables 4k at a time, right?
<gildor>
joelr: yes
<f[x]>
thelema, do nothing, ocaml should be installed by user/admin correctly
<joelr>
gildor: can we revisit those rules again?
<joelr>
gildor: why do you need to copy the executable?
<thelema>
f[x]: and if a user wants some library installed, they need admin privileges to do so?
<joelr>
gildor: i mean, why do you need to rename it?
<f[x]>
thelema, why?
willb has quit [Ping timeout: 244 seconds]
<f[x]>
on stock debian - ocamlfind install doesn't need root
<f[x]>
on user-installed caml (in /opt) it doesn't need root either but one still better create stublibs
philtor has joined #ocaml
<gildor>
joelr: if it is possible to generate directly the executable, without copying involved, that would be better
<joelr>
gildor: why can't you generate foo.{byte,native} from Executable foo
<gildor>
joelr: did you manage to write the rules for myocamlbuild.ml ?
<thelema>
on stock ocaml3.12 + findlib 1.2.7 it needs root to ocamlfind install
<thelema>
f[x]: ^^^
* gildor
gtg
<f[x]>
thelema, ah, adduser me staff
<joelr>
gildor: no, i just started digging into what needs to happen. i think i'm understanding it slowly
<gildor>
joelr: I think the conclusion will be that copying will help to reuse the current ocamlbuild rules
<gildor>
joelr: if you want a direct generation, you need to hack the ocamlbuild default rules
<joelr>
gildor: i don't want copying! it slows our build a lot. i'd rather do without.
<gildor>
joelr: but using myocamlbuild copying rules will only copy when needed
<joelr>
gildor: no copying is i can avoid it, anyway
<f[x]>
thelema, all in all I think you are solving wrong problem, odb installs libs, it should install it where the system is configured too
<joelr>
gildor: i understand. i'm trying to figure out how to set up these rules in myocamlbuild
<f[x]>
not configure something behind my back
<joelr>
gildor: i will need to fix setup.ml as well, right? to skip diff
<thelema>
f[x]: so odb should assume it has privileges to ocamlfind install?
<f[x]>
> sudo tee -a `ocamlc -where`/ld.conf
<f[x]>
that's not what I would expect to see nowhere near install target
<f[x]>
thelema, sure
ymasory has joined #ocaml
<f[x]>
there should be a separate tool to manage separate parallel ocaml+findlib installs that should take care of that
<thelema>
f[x]: I guess I'll find out if it's common that people don't have access.
* f[x]
should probably finish that one
<thelema>
f[x]: I thought ocamlfind had enough support for that. I just found out I was wrong.
<f[x]>
it has some rudimentary support (toolchains)
<f[x]>
but I found it unsatisfactory
<f[x]>
simpler to have separate ocamlfind configs for separate ocaml installs and switch between them with OCAMLFIND_CONF
* thelema
stops using OCAMLFIND_DESTDIR
<thelema>
and OCAMLFIND_LDCONF=ignore
ulfdoz_ has joined #ocaml
<hcarty>
thelema: I hope odb.ml isn't going to stop putting things under ~/.odb ...
ulfdoz has quit [Read error: Operation timed out]
ulfdoz_ is now known as ulfdoz
<hcarty>
That's one of the nicer things about it
<thelema>
hcarty: binaries have to go there. f[x] insists that if you don't have permissions to the configured findlib repo, you shouldn't be installing packages.
boscop_ has joined #ocaml
pdhborges has quit [Quit: Leaving.]
<hcarty>
thelema: I insist that f[x]'s opinion is flawed :-)
boscop has quit [Ping timeout: 246 seconds]
<hcarty>
Why else would findlib allow a user to specify multiple library locations?
<thelema>
hcarty: to install a C stub library, the file `ocamlc -where`/ld.conf has to point to the install dir
<hcarty>
odb seems very much like a cpanminus/perlbrew-light
<thelema>
hcarty: at least once, someone with permissions to that file (root/staff) will have to add an entry in that file
<hcarty>
It looks like that's not true, with a bit of environment variable setup
<thelema>
This variable determines the location of the ld.conf file. This must be the same file the O'Caml compilers read in; it is updated by ocamlfind when installing and removing packages. You can set this variable to the special value "ignore" to disable the automatic modification of the ld.conf file.
<hcarty>
Drat, I misread
<hcarty>
I still think that it is worth leaving odb's install location in place
<thelema>
I think it's an ocaml problem, maybe ocaml can be extended to use a ~/.odb/ld.conf
<f[x]>
I insist that libs should be installed parallel to ocaml compiler used to compile them
<hcarty>
f[x]: Why?
<f[x]>
think of several parallel ocaml installations
<hcarty>
f[x]: What if you want several sets of libraries?
* thelema
gets lunch and will join this conversation in a bit
<hcarty>
For example, a stable, testing and development suite
<f[x]>
exactly, I want a separate environment for each ocaml
<hcarty>
What if you want to use the same ocaml for each?
<f[x]>
that doesn't contradict
<hcarty>
OCaml 3.12.0 with Batteries 1.0, 1.2 and 2.0
<f[x]>
you can have several environments for each ocaml
<hcarty>
It does if you force the libraries to install to the same local-to-ocaml path
<f[x]>
but you cannot have one environment for all ocamls (as with .odb)
<f[x]>
when I said that the path should be same?
<hcarty>
f[x]: Changing the .odb to/ .odb/a/ is a simple enough task
<f[x]>
name it how you like it but keep it tied to ocaml installation
<hcarty>
Tied how?
jamii has quit [Ping timeout: 246 seconds]
<f[x]>
via version number is ok
<f[x]>
but I would prefer $(ocamlc -where)/site-lib
<f[x]>
my main point is that odb shouldn't dictate this choice
<hcarty>
That makes odb unusable by non-root users if you're using a system ocaml
<f[x]>
it should use ocamlfind install and it is up to user to configure it the way he likes
<hcarty>
I think the default should be user-local (~/.odb/) not system-wide ($(ocamlc -where))
<f[x]>
using system ocaml with home-installed libs will require jumping through too many hoops anyway
<f[x]>
better ask root once to "adduser me staff" or install ocaml yourself
<hcarty>
f[x]: I don't see where the hoops are
<hcarty>
CAML_LD_LIBRARY_PATH
<hcarty>
Set a few ocamlfind environment variables
<f[x]>
_a few_
<hcarty>
The result is a very simple way to get the latest version of Some OCaml Library
<f[x]>
a few there and a few here and all that should be done by user
<hcarty>
If odb creates a script or spits out the variables to be set then it's not really an issue.
<hcarty>
Otherwise the user has to learn the variables to set, or learn to build OCaml and findlib themselves
<f[x]>
that's ugly
<hcarty>
It's the way perlbrew works, and I have yet to see a tool which handles this kind of thing better
<f[x]>
at least include the ocaml version string into path somewhere
<hcarty>
odb could potentially allow a user to specify the target path
<hcarty>
The default would be .odb
<hcarty>
But if you want otherwise, you could specify it somehow
<hcarty>
thelema: Does CAML_LD_LIBRARY_PATH get around the need to edit ld.conf?
<hcarty>
thelema: I just tried a bare OCaml 3.12 + ocamlfind + odb.ml install of Batteries, and I get "ocamlfind: Package `camomile' not found"
<hcarty>
thelema: This is against 2.0beta
<hcarty>
It looks like there is a stale dependency somewhere
<thelema>
very odd, I had no problems with batteries without camomile
<thelema>
when do you get that message?
<hcarty>
About 2 minutes ago
<thelema>
when during the install process?
<hcarty>
Let me try a fresh odb.ml download
<thelema>
one sec
<thelema>
let me commit
<thelema>
pushed
<hcarty>
I'm going to start fully fresh
<thelema>
try ocaml odb.ml --clean
<hcarty>
It's too bad OCaml's build system doesn't support parallel make calls
jderque has quit [Quit: leaving]
* thelema
changes odb to clean up the previous install dir when it makes a new one
<thelema>
that was probably the problem
<joelr>
thelema: can you have a tag that says that src/foo/bar depends on src/foo/baz?
<thelema>
make up a new tag, put it on bar and have baz depend on that tag
<joelr>
thelema: this requires editing both myocamlbuild.ml and _tags, right?
<thelema>
no, it can be done entirely within myocamlbuild
<thelema>
dep ["my_new_tag"] ["src/foo/baz"]
<joelr>
thelema: that's what i was gonna ask next. if i'm doing that then why not just add a rule?
<thelema>
tag_file "src/foo/bar" ["my_new_tag"]
<joelr>
thelema: where would a copy rule come in the above scenario?
<thelema>
if you had a rule saying bar depends on baz, then it would build baz and then be be done.
<thelema>
the copy rule could be used to create baz
<joelr>
thelema: can you use tags in rules?
<thelema>
there's a ~tags argument, but it's deprecated for some reason
<joelr>
hmm
<joelr>
thelema: so in the above case it's easier to just create a rule, right?
<thelema>
to add a dependency? no.
<joelr>
thelema: it's both a dependency and a copy operation. i'm trying to figure out the best way.
<joelr>
thelema: the complication is that ocamlbuild will build foo.byte but i need to move it to bar.byte instead
<joelr>
thelema: i have already figured out how setup.ml needs to be modified to trigger the building of bar.byte (the target of the rename/move/copy). now i need to figure out what to add to myocamlbuild.ml to make sure the rename/copy/move is triggered
<joelr>
thelema: unfortunately, i cannot use extentions (%.ml, etc.) because the difference here is in the name of the file
<joelr>
so i will need to list the source/target pairs in myocamlbuild.ml
<thelema>
why don't you just have a postBuild command that does all the copying?
<thelema>
PostBuildCommand: Command to run after build.
<joelr>
thelema: i only need to copy if the "source" has changed
<joelr>
thelema: i don't need to always copy
<joelr>
so i need to plug into the "dependency graph"
<thelema>
forge your own -- I'm sure bash can do a timestamp comparison easy enough
<joelr>
thelema: this is to make our build process faster by far, by eliminating the individual copy operations (and compares) that oasis is doing now
<joelr>
thelema: gildor agreed to fix up oasis to do this right, the way i'm trying to do it
<joelr>
thelema: as long as i find out the right way to do it :D meaning figure out the code to add to myocamlbuild.ml
<joelr>
thelema: i can add rules for each source/target pairs. trying to see if there's a more elegant way
<thelema>
The goal is to build foo by building bar and copying it to foo?
<joelr>
thelema: correct
<joelr>
thelema: but only do it if bar was actually rebuilt
<thelema>
why not build foo from bar's source files?
<thelema>
in fact, why not just rename everything so bar is named foo?
lopex has joined #ocaml
<joelr>
thelema: well, renaming source files would be messing with the user's source code
<joelr>
thelema: and i would love to know how you can tell ocamlbuild that foo.byte is built from bar.ml
<thelema>
ok, let's go back one step further - why are you trying to build foo.byte from bar.ml?
<joelr>
thelema: because with oasis you say Executable foo / MainIs: bar.ml
<joelr>
thelema: that's the crux of the problem. this causes oasis, in the setup.ml file, to do things that slow everything down, e.g. invoke ocamlbuild individually for every such executable
<joelr>
thelema: that's it?!
<joelr>
thelema: wait! there's a complication :D i knew this was too easy
<thelema>
joelr: yeah, just override the existing function. the details of "call ocamlc" aren't trivial, but I'm sure they're in the ocamlbuild source somewhere
<joelr>
thelema: the problem is that the rule is individual for every directory if you are using several
<joelr>
so the path needs to be included above
<joelr>
darn
<thelema>
sure, put in the appropriate paths
<joelr>
thelema: this is not easier than a copy rule, though
<thelema>
you can't use a copy rule, as you don't have a target to depend on
<thelema>
to use a copy rule, you've got to put the target of that rule as a dep
<joelr>
thelema: it works, remember, i showed you that it does
<thelema>
have you dropped the constraint that we can't change the ocamlbuild command line?
<joelr>
thelema: indeed. i can change it to include target
<joelr>
this is what i meant that i can modify setup.ml
<thelema>
if you can put the real target onto the ocamlbuild command line, then add the copy rule and you're done, no tags, no deps
<joelr>
i know how to modify it to first include source.byte and then target.byte after that, e.g. ocamlbuild source.byte target.byte
<thelema>
ocamlbuild target.byte
<joelr>
thelema: indeed, that's what i'md oing
<thelema>
no source.byte
<joelr>
thelema: oh, right, yes
rfg has quit [Quit: rfg]
<joelr>
thelema: works like a charm!
<joelr>
thelema: thanks!
<thelema>
you're welcome
<joelr>
gildor: ping
ymasory has quit [Read error: Connection reset by peer]
_andre has quit [Quit: leaving]
ymasory has joined #ocaml
agarwal1975 has quit [Quit: agarwal1975]
Reaganomicon has joined #ocaml
ikaros has quit [Quit: Ex-Chat]
rfg has joined #ocaml
ymasory has quit [Quit: Leaving]
avsm has joined #ocaml
avsm has quit [Client Quit]
raphscallion has joined #ocaml
emmanuelux has joined #ocaml
smerz has joined #ocaml
joelr has quit [Ping timeout: 240 seconds]
Yoric has quit [Quit: Leaving.]
pdhborges has joined #ocaml
<gildor>
joewilliams: pong
<gildor>
argh joelr left, sorry joewilliams bad completion
rfg has quit [Quit: rfg]
<joewilliams>
np
<thelema>
gildor: does odn 0.0.4 build for you under 3.12?
<thelema>
which is annoying, considering the jane street packages all require 3.12
<thelema>
anyway, gildor.todo.push(fix odn);; thelema.todo.push(go home and eat dinner)
joelr has joined #ocaml
<gildor>
thelema: what version of type-conv ?
<gildor>
joelr: pong
<joelr>
gildor: hi
<joelr>
gildor: did you get my emails?
<thelema>
gildor: type-conv (version: 2.3.0)
<thelema>
gildor: all built using odb.ml from oasis-db testing
<gildor>
thelema: the problem comes from this version of type-conv
<joelr>
gildor: i'm stuck on this right now: E: No one of expected built files '_build/src/daily_view_count/update_view_count' exists
<gildor>
(I use type-conv 1.7.1)
<joelr>
gildor: trying to figure out how to tell setup.ml to check for update_view_count.native instead
<gildor>
joelr: I reply to your email about the .native/.byte stuff
<gildor>
I think we should keep update_view_count rather than update_view_count.native
<gildor>
.native/.byte is something 100% ocamlbuild related
<joelr>
gildor: well, we should in the long run but i need a short-term fix. i have Executable foo, MainIs: foo.ml everywhere and oasis still insists on individually copying/checking my 13 executables
<joelr>
gildor: i need to figure out how to patch this temporarily
<joelr>
gildor: this is one part of the patch: (if unix_tgt = unix_exec_is^ext then
<joelr>
gildor: but, apparently, i need to tell oasis somewhere else that it should check for .native or .byte, depending on what i'm building.
<gildor>
joelr: you really need to have the good filename in this case...
<joelr>
gildor: there's only one in setup.ml
Modius_ has quit [Quit: "Object-oriented design" is an oxymoron]
<joelr>
gildor: i do have a great filename, update_view_count.native in this case (Executable update_view_count, MainIs: update_view_count.ml)
Modius has joined #ocaml
<joelr>
gildor: i would like to tell have oasis look for update_view_count.native in check_and_register
edwin has quit [Remote host closed the connection]
<joelr>
(* Check and register built files *)
<joelr>
let check_and_register (bt, bnm, lst) =
<joelr>
this one
raphscallion has quit [Quit: raphscallion]
mcclurmc_home has quit [Ping timeout: 246 seconds]
pdhborges1 has joined #ocaml
<gildor>
joelr: for a quick fix, I think you can play with cond_targets_hook
pdhborges has quit [Ping timeout: 264 seconds]
<gildor>
joelr: modify the name of the built file using a this hook
raphscallion has joined #ocaml
<joelr>
gildor: cool. how do i pass the extension in, though?
<joelr>
gildor: wouldn't it be easier to modify lst in let check_and_register (bt, bnm, lst) =
<gildor>
"built" should be ["src/update_view_count"; "_build/src/update_view_count"], just List.map (fun str -> str ^ ".native")
<joelr>
gildor: at a point where the target with the extension is available. i'm at a loss how to do this. can;t figure out where lst is being built
<joelr>
gildor: i don't want to hardcode native as some people here build bytecode
<joelr>
gildor: is this the same built as here? let last_rtargets =
<joelr>
List.fold_left
<joelr>
(fun acc (built, tgt) ->
<gildor>
joelr: in this case (List.map (append ".native" built)) @ (List.map (append ".byte") built)
<gildor>
joelr: yes, this is this one
<joelr>
gildor: then i should probably modify it inside last_rtargets instead, seems easier because tgt is the right filename here
<joelr>
gildor: no?
<gildor>
the cond_targets_hook can be changed outside oasis section (i.e. you can keep the fix after regenerating the file)
<gildor>
joelr: ^^^
<joelr>
gildor: awesome. can i determine extension outside oasis section as well?
<gildor>
joelr: you mean accessing the oasis package datastructure ?
<joelr>
gildor: whichever way works :-)
<joelr>
to modify the hook, i need to know whether i'm building native or byte
<gildor>
joelr: you can access setup_t.package and look for an executable with the right name
<joelr>
i see
<gildor>
joelr: I am considering to allow .native/.byte during the build process and only have the final name set when installing
<joelr>
gildor: i think there's a bug in oasis right now because the executable name will never match what oasis is building
<joelr>
gildor: and so things will always go to StdRename
<gildor>
joelr: what do you mean ?
<gildor>
joelr: because I don't consider the ext ?
<joelr>
gildor: i mean that even if you name your executable the same as main, it will still go to StdRename
<joelr>
gildor: do you understand what i'm saying?
<gildor>
joelr: this is expected for ocamlbuild
<joelr>
gildor: no, this is a bug in oasis
<joelr>
gildor: search for the 2nd ocurrence of StdRename in a setup.ml
<gildor>
joelr: I mean this is normal to always end up with StdRename in the case of ocamlbuild
<joelr>
gildor: why is Std there then?
<joelr>
gildor: because Std is the fast path, the one that does not involve copying
raphscallion has quit [Quit: raphscallion]
<gildor>
joelr: humm, if you name your Executable "foo.native" MainIs: foo.ml it should work
sepp2k has quit [Quit: Leaving.]
<joelr>
gildor: i know it will but i'm not gonna do that because i'm using CompiledObject: best and often change to bytecode. i also have 13 executables and a few people on the team
<joelr>
gildor: i really would like to use the (if unix_tgt = unix_exec_is^ext then
<joelr>
check instead
<joelr>
because then no copying happens
<joelr>
except oasis will look for the executable without the extension
<gildor>
joelr: as I said above, I am considering the possibility to use the native name given by ocamlbuild for the exec, until the install
<joelr>
gildor: this is most awesome and i appreciate it. need a temp fix now, though, to use tomorrow :)
<gildor>
but you'll need to use $name to use the file
<joelr>
gildor: use $name where?
<joelr>
gildor: what is the type of built in let last_rtargets = ?
<gildor>
e.g. Executable foo ... Test main Command: $foo
<gildor>
built : string list I think
<joelr>
gildor: hmm... doesn't seem to be string list
oriba has joined #ocaml
<joelr>
i could be wrong, checking
<joelr>
gildor: let f x = info (f_ ">> built = %s") x in List.iter f built; (* Right? *)
<gildor>
BaseBuilt.t * string * string list
<joelr>
gildor: what is the 2nd string?
<gildor>
the name of the exec, as in Executable foo
<joelr>
gildor: aha, great
<gildor>
the string list is filenames
<fourier>
anyone uses Tuareg mode for Emacs ?
<fourier>
Did someone observes that the indentation of the next line of function definition like: 'let f = function' is incorrect ? However 'match .. with' indents correctly
<joelr>
gildor: i'm trying to modify lst at that point, as a temp patch
<gildor>
joelr: best patch for tomorrow
<joelr>
gildor: yes, i think that should be the best patch for tomorrow. will be as soon as i manage to print out lst that's in built :D
emmanuelux has quit [Remote host closed the connection]
ftrvxmtrx has quit [Read error: Connection reset by peer]
<joelr>
gildor: this doesn't work in last_rtargets :(
<joelr>
let f (_, name, lst) = info (f_ ">> name = %s, lst = %s") name (String.concat ", " lst) in List.iter f built;
<gildor>
what is the typing error ?
<joelr>
Error: This expression has type ((BaseBuilt.t * string * string list) list * string) list but an expression was expected of type ((BaseBuilt.t * string * string list list) list * string) list
<joelr>
gildor: ^
<joelr>
gildor: i think last_rtargets is the wrong place to modify that lst, i think it should be done in let cond_targets. what do you say?
<gildor>
joelr: ah yes the string list list
<joelr>
gildor: would cond_targets be a better place to modify that lst?
<gildor>
joelr: not really, the hook is the best place for this kind of code
<joelr>
gildor: the hook does not have information about the current extension so it cannot be used
<gildor>
joelr: Just (String.concat ", " (List.flatten lst))
<joelr>
the hook does not know whether native or byte is used for the current executable
<gildor>
joelr: just give him all the possible extensions, this is just a List.filter Sys.file_exists
<joelr>
gildor: that's interesting. let me try this...
<joelr>
gildor: but if i were to make this a semi-permanent patch for the oasis that we use in the company, wouldn't i modify lst at the point where stuff is inserted into it? shouldn't i?
dnolen has joined #ocaml
ftrvxmtrx has joined #ocaml
<joelr>
gildor: is built put together in cond_targets?
<joelr>
gildor: can you point a finger to the place in "let cond_targets = ..." where things are added to built?
<gildor>
joelr: everything puts in the oasis section will be overwritten, but if you are sure, not to forget it when you regenerate, it should be ok
<joelr>
gildor: i'm trying to patch oasis itself, e.g. OCamlbuildPlugin.ml
<joelr>
gildor: except i'm verifying my patch by modding setup.ml
<gildor>
let host_exec_is =
<gildor>
in_build_dir_of_unix unix_exec_is
<gildor>
in
<joelr>
gildor: except i still don't know where in "let cond_targets = ..." things are being put into built
<joelr>
gildor: yes?
<joelr>
(if unix_tgt = unix_exec_is^ext then
<joelr>
Std [unix_tgt]
<joelr>
else
<joelr>
StdRename (unix_tgt, host_exec_is))
<joelr>
gildor: i'm using this so host_exec_is is not being used.
<joelr>
it goes to Std [unix_tgt]
<joelr>
somewhere around here i would like to stuff unix_tgt into "built" so that check_and_register looks for that instead
<gildor>
joelr: wait a sec, maybe it is BaseBuilt.of_executable
<gildor>
BaseBuilt.of_executable is what you are looking for
<joelr>
gildor: where am i looking for it? i'm in cond_targets now