<rdutra>
Hello. I'm building ocaml in an Alpine Linux (ppc64le arch) and trying to use ocamlc but I'm getting a segfault.
<rdutra>
Gdb points to 'do_relocs' function (ldso/dynlink.c:379) from musl loader but I'm not sure if it is a problem in musl loader or something in ocaml. Any chance someone already saw this?
<smondet[m]>
rdutra: I haven't seen this, but i've noticed that there are opam switches espcially for musl ; maybe related? (see `opam switch -a | grep musl`)
alfredo has quit [Ping timeout: 246 seconds]
troydm has joined #ocaml
<adrien>
and hmmm, docker?
<rdutra>
smondet[m]: will take a look. The tricky is that ocamlc works on Alpine x86_64 but crashes in Alpine ppc64le
samrat has joined #ocaml
Enjolras has joined #ocaml
<orbifx[m]>
Sup camels?
Enjolras has quit [Read error: Connection reset by peer]
MercurialAlchemi has quit [Ping timeout: 260 seconds]
<rdutra>
adrien: not docker, inside a VM
<reynir>
orbifx[m]: not much, just super frustrated about some buggy software at work
<orbifx[m]>
Windows? :P
<reynir>
No, not a MS product :)
<reynir>
It's a product built upon xen. When I was editing the disks for a VM it scrambled the order of the network interfaces, and it broke everything. :|
<rgrinberg>
orbifx[m]: not sure what you expect. I think the current situation is pretty fair
foocraft has quit [Quit: Leaving]
<orbifx[m]>
Which is? I wasn't proposing an alternative, just wanted to know what it will be :)
zpe has quit [Ping timeout: 255 seconds]
<rgrinberg>
The current situation is make a PR and convince jeremie it's a good idea. Seems to work pretty well :D
<orbifx[m]>
Ok :P
<orbifx[m]>
how is ocamlbuild governed?
<companion_cube>
same as the compiler itself, I think? or maybe by the community now
aniou_ is now known as aniou
snowcrshd has quit [Remote host closed the connection]
snowcrshd has joined #ocaml
<rgrinberg>
I dunno, it seems like gasche fulfills a fairly similar role to jeremie
<companion_cube>
gasche is very careful never to break compatibility; I don't know how much this will apply to jbuilder…
<rgrinberg>
Which is why I think these discussions become less as useful as they become more abstract
<rgrinberg>
I agree with that cube, but id also say thats a likely cause of ocamlbuild stagnating
<rgrinberg>
And jbuilder is nowhere near as mature to be this careful
<companion_cube>
well it will have once half the ecosystem depends on it
<companion_cube>
it will have to*
<gasche>
I wouldn't see myself as an ocamlbuild governor, rather a caretaker :-'
snowcrshd has quit [Ping timeout: 240 seconds]
<gasche>
historically the OCaml community has dealt with governance after the fact
<gasche>
like OPAM moved from opam.ocamlpro.com to ocaml.org once it became obvious that it was the right choice
<orbifx[m]>
I have confidence in the people involved. It's been brought this far. Just wanted to know how it's been done and how it will continue.
<gasche>
I think for now Jérémie is doing a fine job handling the project. I see the compatibility worries (it is certainly the case that the Jane Street ecosystem generally cares less about breaking the code of third-party users), but I think that jbuilder is actually in a decent space there -- if I'm not mistake, Jérémie has built in versioning within the description format
<gasche>
(I'm not sure anymore actually, can someone confirm?)
FreeBird_ has quit [Remote host closed the connection]
<orbifx[m]>
A good, widespread builder is the next most important tool than the compiler & language themselves.
<gasche>
personally the governance model I would like best for pillars of the ecosystem is "community-maintained"
FreeBirdLjj has joined #ocaml
<companion_cube>
totally agree
<gasche>
but I must say that in the OCaml projects that live off it (Batteries, ocaml.org), it only works to some extent
<hannes>
gasche: yes, there seems to be a jbuilder_version by now (not used by everybody, since it was only recently introduced)
<gasche>
as a community we are not very good at maintaining a communal infrastructure; maybe this is a size issue
<gasche>
on the other hand
<gasche>
I personally think that jbuilder is overrated right now; it is not the "clearly best choice that all the major players have adopted" that some people describe
<gasche>
it is a fine tool (better than its competitors in many respect), has great potential, but the discussions about it as a standard build system inform us more about the irrational role of fashion and early-adopters in tech culture than careful community planning
boojinks has quit [Quit: leaving]
<gasche>
which is, you know, perfectly fine as far as I'm concerned: if we can collectively hypnotize ourselves into helping build the perfect tool, what is there not to like?
<gasche>
(what I'm less enthusiastic about is seeing people get irritated when it is pointed out that the emperor has only half the clothers/parentheses)
<rgrinberg>
Well, I haven't seen that many good tools come out of careful community planning. So in my opinion that is much more overrated
<gasche>
yep
<companion_cube>
what about libraries? :p
<companion_cube>
many good libraries come from the community (and tools, too, like merlin)
FreeBird_ has joined #ocaml
<companion_cube>
doesn't mean they have been written by everyone cooperatively, but still
<gasche>
hm, I'm not sure what you mean by "community" there
<gasche>
Merlin was built by a tight-knit handful of people
<rgrinberg>
companion_cube: I think you're a counter example yourself
<rgrinberg>
See containers vs batteries
<gasche>
they were not affiliated to any major company, but I don't think that makes a big difference here (jbuilder is still pretty much a one-man stand with some external contributions)
<companion_cube>
I'd consider containers to be sufficiently open to be part of the community :3
<companion_cube>
maybe I'm mistaken, of course
<mrvn>
so? 1000 people all building one tool on their own and sharing them is still a good thing
<rgrinberg>
I have the same opinion as you about jbuilder
<mrvn>
I have no idea what jbuilder is, can't eb "clearly best choice that all the major players have adopted"
<gasche>
in fact with Merlin there are parallels with jbuilder in the sense that people started pushing for it before it became completely clear that it was the right tool for the purpose
<gasche>
(well, it wast clear to me because I liked the design, and I tried to help push for its adoption early on)
<companion_cube>
it was pretty clear from the beginning, imho, because there were no alternatives
FreeBirdLjj has quit [Ping timeout: 276 seconds]
<companion_cube>
unlike build system where the market is already quite fragmented
<gasche>
so maybe opam would be a better comparison
<gasche>
(or topkg/oasis)
<companion_cube>
oasis started as a one person effort, but did attract some contributions
<companion_cube>
(not sure it's the right tool though…)
<rgrinberg>
Imo jbuilder is far more of a community project that oasis
<companion_cube>
really??
<rgrinberg>
Yup. Oasis integrates far better with things that the community finds important
<rgrinberg>
Like opam
<companion_cube>
you mena jbuilder
jbrown has joined #ocaml
<rgrinberg>
Oh yes. :P
<companion_cube>
that's cheating a bit, jbuilder is much more recent
<gasche>
Now we are in this weird dynamic where people say things that are technically not always convincing, but may be what we need to convince ourselves of to maximize medium-term payoff -- and discussing this too critically raises tensions that are best avoided. So let's go for it!
<Drup>
gasche: similarly, I'm carefully entusiastic about jbuilder because I believe the design is much much much better than anything else
<rgrinberg>
Oasis has problems with being pinnable as a dev-repo
<rgrinberg>
I don't think I'm exaggerating in any way
jlam_ has joined #ocaml
<Drup>
(which does not mean it's the best for everything *now*)
<companion_cube>
rgrinberg: not with the dynamic-generation stuff
<companion_cube>
I agree oasis has some very ugly parts though, and will probably have to die at some point
<companion_cube>
but jbuilder isn't expressive enough yet for me
<gasche>
one thing that I dislike about the conversation is the idea that not being flexible is a feature, not a bug
<rgrinberg>
I second drup here too. I contributed to jbuilder because I found it easy and fun
<rgrinberg>
And not because of early adoper fervor ;)
<companion_cube>
gasche: depends for what ^^
<companion_cube>
rigid layout for a project is actually nice, I think
<gasche>
I think the idea is wrong, and I'm surprised how quick people are to adopt it
<companion_cube>
not having generci rules for cppo sucks
<rgrinberg>
While with ocamlbuild I always struggled the api or the code base
jlam has quit [Ping timeout: 255 seconds]
<gasche>
rgrinberg: thanks for your contributions to jbuilder and porting packages, by the way
<gasche>
I think you played a major role in the interest for the tool that exists today
<gasche>
(and I think that this may not be a role that Jérémie would have played on his own)
<Drup>
gasche: that's a different discussion though. jbuilder's internal engine is flexible enough, and in ways that are much more usable than ocamlbuild (let's be honest, ocamlbuild's rules are an horrible mess and defining new ones was always an expert task)
<gasche>
re. flexibility: the problem is that people conveniently confuse "the tool forces me to express things in a certain way rather than another" and "the tool does not let me do things / only handles some instances of the things in a ad-hoc way"
<gasche>
Drup: sure, the internal engine is very nice
<gasche>
the "problem", if I may say so, is the interface layer between the engine and the user; it is fairly unflexible and each new feature currently comes as an ad-hoc invasive change to the codebase
<rgrinberg>
gasche: I think that someone would have played my role eventually. When a good tool is created that solves real problems like jbuilder, it's only a matter of time. See how quickly the mirage people caught on
<companion_cube>
because they have some very specific needs
<companion_cube>
otoh it seems my needs are not really met (yet)
<gasche>
rgrinberg: unfortunately some things never catch on (adoption is unpredictable)
<rgrinberg>
Ah yes like building things at reasonable spees
<rgrinberg>
Speed*
<companion_cube>
like building 30 packages from one repo
<Drup>
gasche: I don't think user-defined rules need to be defined in-syntax
samrat has joined #ocaml
<gasche>
re. ocamlbuild: if I had the time (and perception of worthiness) to reimplement ocamlbuild on top of jbuilder's rule logic, I think it would be an excellent move
<gasche>
I already had this idea wrt. Jenga, but never had the time to work on it
<Drup>
meh. ocamlbuild's UI is not good
<rgrinberg>
Exactly
<Drup>
(also, the rules are top-down instead of bottom-up)
<companion_cube>
it's good for compatibility…
<Drup>
(which is _wrong_)
<gasche>
I'm not saying the result would be better than jbuilder
<gasche>
(it would be better than today's ocamlbuild!)
<companion_cube>
I think gasche has a point
<rgrinberg>
Jbuilder's frontend is far better than Oasis. And it's backend is far better than ocamlbuild
<companion_cube>
not everyone is willing to port the build system in all their projects
<rgrinberg>
The convergence seemed inevitable
<gasche>
companion_cube: on the other hand, most current users of ocamlbuild are sort of ok with its disappointing speed
<companion_cube>
rgrinberg: is there something for ctypes, too, in there?
<companion_cube>
gasche: yeah, it's bad, but I can live with it
<companion_cube>
(but I don't want to spend an horrible afternoon porting my stuff :/)
<rgrinberg>
companion_cube: sure there is. See async_ssl for an example. It's a bit manual but works fine
<Drup>
gasche: About flexibility, one conversation I had with jeremy, and which I believe is a good way forward is "try to build up new rules, see where we need to place the hooks in the code base, and then use dynlink for plugins"
<gasche>
I think that it's a bit late for ocamlbuild to reinvent itself as a build system, because both the backend and the frontend would need to change
<gasche>
solvuu-build, on the other hand, has decent frontend ideas and would benefit from using jbuilder's backend I think
<rgrinberg>
Paradoxically, jbuilder is flexible enough to support ctypes with less hassle than ocamlbuild :)
<Drup>
rgrinberg: huh, not really at the moment
<Drup>
ctypes in ocamlbuild is trivial now ... because several people wrote the (complicated) rules for it
* Drup
waves hand a little bit
<gasche>
Drup: I think seeing how that goes (jbuilder + third-party-implemented tool support) is the major open question right now
<Drup>
gasche: I agree
<companion_cube>
also I'd like having some support for qtest, if the build system is that awesome
<Drup>
As I said, I'm cautiously enthusiastic :p
<Drup>
gasche: personally, jbuilder seems like the only way of having a reasonably decent build system for eliom
<Drup>
(ocamlbuild just doesn't work, I spend a lot of time on it)
<gasche>
right now I think (as I said before) that a tool that only support a closed-world view of the ecosystem is a source of risk/danger in term of future ecosystem health
<gasche>
we should all meet with Jérémie around ICFP and organize a jbuilder design/hacking session!
shinnya has quit [Ping timeout: 240 seconds]
<Drup>
gasche: amusingly, I completely agree with what you just said, but I think I don't have the same definition of "closed-world" :p
<gasche>
rgrinberg: would you remind me where you are physically, whether you plan to attend the OCaml workshop, and whether you'd join such a thing?
<gasche>
(what do others thing? I'm about to send Jérémie an email to discuss the idea)
<Drup>
companion_cube: isn't qtest just a library ?
<rgrinberg>
Probably not. Too bad...
<companion_cube>
no, that's qcheck
<companion_cube>
qtest is the tool to extract tests from comments
<Drup>
oh, right
<companion_cube>
(and yes, I prefer it to ppx for now)
samrat has quit [Ping timeout: 255 seconds]
<Drup>
yeah, that's hurt badly by the lack of patterns in rules, I suppose
<gasche>
others of the chan, would you like to join a jbuilder event?
<companion_cube>
maybe remotely? I don't attend ICFP ^^
<Drup>
(only after having sent my phd thesis to my referees :D)
<gasche>
companion_cube: why not?
<gasche>
:-'
<companion_cube>
becaues I don't publish there
<companion_cube>
and I already go to 2 conferences this year \o/\o/
ryanartecona has quit [Quit: ryanartecona]
<companion_cube>
(ok, afk for the evening, I'm in Amsterdam right now)
<companion_cube>
(and I'd like jbuilder to have generic rules so I can migrate… ;)
yomimono has quit [Ping timeout: 240 seconds]
jbrown has quit [Ping timeout: 255 seconds]
jbrown has joined #ocaml
samrat has joined #ocaml
<gasche>
I sent an email to Jérémie :-)
ryanartecona has joined #ocaml
gasche has left #ocaml ["ERC (IRC client for Emacs 24.5.1)"]
sgronblo has quit [Ping timeout: 240 seconds]
<zozozo>
damn, woke up too late to answer gasche :p
sepp2k has quit [Quit: Leaving.]
tane has joined #ocaml
ziyourenxiang has quit [Ping timeout: 268 seconds]
yomimono has joined #ocaml
slash^ has joined #ocaml
FreeBird_ has quit [Remote host closed the connection]
FreeBirdLjj has joined #ocaml
FreeBirdLjj has quit [Ping timeout: 268 seconds]
AlexRussia has quit [Ping timeout: 268 seconds]
mrkgnao has quit [Ping timeout: 255 seconds]
copy_ has joined #ocaml
rdutra has quit [Quit: Leaving.]
yegods has joined #ocaml
AlexRussia has joined #ocaml
ontologiae has quit [Ping timeout: 276 seconds]
yomimono has quit [Ping timeout: 240 seconds]
rdutra has joined #ocaml
yomimono has joined #ocaml
rdutra has quit [Quit: Leaving.]
rdutra has joined #ocaml
zpe has joined #ocaml
<reynir>
oh damn, I get stack overflow when I try to build uunf
yegods has quit [Remote host closed the connection]
shakalaka has quit [Quit: bye.]
shakalaka has joined #ocaml
snowcrshd has joined #ocaml
kevinqiu has joined #ocaml
shinnya has joined #ocaml
ygrek_ has joined #ocaml
<kevinqiu>
Hi, I was wondering why these two decalrations result in different types. It seems like it has to do with printf using GADTs but I'm not really familiar enough with that to understand what's going on. "let fn fmt = Printf.ksprintf (output_string stderr) fmt" results in "('a, unit, string, unit) format4 -> 'a" while "let fn = Printf.ksprintf (output_string stderr)" results in "('_a, unit, string, unit) format4 -> '_a"