<Vaur>
well right now it only generate the doc for the modules used by my program, I dont know where to put text that would describe the program itself
NoNNaN has quit [Remote host closed the connection]
NoNNaN has joined #ocaml
freling has joined #ocaml
boogie has joined #ocaml
tlockney is now known as tlockney_away
q66 has quit [Ping timeout: 252 seconds]
boogie has quit [Remote host closed the connection]
jwatzman|work has quit [Quit: jwatzman|work]
ddosia1 has quit [Ping timeout: 250 seconds]
freling has quit [Ping timeout: 246 seconds]
rgrinberg has quit [Quit: Leaving.]
araujo has quit [Quit: Leaving]
<companion_cube>
Vaur: ah, yeah
<companion_cube>
ocamldoc is really designed to build API doc
<companion_cube>
you can explain a lot of things in .mli files, but not always everything
<companion_cube>
for this I believe you should use a markup language (say, markdown or restructuredText) to write high-level documentation
q66 has joined #ocaml
q66 has quit [Changing host]
q66 has joined #ocaml
Phibonacci has joined #ocaml
<Vaur>
companion_cube: ok
<Phibonacci>
Hello. Excuse me this too simple question. Is the C form `map[y][x] == (map.(y)).(x)` ?
dotfelix has joined #ocaml
Nuki has quit [Remote host closed the connection]
freling has joined #ocaml
dotfelix has quit [Quit: Leaving...]
<companion_cube>
Phibonacci: yes
<companion_cube>
you don't need parenthesis here
<companion_cube>
map.(y).(x)
andreaa has joined #ocaml
racycle has quit [Quit: ZZZzzz…]
<Phibonacci>
thanks
andreaa has quit [Read error: Connection reset by peer]
waneck has quit [Remote host closed the connection]
tnguyen has quit [Quit: tnguyen]
Phibonacci has left #ocaml []
jao has joined #ocaml
jao has quit [Changing host]
jao has joined #ocaml
malo has quit [Quit: Leaving]
tlockney_away is now known as tlockney
dnm has quit [Ping timeout: 256 seconds]
q66 has quit [Quit: Leaving]
struktured has joined #ocaml
ninegrid_ is now known as ninegrid
rz has quit [Quit: Ex-Chat]
manizzle has quit [Ping timeout: 252 seconds]
rz has joined #ocaml
Don_Pellegrino|l has joined #ocaml
<Drup>
Vaur, companion_cube : actually, you can also add documentation with ocamlbuild, by using the -intro option
<Drup>
with ocamldoc*
ygrek has joined #ocaml
michael_lee has joined #ocaml
Don_Pellegrino|l has quit [Quit: Konversation terminated!]
divyanshu has joined #ocaml
divyanshu has quit [Ping timeout: 245 seconds]
tov has quit [Ping timeout: 252 seconds]
divyanshu has joined #ocaml
andreypopp has quit [Ping timeout: 240 seconds]
termos has quit [Ping timeout: 252 seconds]
__marius____ has quit [Ping timeout: 246 seconds]
ggherdov_ has quit [Ping timeout: 240 seconds]
leifw has quit [Ping timeout: 240 seconds]
jzelinskie has quit [Ping timeout: 252 seconds]
msch has quit [Ping timeout: 245 seconds]
lopex has quit [Ping timeout: 252 seconds]
_tca has quit [Ping timeout: 252 seconds]
tautologico has quit [Ping timeout: 245 seconds]
strmpnk has quit [Ping timeout: 245 seconds]
tov has joined #ocaml
msch has joined #ocaml
__marius____ has joined #ocaml
jzelinskie has joined #ocaml
_tca has joined #ocaml
rgrinberg has joined #ocaml
leifw has joined #ocaml
termos has joined #ocaml
strmpnk has joined #ocaml
tautologico has joined #ocaml
lopex has joined #ocaml
andreypopp has joined #ocaml
axiles has joined #ocaml
divyanshu has quit [Ping timeout: 240 seconds]
divyanshu has joined #ocaml
ggherdov_ has joined #ocaml
yacks has joined #ocaml
yacks has quit [Ping timeout: 240 seconds]
rgrinberg has quit [Quit: Leaving.]
bjorkintosh has joined #ocaml
ygrek has quit [Ping timeout: 240 seconds]
divyanshu has quit [Quit: Computer has gone to sleep.]
__marius____ has quit [Read error: Connection reset by peer]
andreypopp has quit [Read error: Connection reset by peer]
__marius____ has joined #ocaml
andreypopp has joined #ocaml
michael_lee has quit [Ping timeout: 276 seconds]
divyanshu has joined #ocaml
WraithM has quit [Ping timeout: 276 seconds]
jao has quit [Ping timeout: 252 seconds]
wwilly has joined #ocaml
wwilly has quit [Remote host closed the connection]
michael_lee has joined #ocaml
WraithM has joined #ocaml
nikki93 has joined #ocaml
tlockney is now known as tlockney_away
ddosia1 has joined #ocaml
divyanshu has quit [Ping timeout: 240 seconds]
Kakadu has joined #ocaml
divyanshu has joined #ocaml
zpe has joined #ocaml
ggole has joined #ocaml
wwilly has joined #ocaml
WraithM has quit [Remote host closed the connection]
<whitequark>
oddly, one of the best things of working with the OCaml community is that most developers are in nearly same timezone as me
<gasche>
I guess ctypes will have to be updated to support the two strings flavour in 4.02 (or adapter later)
<gasche>
if you're deep in the string-handling code, you might want to have a look at how to tackle this
<whitequark>
gasche: I honestly have no idea how to properly make that change, but not because of anything ctypes-related
<whitequark>
the problem is rather pervasive.
<gasche>
well you'd like ctypes to let you describe APIs with information about whether the string passed or returned are meant to be mutated or not
<whitequark>
see, compliant code before 4.02 must use Strings for mutable chunks, and compliant code after 4.02 must use Bytes
<whitequark>
I have no idea how to write code that is compliant on OCaml versions both before and after 4.02.
<gasche>
I have an idea
<whitequark>
well, without using something like pa_optcomp and a *lot* of ifdefs, which is such a horrible solution I don't even consider it.
<gasche>
we could have a "bytes" ocamlfind package that adds a Bytes module (just "include String") on old versions of OCaml, and is phony otherwise
<ggole>
If you need to be backwards compat, shouldn't you not be using the flag?
<whitequark>
ggole: then nothing will ever adopt Bytes.
<whitequark>
gasche: yes, that will work. I'll do it later today.
<whitequark>
(both the bytes package and ctypes change.)
<ggole>
That's not true, it'll just take freakin' forever
<ggole>
But that's the nature of breaking changes
<gasche>
we should release the Bytes package and get it in OPAM
<ggole>
(It would be easier if the new type was the immutable one, but of course that wouldn't give the benefits to most code.)
<whitequark>
I'll also write a blog post about this whole affair, because so far I don't think there is any kind of coherent explanation of the changes short of the commit message
<whitequark>
much less a transition path for real-world code
<adrien>
gasche: yeah, a package like that is needed; might be good to have the stubs right in the ocaml distribution too
<whitequark>
adrien: that won't work, you can't change released versions of the compiler
<whitequark>
and newer ones have Bytes already
<adrien>
(a no-op package shouldn't add too much maintenance)
<gasche>
indeed
<adrien>
whitequark: obviously but it be available for new ones
<gasche>
but we need an external package on old versions anyway adrien
<adrien>
it would*
<adrien>
you can have a package in the compiler and have a copy outside for older versions
<whitequark>
adrien: ah, but then it will probably be an ocamlfind package, similar to base-bigarray and friends
<gasche>
yes, but it's just as simple to handle everything as an outside package
<whitequark>
I mean, distributed with ocamlfind.
<adrien>
most important thing here is to start in non-ambiguous terms that this is the intended migration path
<adrien>
whitequark: that'd work
ontologiae has joined #ocaml
hyg has joined #ocaml
<whitequark>
the bytes package should also specify -ccopt -safe-string, I think.
<gasche>
distributing it with ocamlfind is too compilcated
<whitequark>
gasche: is it?
<gasche>
you'd need Gerd to make two releases, one with the phony definition and one with the other
<adrien>
configure-time change?
<gasche>
I don't see the problem with just adding an OPAM package that has the right version constraints
<gasche>
version 1. has include String, version 2. is phony
<gasche>
and OCaml < 4.02 are compatible only with 1, >= 4.02 only with 2
<gasche>
external, dead-simple, solves the problem
<hyg>
hi. how would i go about doing something like: if (cond) then module M = MyFunctor(someModule) else module M = MyFunctor(someModule2) ?
<whitequark>
gasche: I agree we probably should start with external.
<whitequark>
it would be always possible to move it from opam to ocamlfind, if necessary.
<whitequark>
(is GODI still alive?)
<gasche>
not sure
<gasche>
Gerd discontinued it but the Win version remained, and maybe the other is still used
<gasche>
I get the point that bundling Bytes in ocamlfind makes it available for non-opam users
<gasche>
we should ask Gerd what his preference is, I guess
<whitequark>
I'll drop him a letter
<gasche>
I'd be interested in cc:
<whitequark>
what's your email?
<gasche>
hyg, you could use first-class modules if this is exactly what you want
<gasche>
gabriel.scherer@gmail.com
* whitequark
nods
<gasche>
in practice hyg I prefer to write the code in a different way that does not require this
pminten has joined #ocaml
Nahra has quit [Remote host closed the connection]
<gasche>
(and uses simpler language features)
<gasche>
you should provide your actual use-case for more precise suggestions
<gasche>
(typically you can wrap the part of the code that depends on the actual module as a functor on the module to delay the choice)
<adrien>
basically no update to godi packages in a long time (although that's an older compiler release I think but that shouldn't matter for godi)
* whitequark
is afk for some time
divyanshu has joined #ocaml
Nahra has joined #ocaml
ebzzry has quit []
ebzzry has joined #ocaml
<hyg>
gasche: thanks, will look at those. fyi, i'd like to change a type to some other type based on the argument passed on commandline
ebzzry has quit [Remote host closed the connection]
<gasche>
I think the best solution may depend on the size of the code that depends on this type definition
ebzzry has joined #ocaml
<gasche>
if it's only used in one function called close to the root of your callgraph, I's easy to functorize or parametrize it and delay it's invocation to the command-line processing point
<gasche>
if it's a program-wise type, you would have to functorize large parts of your code, which is fine but may feel more invasive
<gasche>
(in any case, as your modules will be evaluated *before* the command-line arguments are processed, you can't have a non-parametrized global reference that depends on those)
<gasche>
the option to avoid wide functorization would be to provide a unit-parameter function that returns the right module instance (as a first-class module) based on some global configuration state
<gasche>
but then you have to call this function (and unpack the module) each time you want to use the module, which is all a bit heavy
<gasche>
so less functors (so people that dislike functors are happy), but more ugly solution overall, I don't recommend it
<whitequark>
ooooh, I just realized what "first-class modules are enough to encode existentials" meant in that printf-with-first-class-modules proposal.
<mrvn>
whitequark: if you keep passing the module around as accessor
<ggole>
For static decisions you could hack it up a bit and write a one-line file module Foo = <choice here> as part of the build process
<mrvn>
whitequark: what you have then are objects.
<whitequark>
mrvn: you could probably pull out the type into Test
<whitequark>
yeah, you can
ustunozgur has quit [Remote host closed the connection]
ustunozgur has joined #ocaml
<hyg>
thanks, i ended up doing something on these lines: let var = if (cond) then (module X : IXY) else (module Y : IXY) in module M1 = (val var : IXY) in ...
ustunozg_ has joined #ocaml
ustunoz__ has joined #ocaml
ustunozgur has quit [Ping timeout: 250 seconds]
eizo has joined #ocaml
ontologiae has quit [Ping timeout: 252 seconds]
cdidd has quit [Ping timeout: 252 seconds]
Thooms has joined #ocaml
ustunozg_ has quit [Ping timeout: 250 seconds]
zarul has joined #ocaml
zarul has quit [Changing host]
zarul has joined #ocaml
albreche has joined #ocaml
ustunoz__ has quit [Quit: Leaving...]
ustunozgur has joined #ocaml
darkf has quit [Quit: Leaving]
ontologiae has joined #ocaml
ustunozgur has quit [Ping timeout: 240 seconds]
araujo has joined #ocaml
araujo has quit [Changing host]
araujo has joined #ocaml
cdidd has joined #ocaml
<gasche>
whitequark, I suspect your GADT change may have been more complex than necessary due to using polymorphic variants as GADT indices
<gasche>
you could have done with just dumb types (ocaml) and (c) instead of [`OCaml] and [`C]
<gasche>
variants may be useful when you also want to work with subsets of the possible options, but I don't see such a need here
ustunozgur has joined #ocaml
<ggole>
I've gotta try that again when I upgrade to 4.02
<ggole>
(Just for fun.)
araujo has quit [Ping timeout: 245 seconds]
<gasche>
I also wanted to complain about non-exhaustive pattern matching in the patch, but it's not code that was introduced, it's already there
araujo has joined #ocaml
ollehar has quit [Ping timeout: 252 seconds]
yacks has joined #ocaml
Hannibal_Smith has joined #ocaml
<whitequark>
gasche: (dumb types) this is what Jeremy suggested; I would have used mere abstract types
jao has quit [Ping timeout: 240 seconds]
<whitequark>
(non-exhaustive matching) it's code that was introduced, but indirectly; the stubs generator cannot yet handle the types I've introduced
<whitequark>
I have no understanding of the stub generator, so I left it as is
ustunozg_ has joined #ocaml
pminten has quit [Remote host closed the connection]
ustunozgur has quit [Ping timeout: 250 seconds]
divyanshu has quit [Quit: Computer has gone to sleep.]
ustunozg_ has quit [Ping timeout: 245 seconds]
hyg` has joined #ocaml
hyg has quit [Ping timeout: 252 seconds]
NoNNaN has quit [Remote host closed the connection]
ousado_ has joined #ocaml
ousado has quit [Ping timeout: 245 seconds]
NoNNaN has joined #ocaml
ousado_ is now known as ousado
struktured has quit [Ping timeout: 245 seconds]
ousado has quit [Changing host]
ousado has joined #ocaml
<gasche>
nicoo, done, thanks
struktured has joined #ocaml
Thooms has quit [Quit: WeeChat 0.3.8]
ontologiae has quit [Ping timeout: 245 seconds]
<gasche>
whitequark, I applaud your work on writing stuff to present the new OCaml features
<gasche>
I think it's useful and more people should do more of that
<gasche>
(I also know it's a lot of work)
<whitequark>
gasche: thanks :3
<rks`>
(one could add that it's also very well documented, congrats)
<whitequark>
I should update that post with info on how to use ppx_tools, by the way.
<whitequark>
(or perhaps write another one? not sure.)
divyanshu has joined #ocaml
ontologiae has joined #ocaml
divyanshu has quit [Client Quit]
<gasche>
writing another one is fine
<gasche>
don't forget about the LLVM piece either :]
<whitequark>
I won't :p
* whitequark
has got a lot of interest from his current employer on that side, so it's not like he is not motivated
<whitequark>
(yes, that's the legal name, too: "Evil Martians Ltd." / ООО «Злые марсиане»)
<gasche>
"Working with Evil Martians lets us grow faster and earn more."
<whitequark>
consulting.
<gasche>
indeed
<gasche>
name is cool
<gasche>
I was amused at the quote that wouldn't be formulated so crudely over there, I think
<whitequark>
crudely?
divyanshu has joined #ocaml
<nicoo>
gasche: Thanks for merging :)
<gasche>
"Solution foo lets us make more money." is a rather simple way to express the good thing about someone
<gasche>
s/someone/something/
<companion_cube>
:D
<whitequark>
I see
<gasche>
in France you'd rather use some euphemism like "provides business value" or I don't know what
<gasche>
("make a better job", whatever)
<mrvn>
So much for "do no evil"
<gasche>
I like that slogan
<gasche>
"humanity to others" was also excellent
<companion_cube>
"always more money" would be a good company slogan
<companion_cube>
it woud be honest
<gasche>
for OCaml I support "effective functional programming"
<NoNNaN>
"i represent you as a type"
<companion_cube>
gasche: some may say "effectful functional programming"
ustunozgur has joined #ocaml
<gasche>
then I'd say they do "partial functional programming"
<whitequark>
oh, you could read "effective" as a mix between "effectful" and "efficient". clever.
<companion_cube>
gasche: isn't it the point of ML? mixing effects and functional programming?
* whitequark
idly wonders whether idiomatic functional code is faster than imperative equivalent due to caml_modify calls
<companion_cube>
it can happens, I guess
racycle_ has quit [Ping timeout: 240 seconds]
<ggole>
To some extent that's up to the implementation
<gasche>
it happens reasonably often with the current one
<ggole>
Other environments try to provide faster mutation at the cost of making GC a bit more expensive (ie, card marking schemes)
ggherdov_ has quit [Read error: Connection reset by peer]
<Drup>
companion_cube: a text file formated with ocamldoc markup
<companion_cube>
Drup: oh, ok, interesting
ontologiae has quit [Ping timeout: 245 seconds]
<ggole>
Urz Hölze has a good paper on a fast write barrier
<whitequark>
Hölzle?
<ggole>
Yeah, I probably spelled that wrong :E
<ggole>
Funny that I bothered with the dots, but not the second l
ygrek has joined #ocaml
<whitequark>
whoa, he invented polymorphic inline caches.
<ggole>
It might be interesting to do more write barrier elimination, too, I think I've blabbed on about that in the past
<whitequark>
as far as I know, that's currently used to great success in Hotspot
<whitequark>
(especially on non-Java targets such as JRuby)
<ggole>
He worked on Hotspot afaik
<companion_cube>
what's that?
<companion_cube>
the inline cache thing I mean
<ggole>
It's basically a guarded assumption that the code will go down a certain path
<whitequark>
specifically for method lookup, I may add
<whitequark>
well, in this case.
<companion_cube>
oh ok
<companion_cube>
so you look up a virtual method
<companion_cube>
and assume it's some particular implementation?
<companion_cube>
(with a guard ofc)
<whitequark>
you can observe that in a program written in a dynamic language like Ruby, most call sites are (dynamically) monomorphic
<ggole>
I think usually the method is inlined at the site
<whitequark>
most of the rest are megamorphic; those usually correspond to the dispatch methods and the like
<whitequark>
for monomorphic call sites, you may want to speculatively inline them, for example. for megamorphic, you don't bother, as you won't win anything.
<ggole>
And if you only have a small number of methods arriving at a given site, I think you can do a little comparison tree and win
<whitequark>
but there is also a fair share of call sites which resolve to 2-3 different methods, and it turns out that if you cache the result for that call site and do the lookup among the cached resolutions first, it provides quite a net win
<ggole>
Pretty cool stuff considering that you don't need to know anything about the code ahead of time
<whitequark>
I think this would apply to e.g. Numeric implementations which have a tiny Fixnum and deoptimize to Bignum; it makes sense to expect both in generic processing code.
<whitequark>
as an example.
<whitequark>
the JRuby head developer was quite happy about this, as I recall.
<gasche>
it's a form of (just-in-time) profile-guided code specialization, like most JIT techniques
<whitequark>
sure
<gasche>
some parts of language design can be improved with JIT techniques
<whitequark>
it's not conceptually complex; the hard part is figuring out what to include in your JIT and what to leave out.
<gasche>
but the implementation overhead are unpalatable
<ggole>
I wonder how effective it would be for making pattern matching cheaper
<gasche>
I think it's an interesting question for the future
<ggole>
Probably way overkill.
<gasche>
not sure how it would improve OCaml's pattern matching
ggherdov_ has joined #ocaml
<whitequark>
gasche: have you seen PyPy? I think they have quite an elegant re-targetable implementation of an advanced JIT
<gasche>
but for things like deciding to unbox on the fly, it could be effective
<ggole>
Pattern matching is essentially a dynamic decision, which is the sort of thing that JITs can optimize more aggressively than traditional compilers
<ggole>
At least, in theory
<whitequark>
HotSpot borrows some of the techniques used in PyPy with their Project Graal
<companion_cube>
doesn't Pierre Chambart's work on inlining work a bit like this?
<gasche>
whitequark, but I don't hope that you could win for OCaml by moving to PyPy
<gasche>
Pierre doesn't do anything profile-guided afaik
<whitequark>
gasche: good question
<gasche>
the idea of JIT is to perform an optimization that would in general be too expansive, but only in the places where it actually matters, to get a gain istead of a loss
<gasche>
whitequark, more generally, the bar is much higher for reasonable native languages
<gasche>
we don't have say reference-count updates that you can massively optimize
<gasche>
(though ggole's write-barrier elision point is well-taken)
<companion_cube>
I was thinking about using several monomorphized instances of the same piece of code
<companion_cube>
but as always, I feel like a total dilettante when I talk about compilers :)
<whitequark>
gasche: in principle, PyPy is able to do all the transformations that I want LLVM to do, but it has the advantage of already supporting advanced GCs and having runtime information, e.g. loop trip count, hotness and the like.
<whitequark>
gasche: the bar is much higher, I agree.
<gasche>
companion_cube, you should get a Post-Doc in compilation techniques, you seem obsessed with that :]
<companion_cube>
hey! :D
<companion_cube>
I just have a healthy concern for performance
<gasche>
the problem with this field is that it is unforgiving
<whitequark>
gasche: PyPy is more focused on things like inlining with on-stack replacement, which are in general much harder to do than, say, move to a non-refcounting scheme
<companion_cube>
and it's getting better I think
<AeroNotix>
Anything good for using ElasticSearch? I've seen a couple of libraries, but they seem a bit underdeveloped.
<gasche>
a lot of ideas don't make much of a difference in practice
<gasche>
whitequark, there was a paper recently about a refcount-elision technique that made large improvements over CPython
<gasche>
(not from the PyPy folks)
<whitequark>
well, practically anything would be an improvement over CPython -_-'
<AeroNotix>
whitequark: why
struktured has quit [Ping timeout: 250 seconds]
<whitequark>
AeroNotix: imo, it's a really badly designed runtime, even among its class.
<AeroNotix>
whitequark: doesn't OCaml have similar problems related to threading due to the GC?
<whitequark>
for example, the odd decision to do reference counting instead of a tracing GC, which is a) slow b) annoying for writing interop code c) really error-prone if you forget a Py_INCREF somewhere d) still requires a tracing GC to resolve cycles
<whitequark>
CPython doesn't have parallelism, just like OCaml
<AeroNotix>
Aren't B and C the same?
<mrvn>
AeroNotix: ocaml can't do preemptive multithreading, only cooperative
<AeroNotix>
mrvn: and the switch is left to the programmer to use a bind, right?
<whitequark>
NoNNaN: yeah, I just mentioned it--Graal and Truffle are the same thing (iirc?)
<AeroNotix>
ok, but what about a different perspective: How is OCaml's surrounding tooling? Pip/Setuptools/VirtualEnv. It's great to spend time microoptimizing the compiler, but as someone looking at OCaml, it seems there's relatively underdeveloped tooling.
<whitequark>
or maybe Truffle is the JRuby module that uses Graal. I'm a bit confused.
<gasche>
AeroNotix, that's also a good point
<companion_cube>
it's got a lot better with ocamlfind and opam
<whitequark>
AeroNotix: lol, pip/setuptools/virtualenv are better than opam?
<mrvn>
gasche: the amount time spend by hobbyist is way higher. money isn't the problem in writing a good multicore runtime.
<AeroNotix>
whitequark: I'm asking you
<companion_cube>
but there is still the problem of the standard library ^^
<ggole>
Truffle is built on top of Graal, I think
<companion_cube>
and other important choices
<gasche>
mrvn, not sure what you mean
<whitequark>
AeroNotix: I find the tooling around python incredibly immature
<whitequark>
you can't even uninstall eggs, I believe
<AeroNotix>
whitequark: is there even a Virtualenv for OCaml?
<whitequark>
AeroNotix: opam.
<ggole>
Graal is the meta-tracing compiler, truffle a library on top of it?
<ggole>
Something like that.
<whitequark>
ggole: I think you're right.
<gasche>
it's clear that OCaml has less manpower spent on tooling than Python
<gasche>
I'm not sure the actual difference is so important
<mrvn>
gasche: you can write a runtime that is good for some cases but then it will be bad for others. There isn't a good general solution (yet).
<whitequark>
gasche: I wouldn't immediately dismiss OCaml's tooling in favor of Python's.
<gasche>
I'm envious of some of Go's tooling for example
<companion_cube>
gasche: it helps a lot newcomers
<whitequark>
in my experience, OCaml has it vastly better
<companion_cube>
and adoption
<AeroNotix>
gasche: Go's is ok, but Clojure's is rock-solid.
<AeroNotix>
whitequark: what is your reasoning there?
<gasche>
no experience with Clojure's tooling
<AeroNotix>
gasche: leiningen has ruined me for other dependency/project management tools
<companion_cube>
because if you're totally new to Ocaml, there's a lot of complicated things you have to learn before you can even run a program
<companion_cube>
in ocaml you don't have 1 module = 1 file
<Drup>
it take me 1 minutes to set up a project by copy pasting stuff from other projects
tnguyen has joined #ocaml
<whitequark>
Drup: (blur the difference) here I agree, though if you are fine with Core replacing the stdlib, it's not that bad
<Drup>
I should really complete the ocaml.org page about "set up a projet with oasis in 1 minutes"
<gasche>
Drup, why don't you just now?
<whitequark>
but I think Core is not there, even after the module aliases patch. it's too undocumented and can be too specific to JaneStreet's needs at times.
<Drup>
gasche: because I tend to forget about it :(
<gasche>
go back and look at your last attempt
<Drup>
gasche: everytime I think about it, it's 2 in the mroning
<gasche>
if you do it now, we can review your PR and provide feedback
<Drup>
ok ok, let me eat and I will start it
nikki93 has quit [Ping timeout: 252 seconds]
<mrvn>
whitequark: a lot of the time I just have an mli file to make a type private or abstract or to hide a helper function. And that requires writing out all the types for all functions and duplicating all types. That's stupid. One should just be able to flag a function or type protected (can only be used inside the module, not part of the cmi)
<Drup>
whitequark: and until 4.02, it will blow up the size of your binary
<gasche>
mrvn, if you can come up with a good language proposal for that, that could be interesting
<Drup>
(and after, it will probably still do it a bit)
<whitequark>
"let private f x = x"
<AeroNotix>
let private f a = (* do stuff *)
<AeroNotix>
whitequark: yeah ! high 5
<gasche>
that's only a part of the problem
<mrvn>
type t = protected int type s = abstract float
<whitequark>
uh, introducing new keywords
<Drup>
mrvn: "ocaml c -i foo.ml > foo.mli" then supress t definition
<gasche>
one of the issues with "no .mli" is that you have to cover for everything that people can say in .mli
<ggole>
It'd be nice not to have to duplicate large types between .mli and .ml, too
<gasche>
my own attempt was rather to let people reuse the .mli content to avoid duplication in .ml
<whitequark>
gasche++
zpe_ has joined #ocaml
<mrvn>
Drup: the problem is maintainance overhead. you have to update that every time you change something
<Drup>
I agree with ggole on that one
<whitequark>
I think importing stuff from .mli makes much more sense
ruzu2 has quit [Read error: Connection reset by peer]
<Drup>
you can actually do that .. sort of
<ggole>
You could come up with syntax for it. type t = .. or something
<whitequark>
oh?
<Drup>
you can have mlis alone
philtor has quit [Ping timeout: 240 seconds]
<Drup>
without any ml
<companion_cube>
I like .mli files a lot
ruzu has joined #ocaml
<Drup>
and use the in other mlis
<Drup>
them
<companion_cube>
the only boring part is copying module types
<mrvn>
gasche: module M = typeof <this module> include M?
<companion_cube>
why can't a module type in the .mli be enough for the .ml ? :/
<mrvn>
gasche: there is probably some hack like that to get the signature reused to define the types.
zpe has quit [Ping timeout: 240 seconds]
<mrvn>
gasche: I hate not only the duplication but also that the information is in multiple places.
<Drup>
one thing I would like
<Drup>
is something in the mli "just use the infered type"
<gasche>
Drup, aren't you supposed to eat then edit ocaml.org? :]
<ggole>
Wouldn't that break separate compilation?
<mrvn>
Drup: just don't have an mli
<Drup>
gasche: I have my bowl of cereal in front of me !
<gasche>
wow, eating in front of your computer, that sucks
<Drup>
pff.
<gasche>
but then you could start looking at ocaml.org instead of participating to one more unproductive discuss
<ggole>
Don't get milk on the keys.
<Drup>
gasche: I'm perfectly fine with my life, but thanks for you concern.
<whitequark>
:D
<companion_cube>
ggole: well Drup just eats, and it happens that his computer stands in front of him, for no reason
<companion_cube>
should he be blamed?
<Drup>
(actually, companion_cube is having a point : there is no other space in my studio)
<whitequark>
"Man discovered eating in front of computer. Should he be blamed? More at 11"
studybot has joined #ocaml
<companion_cube>
how do you know Drup is a man?
<ggole>
"Computer discovered covered in pistachio detritus."
<companion_cube>
he might be a majestuous Camel
<whitequark>
"BREAKING: Author of popular open-source software is actually a camel"
studybot has quit [Remote host closed the connection]
<mrvn>
I have to write a Time / Timer module intgeracting with ARM hardware. The cpu has a 64bit counter running at 1MHz and 2 timer interrupts I can use that trigger when the lower 32bit of the timer match the timer interrupt register. I'm wondering what would be a good way to represent time on the ocaml side.
studybot has joined #ocaml
<whitequark>
Int64.t?
<mrvn>
whitequark: not nice to specify 3 seconds.
<whitequark>
and write some code that would handle comparing the upper side; you would need it anyway to wait on several timeouts
<whitequark>
actually, hav you considered exporting a React interface?
<whitequark>
(3 seconds) why?
<mrvn>
whitequark: sleep(3) for example
zarul has quit [Read error: Connection reset by peer]
<mrvn>
whitequark: of for wall clock time
<whitequark>
Time.Interval.of_seconds 3
zarul has joined #ocaml
zarul has quit [Changing host]
zarul has joined #ocaml
<whitequark>
anything more complex than seconds requires a lot of wrapping anyway, and frankly, waiting for X seconds is really only useful in a blinking LED PoC
divyanshu has quit [Quit: Computer has gone to sleep.]
<whitequark>
I don't think I *ever* used sleep($seconds) outside of a LED-blinking loop.
<mrvn>
I'm thinking maybe have type time = { sec:int; msec:int; } similar to what C has.
nikki93 has joined #ocaml
<AeroNotix>
whitequark: I use it for writing tests against certain eventually-consistent databases
<whitequark>
ew
<AeroNotix>
I know
<AeroNotix>
riak deletes, I'm looking at you
tnguyen has quit [Quit: tnguyen]
divyanshu has joined #ocaml
<Drup>
mrvn: calendar ?
racycle_ has joined #ocaml
<Drup>
(it's a library)
<Drup>
(very nice)
<Drup>
(slightly overkill)
<adrien>
nothing is overkill when dealing with dates
<companion_cube>
it's like unicode
<whitequark>
what adrien says
<whitequark>
companion_cube: it's way, way worse than unicode
<whitequark>
if you take timezones into account, especially, but even without that
<whitequark>
Drup: seems abandoned
nikki93 has quit [Ping timeout: 252 seconds]
<Drup>
it's not
<whitequark>
last release in 2012...
<Drup>
when a library is perfect, the maintenance cost is small.
<companion_cube>
:D
<Drup>
I used it a few month ago, work like a charm.
<whitequark>
the timezone handling is simplistic, i.e. doesn't take tzdata into account.
<adrien>
companion_cube: when was the last time the world changed calendars?
<companion_cube>
before the last time it changed encodings
<adrien>
:)
<whitequark>
Drup: nice library, I'll probably use it.
avsm has joined #ocaml
maattdd__ has quit [Ping timeout: 245 seconds]
<Drup>
whitequark: tzdata is a big can of worn you don't need super often :)
<whitequark>
Drup: do you have DST?
<whitequark>
do you have idiot politicians which have changed DST rules twice in last five years?
<Drup>
I have DST, but it hasn't changed since a very long time
<whitequark>
(although they have *finally* abolished it in favor of UTC+4)
<gasche>
I've also had good (limited) experiences with Calendar
yami has quit [Ping timeout: 240 seconds]
rom1504 has quit [Remote host closed the connection]
<whitequark>
ok, I now see Jeremy's point that functorizing the ocaml-sodium internals would be better in the long run
<whitequark>
but it is still so annoying. hopefully no one will have to do this in future after the ctypes PR is merged, though.
S11001001 has joined #ocaml
S11001001 has quit [Changing host]
S11001001 has joined #ocaml
rom1504 has joined #ocaml
<Drup>
AeroNotix: since you are new to this whole thing, could you look at ocaml.org and give your opinion ?
jbrown has quit [Ping timeout: 264 seconds]
<AeroNotix>
Drup: at anything in particular?
jbrown has joined #ocaml
<Drup>
accessibility and organisation, ease of discovering interesting informations, stuff like that.
<whitequark>
\o/ sodium just passed tests with new ctypes.
maattdd__ has joined #ocaml
<AeroNotix>
Drup: will poke around, :)
<AeroNotix>
Drup: there's no information on how to structure a project layout or how to compile a project as-a-whole.
<Drup>
yes, I know
<companion_cube>
Drup: time for you to promote oasis and show some example oasis files ;)
<AeroNotix>
so it's fine if you're making little one-off functions but I want to write a library or a program or just structure my code according to well-known conventions.
<Drup>
companion_cube: I was trying to find where to fit it
jbrown has quit [Ping timeout: 245 seconds]
jbrown has joined #ocaml
<AeroNotix>
well I just found merlin through this page
<orbitz>
whitequark: I saw your ANN, pretty cool. Loading teh README now
<AeroNotix>
orbitz: why do you hate
avsm has quit [Quit: Leaving.]
<Drup>
AeroNotix: yes it is :)
<orbitz>
What do I hate?
<AeroNotix>
orbitz: dunno, you asked me that once in #erlang
<orbitz>
AeroNotix: but you're a hater
<orbitz>
i'm not!
<orbitz>
so it makes no sense to ask me
<AeroNotix>
orbitz: how am I the hater? :P
<companion_cube>
do you wear or manufacture hats?
<orbitz>
because you were hating when I asked you, duh :)
<AeroNotix>
orbitz: Not really :)
maattdd has joined #ocaml
<orbitz>
whitequark: pretty nice work
<orbitz>
whitequark: I'm not actually a fan of mixing type defintions with encoder/decoder creation, but I think a lot of people will like it
maattdd__ has quit [Ping timeout: 250 seconds]
Rotacidni has quit [Ping timeout: 240 seconds]
ustunozgur has quit [Remote host closed the connection]
<whitequark>
orbitz: I was thinking about merging the two projects, so that e.g. it would only be necessary to verify an unsafe approach to converting data once
<whitequark>
also I believe you don't handle a few of the obscure corners of the spec, such as packed fields
albreche has quit [Quit: Quitte]
<orbitz>
whitequark: I handle packed ones, but I am pretty sure I don't handle all cases
* whitequark
nods
<whitequark>
I've spent a great deal of time making sure all overflows are handled correctly, too
<whitequark>
and errors in general
<orbitz>
whitequark: I'll look into scrubbing mine for yours
<orbitz>
gotta go take a shower!
<whitequark>
orbitz: I'll be glad to assist (with the ppx_protobuf :D)
<Drup>
slowly, because I'm terrible at writing stuff
<whitequark>
adrien: what do you mean by index?
<adrien>
if not it's not an issue, I'll simply put both
<adrien>
let's way I want to download files for the past 3 years
<whitequark>
you have full-text search provided by mysql with the box on the left, *and* you have Google indexing all the pages quite quickly
<whitequark>
oh
<adrien>
grep!
Vaur has quit [Ping timeout: 252 seconds]
<whitequark>
adrien: write a for loop? :D for i in `seq 2012 2014`; do for j in `seq 1 12`; do wget http://irclog.whitequark.org/ocaml/$i-$j.txt; done; done"
<Drup>
whitequark: the good way is that it's not even less user friendly than the current situation.
<adrien>
well, no problem, I'll simply put both in topic
<adrien>
they have different UIs which serve different purpose
<Drup>
sorry adrien
<Drup>
but the current one have no UI
<whitequark>
I'm not sure what the old logger provides that the new one does not
<adrien>
lftp and redundancy
<whitequark>
I mean, you're free to put both in the topic, of course
Cyanure has quit [Remote host closed the connection]
<whitequark>
lftp?
<whitequark>
is that something that would traverse the links?
Cyanure has joined #ocaml
nikki93 has joined #ocaml
<whitequark>
I mean, I could easily put together the index page like that for irclog, if it serves some useful purpose
<gasche>
lftp is a FTP client that allows to fetch all the logs at once
<gasche>
I suspect that updating a .7z archive of the logs daily would be enough
<gasche>
and that's the reason why OCaml works well on Debian, unlike, say, Archlinux
<flux>
well, this way it doesn't need to depend on an exact version
<flux>
you can have a more recent version and the package is still compatible if the interfaces are
<gasche>
the problem is more than package managers usually assume that if one of your dependencies gets a version update, you don't need to get one as well
<flux>
..although I wonder if that works for ocamlopt and cross-module inlining
<gasche>
there was a paper by the debian-ocaml team about their work on packaging
<flux>
I don't think I was on this channel at 2002
<flux>
2006 is probably the earliest for me
avsm has joined #ocaml
* Drup
is far too young.
ygrek has joined #ocaml
avsm has quit [Client Quit]
avsm has joined #ocaml
Kakadu has joined #ocaml
whitequark is now known as sdfsdfsdf
sdfsdfsdf is now known as whitequark
<Drup>
do someone have a real world example of a simple but featureful _oasis file ? https://github.com/c-cube/sequence/blob/master/_oasis is almost good, but there is no Executable and Tests sections, and there is no flag
<Drup>
Lwt's one is completely overkill :D
<mrvn>
Drup: write some Ulwt (ultra light weight threads)
<gasche>
Drup, why don't you answer to Malcom on the caml-list?
<gasche>
(I considered doing so but then I remembered I had a format-patch to rebase)
<whitequark>
fascinating. in 2008, the usual way of installing packages was: 14:16 <tsuyoshi> I get the impression most people just use the packages in debian or redhat
<Drup>
companion_cube: whitequark's one contains less stuff but more features :D
<AeroNotix>
annoyingly a lot of stuff in AUR uses packages not installed via OPAM.
<companion_cube>
meh
<companion_cube>
I feel jalous!
<Drup>
AeroNotix: don't use AUR for ocaml packages
<AeroNotix>
Drup: I know
<whitequark>
companion_cube: :D
<AeroNotix>
I'm saying that there are tools like oasis which wants to install packages system-wide.
<companion_cube>
oasis doesn't specifically want this, it makes it very easy to have a configure file
<adrien>
whitequark: my logs start on Jul 03 2010
<adrien>
localtime paris btw
<Drup>
AeroNotix: oasis is just using ocamlfind. if ocamlfind is parametrized to have system wide install, it's going to go this way.
<whitequark>
adrien: oooh by the way, what's the timezone for tunes.org?
<AeroNotix>
Drup: hmm
<adrien>
no idea :D
<adrien>
but I can correlate
rgrinberg has quit [Quit: Leaving.]
<Drup>
I think it's UTC
<adrien>
don't thnk so
<Drup>
actually, no
<Drup>
it's ... weird
<adrien>
unless I woke up at midnight :P
<adrien>
Paris: 11H49, tunes.org: 2H51
<Drup>
it's UTC-7
<adrien>
(my clock is probably more precise but I doubt anyone cares about two minutes :P )
<adrien>
west coast?
<whitequark>
adrien: I bet it had a lot of skew over 13 years, too
<gasche>
if you use _oasis as suggested by Drup, you will not really have to make a choice
<AeroNotix>
ok
<whitequark>
why does jenga exist?
<Drup>
whitequark: because jst has NIH ?
<AeroNotix>
NIH?
<whitequark>
well, I thought that maybe there is another reason
<AeroNotix>
in softare? LOL
<AeroNotix>
software*
<gasche>
whitequark, my understanding is that Jane Street has the same needs that made OCamlbuild exist in the first place, but they did their own thing -- possibly because ocamlbuild was perceived as too inflexible
<companion_cube>
they also had scalability problems, I think
<whitequark>
I see
<Drup>
gasche: huuum, wasn't it more an efficienty issue ?
<gasche>
well
<Drup>
they have a huge code base and ocamlbuild is really slow
<def-lkb>
yes, it's more about scalability in the first place (they were using omake before)
<gasche>
(1) they were using OMake before iirc, not ocamlbuild (2) you can make ocamlbuild faster
<gasche>
basically using exactly the same techniques that are supposed to make Jenga scalable
<Drup>
gasche: the point 2) is why I said NIH
<companion_cube>
can you really make ocamlbuild faster without rewriting the whole of it?
<gasche>
this is no criticism of Jenga
<whitequark>
or adapted something that exists like ninja
<gasche>
whitequark, the hard/interesting part is dependency tracking and understanding OCaml's compilation model, which I don't think ninja is so good at
<gasche>
I mean
<gasche>
you could use ninja as a build-order-scheduling backend
<gasche>
but that's not necessarily the hard part
<gasche>
companion_cube, yes?
<whitequark>
gasche: I suspect you can
<companion_cube>
I'm impressed then
<gasche>
I don't think ocamlbuild is in fact that slow
<companion_cube>
yes it is
<Drup>
yeah, it really is.
<gasche>
I mean there is not much that is structurally slow about ocamlbuild
<companion_cube>
it takes several seconds, on a smallish project, just to detect that it has nothing to do
<Drup>
gasche: you will hit some limitations involved by dynamic scheduling with ocamlbuild
<companion_cube>
gasche: scanning files?
<gasche>
that's a content-based build system
<Drup>
and dynamic scheduling.
<companion_cube>
before starting compiling it scans everything
<gasche>
you complain about that because Make does timestamp-based
<companion_cube>
it's extremely slow
<gasche>
it's also (1) correct and (2) sometimes asymptotically faster
<companion_cube>
gasche: jenga deals with dependencies/updates in a bottom-up fashion iirc
<companion_cube>
rather than top-down
<companion_cube>
gasche: unrelated question, is there a general accepted term for fuel-based evaluation/combinators?
<gasche>
fuel-based? :p
<Drup>
and still, you can't properly parallelize if you're discovering build dependencies while building ...
<gasche>
I don't think that is true
<companion_cube>
gasche: like the models of lambda calculus in coq, that terminate because you restrict the number of reduction steps
<Drup>
then your scheduling teacher forgot to mention some fundamental theorems :>
<gasche>
yes, I'd use fueld-based companion_cube
nikki93 has joined #ocaml
<gasche>
or "using fuel"
<companion_cube>
ok
<companion_cube>
I was wondering whether there are some (declarative?) languages that had fueld-based evaluation everywhere
<whitequark>
fueld?
<gasche>
fuel-based, sorry
<gasche>
the "d" in fueld was a typo
<companion_cube>
whitequark: yes, fuel-daemon
<companion_cube>
like systemd
<pippijn>
gasche: the "d" is silent
* whitequark
is confused
<gasche>
companion_cube, the indexed lambda-calculus is used as a theoretical language to study the metatheory
hyg` has quit [Remote host closed the connection]
<gasche>
step-indexing techniques for example rely on some sort of underlying "fueled lambda-calculus"
<gasche>
but that's only in the proofs
<companion_cube>
yes
phao has joined #ocaml
<gasche>
Drup, (1) you could do better than ocamlbuild's current parallelization with purely dynamic scheduling (2) I see no fundamental problem with caching last time's dependency and using them as a static overapproximation for better parallelization
<companion_cube>
but imagine you have a potentially non-terminating algorithm (say, theorem proving, prolog-like reasoning, planning, etc.)
<gasche>
(it doesn't change the nature of the tool in any way)
<companion_cube>
having fueled evaluation could help
<phao>
Hi. If I write a generic piece of code using functors (I did some SML some time ago, and Ocaml I did a lot less, so I could be saying non-sense here), will I incur a run-time overhead? Or can it be done like with C++ templates, in which lots can be inlined and statically decided?
<Drup>
phao: it will be static
<gasche>
phao, functors get compiled into functions
<gasche>
if you're lucky, the call of known-functor to known-argument will be inlined
<gasche>
it's probably too early to worry about that anyway
<mrvn>
phao: first class modules have a runtime overhead, functors a compile time / code size overhead
<phao>
Right. I was thinking to a situation like qsort, which takes a comparator. Afaik, it can't really do much inlining work.
<phao>
mrvn, Ok.
<Drup>
gasche: for 1) .. obviously, you can do slightly better, considering the terrible current state.
<gasche>
the natural way to handle qsort would be to take a function as parameter
<gasche>
no need for functors there
<Drup>
2) I could derive you an example by hand, but I'm busy and it's horrible to do by IRC.
<companion_cube>
gasche: the difference between ocamlbuild and jenga would be the same as between make and tup (ninja?)
ollehar1 has joined #ocaml
<phao>
gasche, right... and would the ocaml compiler be able to do inlining there?
<mrvn>
phao: ocaml does cross module inlining. SO it could inline the comparator into qsort. But closures are never inlined. Big drawback in ocaml.
<companion_cube>
it does matter on big projects
<companion_cube>
qsort would be a mere function, not a functor, anyway
<phao>
mrvn, do you know why not?
<mrvn>
phao: because nobody has implemented it
<phao>
ahhh
<Drup>
phao: the compiler is not *yet* very good at inlining
<Drup>
it inlines a bit
<Drup>
but not that much
<Drup>
someone is actively working on the subject.
Thooms has joined #ocaml
<mrvn>
qsort as functors could actually be several times faster than with passing a compar function
<Drup>
mrvn: really ? bench please :D
<phao>
Drup, people say things like that with std::sort versus qsort
<phao>
C++ people*
<whitequark>
ok, looks like the entire corpus of logs can be imported
<Drup>
C++ people says a lot of stuff that are not correct when you step out of the C++ world.
<phao>
Drup, the idea seems valid though
<phao>
the idea is that you can inline the comparison function in one, but not in the other.
<phao>
Right?
<Drup>
phao: oh, it is, I'm wondering about the "several times faster"
<gasche>
I'd be surprised if it was correct of OCaml functors however
tobiasBora has joined #ocaml
<phao>
I see.
_whitelogger has joined #ocaml
<gasche>
but my point is that you could still use a system whose semantics is about dynamic dependencies, but whose behavior in 80% of cases is not distinguishable from a tool assuming static knowledge
<phao>
THe issue in C is that, afaik, inlining with qsort is way more difficult, afaik.
<Drup>
gasche: which is absolutly not how ocamlbuild is right now.
<gasche>
no contradiction here
lostcuaz has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<gasche>
but the design makes it a reasonable place to go to if you want
<Drup>
the theoretic design, maybe, the way it's implemented ? I don't think so.
<phao>
well, thanks all. Gotta go
<Drup>
I'm talking about ocamlbuild, you are talking about an hypothetic build system with dynamic features that resemble ocamlbuild.
<companion_cube>
hence my feeling that making ocamlbuild as fast as jenga would require an almost complete re-implementation
<Drup>
exactly.
<Drup>
mrvn: I do want to see the "polymorphic qsort vs. functorized qsort" bench :]
nikki93_ has joined #ocaml
<mrvn>
Drup: testing. I expected the functor to inline but that doesn't seem to happen
<companion_cube>
if you make a partial application otoh, does it inline?
<companion_cube>
like, let mysort = qsrort cmp_fun
<companion_cube>
qsort*
<mrvn>
companion_cube: closures are never inlined
<companion_cube>
really really never? :(
<companion_cube>
sad
<Drup>
mrvn: can you try with pierre's version of the compiler ? :)
<whitequark>
hmm, perhaps my LLVM idea wasn't that bad after all
<gasche>
<companion_cube> hence my feeling that making ocamlbuild as fast as jenga would require an almost complete re-implementation
<gasche>
<Drup> exactly.
<whitequark>
in Foundry [the language I once developed] it had no problems unfolding the ceremony around closure creation and inlining it
<gasche>
if I understand, your argument is
<gasche>
"ocamlbuild is really slow, it feels so slow to me, certainly it would require a rewrite to make it fast"
<whitequark>
although that allocated the environment on stack, it should be equally able to lift heap allocation to allocas
<companion_cube>
by design and implementation, yes
<gasche>
or "I believe dynamic dependencies suck so certainly it requires a rewrite"
<companion_cube>
come on, several seconds only to check that nothing has to be done
<gasche>
(while Jenga to my knowledge also use dynamic dependencies, but that's another story)
<Drup>
I believe dynamic dependencies suck, and ocamlbuild is using *only* dynamic dependencies
<mrvn>
Passing (=) as closure also doesn't optimize the = when it infers that the type is int -> int -> bool
<gasche>
I can't really comment on whether it is true that ocamlbuild would need an actual rewrite
<Drup>
I never said Jenga was good, I have no idea how it is working.
<gasche>
but I can't help feeling that your argumentation is not very good
<companion_cube>
I thought jenga used little dynamic dependency, and worked bottom up
<def-lkb>
gasche: dynamic dependencies, cached
<gasche>
indeed
<companion_cube>
it's a server that recompiles whenever it detects a change
<companion_cube>
but it starts from the change and propagates
<gasche>
that's the polling mode
<def-lkb>
it's not necessarily a server
<gasche>
but those are goodies that you get when you design the rule language right
<companion_cube>
also, if you change a .mli but the actual interface (.cmi) is the same, it doesn't recompile files that depend on the interface
<mrvn>
Hey, wait a second. I get a closure inlined.
<gasche>
that's what jenga and ocamlbuild are about : finding abstractions to describe building stuff in OCaml
<companion_cube>
gasche: sure
<gasche>
if you get the right abstractions, you can have nice stuff
<companion_cube>
so that can justify why jenga exists
<mrvn>
ahh, no. my bad. read that wrong.
<gasche>
<companion_cube> also, if you change a .mli but the actual interface (.cmi) is the same, it doesn't recompile files that depend on the interface
<gasche>
ocamlbuild shouldn't either
<mrvn>
I shouldn't call 2 functions "fn" in the test case.
<gasche>
(or rather there is no reason for a difference in behavior here)
<companion_cube>
shouldn't, but does
<gasche>
do you have a test case?
<gasche>
have you filed a bug report?
<companion_cube>
every time I recompile one of my projects?
<mrvn>
Hence the trick of building an .mli file and compiling cmi from that once.
<gasche>
(this is a bugtracker discussion about what happens there)
<mrvn>
gasche: yep. that's the bug
<gasche>
the re-read is caused by the checksum calculation
<gasche>
it's not the sign that compilation restarts anything
<mrvn>
gasche: maybe. At the time I was more concerned with parallelity. Plus I like having mli files to check the type are right.
<gasche>
indeed
<gasche>
Damien recommends to just check those out in your source tree
<gasche>
in Make, if you know that you are going to build both .cmo and .cmx anyway, a solution to avoid parallelization problem is to make the .cmx depend on the .cmo
<mrvn>
ocamldep screws up there
<gasche>
hm
<gasche>
I probably meant "make the .cmo depend on the .cmi"
<whitequark>
what's the deal about .cmx and .cmo, anyway? why do I need to build .cmos if all I want is .cmx
<gasche>
(but those things are tricky)
<gasche>
whitequark, you don't
<mrvn>
whitequark: you don't.
<mrvn>
whitequark: I think you get the cmo as side effect of needing the cmi
<whitequark>
oh.
<mrvn>
there should be different depends depending on wether you build bytecode or native. But most build systems aren't that smart
<mrvn>
whitequark: man ocamldep /-native
<gasche>
I think ocamlbuild (at least) knows to use ocamlopt-only when that's what you want
avsm has quit [Quit: Leaving.]
<mrvn>
sometimes simpler is also better. understanding the error messages from oasis/myocamlbuild when you wrote something wrong in the _oasis file is a nightmare.
<mrvn>
worse than "foo.ml and foo.mal are different interfaces" errors.
<gasche>
certainly, there are good reasons for using make
<gasche>
but "it's easy to encode OCaml's compilation semantics to get efficient and correct compilation" isn't
<gasche>
that said, OCamlMakefiles makes a surprisingly good job
<mrvn>
could be easier by saying what pattern rules should exist. Like is ocamllex used or not.
ollehar1 has quit [Ping timeout: 252 seconds]
<mrvn>
Sometimes you get errors that foo.mll file is missing while you've never heard of ocamllex
<whitequark>
yes, this is really annoying
<whitequark>
the error messages of ocamlbuild are almost entirely useless
<mrvn>
+1
<Drup>
the circular dependency error message, oh god X_x
<mrvn>
could be worse. With g++ someone got a 160kb error message.
<gasche>
impreovement suggests are welcome
rgrinberg has joined #ocaml
<mrvn>
gasche: suggestion: Stop at the file that is there and give an error. Don't go looking for 20 other targets that aren't there.
<gasche>
hm
<gasche>
I'm not sure what example you have in mind, but if ocamlbuild looks at those targets it is because, if they could be built, there would not be an error
<gasche>
ah
<mrvn>
gasche: yes. But it seems for the error it picks the most complicated chain of depends possible to generate the target.
<gasche>
you mean in the error message only say "could not build blah" instead of "could not build blah because neither ... are present"
<whitequark>
gasche: even that would be an improvement
<mrvn>
gasche: The thing is there is a .ml file but somehow it isn't usable. That is the error. Not that it can't build those other 20 targets to get the result.
<rgrinberg>
right now i've settled on a lazy string + position to make the copying optional
<gasche>
rgrinberg: if you don't need caching, prefer (unit -> t) over (t Lazy.t)
<gasche>
it's just simpler to use for the user
philtor has quit [Ping timeout: 240 seconds]
<gasche>
mrvn, do you have an example?
<gasche>
but sure, the tree could be disabled
<mrvn>
no.
<rgrinberg>
gasche: how come? the type signature looks a little uglier. haven't thought of that before though...
<gasche>
hm
<rgrinberg>
I've also thought of < pos : int * int ; str : string > as the param but people are scared of objects...
<Drup>
also, if it's a one shot access object (not repeated access), "fun () -> foo" is faster than "lazy foo"
<gasche>
my gut feeling is that everyone knows how to work with (unit -> 't)
<gasche>
while lazy needs some time to stop and think about it
<gasche>
Drup, do you observe a difference?
zpe has joined #ocaml
<Drup>
gasche: yeah, on lilis it was pretty big
phao has left #ocaml ["Leaving"]
<rgrinberg>
doesn't it make sense intuitively because you don't have to write the cached value?
<Drup>
I'm not sure I still have the relevant files, though
<gasche>
know that I think of it
<Drup>
rgrinberg: yes, that's the reason
<gasche>
the lazy version lets you write
<gasche>
fun (lazy substr) pos -> ...
<rgrinberg>
gasche: always forget about that trick!
<gasche>
which is syntactically more convenient than (fun sub pos -> let substr = sub () in ...)
<rgrinberg>
we need view patterns ^_^
<companion_cube>
\o/
<whitequark>
view patterns?
<Drup>
whitequark: functions over patterns, basically
<Drup>
btw rgrinberg, I was looking at the interface yesterday
<Drup>
you still have some "string" instead of "str" raound
<rgrinberg>
it's also a little strange. but I'm not sure what else could work. i've tried f:(Group.t -> [`Replace of str | `Keep]) but it doesn't maintain all the invariants
<Drup>
around*
<rgrinberg>
yeah i haven't fixed that, will d
<rgrinberg>
no sense in making the signature generic in that type until ocaml-re works on anything else
<Drup>
well, it's still better to be consistent
<Drup>
like, for all and alli
<rgrinberg>
indeed, will fix that
zpe has quit [Ping timeout: 245 seconds]
<gasche>
whitequark, mrvn: in fact ocamlbuild prints first an explanation, and then a backtrace of the failure
<gasche>
it would be trivial to move the backtrace part to above-0 debug levels only
<mrvn>
gasche: must have always scrolled out of the screen or been equally incomprehensible.
<Drup>
rgrinberg: for the rest, I am not a big user of ocaml-re, but I like it
<Drup>
tell me when you start the functor-spagetti part to make it work on non-string data types, I will be happy to contribute to that :D
<ggole>
Abstraction over patterns would definitely make some code nicer
<whitequark>
gasche: that would be great
<ggole>
Haskell got it recently, I was pretty jelly
<ggole>
(Although they seem to implement them as functions? Bit odd.)
<rgrinberg>
Drup: teh functor spaghett will have to be done on ocaml-re first
<mrvn>
Tomorrow I need to implement line drawing. Everyone remember bresenham (or what's it called)?
<Drup>
rgrinberg: sure
<rgrinberg>
unless i will support other backends such pcre, re2, str
<rgrinberg>
which i'm not really fond of
<Drup>
I'm not sure to see the point
<Drup>
str and pcre are completely subsumed by ocaml-re
<Drup>
(don't know about re2 except by you)
<rgrinberg>
ocaml-re doesn't support all of pcre
<Drup>
oh ?
<rgrinberg>
i would say it's not even close if you care about all the new features
<rgrinberg>
s/new/obscure/
<rgrinberg>
also pcre has a a nice and big api
<rgrinberg>
my own api is heavily inspired by re2 but it's much more simple and doesn't support all the use cases that re2 does
yastero has quit [Ping timeout: 252 seconds]
<rgrinberg>
an str backend would be mostly a gimmick i agree
<ggole>
It was brought up last time we had this discussion :]
<companion_cube>
^^
<AeroNotix>
whitequark: ah, uses cinch?
<whitequark>
is there much python in ipython notebooks?
<whitequark>
I mean, could I use the web part and ocaml part without any python parts? I wonder
<whitequark>
AeroNotix: yes
<AeroNotix>
whitequark: my friend wrote that :)
<evilkidder>
tautologico: I have iocaml working with both zmq3 and 4 so hopefully your issues will be fixed. much more complex build now so there might a some lingering problems to be fixed.
<Drup>
gasche: for that dream to realize, browser need to start quicker and don't consume that much ram ... :(
<whitequark>
AeroNotix: dominikh, I know.
<AeroNotix>
:)
<evilkidder>
whitequark: iocaml with iocamlserver has no python
<whitequark>
evilkidder: cool
<evilkidder>
iocamljs run off a github pages site has no ocaml either...!
<Drup>
evilkidder: this mean we will actually be able to do this iocaml+tyxml integrated tutorial ?
<evilkidder>
drup: yes with 1 caveat. Doing the module Html = Html.M thing it prints 100000's of lines of response and blows the (default) javascript stack, which is annoying.
<whitequark>
evilkidder: wow, only 550KB of code
<Drup>
evilkidder: ahah, indeed :D
<whitequark>
evilkidder: this is seriously amazing, I'm impressed
<evilkidder>
I have a small fix in mind to (properly) turn off printing which would get round this.
<AeroNotix>
whitequark: you could use ElasticSearch as a backend for irclogger
<tautologico>
last time I tested iocamljs many things didn't work, but it is quite promising
<whitequark>
AeroNotix: elasticsearch is crap
<AeroNotix>
whitequark: for text searching it's awesome
<AeroNotix>
For everything else? Crap.
<tautologico>
to be able to have people run notebooks in their machines without installing ocaml is great
<Drup>
evilkidder: wouldn't it work correctly simply with 4.02 ?
<whitequark>
AeroNotix: except for the part where it runs on Java and I don't have enough RAM for that
<AeroNotix>
whitequark: Meh
<Drup>
the module alias behavior changed, it would probably alienate this issue completly
<whitequark>
no, seriously, I simply don't, I'm not paying Linode 2x more solely for ES
<AeroNotix>
whitequark: understandable
<AeroNotix>
:)
<whitequark>
tautologico: that's mostly irrelevant. I'm saying that the UI is really amazing
<whitequark>
that is how it must be done.
<evilkidder>
drup: I dunno - if it shortens printing then yes. If you run the browser with a bigger stack tyxml works fine in iocamljs
<whitequark>
evilkidder: can you do a plot there or something?
<Drup>
evilkidder: it doesn't print anymore
<Drup>
whitequark: better
<Drup>
whitequark: you can run tyxml and output svg
<Drup>
which is interpreted as pictures by the browser
<whitequark>
Drup: I wanna plot (fun x -> x * x) [0;10]
<tautologico>
whitequark: isn't the iocamljs UI the same as the iocaml (and IPython notebooks, for that matter)?
<whitequark>
tautologico: yes
<whitequark>
it's the first time I see it
<tautologico>
oh right
<gasche>
evilkidder, the "module alias" changes Drup is talking about will also make your life much simpler regarding Core
divyanshu has joined #ocaml
<gasche>
(which I guess has the same issues, only worse)
<tautologico>
I'm waiting for iocaml to install here to get plotting going... currently I think there's cairo support
<evilkidder>
whitequark: you can render anything thats html
<tautologico>
but much can be done to get more visualizations ready out-of-the-box
<evilkidder>
tautologico: not sure if iocaml is live just yet (its been pushed, waiting for opam to update)
<whitequark>
evilkidder: well that's not really convenient
<whitequark>
see my answer to Drup above
<tautologico>
evilkidder: cool, what about lwt-zmq and iocaml-server, everything updated as well?
<tautologico>
evilkidder: btw, great work on IOCaml all around, this will be tremendously useful for me
<evilkidder>
I rewrote the zmq layer and brought it into iocaml so yes iocaml-server is ok.
<tautologico>
whitequark: if no one else does it I plan to work on that
<whitequark>
evilkidder: wait, you rewrote the zmq layer?
<whitequark>
evilkidder: that sounds not very good, I'd much rather integrate it into ocaml-zmq
<evilkidder>
whitequark: we both want plotting. we need a library for that
philtor has joined #ocaml
<evilkidder>
I wanted compatibility with zmq3+4 so I needed to make a change
<Drup>
maybe we could port archimed to js_of_ocaml
<Drup>
this would allow to plot in a canvas
divyanshu has quit [Client Quit]
<Drup>
if archimed uses graphics, there should be nothing to do
maattdd has joined #ocaml
<Drup>
(or you can a very simple library using tyxml to generate the svg, but that would be less featureful and probably more painful)
<Drup>
+make
Kakadu has quit [Quit: Konversation terminated!]
dnm has quit [Ping timeout: 252 seconds]
<gasche>
just a trick: "(" ^ foo ^ ")" can be written String.concat foo ["("; ")"]
lostcuaz has joined #ocaml
<jpdeplaix>
gasche: while you are on ocamlbuild, can you merge my PR ? :))