<chsn>
why does bucklescript have so many lines? it's just a new backend right?
<chsn>
I would have expected something on the scale of ~ 10k lines
<chsn>
instead, it's 200k
tenwit has joined #ocaml
<obj_magic>
it includes ocaml compiler source code
tenwit has quit [Client Quit]
<evhan>
Bluddy[m]: ocamlobjinfo(1) will give you some basic info.
<Bluddy[m]>
cool. But I'd like a tool/lib that's more in-depth -- like printing out the types
copy` has joined #ocaml
d0nn1e has quit [Ping timeout: 276 seconds]
d0nn1e has joined #ocaml
al-damiri has quit [Quit: Connection closed for inactivity]
rgrinberg has joined #ocaml
thizanne has quit [Ping timeout: 250 seconds]
adelbertc has quit [Quit: Connection closed for inactivity]
ygrek has quit [Ping timeout: 260 seconds]
FreeBirdLjj has joined #ocaml
govg has quit [Ping timeout: 276 seconds]
FreeBirdLjj has quit [Remote host closed the connection]
struktured has joined #ocaml
manizzle has quit [Ping timeout: 244 seconds]
FreeBirdLjj has joined #ocaml
nicholasf has quit [Remote host closed the connection]
struktured has quit [Ping timeout: 244 seconds]
nicholasf has joined #ocaml
rgrinberg has quit [Ping timeout: 250 seconds]
adelbertc has joined #ocaml
FreeBirdLjj has quit [Remote host closed the connection]
manizzle has joined #ocaml
kushal has joined #ocaml
manizzle has quit [Read error: Connection reset by peer]
AlexDenisov has joined #ocaml
nicholas_ has joined #ocaml
nicholasf has quit [Ping timeout: 240 seconds]
nicholasf has joined #ocaml
nicholas_ has quit [Ping timeout: 265 seconds]
MercurialAlchemi has joined #ocaml
tmtwd has joined #ocaml
sdothum has quit [Quit: ZNC - 1.6.0 - http://znc.in]
FreeBirdLjj has joined #ocaml
FreeBirdLjj has quit [Ping timeout: 276 seconds]
AlexRussia has joined #ocaml
govg has joined #ocaml
MercurialAlchemi has quit [Ping timeout: 276 seconds]
FreeBirdLjj has joined #ocaml
govg has quit [Ping timeout: 276 seconds]
FreeBirdLjj has quit [Ping timeout: 240 seconds]
govg has joined #ocaml
govg has quit [Ping timeout: 276 seconds]
tmtwd has quit [Ping timeout: 240 seconds]
kevinch has joined #ocaml
<chsn>
is there something like clojure/figwheel for ocaml/bucklescript?
MercurialAlchemi has joined #ocaml
napis has joined #ocaml
<napis>
I created a menhir .messages file and generated the `message(int -> string)` function. But how can I use it? I don't know the way to access the state of the menhir generated parser
<reynir>
Is there a convenient function somewhere to make human readable strings from numbers? e.g. 16384 ~> "16K"
freusque has quit [Quit: WeeChat 1.4]
freusque has joined #ocaml
<Algebr``>
reynir: I think core had something for that
AlexDenisov has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
<Algebr``>
I tried factoring it out once but it was a hassle to remove all the core stuff
napis has quit [Ping timeout: 264 seconds]
<Algebr``>
would have been nice as a separate small lib
larhat has joined #ocaml
larhat has quit [Quit: Leaving.]
larhat has joined #ocaml
jwatzman|work has joined #ocaml
Sim_n has quit [Read error: Connection reset by peer]
Simn has joined #ocaml
freusque has quit [Quit: WeeChat 1.4]
tane has quit [Quit: Leaving]
picolino has quit [Ping timeout: 265 seconds]
Simn has quit [Read error: Connection reset by peer]
Simn has joined #ocaml
picolino has joined #ocaml
sh0t has joined #ocaml
Simn has quit [Read error: Connection reset by peer]
Simn has joined #ocaml
filp has joined #ocaml
nicholasf has quit [Remote host closed the connection]
freusque has joined #ocaml
freusque has quit [Client Quit]
freusque has joined #ocaml
nicholasf has joined #ocaml
Simn has quit [Write error: Connection reset by peer]
Simn has joined #ocaml
freusque has quit [Client Quit]
freusque has joined #ocaml
freusque has quit [Client Quit]
<Leonidas>
infinity0: maybe delimcc?
<Leonidas>
oh, ggole already mentioned it
manizzle has joined #ocaml
manizzle has quit [Client Quit]
manizzle has joined #ocaml
chambart has joined #ocaml
<companion_cube>
so much magic
Simn has quit [Read error: Connection reset by peer]
Simn has joined #ocaml
ygrek has joined #ocaml
ggole has quit [Ping timeout: 252 seconds]
Simn has quit [Read error: Connection reset by peer]
Simn has joined #ocaml
picolino has quit [Ping timeout: 258 seconds]
picolino has joined #ocaml
tane has joined #ocaml
<infinity0>
i'll take a look, thanks
ggole has joined #ocaml
ygrek has quit [Ping timeout: 252 seconds]
filp has quit [Quit: Bye]
FreeBirdLjj has quit [Remote host closed the connection]
Simn has quit [Read error: Connection reset by peer]
adelbertc has quit [Quit: Connection closed for inactivity]
Simn has joined #ocaml
lorantalas has quit [Remote host closed the connection]
larhat1 has joined #ocaml
larhat has quit [Read error: Connection reset by peer]
<Algebr``>
delimcc looks amazing
fraggle_ has joined #ocaml
fraggle_ has quit [Read error: Connection reset by peer]
fraggle__ has joined #ocaml
TheLemonMan has joined #ocaml
yegods has quit []
Guest41028 has quit [Ping timeout: 276 seconds]
kandu has joined #ocaml
kandu is now known as Guest94222
nicholasf has quit [Ping timeout: 276 seconds]
nicholasf has joined #ocaml
sdothum has joined #ocaml
silver has joined #ocaml
chambart has quit [Ping timeout: 265 seconds]
lorantalas has joined #ocaml
bamco has joined #ocaml
bamco has quit [Client Quit]
orbifx-m has joined #ocaml
<orbifx-m>
mrvn: why is it that a custom block can't contain a value? Assuming we register that value.
<nicoo>
infinity0: What do you want coroutines for, btw?
<nicoo>
(delimcc isn't an exceedingly nice thing; it's really cool, but it has quite a bit of magic in the implementation)
tristero has quit [*.net *.split]
troydm has quit [*.net *.split]
fraggle-boate has quit [*.net *.split]
dinosaure has quit [*.net *.split]
rbocquet has quit [*.net *.split]
justin_smith has quit [*.net *.split]
vishesh has quit [*.net *.split]
SimonJF has quit [*.net *.split]
Algebr`` has quit [Ping timeout: 240 seconds]
fraggle-boate has joined #ocaml
SimonJF has joined #ocaml
vishesh has joined #ocaml
justin_smith has joined #ocaml
rbocquet has joined #ocaml
dinosaure has joined #ocaml
troydm has joined #ocaml
tristero has joined #ocaml
Algebr`` has joined #ocaml
FreeBirdLjj has joined #ocaml
AlexDenisov has joined #ocaml
lorantalas has quit [Quit: bye]
fraggle__ is now known as fraggle_
lorantalas has joined #ocaml
<flux>
infinity0, you can whip up something similar to with continuation passing style
<flux>
infinity0, or then you can check out the new experimental ocaml multicore branch ;-), where within domains (a single core) you have fast threads
Algebr`` has quit [Ping timeout: 250 seconds]
_andre has joined #ocaml
Fleurety has quit [K-Lined]
Algebr`` has joined #ocaml
Algebr`` has quit [Ping timeout: 255 seconds]
Algebr`` has joined #ocaml
<ggole>
orbifx-m: registration can't handle pointing into an object that is moved into the GC, afaik
<ggole>
Er, moved *by* the GC
Algebr`` has quit [Ping timeout: 264 seconds]
FreeBirdLjj has quit [Remote host closed the connection]
<mrvn>
orbifx-m: only blocks outside the heap can be registered with the GC or it chokes once it's moved.
<orbifx-m>
Ok makes sense.
<mrvn>
s/blocks/pointers/
<orbifx-m>
Guess it would be too much work to deal with that scenario
pierpa has joined #ocaml
<ggole>
There's no current mechanism to deal with it.
lorantalas has quit [Quit: bye]
<ggole>
You don't get a notification when a block moves, and it might be expensive to add one.
lorantalas has joined #ocaml
<gasche`>
delimcc is interesting (but a bit experimental), another way is to write your code in continuation-passing style directly
rgrinberg has joined #ocaml
<gasche`>
finally the multicore-OCaml project also has some runtime supports for cheap delimited continuations (the basis of the "effects" machinery in particular), but they're not released yet
rgrinberg has quit [Quit: WeeChat 1.5]
rgrinberg has joined #ocaml
chambart has joined #ocaml
fraggle-boate has quit [Quit: Quitte]
nicholasf has quit [Remote host closed the connection]
nicholasf has joined #ocaml
<flux>
cool. my gtk-based app is apparently leaking memory. C-bindings are involved, but I wonder, how much might it affect that lablgtk disables (AFAIK) gc compaction?
<flux>
it's allocating tens of video frames per second and then discarding them
<mrvn>
WTF? 1) how do you do that? 2) how does it ever free memory if it does?
<flux>
I use curl, libjpeg and gtk
<flux>
I think it must leak somehow slowly, because it takes quite a while to grow into 9 gigabytes
<flux>
the app receives jpeg images about one megabyte per second
<def`>
what if you do a Gc.full_major () ?
<def`>
is it any better ?
<flux>
I'll try at home to add a menu option to do that
<def`>
Also, logging Gc.stat () could help seeing what's going on in OCaml heap
<def`>
(the leak is likely to be on C-side)
<flux>
ok, so if I leaked just all jpeg frames (uncompressed) I would be leaking 3.6 gigabytes per hour
<flux>
and obviously if I leaked the uncompressed frames I would leak even faster
<def`>
For that kind of use case, you should have your own pool manager
<flux>
it's been running since the 27th and its virtual size is now 9 gigabytes
demonimin has joined #ocaml
<flux>
def`, so let's assume it's on the C side, what's the best tool to find it?
<flux>
I might usually just use valgrind, but I guess it won't work well with ocaml+c
<flux>
also valgrind might be too slow to usably run this app, though not sure if it would affect this issue
<def`>
the problem is that it will be very slow
<flux>
there is this clang-basead solution by google that's apparently fast, but I don't know how easy it is to use with ocaml
<flux>
..and if it works
kushal has joined #ocaml
<def`>
flux: you can profile with tcmalloc
AlexDenisov has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
<Bluddy[m]>
what happened to codoc? It was so happening, and then it... died?
<orbifx-m>
mrvn: it does crash around the major gc
AlexDenisov has quit [Ping timeout: 276 seconds]
freusque has joined #ocaml
freusque has quit [Read error: No route to host]
kreas has joined #ocaml
MercurialAlchemi has quit [Ping timeout: 265 seconds]
<orbifx-m>
Actually I don't know if it crashes because gc. It actually crashes by qt
AlexDeni_ has quit [Ping timeout: 265 seconds]
AlexDenisov has joined #ocaml
<gasche`>
Bluddy[m]: it's still being worked on I believe, and may be discussed at the upcoming OCaml Workshop in September
shinnya has joined #ocaml
<Bluddy[m]>
gasche`: good to know. It's kinda one of the foundational missing pieces as far as the ecosystem is concerned. I tried to resuscitate ocamloscope, but its code is a hot mess. dock-ock would be a much better solution
<Bluddy[m]>
*doc-ock
<Bluddy[m]>
gasche`: what do you think of including namespaces as an option in ocamlbuild? That would make it more popular and allow for more projects to transition to a namespaced code style
<Bluddy[m]>
gasche`: also, it would be really nice to include some of the popular workflows, such as compiling a ppx and then applying it to the same project
<rgrinberg>
there, a concrete example. Nope, that should be about it.
<rgrinberg>
It's rather new
<Bluddy[m]>
I remember agarwal being pissed off at ocamlbuild's design. I guess this is his answer to that?
<rgrinberg>
agarwal1975: can you answer? ^_^
<rgrinberg>
i don't understand either. if you're going to be writing your own build rules, might as well generate a makefile
<rgrinberg>
ocamlbuild's api is bad and its only saving grace is the extensive built in rules for ocaml projects
<agarwal1975>
Hi, I’m the author of solvuu-build.
<companion_cube>
rgrinberg: but it's far more powerful than make
<Bluddy[m]>
rgrinberg: I hear you, but I have to take that with a grain a salt, since you like manual dependencies :)
<companion_cube>
heh
<rgrinberg>
Bluddy[m]: ocamldep works with make just as well.
<Bluddy[m]>
hey agarwal1975. I remember you being ticked off at ocamlbuild's design choices. Is this your response, to try and fix it to your liking?
<agarwal1975>
Sorry there is no README. It has been under active development, and I didn’t think it was ready for others to use yet. However, it is pretty reasonable now, and some others have started using it.
<Bluddy[m]>
rgrinberg: but make is awful. As in, awful awful.
kushal has quit [Quit: Leaving]
<agarwal1975>
Yes, I think ocamlbuild has gotten quite a few things wrong, and I’m just making something that I like better. That’s all.
<Bluddy[m]>
agarwal1975: could you explain some of your changes? Looks like you're abandoning _tags files?
<companion_cube>
I think everything is in one (.ml) file
<agarwal1975>
One goal of solvuu-build is to express your entire in only one file and that file should be ocaml.
<Bluddy[m]>
yes. I like that a lot
<rgrinberg>
agarwal1975: how much of the ocamlbuild api do you use?
<rgrinberg>
just the dependency tracking?
<flux>
what if myocamlbuild.ml supported loading modules from say directory "ocamlbuild"? alternatively/additionally by using some some findlibbable criteria?
<flux>
I've found myself copypasting my myocamlbuild.ml files between projects..
<agarwal1975>
It seems pointless to me that we introduce more syntax and litter our whole repo with little files, when if you’re using ocamlbuild, certainly you’re an ocaml programmer and ocaml is nicer, right?
<Bluddy[m]>
I totally agree. The tens of files thing makes no sense
<agarwal1975>
Only part of ocamlbuild that solvuu-build is: create rules as ocamlbuild requires, and thus ocamlbuild tracks the dependenices and executes the rules.
<flux>
each ocaml file should automatically get turned into a `SourceFileName and then there'd be a function to find file names by their symbol and vice versa.. statically checked build scripts :)
larhat1 has quit [Read error: Connection reset by peer]
larhat has joined #ocaml
<Bluddy[m]>
agarwal1975: What do you think of adding the option to use the namespaces plugin features? Integrating that in as well?
<agarwal1975>
That part is much better than Make, which is why solvuu-build doesn’t simply use a Makefile. There’s no comparision. I’m writing ocaml code, have elegant abstractions, run commands and capture stdout and parse it, and all kinds of other things that would be excruciating in Make.
<Bluddy[m]>
are you producing normal executable files, or .native/.byte stuff? Also, is there any way to completely get rid of make by having target choices?
<agarwal1975>
I should mention my main complaint with ocamlbuild. It overreached in its goals. It tries to let you have “zero configuration”. On simple projects, you can write absolutely nothing, and just do “ocamlbuild foo.cmxa” and its built-in rules do it all. That sounds awesome at first.
<flux>
solvuu_build does seem interesting
<flux>
sadly the opam version doesn't seem to build for me :) # File "lib/solvuu_build.ml", line 111, characters 22-29: # Error: This expression has type 'a -> 'a -> int # but an expression was expected of type 'b list
<agarwal1975>
Please pin to master. It is in far too much flux still.
<agarwal1975>
ocamlbuild’s magic is accomplished by registering a bunch of default rules.
<agarwal1975>
However, those rules obviously need to be alterable because different projects obviously will need different things.
<flux>
agarwal1975, does it do well for making libraries involving C code and C libraries yet?
<agarwal1975>
So how to make them alterable, by inventing this highly complicated concept of tags.
<agarwal1975>
It should work with C files, but it has been tested only minimally. Biocaml has just one C file, but solvuu-build is also being tested out by the author of ocephes, which is a binding to a C library.
<flux>
some natural way to work with Ctypes would be nice
<agarwal1975>
The whole tags thing is a way of parameterizing over the rules, but as OCaml programmers we already have an elegant way of parameterizing things, i.e. functions.
<Bluddy[m]>
agarwal1975: this all sounds great, and needs to be in the readme, so other people can find this and help contribute
<flux>
I guess the standard way to extend solvuu is to just write more ocamlfind packages and then write some magic to the Makefile?
<rgrinberg>
agarwal1975: can solvuu express moderatly complex dependencies?
<agarwal1975>
So really we just want functions that register different rules depending on what arguments you give.
<rgrinberg>
say I'd like to build a preprocessor and then use it to preprocess the rest of the sources in my project
<agarwal1975>
solvuu-build promotes doing it this way, just write ocaml functions for whatever you want.
<companion_cube>
agarwal1975: would there be a way to compose solvuu files (plugins?) same as ocamlbuild?
kreas has quit [Remote host closed the connection]
<companion_cube>
so I can just add cppo in one line?
<flux>
I suppose solvuu is not in position to do anything about ocamlbuild's performance issues with large projects?
kushal has joined #ocaml
<Bluddy[m]>
flux: that has to be solved within ocamlbuild itself, but if solvuu-build solves things well enough, then it's worth it to put in the effort to improve ocamlbuild
<flux>
it is sort of sad how the blindin' fast ocaml compile times are lost in the build system.. :)
<agarwal1975>
I’m using solvuu-build for a pretty broad range of projects, including static site generators, projects that generate whole opam repos as build artefacts, projects that download packages from NPM as part of the build. Not all of what you need is already supported in solvuu-build, but the point is doesn’t need to be.
<agarwal1975>
Just add your own rule for whatever you need.
MercurialAlchemi has joined #ocaml
<rgrinberg>
agarwal1975: ok that's good. What i'm trying to say is that something like oasis is too opinionated.
<agarwal1975>
comanion_cube: Does ocamlbuild really support composing plugins. What do we mean by “compose”. Is there actually any property that is maintained when you compose two plugins, such as they don’t step on each other’s rules?
<agarwal1975>
Also oasis is not ocaml. I just want to write my build configuration in the same language I already like for everything else.
<agarwal1975>
rgrinberg: Supporting moderately complex dependencies isn’t in solvuu’s purview. I think that is just up to ocamlbuild’s rule system. Right, or maybe I’m misunderstanding your question.
<Bluddy[m]>
agarwal1975: I think you're going to want to share the popular rules. solvuu-build should have a way to specify findlib packages to load.
<agarwal1975>
Yes, it supports findlib package dependencies. Actually, currently that is required.
<agarwal1975>
Rules that seem to be general purpose enough can certainly be exposed in the mli.
<Bluddy[m]>
agarwal1975: so i can load remote rules to run?
<agarwal1975>
Or more correctly, functions to register the rules. That’s important because then these functions can take any number of arguments, to allow customization of the rules as much as needed.
<companion_cube>
agarwal1975: if you want to hl me, use tab-completion
<agarwal1975>
What’s a “remote rule”?
<companion_cube>
and I suppose ocamlbuild composes if the plugins declare orthogonal rules
<companion_cube>
i.e. rules that never overlap
<agarwal1975>
Sure, but then that just means you can rules on top of rules. Sure, I mean the Project.basic1 function (the main starting point for declaring a build artefact) has an “additional_rules” argument. Go ahead and give more rules.
<Bluddy[m]>
agarwal1975: I just want to get the point across. Plugins with popular rules would be on opam, and I can specify them as opam dependencies (for opam to download), and then in my local myocamlbuild, I can just use those popular rules with some small tweaks.
<Bluddy[m]>
agarwal1975: is this currently possible?
<agarwal1975>
Yes, that’s totally doable. That’s what solvuu-build is. The support for that is in ocamlbuild really.
dmiller has quit [Ping timeout: 240 seconds]
<agarwal1975>
No reason you can’t tell ocamlbuild to load solvuu-build and another project, and then call functions from both projects.
<Bluddy[m]>
agarwal1975: Oh. I didn't realize that. I thought only the myocamlbuild.ml was loaded.
<Bluddy[m]>
agarwal1975: I guess I do that with command line stuff, right?
<agarwal1975>
Yes, only myocamlbuild.ml is loaded, but within that file you can call functions from other projects.
<companion_cube>
can the myocamlbuild require stuff from ocamlfind?
<companion_cube>
that would be amazing, we would have packages for easing the build
<companion_cube>
e.g. a rule for generating a version.ml file from the git repo, or whateve
<companion_cube>
r
<agarwal1975>
What your other project shouldn’t do IMO is register a bunch of rules as a side effect of loading. There should be a function that has to be called.
kushal has quit [Quit: Leaving]
yomimono has joined #ocaml
<Bluddy[m]>
companion_cube, agarwal1975: that's what I want to understand. If I can call ocamlbuild with no command line args, and myocamlbuild loads specialized plugins from ocamlfind and runs that code.
<agarwal1975>
Yes, ocamlbuild supports that. That is how solvuu-build works. See the -plugin-tag flag.
<companion_cube>
agarwal1975: well, once you have a good set of defaults and a good documentation, you should make as much noise as possible ;-)
<companion_cube>
I wonder if solvuu could be a fork of ocamlbuild
<companion_cube>
(instead of depending on it)
<companion_cube>
so you just ship/depend on the ocamlbuild engine + solvuu default rules
<companion_cube>
(and throw all the old ugly stuff by the window)
<agarwal1975>
Typing `ocamlbuild -use-ocamlfind -plugin-tag “package(solvuu-build”) foo.cmo` a hundred times a day is obviously too burdensome, so the makefile we generate does a trick that let’s you just type “make _build/foo.cmo” for every build artefact.
<agarwal1975>
I deliberatetly have the makefile targets include the _build prefix. I don’t think it is good to hide it as ocamlbuild does.
<agarwal1975>
To remove solvuu-build’s dependency on ocamlbuild, we need a rule engine.
<agarwal1975>
In fact, ocamlbuild’s rule engine, though superior to make, isn’t the best we know about.
<Bluddy[m]>
What would be really nice is if there was a convention like ocamlscript, and myocamlbuild.ml had a prefix section that could provide all the command line stuff. Then there's no need for makefiles.
<agarwal1975>
The better answer is that rules should form a monad, as done for example by Jenga.
<agarwal1975>
Yes, that was discussed for ocamlbuild. I’m trying to find the link.
<companion_cube>
agarwal1975: by forking ocamlbuild, I meant putting solvuu's rules in an ocamlbuild branch, and purge all the old stuff
<companion_cube>
so that the ocamlbuild rule engine would automatically load solvuu, but not the tag system
<agarwal1975>
Oh right, if the community wanted that, certainly that would be great IMO.
<orbifx-m>
mrvn: let me know if you get some free time
<agarwal1975>
BTW, internally I also have rules for compiling ocsigen projects. I’ll add them to solvuu-build soon.
<Bluddy[m]>
agarwal1975: I've noticed already that almost every time I read your comments in a git issue, it's like you read my mind
<agarwal1975>
But importantly, if you don’t use ocsigen, these rules won’t get registered and pollute your rule space.
<agarwal1975>
:) That’s why GitHub is great. Whatever issue you’re having, certainly someone else has it too.
<Bluddy[m]>
indeed
kushal has joined #ocaml
<Bluddy[m]>
agarwal1975: how did you come up with the company name solvuu? How is it supposed to be pronounced?
<agarwal1975>
It is pronounced “solve view”. It was the only domain name I could get after trying about 500 different names. :)
<Bluddy[m]>
ha!
<Bluddy[m]>
but there's no natural connection to genomics in the name. Were they all taken?
<agarwal1975>
That is a deliberate strategic choice. Solvuu’s core technology is not fundamentally related to genomics, though that is certainly our first and primary target market. But I think this is off topic for this channel.
fjkdka2 has joined #ocaml
<Bluddy[m]>
also: does it make more sense to just use jenga as the underlying tool and forget about ocamlbuild? Jane Street will undoubtedly put boundless effort into improving performance. Why compete with them when you can join them and use their tech?
<Bluddy[m]>
i know you suggested it, i'm just asking if a switch makes more sense
<agarwal1975>
Jenga doesn’t seem right in several ways. In JS’s defense, they’ve openly stated that Jenga is not ready for general consumption and they know the API needs to be improved.
<Bluddy[m]>
ok fair enough. ocamlbuild it is.
<companion_cube>
jenga lives in the JST ecosystem, it's far too fat for me
<agarwal1975>
But last year I spent 4 days trying to use it, and after all that I hadn’t managed to write a `clean` rule.
<agarwal1975>
It was crazy!
<Bluddy[m]>
hehe that's crazy
<agarwal1975>
I just wanted to rm a file, and sometimes it would get removed and sometimes not. I just couldn’t figure it out.
<Bluddy[m]>
i guess there's value in simplicity here
<agarwal1975>
I’m definitely more okay with dependencies than many, but a build tool does seem to be the one place that even I agree you want less dependencies.
malc_ has joined #ocaml
<Bluddy[m]>
yeah definitely. My aim isn't for myself btw, I want to help craft the 'perfect average minimal effort build tool' for the OCaml ecosystem, and solvuu-build definitely seems like the right direction
<Bluddy[m]>
I don't like so many of the default design decisions in ocamlbuild, but I love how you were able to cut through that mess and just use its good parts.
<companion_cube>
there is a lot of room for optimization here
Sorella has quit [Quit: Connection closed for inactivity]
<gasche`>
Bluddy[m]: I haven't had the time to play with the namespace plugin myself
jwatzman|work has quit [Quit: jwatzman|work]
<gasche`>
but I'm not a-priori opposed to including it upstream
<gasche`>
(and I'm also very interested in proposed changes to the backend that would make it and other tools like solvuu easier to build
<gasche`>
)
<gasche`>
I haven't read my IRC backlog yet but I see that you mention Jenga
<gasche`>
let me point out that the idea of trying to re-implement ocamlbuild's rules on top of a Jenga-powered backend has been mentioned before, and I think Jane Street may be interested in funding an experiment in that direction
<gasche`>
so if you know someone willing to spent a few months on that...
<gasche`>
*spend
<gasche`>
of course there are also people that dislike ocamlbuild's default rules (and rule-declaration API which is far from perfect) and would rather start from scratch
adelbertc has joined #ocaml
<gasche`>
(a jenga backend for ocamlbuild would make sense for people that have working projects and want to have shorter build times or better parallelization)
<gasche`>
(I think that there are also nice ideas in the Jenga API that would improve the experience of defining new ocamlbuild-like rules if they were made available)
<gasche`>
aslo Bluddy[m] , hm, I'm not sure why you seem obsessed with ".byte/.native" as an ocamlbuild defect
<rgrinberg>
gasche`: does it really make sense to pursue this ocamlbuild on top of jenga thing until jenga has a trimmed dependency profile?
<gasche`>
(I suspect that's either a misunderstanding somewhere or a personal annoyance on your part that is, in absolute terms, very far from the top of things that should be improved in ocamlbuild or done better in another build system)
<rgrinberg>
i'm convinced that one of the reasons people like ocamlbuild is the fact that it's so slim
<gasche`>
well rgrinberg I have no time to pursue it anyway
<Bluddy[m]>
gasche`: because I want a complete solution that users can use and can compete with cargo etc. You can't have an ocaml app produce a .native file just because it happens to be made in OCaml
<gasche`>
but copying your .native file into something named differently is like, super-easy
<Bluddy[m]>
gasche`: only if you wrap ocamlbuild with something else, which I don't want to do
<gasche`>
well you can also do this in the myocamlbuil.ml easily
<gasche`>
(there is a "copy_rule" function I believe)
<Bluddy[m]>
ok that sounds fine
<gasche`>
but note that some people (not Ashish obviously that is going the opposite way) strongly dislike writing OCaml code as part of their build description
<gasche`>
(and have a Makefile wrapper or an oasis file on top anyway that they would rather use)
<Bluddy[m]>
I think the dislike is only there for trivial projects. I'd much rather have a single OCaml file (so long as its not incredibly complex) than a _tags file etc
<Bluddy[m]>
Ocamlbuild's plugin_tags are great, because they mean you can have plugins for more complex rules off in the (opam) cloud, while your own build rules remain simple. A simple myocamlbuild.ml file is great.
<gasche`>
if you or someone else is willing to implement a pull-request to make this possible in a generic way in ocamlbuild, be my guest
<gasche`>
(for _tags it is very easy and doable today, but to avoid foo.mllib you would have to give a rule for it which is heavier than required)
johnelse is now known as johnel_away
johnel_away is now known as johnelse
ebird has quit [Quit: ERC (IRC client for Emacs 25.1.50.2)]
<Bluddy[m]>
well it seems like solvuu-build is trying to do precisely this
ldopa has quit [Quit:]
AlexDenisov has joined #ocaml
<gasche`>
I would be happy to steal the parts that make a nice API for defining things that require auxiliary files with today's ocamlbuild rules
ldopa has joined #ocaml
ldopa has quit [Client Quit]
<Bluddy[m]>
ok, that's good to hear
<gasche`>
ocamlbuild is a collaborative project and I would be happy to give commit rights to people motivated to help improve it
orbifx-m has quit [Ping timeout: 252 seconds]
orbifx-m has joined #ocaml
<gasche`>
I'm also perfectly fine with people working on other build systems if they have their own view, and support diversity in the ecosystem (I think it's great that omake gets first-class oasis support for example)
ldopa has joined #ocaml
Sorella has joined #ocaml
<gasche`>
what I strive to do on my own time is fix ocamlbuild bugs, have it support the evolution of the language, and improve usability where reasonably possible; but already that is a bit too much work
<gasche`>
(usability includes documentation)
<Bluddy[m]>
i think our target needs to be something very close to cargo. As close as we can get. Have you seen my thread on reddit (https://www.reddit.com/r/ocaml/comments/50n3wm/whats_missing_in_the_ecosystem/)? People want a build system that just works with minimal effort, all the way through. I would personally also like to see namespaces become a thing, even if it's only in the build system at first.
<Bluddy[m]>
And I really appreciate your work, including the new manual, which is really terrific.
octachron has quit [Quit: Page closed]
<gasche`>
hm
<gasche`>
cargo (or the "go" tool) mix a lot of concerns, and a large part of their work is at the opam or oasis level
<gasche`>
regarding builds specifically, my impression is that the build-system part of cargo is not very expressive, and in particular I see no support for outside-the-language code generation
<ggole>
Integration has its advantages
<gasche`>
(which is fine if you think that any metaprogramming will happen through the language-blessed macros, but (1) I'm skeptical and (2) it clearly wouldn't work for the OCaml ecosystem of today)
<gasche`>
sure
<ggole>
At the cost of being in hot water if you screw something up very badly
<gasche`>
today we have too much friction caused by the layering of different tools
<ggole>
Yeah, that's hard to avoid without choosing a 'blessed' tool that gets a large swatch of responsibilities
octachron has joined #ocaml
<gasche`>
but I'm pointing out that, as far as ocamlbuild alone is concerned, I'm not sure what excellent ideas I should get from cargo
<gasche`>
(explicit suggestions are welcome)
<ggole>
OCaml is in a pretty different situation from Rust, with a drastically different "community attitudes" and history of development
<gasche`>
re. integration: I'm not sure if the "perfect solution" (assuming infinite time and resources) is a perfect unified tools, or rather separate tools that work along well-defined bounadries
<ggole>
So the relatively integrated approach might go down poorly
<Drup>
I know this is not a comment that is actually going to help you, but I'm still not convinced that the core of ocamlbuild is worth fighting for
<gasche`>
for example, I personally think that the split between "opam files" and what's below is rather neat
<gasche`>
Drup: I'm not necessarily either (but then is the core of OCaml? of what?), I'm maintaining it because it helps people in practice
<ggole>
Knowing where to put the boundaries seems like something that can go wrong easily
<gasche`>
well
<gasche`>
in practice the oasis/ocamlbuild boundary is not very good today
<gasche`>
and you can notice because you often have to answer people "well no in that case you have to go to the _tags file" etc.
<Drup>
That's an understatement :)
<gasche`>
but I've never had interactions with people expecting to put something in ./opam when it should be in _tags/myocamlbuild.ml
<Drup>
gasche`: several people expressed the expectaction not to have to put informations in both the oasis file and the opam file
<ggole>
ocamlbuild and .merlin is another example
<gasche`>
on the other hand, there is duplicate information today (between .merlin and _tags for example) that could be solved by either an oasis-style scaffolder, or stricter conventions (namespace-style, or cargo-style: there is a "test" subdirectory whose semantics is blah), or better information exchange
<gasche`>
in some respect I have the impression that the Reason people are trying to move from the "you can structure you stuff whatever you want" model inherited from C into a bondage-and-discipline notion closer to cargo/go/whatever (where you are forced to work at the level of an island of connected-but-separate rigid sub-projects)
<ggole>
The desire for fewer moving parts is understandable.
<Drup>
(on the topic of build system, what I have seen from shake was rather seducing, and since it's quite low level, building oasis on top of something similar seems like it could work)
fjkdka2 has quit [Ping timeout: 264 seconds]
<ggole>
On the other hand, I'm not sure I really want Visual Studio but for OCaml
orbifx-m2 has joined #ocaml
govg has joined #ocaml
orbifx-m has quit [Ping timeout: 250 seconds]
dmiller has joined #ocaml
<gasche`>
Drup: well you could even have oasis directly use shake, couldn't you?
Sim_n has joined #ocaml
Simn has quit [Ping timeout: 264 seconds]
<Bluddy[m]>
well jenga is very similar to shake, I think. no?
octachron_ has joined #ocaml
<malc_>
Bluddy[m]: jenga requires a lot of jane street libraries, and i had very hard time trying to build it... building shake (cabal or stack) as a lot simpler for whatever reason
<Bluddy[m]>
probably has to do with the whole 'standard library' thing...
<malc_>
then again having 800M ~/.cabal (+ GHC obviously) is quite a price to pay for a decent build system
octachron has quit [Ping timeout: 244 seconds]
Denommus has joined #ocaml
<companion_cube>
having .merlin, META, etc. coudl also be solved by having solvuu_build generate them
<Bluddy[m]>
companion_cube: yes!
orbifx-m has joined #ocaml
AlexDenisov has quit [Read error: Connection reset by peer]
AlexDenisov has joined #ocaml
orbifx-m2 has quit [Ping timeout: 250 seconds]
<rgrinberg>
Drup: you'd rather write your rules in haskell than in OCaml? :O
<rgrinberg>
as a first approximation, jenga is basically an ocaml clone of shake. So shake definitely makes little sense to me
<rgrinberg>
maybe if there was a dependency free port of shake to OCaml that would be nice
AlexDenisov has quit [Read error: Connection reset by peer]
AlexDenisov has joined #ocaml
octachron_ has quit [Ping timeout: 276 seconds]
orbifx-m has quit [Remote host closed the connection]
octachron has joined #ocaml
mfp has quit [Ping timeout: 265 seconds]
mfp has joined #ocaml
<Bluddy[m]>
the thing is, ocamlbuild is good enough(TM) IMO, especially with a few enhancements
orbifx-m has joined #ocaml
<Bluddy[m]>
gasche`: To answer your earlier question, I want to get the people who are using OCaml to concentrate on one build tool as much as possible by improving its state
<Bluddy[m]>
gasche`: That will lead to the consolidation needed to make the whole process cleaner
<Bluddy[m]>
Similar to the way opam revolutionized the ecosystem
Algebr`` has joined #ocaml
<companion_cube>
if the language used to describe a project (solvuu) is good enough, people might indeed switch
<companion_cube>
because currently they are all terrible
<Bluddy[m]>
companion_cube: and as you were saying, it appears that solvuu's approach may be able to completely replace OASIS
<Bluddy[m]>
while cleaning up all the files littering projects that people just don't want
<rgrinberg>
I'd like to see how well solvuu handles optional subprojects and bytecode only configurations
<Algebr``>
what was context re:solvuu?
<rgrinberg>
also, how easy it is to integrate stuff like bisect_ppx
<companion_cube>
Algebr``: an alternative setup for ocamlbuild, whole project description in a .ml file
<companion_cube>
rgrinberg: +1
<companion_cube>
how easy is it to enable debug, do some configuration before building, etc.
<companion_cube>
(how easy is it to replace oasis, basically)
<rgrinberg>
gasche wrote a really good post about it
<rgrinberg>
but there are also other random inefficiencies in it
<rgrinberg>
didn't ygrek get a huge perf. boost just by removing some invisible logging in a recent patch?
<Algebr``>
what about jenga, what's happening with that
<rgrinberg>
what about it? it's a non starter the dep. list is way too big
<Algebr``>
damnit.
<Algebr``>
it would be nice to take the lessons of oasis/ocamlbuild, and make something fresh
<Bluddy[m]>
rgrinberg: haven't read the post yet, but are the performance issues intractable?
<Algebr``>
and possibly keep the _oasis file format
<companion_cube>
rgrinberg: ah right
<companion_cube>
+1 at non starter
<rgrinberg>
Bluddy[m]: tractable, but you will break every single API in existence without something like effects letting you change to indirect style under the covers
<companion_cube>
theoretically, if a significant portion of the community was to move to solvuu, and IF solvuu provides a nice monadic interface that relies on OCaml
<companion_cube>
ocamlbuild*
<rgrinberg>
so actually, that's intractable in practice
<companion_cube>
at some point ocamlbuild's engine could become monadic, couldn't it?
<Bluddy[m]>
yeah it's absolutely possible
<rgrinberg>
like i said, you will need to break everything or use delimcc/effects
<Bluddy[m]>
rgrinberg: if solvuu is the only interface used, then you break everything
<Bluddy[m]>
*else
<Bluddy[m]>
i.e. just fork at that point
<Algebr``>
topkg is just for packaging right, not building?
<Bluddy[m]>
this isn't the language itself. Nobody's married to a build system -- they just want it to work
<Bluddy[m]>
if you give me a better build system, I'll switch tomorrow
<rgrinberg>
I wonder if it makes any sense to split ocamlbuild into multiple opam packages (obviously in 1 repo still)
<Algebr``>
companion_cube: having spent time with oasis, any thoughts on its future?
<rgrinberg>
this will allow things like solvuu to experiment with different build engines but still use all that ocamlbuild good stuff like shell quoting, xplatform fs calls, etc.
<rgrinberg>
the myocamlbuild dynlinking bit
<companion_cube>
well, I will use it as long as there isn't something obviously better
<companion_cube>
oh please, no, no dynlink
<Algebr``>
I also don't really see anything better...
<Algebr``>
atm
<companion_cube>
dynlink is what prevents me from building on windows right now
<rgrinberg>
companion_cube: isn't that how myocamlbuild works though?
<rgrinberg>
I could be woefully confused though
<companion_cube>
agarwal1975: in theory, c ould solvuu expose a monadic interface (that, behind the scene, relies on ocamlbuild's mutable stuff)
<companion_cube>
agarwal1975: so that later, the ocamlbuild engine could theoretically become more functional without braeking solvuu files?
<companion_cube>
rgrinberg: I think it does, and it is super annoying
<rgrinberg>
companion_cube: can you rewrite a small, cross platform jenga/shake core in ocaml <2k lines and then see if you can reimplement solvuu on top of it?
<rgrinberg>
by tuesday if possible?
<Bluddy[m]>
rgrinberg: work on front-end first, back-end later. not the same thing
<agarwal1975>
companion_cube: I suppose. I would ideally like to have a `type rule` within solvuu-build that is monadic. But then, could we map that to ocamlbuild’s rule engine? I’m not sure. Or at that point, do you have to implement your own rule executor? I actually think that would be an interesting project, but not one I can work on.
ollehar has joined #ocaml
<companion_cube>
rgrinberg: are you kidding? :D
<agarwal1975>
A build system really is a DAG executor. You want to express a DAG (possibly generated dynamically, thus monad not applicative), and an engine for incrementally processing the DAG. That would be a cool project and have used beyond build systems.
<companion_cube>
agarwal1975: the monad could bind to the usual imperative stuff at first
<companion_cube>
let (>>=) x f = f x; ()
<companion_cube>
let return x = x
<rgrinberg>
companion_cube: just mimicing some of my old managers ^_^
<agarwal1975>
Right. Hmm… maybe it wouldn’t be all that hard.
<companion_cube>
heh
<Algebr``>
agarwal1975: spending time on build systems =P
<agarwal1975>
I’m definitely reaching the limits of my time on them!
<agarwal1975>
But I can say that working on solvuu-build has been a net time saver. It definitely took less time to implement it, then the aggregate time I’ve spent over the last years on oasis, omake, ocamlbuild, omakefile, ...
<agarwal1975>
then —> than
<Algebr``>
what's slightly annoying is that no build system dies completely, like they are in some zombie state with someone coming along and reviving it, ie omake recently.
<Algebr``>
no oasis getting more attention/love
<Algebr``>
now*
<rgrinberg>
to omake's credit, it didn't deserve to die at all
<Algebr``>
right, I never quite understood why it went out of fashion?
<rgrinberg>
it's like make that's xplatform, well documented, support dynamic dependency
yegods has joined #ocaml
companion_square has joined #ocaml
<companion_cube>
oasis + omake should work, heh
orbifx-m has quit [Read error: Connection reset by peer]
<Algebr``>
should work meaning works now or ought to in the future?
<companion_cube>
should work now
<companion_cube>
Gerd has contributed it for the last release
<gasche`>
(with funding from Lexifi I think)
<gasche`>
agarwal1975: re. a monadic interface for ocamlbuild, I would be glad to support a monadic rule-action interface in ocamlbuild, as I sketched in the blog post ( http://gallium.inria.fr/blog/ocamlbuild-parallelization/
<gasche`>
)
<yunxing>
Hey, is it possible to statically link all bytecode dependencies into a bytecode executable using ocamlc?
<gasche`>
isn't it what happens by default?
cube_bot has quit [Remote host closed the connection]
companion_cube has quit [Remote host closed the connection]
<gasche`>
I worked on monadic-rules for a bit (something like one week full-time) and it worked decently and was rather easy to port
<gasche`>
the delicate side was to get an actually-parallel solver (but I'm not sure it is unsurmountable either)
<gasche`>
on the other side, the monad I use is a rather simple "dependency monad"
<yunxing>
@gasche` I'm trying to link a binary against utop using : ocamlfind ocamlc -o myutop -linkall -thread -linkpkg -predicates create_toploop -custom -package compiler-libs.toplevel,utop myutop.cmo
<yunxing>
But if I run it in another place, it errors on Fatal error: exception Fl_package_base.No_such_package("utop", "")
<gasche`>
when I looked at it, Jenga's API had more elaborate monads with a layering of dependency stuff and incremental/interruptible/refreshable computation stuff
<gasche`>
I think it would be nice to take some time to see what can be reused of a good such API
<rgrinberg>
gasche`: interesting, what's the type parameter in your monad?
<gasche`>
the result type I think
<gasche`>
basically an action is either "here is the result" or "wait I want you to recursively build this and here is a continuation where to plug the result"
<gasche`>
a point I forgot to make is that it's easy to have a transitional model where some rules are declared in monadic style, some in the legacy style
<gasche`>
(of course if you change the type of the rule-declaration API you break user plugins, but you just add the monadic declarations with new names instead)
cube_bot has joined #ocaml
companion_cube has joined #ocaml
companion_square has quit [Quit: WeeChat 1.5]
<gasche`>
(note that the ocamlbuild solver is rather small and I'm sure someone could replace it with something else if they want)
<yunxing>
What's the point of a monadic style API? support of concurrency?
<agarwal1975>
No, support for dynamically generating rules.
<yunxing>
hmm ok
<yunxing>
good point
<Algebr``>
question: Why not put this effort into opam, make opam also build code, not just package. opam is a success story, lets build on top of that?
<rgrinberg>
gasche`: are rules parameterized in ocamlbuild today? haven't looked in a while
<agarwal1975>
Sometimes you can’t know statically what your whole DAG should be.
kushal has quit [Quit: Leaving]
<Algebr``>
opam 3.0 release
<gasche`>
rgrinberg: no it's the monomorphic (env -> builder -> Command.t)
<Algebr``>
like cargo
<gasche`>
hm
<Algebr``>
or go
<gasche`>
there is something that I find rather troubling in Algebr`'s or Bluddy[m] narrative to "pick just one tool and consolidate it"
<rgrinberg>
gasche`: yeah so how does your parameterized API work? what does the rule db look like then?
<Algebr``>
gasche`: what is troubling? Is it less troubling than years of effort scattered across oasis, ocamlbuild, omake, ocamlmakefile
<gasche`>
there is the code of the experiment linked from the blog post, right now I don't remember the detail and am about to get dinner (but I can post URLs to code exmaple on the way back)
<gasche`>
the troubling part is to tell people to stop working one something because "we" decided it's better to work on something else
<gasche`>
in my experience this creates negativity and doesn't actually help much
<Algebr``>
isn't opam a success story?
<gasche`>
notice that in the opam case, this did not happen: opam occured, and people switched because it was better than the alternatives (except for people using GODI on Windows, where it is still better than the alternatives)
<gasche`>
nobody tried to tell actively "well we decide to focus on opam, let's just drop the rest"
<gasche`>
Gerd did not appreciate the way GODI was deserted, and I think it was not an easy transition for him, but he's still part of the OCaml community today and has produced a lot of valuable work since then
<gasche`>
(just like ocaml forge is, honestly, dying, but we have not alienated Sylvain)
<Algebr``>
right
<Algebr``>
well, its one opinion, but I do wish opam was like cargo, package and build code.
<gasche`>
(hm and also the idea of "just embedding a build system inside opam because opam works" is not technically very interesting; there is no difference with calling a separate tool)
<Algebr``>
sure there is...extra outside dependencies, _tags, etc...
<Algebr``>
anyway, just a silly idea I guess.
<companion_cube>
I'd rather merge ocamlbuild/solvuu with ocamlfind, and keep opam separate (at least in a first step)
<rgrinberg>
companion_cube: Algebr``: there asome pluses to this idea actually
<Algebr``>
it would be nice to tell people just opam rather than hey, there's opam, and there's then oasis and ocamlbuild and then btw under it all is ocamlfind
<rgrinberg>
one nice thing about opam is that it's the 4th (or 5th?) stdlib
<Algebr``>
and you have to write a _oasis, setup.ml, _tags, opam file
<rgrinberg>
in particular, it has a nice process/fs api that is xplatform
<rgrinberg>
so it does make some sense to use opam lib in a build system
<rgrinberg>
but otherwise, opam simply doesn't know enough about ocaml packages to be useful for a build system
<Algebr``>
rgrinberg: but could be, the opam file format is getting bigger and bigger.
<rgrinberg>
personally, it's hard or me to imagine how an opam file might describe even a moderately complex project
<rgrinberg>
i guess it would be something hpack like?
<companion_cube>
a possible issue is that opam is also designed to cater to other languages (e.g. Coq)
<companion_cube>
so it shouldn't be too tied to OCaml
<Algebr``>
yea but its de facto ocaml
<rgrinberg>
i think the more productive thing to pursue would be eliminating ocamlfind into opam
<rgrinberg>
once that is done, i will see a foundatoin for a build system
<Algebr``>
+1
<Algebr``>
Like opam rules for building unikernels would be nice.
<Algebr``>
instead of more command line tools to learn
govg has quit [Ping timeout: 264 seconds]
<malc_>
rgrinberg: what does "eliminating ocamlfind into opam" mean? the eliminating ppart specifically
<companion_cube>
rgrinberg: yeah, why not
<companion_cube>
merge the `opam` and `meta` files
<companion_cube>
keep the build system separate
orbifx has joined #ocaml
<orbifx>
rgrinberg: does opium provide anything to compose html header, tags etc? or is that not in its scope?
<rgrinberg>
orbifx: composing headers is part of cohttp's api. Cohttp.Header that is
<rgrinberg>
malc_: first that would be making all the information in META files available in opam.
<orbifx>
Both http and html headers? I'm asking about html headers here
<rgrinberg>
what do you mean by html headers?
<orbifx>
<header>...
<orbifx>
sorry, <head>..
<rgrinberg>
oh, you mean templating basically. You should just use w/e templating lib you want here.
<rgrinberg>
tyxml, jinja, mustache should all work
<orbifx>
any recommendations?
hugomg has joined #ocaml
<rgrinberg>
orbifx: tyxml
<rgrinberg>
type safety is nice
<orbifx>
type safety is a good
<orbifx>
also want to be able to have good manipulation of tag attributes, because a friend wants to push semantic web stuff
<orbifx>
tyxml you reckon?
_whitelogger has joined #ocaml
kushal has joined #ocaml
kushal has quit [Read error: Connection reset by peer]
<chsn>
Here's somethign I don't understand about *.mli and *.ml files. If in foo.ml, I have type animal = Cat Int | Dog String, and I want to use "animal" in foo.ml, do I have to redeclare it in foo.ml? (this seems like useless repetition), or does foo.ml aucomatically pull in foo.mli [my repl seems to not be doing taht]
<chsn>
Here's somethign I don't understand about *.mli and *.ml files. If in ** EDIT* foo.mli, I have type animal = Cat Int | Dog String, and I want to use "animal" in foo.ml, do I have to redeclare it in foo.ml? (this seems like useless repetition), or does foo.ml aucomatically pull in foo.mli [my repl seems to not be doing taht]
<chsn>
EDIT: it's defined in foo.mli
<rgrinberg>
yes, in general you must duplicate definitions in .ml/.mli pairs
<chsn>
okay, and I assume they also need to be identical?
<chsn>
and if I screw up, I get weird errors
<chsn>
is there a reason behind this, or is this silly and no one bothered to fix it?
<ggole>
Type definitions don't need to be identical, in fact refining types is one of the major purposes of signatures
<ggole>
Unfortunately in the very common case of just using the type as is, you have duplication.
<chsn>
I can understand if one of them is 'opaque', i.e. mlik has 'type animal' and then you can't look inside it
<chsn>
ggole: can you give an example of where the *.ml and *mli files for a single type are different AND the mli one is NOT opaque?
yegods has quit [Remote host closed the connection]
<ggole>
Private types would be the obvious example
<chsn>
I know haskell, but am new to ocaml. Can you point me to a link to read?
<chsn>
(sorry for the newb questinos)
<ggole>
Private types are sort of like newtypes
<ggole>
You can't create or mutate one directly, you have to go through the module's interface
<lyxia>
there are ways to avoid that duplication though
<ggole>
Inside the module you just have an ordinary type and can do what you like.
<mengu>
when i am in utop and try using Date.parse ~fmt string, it says unbound value Date.parse
<mengu>
what am i doing wrong?
tane has quit [Quit: Leaving]
<smondet>
mengu: did you `#require "core"` and `open Core.Std`?
<mengu>
they are already defined at the toplevel
<mengu>
but yes, just to make sure, i did that as well
<mengu>
let me try again
uberTaco has quit [Quit: And away!]
thizanne has joined #ocaml
octachron has quit [Quit: octachron]
kakadu has joined #ocaml
SilverKey has quit [Ping timeout: 240 seconds]
annoymouse has joined #ocaml
<annoymouse>
Hey
<annoymouse>
I'm trying to compile an OCaml program but I'm getting the error: "Error: /usr/local/lib/ocaml/pervasives.cmi is not a compiled interface for this version of OCaml. It seems to be for a newer version of OCaml."
<companion_cube>
sounds like a `make clean` case
zpe has joined #ocaml
<annoymouse>
companion_cube: So I should cd to my project folder and run make clean?
<annoymouse>
companion_cube: For what it's worth I installed OCaml and OPAM using brew
<companion_cube>
well, you should clean build files
<annoymouse>
My OCaml version is 4.03.x and the version I switched to in OPAM is 4.01.0
<annoymouse>
companion_cube: Which build files?
<companion_cube>
the ones you are trying to build?
<companion_cube>
I mean, you are trying to compile a project, right?
<annoymouse>
Yes
<annoymouse>
I don't see any build files though
<companion_cube>
in _build maybe
<annoymouse>
I have an ml file, an mli file, and two more mli files under External files
<annoymouse>
companion_cube: I'm using Eclipse with OcaIDE for compilation
<annoymouse>
companion_cube: Does OPAM create its own lib dir for each version?
<companion_cube>
look in the directory if there isn't a _build directory
<annoymouse>
companion_cube: I just told you the contents of the dir
<companion_cube>
opam creates a new dir for each "switch" (i.e. each compiler version)
<companion_cube>
if you're on windows it would be hidden
<annoymouse>
companion_cube: On mac
<annoymouse>
But does each switch have its own lib dir?
<companion_cube>
yes
<annoymouse>
and if so where would that be located?
<annoymouse>
that's the problem then
<companion_cube>
~/.opam/<version>/lib/
<chsn>
so I'm on chapter 4 of real world ocaml. I don't understand how importing modules work in Ocaml. In haskell, to import the module Counter, at the top of the file, I just put "import Counter"; in ocaml, how do I import module Counter ?
<companion_cube>
if it's included during compilation, it's automatically in scope
<companion_cube>
there is no "import"
<chsn>
I'm currently developing in emacs using tuareg mode
<chsn>
I'm working on freq.ml, I need it to somehow load in counter.ml also
fUD has quit [Quit: Connection closed for inactivity]
<companion_cube>
if it's in a toplevel (and you followed the setup properly), #require "foo";; will link the library foo
<chsn>
le tme try
<annoymouse>
companion_cube: Got it!
<annoymouse>
companion_cube: Thanks for your help!
<chsn>
so in my current directoyr, I have counter.ml, freq.ml; in freq.ml, I have #require "counter" ; -- and in my repl, I get "No package: counter"
<annoymouse>
Basically, Eclipse was pointing to the lib for the OCaml that was installed with brew (v4.03.0) so I had to repoint it towards the switch I installed with OPAM (v4.01.0).
companion_square has joined #ocaml
companion_square has quit [Client Quit]
agarwal1975 has quit [Quit: agarwal1975]
<companion_cube>
annoymouse: classic ^^
<companion_cube>
chsn: ah, there is a difference between a lib (e.g. core) and a mere module
AlexDenisov has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
<chsn>
companion_cube: clearly I have got my terms wrong (ocamll-er for 24 hours); I still don't understand chapter 4 of RWO -- how do I import a user-module from another user-module ?
Denommus has quit [Quit: ERC Version 5.3 (IRC client for Emacs)]
<companion_cube>
within the same project, just refer to it
<companion_cube>
(at least when you compile; in the toplevel it's another matter)
octachron has joined #ocaml
ggole has quit []
lorantalas has quit [Quit: bye]
ollehar has joined #ocaml
zpe has quit [Remote host closed the connection]
MercurialAlchemi has quit [Ping timeout: 258 seconds]
nicholasf has joined #ocaml
octachron has quit [Quit: Leaving]
ollehar has quit [Remote host closed the connection]
_andre has quit [Quit: leaving]
yomimono has quit [Remote host closed the connection]
<chsn>
I became aware of 'reason' while looking at bucklescript
<chsn>
I don't know enough about ocaml to understand ocaml vs reason frontend syntax changes
<chsn>
all the change seem pretty superficial though
<jmasseo>
sarcasm. the front page takes up my whole window and provides no content and a menu bar, so it makes sense to use the menus rather than scroll down
<jmasseo>
it seems to be mostly syntactic sugar to make it easier to deal with for people coming from other languages?
<chsn>
yeah
<chsn>
I think it's "make ocaml look like javascript
<chsn>
"
<jmasseo>
i didn't know facebook used ocaml
<jmasseo>
are they a bigger user than Jane St now?
<chsn>
market cap or ocaml usage? :-)
<jmasseo>
ocaml usage. :)
<chsn>
percentagne wise, probably not there; employee count, hard to say
<jmasseo>
i don't know how much jst is worth but i assume it's a lot.
<jmasseo>
my wife shot those ambitions down real quick. no nyc.
<chsn>
with the jst salary, should not be hard to find a new wife
<jmasseo>
haha i like the one i have.
<chsn>
(I'm kidding)
<jmasseo>
there are many means to an end
<chsn>
so I started with wanting to wirte ios/android/web apps in haskell
<chsn>
then I looked at react-native, ... which brought me to "I need haskell -> javascript"
<chsn>
but haste/ghcjs looked too heavy weight, and there was "bucklescript", so then it became "how hard could it be to learn ocaml"
<chsn>
it's a very interesting langauge coming from ahskell land
<jmasseo>
i'm gonna do the mooc again
<chsn>
besides monads/typeclases, I don't think I'll be missing much from haskell
<jmasseo>
it's pretty fun.
<jmasseo>
i have not done haskell yet
bruce_r has quit [Ping timeout: 258 seconds]
<chsn>
haskell is great *except* for the brain power involved in eyeballing a piece of code and aswking "what is the space/time usage?"
<chsn>
lazy evaluation confuses me
<jmasseo>
i do think it's literally to make it more like javascript
<jmasseo>
it has two comparisons
<chsn>
then it would really have it's merits
<chsn>
ocaml -> reason == not much of a jump
<chsn>
javascript -> reason == holy $&%)(#* makes life so much better
<jmasseo>
hahahaha
<jmasseo>
right
octachron has joined #ocaml
* jmasseo
puts the gun down.
<jmasseo>
i do hate working in javascript
<jmasseo>
i guess that is why they targetted ocaml?
<chsn>
I hate javascript so much that I've been *learning langauges taht compile to js* just t avoid learning js
thizanne has quit [Quit: WeeChat 1.5]
<chsn>
I was literrally googling around for "langauges that compile to JS" -- and lookinat at F#, Ocaml, Kotalin, Purescript, .... and finding the one closest to ahskell
<chsn>
I think it's also that the ocaml pipeline is the easiest to hack
<chsn>
the ocaml compiler, iirc, is very cleanly structured with "here's our parser" "here's our type chcker" "here's our backend"
<jmasseo>
right
<jmasseo>
ocaml is pretty legit
nicholasf has quit [Remote host closed the connection]
<chsn>
and it makes it easy to replace-parser/reason or replace-backend/bucklescript
<chsn>
whereas with haskell, ghc is pretty intimidating
<jmasseo>
i have not actually done anything with F# yet.
<jmasseo>
but i tend to like MSFT stuff.
<jmasseo>
i did a small project in ocaml with lwt and had some interesting learning experiences. :)
<gasche`>
chsn: to be fair, Fay is closer to Haskell than OCaml and ghc-js is progressing
<chsn>
gasche`: Fay lacks typeclasses
<chsn>
gasche`: ghcjs output is unreadable, and almost uncompilable
<gasche`>
(I think OCaml is an excellent language but that's because it has other compelling qualities than "close to Haskell")
<chsn>
gasche`: people who use ghcjs go as far as writing nix-os-descriptions to make sure they have all the right libs
<gasche`>
OCaml also lacks typeclasses
<chsn>
gasche`: sure, but Fay seems like a language that "syntastically is very close to ahskell since all fay progs are subsets of ahskell progs", but the typesystem of fay seems more primitiave than Ocaml's
<jmasseo>
i really liked the type system of ocaml a lot
<jmasseo>
so much that i had difficulty writing go code afterwards
<chsn>
jmasseo: lol
hugomg has quit [Quit: Ex-Chat]
<chsn>
so I need to write go to write on google app engine
<chsn>
and as a result, I've been looking to see how hard it' to write a ocaml bytecode interpreter in go
<jmasseo>
i will hopefully never ever write to google app engine
<chsn>
because the server codedoesn't have to be fast, I just need it to be safe
<jmasseo>
real talk: pike is insane.
<jmasseo>
he wrote a little APL
<jmasseo>
'Ivy'
<jmasseo>
Go is like a crack party.
<jmasseo>
it's sort of compelling though
<jmasseo>
i mean just one line and one hooker
<jmasseo>
some things are really really easy to do in go
<jmasseo>
and some things are really really hard
<chsn>
go is great if you other choice is C
<chsn>
go is not very good if you want to do functional programming
<jmasseo>
yeah in C everything is really really hard
bruce_r has joined #ocaml
<chsn>
bufferoverflows are pretty easy
<jmasseo>
zing
<jmasseo>
true bugs wait
<gasche`>
(I think we can discuss programming languages without moving into the dangerous waters of hard drugs or prostitution)
<jmasseo>
anything involving polymorphism or dynamic data is difficult in go
<chsn>
these days, I can't imagine programming without being allowed to pattern match on union types
<chsn>
case statements just don't work
<gasche`>
hm
<chsn>
I thikn this limits me to haskell, ocaml, rust, f#
<jmasseo>
i have not tried rust either
<jmasseo>
it's supposed to be nice.
<gasche`>
writing a bytecode interpreter in go should be doable, but that's assuming you reuse the runtime implemented in C (the garbage collector especially)
<jmasseo>
cgo
<chsn>
gasche`: no, but I can just leverage go's gc
<chsn>
gasche`: I don't care if it's slow
<chsn>
I just want to write ocaml code, and be able to deploy it on gae
<gasche`>
hm
<gasche`>
that might work
<chsn>
this means ocaml -> java, python, php, or go
<gasche`>
well we have an ocaml -> java compiler already
<gasche`>
OCamlJava
<gasche`>
(hm OcamlJava is many things but it can run OCaml code on the JVM)
<Drup>
rgrinberg: I don't want to use shake with opam, and I don't want to use jenga because it has billions of very heavy and non portable dependencies
<Drup>
shake with oasis*
<gasche`>
I think implementing a bytecode interpreter in Go that reuses Go's GC is doable, but the standard library has a large-ish surface of calls to C functions that would be a bit painful to reimplement (like js_of_ocaml had to do in Javascript)
<Drup>
I'm already at the point of avoiding to have jst libraries installed, because if I do an update, they take 2/3 of the time (and I don't use them except for very niche things like "helping people on IRC" and "running stuff written with core_bench" (which I can't atm, because async_extended's install crashes)
<rgrinberg>
Drup: let me guess, you're running out of memory compiling? :P
<Drup>
I have 12Go of memory, so I hope not
<chsn>
I have 32
<Drup>
(the crash is during *install*, which is even more confusing)
<companion_cube>
Drup: I so agree
<companion_cube>
I eventually removed core_kernel because it took so much time to build, and was only used for benchs
<gasche`>
opam-builder has a binary package cache in its own variant of opam
<gasche`>
I hope that we can get this into mainstream opam on as many systems as possible soon-ish
<rgrinberg>
companion_cube: really? core_kernel takes a while to build :O
<rgrinberg>
i wonder how much of that is linking
<Drup>
the opam package core_kernel takes more time to build than a compiler from scratch (for me)
<gasche`>
(opam-builder caches the build of a package and reuses it when it detect that none of the dependencies changed; I guess you would need a more general cache-sharing strategy to use it in a more general setting)
<Drup>
(granted, one is parallel makefile, the other is ... not so parallel ocamlbuild)
<orbifx>
Kakadu2[m]: here/
<orbifx>
kakadu: ?
<kakadu>
almost
<gasche`>
(the "parallel" build of the OCaml compiler is not a miracle of reliability either)
<kakadu>
orbifx: Can it wait half of an hour?
<orbifx>
possibly, might end up sleeping :P
<orbifx>
will try
<Drup>
gasche`: it's not maximally parallel, sure, but it's still quite decent (and it's reliable now, at least, it the sense that it's not wrong anymore)
<gasche`>
hm Drup, does opam actually attempt to build the compiler in parallel? I would suspect it doesn't
<gasche`>
(I encounter breakage due to wrong dependencies or excessive parallelization fairly recently when hacking on the compiler)
<Drup>
huum, opam probably doesn't, no
<Drup>
I never get any breakage, except when I do idiotic things with dependencies.
<Drup>
(just checked, I conform, opam doesn't)
Sorella has quit [Quit: Connection closed for inactivity]
<kakadu>
orbifx: I'm here
fedruantine has quit [Quit: client exited: Ex-Chat]
<jmasseo>
.u agora
<orbifx>
kakadu: I made some further changes, but in a branch cause they are unstable.
<orbifx>
my master works, but it doesn't ever free the memory
<octachron>
gasche`, what is your opinion on adding the stdlib manual exhaustiveness check to the compiler travis script?
<orbifx>
At some point we have to implement the memory recovery, for completeness
<orbifx>
In case someone creates and deletes propmaps on the fly
<orbifx>
that branch crashes when i run the stress test, about after 1200 signals. Dunno or understand why
<orbifx>
gdb says it's someting to do with Qt, possibly dealing with a pointer which is not registered properly with it
<orbifx>
was wondering if you can give it a spin too and see what you make of it
<orbifx>
had to change the block to Custom_tag for custom_ops
<orbifx>
brb
<gasche`>
octachron: the merge I did only had the minimal checking, and you are thinking of the full check, is that it?
malc_ has quit [Quit: ERC (IRC client for Emacs 25.0.50.2)]
groovy2shoes has quit [Quit: Leaving]
<octachron>
gasche`, not exactly. Damien added (somehow recently) a script that checks that all modules in stdlib/* are present in the library section of the manual
<octachron>
I was thinking that this is the kind of potential problem that could be cheaper to catch earlier
<kakadu>
It sounds stupid but when I add debug printf it works bette
<kakadu>
r
<gasche`>
octachron: so I don't know the details but no negative opinion (especially if the check is fast, which sounds like it is the case)
<orbifx>
kakadu: ok, could be the other those are called then. And maybe property maps have some requirements for getting deleted
<orbifx>
send me an email, cause it's time for me to get a rest
<orbifx>
fresh eyes on this will help better most likely
<kakadu>
I will not have one in nearest future TT
tane has joined #ocaml
<orbifx>
one what?
<kakadu>
eyes
<orbifx>
fresh eyes? :P get some sleep then
<kakadu>
It's too easy
<kakadu>
In the morniong I'm kind of forced to do some shit that seems needed but I really don't want to
<kakadu>
And in the evening I'm tired
<orbifx>
such is our culture
<orbifx>
maybe it the vicious cicle can be broken ;)
<orbifx>
anyway, maybe catch you tomorrow
<kakadu>
I know when it weill be broken but I need to do some stuff before
<octachron>
gasche`, the check is indeed quite fast (~0.08s?), thanks for the opinion
orbifx has quit [Ping timeout: 276 seconds]
<gasche`>
octachron: I was going to recommend you to ask Damien (which I suspect has clerer opinions than I do), but then it's kind of hard to reach him in these release days