walter has quit [Quit: This computer has gone to sleep]
mhd has joined #ocaml
<mhd>
I am trying to get Bitstring to work; in the toplevel i have #loaded bitstring/bitstring.cma, bitstring_persistent.cma
<mhd>
but I can't use the BITSTRING { ... } syntax
<mhd>
why is that?
<mhd>
it also tells me that Bitstring is an unbound module
<mhd>
this is all very confusing
Anarchos has quit [Quit: Vision[0.9.7-H-130604]: i've been blurred!]
q66 has quit [Quit: Leaving]
stevej has quit [Ping timeout: 240 seconds]
ollehar has quit [Ping timeout: 248 seconds]
n06rin has joined #ocaml
Xom has joined #ocaml
Xom has quit [Client Quit]
csakatoku has joined #ocaml
breakds has quit [Quit: Konversation terminated!]
madroach has quit [Ping timeout: 264 seconds]
Myk267 has quit [Quit: Myk267]
madroach has joined #ocaml
csakatoku has quit [Ping timeout: 245 seconds]
walter has joined #ocaml
mhd has quit [Quit: byes]
mhd_ has joined #ocaml
Myk267 has joined #ocaml
<mhd_>
is there a persistent problem with bitstring?
ollehar has joined #ocaml
Myk267 has quit [Quit: Myk267]
talzeus has joined #ocaml
talzeus has quit [Remote host closed the connection]
talzeus has joined #ocaml
talzeus has quit [Client Quit]
talzeus has joined #ocaml
csakatoku has joined #ocaml
csakatoku has quit [Remote host closed the connection]
<whitequark>
actually, I highly recommend setting OCAMLRUNPARAM=R in your test suite.
<whitequark>
it exposes potential bugs like nothing else.
ygrek has joined #ocaml
introom has joined #ocaml
introom has quit [Remote host closed the connection]
vpm has quit [Ping timeout: 264 seconds]
vpm has joined #ocaml
pkrnj has joined #ocaml
csakatoku has joined #ocaml
darkf has joined #ocaml
void64 has quit [Read error: Operation timed out]
arquebus has joined #ocaml
void64 has joined #ocaml
void64 has quit [Read error: Operation timed out]
mhd_ has quit [Quit: byes]
cdidd has quit [Remote host closed the connection]
void64 has joined #ocaml
arquebus has quit [Quit: Konversation terminated!]
ygrek has quit [Ping timeout: 276 seconds]
ben_zen has joined #ocaml
<n06rin>
i'm reading real world ocaml, but it's plenty hard. It have a lot of redundant information.
<n06rin>
Maybe need to make some simple exercise on ocaml to master him? Books is so teoretical
ollehar has quit [Ping timeout: 256 seconds]
n06rin has quit [Quit: Leaving.]
csakatoku has quit [Remote host closed the connection]
Drup has quit [Quit: Leaving.]
ygrek has joined #ocaml
Xom has joined #ocaml
Xom has quit [Client Quit]
csakatoku has joined #ocaml
Simn has joined #ocaml
ggole has joined #ocaml
ben_zen has quit [Quit: leaving]
<kerneis>
gasche: I like the plugin-pkg option, except that it's sometimes painful (in particular for test purposes) to have to install a module
<kerneis>
so what about a simple -plugin option, which would 1) dynlink directly if the provided option is an actual file 2) perform a findlib lookup otherwise
<kerneis>
that's my current approach in CIL and I feel it gives you best of both worlds
<kerneis>
(but I might miss something specific to ocamlbuild that would make this useless)
csakatoku has quit [Remote host closed the connection]
<gasche>
kerneis: I pushed a patch implementing -plugin-tags to solve the regression ASAP and give me more time to think on the matter
<gasche>
(also being tags-based integrated better in the existing implementation setting)
<gasche>
there are a few awkward things with the "(dyn)link files directly" idea
<gasche>
(1) I wouldn't want to encourage modules that have observable initialization-time side-effect as a preferred plugin mechanism, because they're dangerously non-flexible
<gasche>
(2) it is unclear at which time these modules would be compiled, if they're part of the current project (Daniel Bünzli's use-case); you can make it work by manually building the .cmo you need with -no-plugin, but I think what we would like to have is an automatic dependency on those modules
<kerneis>
gasche: we're talking about trunk, not 4.01, right?
<gasche>
-plugin-tags is in 4.01 as well
n06rin has joined #ocaml
<kerneis>
ok, I thought you had rollbacked everything in 4.01 anyway
<gasche>
The rollback option is still on the table, but I wanted to discuss it with Damien. I'm interested in your opinion.
zpe has joined #ocaml
<kerneis>
my gut feeling is that we uncovered too many issues in a too short time-frame to be confident about pushing in the wild whatever we think is "finally the right thing"
<kerneis>
but I also understand how delaying this feature by a few months would hinder its adoption
<kerneis>
and we need feedback from users
<kerneis>
now, for your objections
ygrek has quit [Ping timeout: 248 seconds]
<kerneis>
(1) I don't understand how loading a cmo directly is different from finding a cmo with findlib and then loading it
<kerneis>
I don't get your point at all in fact
<kerneis>
I'm just saying that you are (unnecessarily) tying this feature to findlib
<kerneis>
whereas findlib should only be a way to ease the lookup of modules
<kerneis>
hmm, I got it
<kerneis>
you're not arguing about -plugin vs. -plugin-pkg, but about this approach of plugins in general
<kerneis>
(2) I thought you said you didn't plan to support that case anyway, but I need to thinks more about it
<kerneis>
back to (1): just like Daniel's last comment on the PR, I don't understand what is different between giving modules on the command-line and specifying them in myocamlbuild.ml to be dynamically loaded
<gasche>
there is no dynlinking at all in ocamlbuild's plugin system so far
<kerneis>
(note that in all of this, I agree the -plugin-tags works-around the issues, I'm just not convinced I understand the rationale)
<kerneis>
oh, right
<kerneis>
you statically link
<kerneis>
during the first stage
<gasche>
yep
<gasche>
so I've been wary of introducing some
<kerneis>
why is that better?
<gasche>
to be frank, I'm not sure
<gasche>
Nicolas Pouillard evidently knew about plugin dynlinking from his Camlp4 experience, and he avoided that in ocamlbuild
<kerneis>
disclaimer: I'm in the middle (or rather the end) of converting CIL modules from a statically linked model to a dynamically-linked one
<kerneis>
but it's a different context
<gasche>
what kind of features would CIL plugins bring in?
<gasche>
in any case
<gasche>
if I were to add a magical tag/option "use this .cmo as a plugin", I could give it a semantics that does not assume initialization-time side-effects
<kerneis>
gasche: currently, when people want to extend CIL, they have to take the source, ./configure --with-extrafeature=theirplugin && make
<kerneis>
with plugins, they just build a plugin against the (installed) CIL library, and dynlink it
<gasche>
for example I could say that if you add the option -plugin-mod foo.cmo, I'll add a call to use_plugin (module Foo : PLUGIN_MODULE); in myocamlbuild.ml
<gasche>
with use_pugin doing something like, dispatch (Foo.init ())
<gasche>
(I'm not sure that's a good idea because I don't really like implicit code)
<gasche>
on the contrary, if I dynlink, I'm pretty much tied to the init-time semantics of the module
<gasche>
so we could provide a registration service to still keep freedom about the initialization time, as Camlp4 does
<kerneis>
but I mean, even if you statically link, you still have init-time semantics, isn't it?
<gasche>
but so far I found this all sounds fishy, and explicit use of *libraries* in myocamlbuild.ml is a better model
<gasche>
of course, but there are other options
<kerneis>
now, this is something I (almost) agree with: libraries sound good
<gasche>
in particular, were -plugin-mod to enforce this kind of interface, that would provide strong pressure to plugin authors not use that interface that favors explicitly-called observable effects
<gasche>
-not
<gasche>
+to
<kerneis>
except if you want to tell your users: just add <true>: plugin-pkg(foobar) in your _tags file
<kerneis>
it would be convenient, but maybe brings in too much complexity
<gasche>
well that still doesn't prevent foobar from being distributed as a library
introom has joined #ocaml
<kerneis>
but it needs an interface to hook up into dispatch
<gasche>
(if I give this special semantics to plugin-pkg, of passing a specific function of Foobar to `dispatch`)
<gasche>
yep
<gasche>
hm
<kerneis>
so, we in fact need two things:
<kerneis>
(1) a way to use libraries in myocamlbuild.ml
<kerneis>
(2) an interface to register an entry point into dispatch, and an option in ocamlbuild (and _tags?) to load a module using that interface
<kerneis>
the "good style" would be to write a library
<kerneis>
and provide a separate, dummy module which does only the dispatch hook
<kerneis>
so that users can either use your functions, or your predefined actions
<gasche>
note that (2) is not really needed, it's only useful for convenience, but yes
<kerneis>
yes, (2) can even be added later
<kerneis>
if we want to ship this soon, I mean
<kerneis>
the first version could require users to write their own myocamlbuild.ml
<gasche>
of course, (2) is not planned short-term
<kerneis>
which is fine
<gasche>
I always focused on (1) so far
<gasche>
hm
<gasche>
something else that makes me see (2) as less important than eg. Daniel, is that currently I don't think we can get rid of myocamlbuild.ml completely
<gasche>
I understand the urge of people to avoid it and stuff everything in _tags instead, but from a design p.o.v. it often doesn't work
<gasche>
(... as this experience with overloading _tags with plugin-compilation-time information helped demonstrate)
<gasche>
my current plan is more to better document how to write myocamlbuild.ml files, and progressively isolate the 90% usage cases in "myocamlbuild libraries" (or upstream) to make them as simple as possible
ulfdoz has joined #ocaml
<gasche>
I don't think we should jump to "magic" tags that are convenient but don't fit very well in the existing tag model
<kerneis>
agreed
<gasche>
that said, I had another idea about _tags (welcome to the Sunday Morning OCamlbuild Brainstorming Session)
<kerneis>
wait
<gasche>
whic comes from the remark of Daniel that he feels ocamlbuild's information is split in too many files already
<gasche>
(waiting)
<kerneis>
(carry on, in fact, I'll keep thinking and come back ;-)
<gasche>
my idea was to have a file, say `_config`, that would be seen from ocamlbuild as a piece of filesystem describing the project
<gasche>
I mean that it would have different sections, whose header would be path names (relative to the project), and the content would be the file content
<kerneis>
it would be easy to provide that would generate it for existing projects, to ease migration
<kerneis>
+a tool
<gasche>
well the two ways could also cohabitate peacefully
<kerneis>
the only downside is that it breaks the model where you clone locally subprojects and build them all (but this model doesn't work very well with ocamlbuild)
<kerneis>
then you need to decide who wins in case of conflict
<gasche>
well
<kerneis>
well, it's already the case with multiplt _tags file I guess
<gasche>
and we can also fail instead of making choices
<rks`>
I like that idea
<rks`>
(oh no, wait, yet another file? oh well.... ok.)
<gasche>
it would be possible to overload _tags meaning to have that
<gasche>
but I don't think it's a particularly good idea
<gasche>
hm
<rks`>
neither do I
<rks`>
_config is fine.
<kerneis>
so, what was the problem with merlin again?
introom has quit [Read error: Connection reset by peer]
<kerneis>
linking unix twice, but I don't remember why
introom has joined #ocaml
void64 has quit [Ping timeout: 248 seconds]
zpe has quit [Remote host closed the connection]
introom has quit [Read error: Connection reset by peer]
<gasche>
the problem is that, in the way plugin compilation was hardcoded in ocamlbuild before I started making it modular
introom has joined #ocaml
<gasche>
unix is linked with the plugin (because Unix features are used at various places by ocamlbuild)
<gasche>
if you add tags that also have the semantics of linking unix, such as package(unix) or use_unix, unix gets linked twice
<gasche>
and ocamlopt is not really friendly if two identical .cmxa are passed: it fails with an error
<kerneis>
ok
<gasche>
the root of the problem is a design issue I found annoying but ignorable at first: the (true: foo) stuff really doesn't belong to plugin compilation
<kerneis>
but it's not only true
<gasche>
I tried to hack around that at first, but the ocamlbuild implementation really does not want to let you use _tags line for anything else than their natural predicate semantics
contempt has quit [Remote host closed the connection]
<kerneis>
people might use <**/*> or <**/*.cmxa> without realizing the consequences
<gasche>
yeah
<gasche>
(except it was the tags of "myocamlbuild.ml" so .cmxa wouldn't have worked)
<kerneis>
*.ml
<gasche>
my solution was to plug out the "use what's in _tags" idea and use explicit command-line passing instead
<gasche>
this one is less invasive from this point of view
<kerneis>
and mine was "use only the <myocamlbuild.*> line", but it violates principle of least surprise
<kerneis>
ok
<kerneis>
I think your solution works
<gasche>
well "use only this line" really requires to hack the implementation in unnatural ways
<gasche>
so I finally dropped that
<kerneis>
we need to add a warning if _tags contains a <myocamlbuild.*> line then
<gasche>
I don't think anything so specific is needed; we could just warn for predicates that don't match anything
<gasche>
(well except it's hard to implement in a good way)
zpe has joined #ocaml
<gasche>
note that we never had such a warning and nobody protested
contempt has joined #ocaml
<gasche>
use-cases for the warning would be people having heard about the modular-ocamlbuild work, but not the recent change in interface
<gasche>
and an easier solution is to document
introom has quit [Read error: Connection reset by peer]
<kerneis>
ok
<gasche>
re. whether it would be wiser to revert the whole patchset for 4.01
introom has joined #ocaml
<gasche>
there is still a space open for regressions: to make the whole modular-ocamlbuild approach work I had to delay the time at which plugins are compiled with respect to rule loading, etc.
<kerneis>
(note that -plugin-tags does not allow for fine-grained tagging to build local ocamlbuild plugins, but I guess it's fine a least in the first place)
<gasche>
you can use "ocamlbuild -no-plugin plugin_part.cmo"
<kerneis>
and this will use _tags?
<gasche>
yes
<kerneis>
fine
<gasche>
it's partly unsatisfying because you'll get warnings for tags in the _tags file that are defined in myocamlbuild.ml
<kerneis>
not everything needs to be doable from within ocamlbuild
<gasche>
yeah, in practice most projects have a makefile wrapper for stuff that is easier to do with bare shell scripts :]
void64 has joined #ocaml
<gasche>
re. the _config idea
<gasche>
I don't think I'll have time to implement that in the couple of coming months
<gasche>
so if anyone is interested in providing a patch...
<gasche>
( rks` ? )
<gasche>
I'd like to focus on documentation and warnings first, then performance
<kerneis>
sounds more important
<rks`>
gasche: why not
<gasche>
something else I would be interested in getting done is collecting existing plugins for ocamlbuild
<gasche>
I know pippijn has some
<gasche>
OASIS certainly has interesting stuff as well
<gasche>
it would be nice to start packaging them
<pippijn>
libocamlbuild-noweb-ocaml
zpe has quit [Remote host closed the connection]
introom has quit [Read error: Connection reset by peer]
introom has joined #ocaml
cdidd has joined #ocaml
csakatoku has joined #ocaml
introom has quit [Remote host closed the connection]
void64 has quit [Ping timeout: 264 seconds]
<gasche>
pippijn: do you have a link to the sources of your plugins again?
<gasche>
(I assume what you just pasted in a Debian package name, but googling it returns nothing)
contempt has quit [Read error: Operation timed out]
void64 has joined #ocaml
contempt has joined #ocaml
ollehar has joined #ocaml
csakatoku has quit [Remote host closed the connection]
<pippijn>
gasche: these are not well-written or generic, at all
<pippijn>
gasche: because I didn't really want to spend much time on the build system
<pippijn>
gasche: it works(/worked) for me
introom has joined #ocaml
ygrek has joined #ocaml
introom has quit [Remote host closed the connection]
ttamttam has quit [Quit: ttamttam]
weie has joined #ocaml
weie_ has quit [Ping timeout: 264 seconds]
zpe has joined #ocaml
zpe has quit [Ping timeout: 256 seconds]
ollehar has quit [Ping timeout: 248 seconds]
contempt has quit [Ping timeout: 240 seconds]
contempt has joined #ocaml
contempt has quit [Ping timeout: 248 seconds]
contempt has joined #ocaml
talzeus has quit [Read error: Connection reset by peer]
zpe has joined #ocaml
n06rin has joined #ocaml
zpe has quit [Ping timeout: 248 seconds]
introom has joined #ocaml
zpe has joined #ocaml
zpe has quit [Ping timeout: 245 seconds]
Myk267 has joined #ocaml
zpe has joined #ocaml
zpe has quit [Ping timeout: 245 seconds]
ollehar has joined #ocaml
talzeus has joined #ocaml
talzeus has quit [Remote host closed the connection]
talzeus has joined #ocaml
csakatoku has joined #ocaml
zpe has joined #ocaml
zpe has quit [Remote host closed the connection]
csakatoku has quit [Remote host closed the connection]
Drup has joined #ocaml
ulfdoz has quit [Ping timeout: 256 seconds]
trans_finite has joined #ocaml
BiDOrD_ has joined #ocaml
othiym23` has joined #ocaml
hnrgrgr_ has joined #ocaml
thizanne has quit [Read error: Operation timed out]
transfinite has quit [Ping timeout: 240 seconds]
ipoulet_ has quit [Read error: Operation timed out]
companion_cube has quit [Read error: Operation timed out]
hnrgrgr has quit [Read error: Operation timed out]
othiym23 has quit [Ping timeout: 240 seconds]
BiDOrD has quit [Remote host closed the connection]
jlouis has quit [Read error: Operation timed out]
fayden has quit [Read error: Operation timed out]
q66 has quit [Ping timeout: 240 seconds]
alexey has quit [Read error: Operation timed out]
q66 has joined #ocaml
jlouis has joined #ocaml
alexey has joined #ocaml
companion_cube has joined #ocaml
ipoulet has joined #ocaml
tianon has quit [Read error: Connection reset by peer]
tianon has joined #ocaml
hnrgrgr_ is now known as hnrgrgr
zpe has joined #ocaml
n06rin has quit [Quit: Leaving.]
thizanne has joined #ocaml
n06rin has joined #ocaml
fayden has joined #ocaml
contempt has quit [Ping timeout: 245 seconds]
contempt has joined #ocaml
zpe has quit [Ping timeout: 264 seconds]
ulfdoz has joined #ocaml
contempt has quit [Ping timeout: 264 seconds]
contempt has joined #ocaml
structuralist has joined #ocaml
csakatoku has joined #ocaml
csakatoku has quit [Ping timeout: 248 seconds]
zpe has joined #ocaml
ttamttam has joined #ocaml
ttamttam has quit [Client Quit]
zpe has quit [Ping timeout: 245 seconds]
n06rin has quit [Quit: Leaving.]
contempt has quit [Ping timeout: 246 seconds]
contempt has joined #ocaml
talzeus has quit [Ping timeout: 276 seconds]
cdidd has quit [Ping timeout: 246 seconds]
cdidd has joined #ocaml
talzeus has joined #ocaml
zpe has joined #ocaml
n06rin has joined #ocaml
structuralist has quit []
csakatoku has joined #ocaml
csakatoku has quit [Ping timeout: 260 seconds]
ollehar has quit [Ping timeout: 256 seconds]
breakds has joined #ocaml
ben_zen has joined #ocaml
contempt has quit [Ping timeout: 264 seconds]
contempt has joined #ocaml
contempt has quit [Ping timeout: 246 seconds]
contempt has joined #ocaml
introom has quit [Remote host closed the connection]
n06rin has quit [Quit: Leaving.]
contempt has quit [Ping timeout: 264 seconds]
contempt has joined #ocaml
ben_zen has quit [Ping timeout: 276 seconds]
tane has joined #ocaml
darkf has quit [Quit: Leaving]
ygrek has quit [Ping timeout: 276 seconds]
zpe has quit [Remote host closed the connection]
malc has joined #ocaml
contempt has quit [Ping timeout: 245 seconds]
contempt has joined #ocaml
zpe has joined #ocaml
introom has joined #ocaml
walter has quit [Quit: This computer has gone to sleep]
introom has quit [Ping timeout: 260 seconds]
contempt has quit [Ping timeout: 240 seconds]
mcclurmc has quit [Quit: Leaving.]
contempt has joined #ocaml
contempt has quit [Ping timeout: 256 seconds]
contempt has joined #ocaml
malc has quit [Ping timeout: 240 seconds]
contempt has quit [Ping timeout: 246 seconds]
contempt has joined #ocaml
contempt has quit [Ping timeout: 256 seconds]
contempt has joined #ocaml
contempt has quit [Quit: Lost terminal]
ulfdoz has quit [Ping timeout: 245 seconds]
turnersr has joined #ocaml
yacks has joined #ocaml
Neros has joined #ocaml
csakatoku has joined #ocaml
ggole has quit []
csakatoku has quit [Ping timeout: 264 seconds]
wmeyer has joined #ocaml
<wmeyer>
hello.
<wmeyer>
ping adrien
<kerneis>
hello wmeyer
gustav_ has quit [Ping timeout: 264 seconds]
gustav_ has joined #ocaml
tane has quit [Read error: Operation timed out]
gustav_ has quit [Remote host closed the connection]
gustav_ has joined #ocaml
void64 has quit [Read error: Connection reset by peer]
void64 has joined #ocaml
Snark has quit [Quit: leaving]
<wmeyer>
kerneis: hello
<pippijn>
hi wmeyer
<wmeyer>
hi pippijn
<kerneis>
everybody wants to welcome wmeyer, except adrien who is not here :-)
<kerneis>
« Mais la lune n'est pas là, et le soleil attend... »
<bernardofpc>
ou Godot ?
<rks`>
.
<bernardofpc>
(how many people here know OCaml from being in France ?)
<bernardofpc>
(precisely asked because even if I'm not French, that's where I heard about it)
<kerneis>
(for what it's worth, I always quote in the original language when I know it, and even sometimes when I don't)
<kerneis>
I discovered it because I studied in France indeed
* pippijn
is always here, therefore is never welcomed
ontologiae has joined #ocaml
tane has joined #ocaml
<wmeyer>
rks`: hello.
<rks`>
eh :)
<rks`>
how are you wmeyer
<rks`>
how are you wmeyer?
<rks`>
(oups)
<wmeyer>
rks`: OK, you? :-)
ben_zen has joined #ocaml
<rks`>
wmeyer: good :)
ben_zen has quit [Ping timeout: 246 seconds]
<wmeyer>
kerneis: :D
<wmeyer>
haven't been here for quite long
<wmeyer>
my hard driver failed recently and I wasn't fast fixing it
<wmeyer>
/driver/drive/
contempt has joined #ocaml
<ousado>
wmeyer: o//
<wmeyer>
ousado: \\o
<whitequark>
has anyone here tried cross-compilation in ToT ocaml?
tane has quit [Quit: Verlassend]
zpe has quit [Remote host closed the connection]
<wmeyer>
whitequark: as far I can tell it's not yet implemented, there is some mantis issue around it, and we are all waiting for adrien to submit final patches
<whitequark>
wmeyer: very interesting. which platforms would it support?
<whitequark>
could I do linux->osx? ->freebsd? ->windows?
<wmeyer>
it's being tested for cross compilation on linux to windows mingw-{32,64}, of course once the patches go in, we will try to cross compile to the other platforms or architectures
<whitequark>
really awesome.
mcclurmc has joined #ocaml
<levi>
wmeyer: I was wondering what happened to you. :)
<wmeyer>
I think I (not intentionally) made adrien turn off or his having a vacation I hope. The bottom line here is that I need some time to commit the patches :-)
<wmeyer>
and that's most likely would be this week
<wmeyer>
levi: hi, sorry, HDD failure, plus lot of work, nothing specific really :)
csakatoku has joined #ocaml
<wmeyer>
levi: where is your fork of Indigo? The interface does not seem to show me your repository
pkrnj has joined #ocaml
zpe has joined #ocaml
ben_zen has joined #ocaml
Simn has quit [Read error: Connection reset by peer]
zpe has quit [Ping timeout: 260 seconds]
<wmeyer>
whitequark: thanks.
<wmeyer>
cross compilation would be really nice, i keep saying that, but always people neglect it
<whitequark>
wmeyer: nonono, I really really want it, if I can help somehow, let me know
<whitequark>
well, I really don't want to use Windows, rather.
<whitequark>
(and OS X, incidentally, but that's another story.)
<whitequark>
wmeyer: do you think it will work with C libraries? I think LLVM bindings are packed up as a bunch of .a's
<wmeyer>
adrien has put significant effort to cross compile several tens of packages on linux
<wmeyer>
so I don't think there is any problem like this
<whitequark>
excellent
<wmeyer>
whitequark: as for help, you can just do some testing on your favourite platform. I don't mind addtional patch, they are always welcome, if that helps
<whitequark>
yeah, will test. I'll also probably try to marry it with clang and/or os x, but not sure if it works out or I have enough time.
<wmeyer>
however at the moment, I envy people having 48 cores, the build takes consiredable time, and testing all the permutations is not easy or pleasant either ...
<wmeyer>
but I have to say I don't have specific platfrom in mind apart mingw for testing
<wmeyer>
btw, as for clang, clang driver has completely different set of flags
<wmeyer>
there are ones interesting in the gcc mode
<whitequark>
I see
gnuvince has quit [Ping timeout: 245 seconds]
<wmeyer>
I wish to see the whole triple supported one day :-)
<wmeyer>
but thank to adrien he has made a great effort to make it possible.
<whitequark>
triple ?
void64 has quit [Remote host closed the connection]
<wmeyer>
yes target triple
<wmeyer>
the 3 variables that describe the target
<whitequark>
ah
ontologiae has quit [Ping timeout: 245 seconds]
void64 has joined #ocaml
zpe has joined #ocaml
zpe has quit [Ping timeout: 246 seconds]
<adrien>
wmeyer: you're going to suffer soon :D
<adrien>
whitequark: do you already have a C toolchain targetting mac os x?
<adrien>
if not, you might want to start now
<adrien>
maybe you'll have something by 2015
<whitequark>
adrien: :D
mcclurmc has quit [Quit: Leaving.]
<wmeyer>
adrien: I'm suffering already :S :S
<wmeyer>
adrien: please submit the patches :-) and I will do my best to review them and commit them this week
<wmeyer>
adrien: great, can't wait to review them.
<whitequark>
adrien: I'd really like to have a buildbot which could compile my compiler for all target platforms, so I'll try to get it to work
<adrien>
wmeyer: basically I make a makefile that "include config/Makefile" and has a rule which runs "echo FOO=$(FOO)"
<adrien>
whitequark: good luck; afaik it's really annoying
ollehar has joined #ocaml
<whitequark>
it is >_<
<wmeyer>
fully agree it's annoying
<wmeyer>
adrien: we don't have enough testing of the cross compilation patches, and don't know how to test it apart from regural build bots for the packages you submitted
<adrien>
I don't think there's anything to tests right now
<adrien>
I'm fairly sure they'll need another pass of fixes (I'm pessimistic by nature)
zpe has joined #ocaml
csakatoku has quit [Remote host closed the connection]
<wmeyer>
that was a notification that cross compilation patches are in big need adrien! :D
<wmeyer>
if you work on this, you will be blessed by the windows users :-) In essence OCaml backends are flexible enough to make it possible.
gnuvince- has quit [Remote host closed the connection]
zpe has quit [Ping timeout: 256 seconds]
TDJACR has quit [Read error: Connection reset by peer]
zpe has joined #ocaml
pkrnj has quit [Quit: Computer has gone to sleep.]
zpe has quit [Ping timeout: 264 seconds]
<wmeyer>
gasche: thanks for patching ocamlbuild, it looks like you've made a big progress. Keep it going, I'm observing the commits.
<wmeyer>
massaging the ocamlbuild_test.ml is also good, happy to see the testsuite system I developed is in full production at the moment.