connorjacobsen has quit [Ping timeout: 252 seconds]
AlexRussia has joined #ocaml
connorjacobsen has joined #ocaml
Soni has joined #ocaml
connorjacobsen has quit [Ping timeout: 252 seconds]
Soni is now known as APNG
nicholasf has joined #ocaml
nicholasf has quit [Remote host closed the connection]
agarwal1975 has joined #ocaml
nicholasf has joined #ocaml
copy` has joined #ocaml
AlexDenisov has quit [Read error: Connection reset by peer]
AlexDenisov has joined #ocaml
Reshi has quit [Quit: WeeChat 1.5]
connorjacobsen has joined #ocaml
AlexDenisov has quit [Read error: Connection reset by peer]
<tizoc>
I'm on OSX, with ocaml 4.03 as the system's ocaml, and I have a switch for 4.02
<tizoc>
but when I run 'ocaml setup.ml -build' (setup.ml generated by oasis), it calls ocamlfind from the system switch, not the one I have active, has this happened to anyone?
connorjacobsen has quit [Ping timeout: 252 seconds]
AlexDenisov has joined #ocaml
<Algebr``>
check opam switch if you are out of sync
<Algebr``>
or perhaps you have a stale setup.data
<tizoc>
Algebr``: thank you, it seems to be a stale setup.data
<tizoc>
that was it :)
<Algebr``>
yup, I learned this one the hard way.
hongbo_ has joined #ocaml
<hongbo_>
Drup: OCaml is a small community, we should really help each other. I never said a single bad word towards jsoo. I think both BuckleScript and jsoo have good use cases, we should work together to make OCaml the best language
<companion_cube>
I'm a bit surprised no one mentioned jsoo on the HN thread, though
<Algebr``>
it was mentioned
<Algebr``>
hongbo_: I agree with you 100%
<companion_cube>
ah, must have been mentioned after I looked then
<hongbo_>
jsoo is more friendly to existing OCaml libraries. But BuckleScript brings a much much larger audience to OCaml
<hongbo_>
one thing I am particular interesting is electron/react native
<Algebr``>
agreed, I want to make cross platform apps in OCaml
<Algebr``>
hongbo_: because the semantics of BS are slightly different, can I create objects at runtime?
<Algebr``>
like JavaScript can dynamically create object definitions, I want to as well.
AlexDenisov has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
<hongbo_>
create js objects?
<Algebr``>
I want to be able to create OCaml stuff at runtime, say, class foo = object end
<hongbo_>
something like ocaml_plugin?
<Algebr``>
whats ocaml_plugin
<hongbo_>
dynamic linking with a type safe interface?
<hongbo_>
if your target is js, there is no reason you can not do it, you have unsafe `eval`
connorjacobsen has joined #ocaml
<Algebr``>
And can I somehow use BS as a library from C code?
<Drup>
hongbo_: OCaml is a very small community, we should not aim to build several tool which usecase overlaps at 95%.
<Algebr``>
Drup: that's hardly the truth here
<Algebr``>
jsoo doesn't make the JavaScript ecosystem a priority, it actively scoffs at it
<companion_cube>
if they don't know OCaml yet, why would JS programmers pick ocaml over TS, flow, etc.?
<Drup>
it isn't ? hongbo_ here did some great work on making the code readable that could perfectly be applied to js_of_ocaml. The work on FFI is equally applicable
connorja_ has joined #ocaml
<Algebr``>
companion_cube: because OCaml is a real functional programming language from the beginning
<hongbo_>
jsoo has been there for 6 years, most people interested in BuckleScript does not have too much background in OCaml
<Drup>
hongbo_: that's not a technical argument.
<hongbo_>
Algebr``: yes you can, you can embed OCaml libraries into c application
<Algebr``>
Drup: technical arguments don't win adoption, community does.
<Algebr``>
hongbo_: is BS ready for that?
<ggole>
Doesn't js_of_ocaml consume bytecode? How do you make that readable?
<companion_cube>
Algebr``: why would JS programmers care about "real functional programming language"?
<Drup>
ggole: debug info allows you to go back to the source code. That's already used by jsoo to do sourcemaps, we could do more
<hongbo_>
companion_cube: Js community is moving fast, they embrace more and more functional programming
<Algebr``>
companion_cube: because they are hungry and very much desiring of functional programming and would prefer something correct from the get go rather than bolted on
<companion_cube>
but then, interfacing with existing libs full of untypedness and nulls seems pointless
<Algebr``>
Its not because many libs are battle tested
<companion_cube>
well, if it works, good thing, but I don't believe OCaml will become popular at all because of this
connorjacobsen has quit [Ping timeout: 252 seconds]
<hongbo_>
Luckily ocaml has a very advanced type system, and we are working hard to improve Buckle FFi
<Algebr``>
its like interfacing with battle tested C code
<companion_cube>
(why pick ocaml rather than ghcjs, or scalajs, also)
<Algebr``>
many simple JS libraries have more adoption than the most popular OCaml code ever.
<hongbo_>
ghcjs is far from being production ready
<def`>
(e.g leftpad, fs, etc)
<companion_cube>
0:-)
<Algebr``>
this one simple leftpad had more users than the entire ocaml ecosystem, what is there to smile about?
<hongbo_>
the cool thing is that you can only use a type safe subset of js libs, you still gain type safety
connorja_ has quit [Ping timeout: 265 seconds]
<Algebr``>
ghcjs has stalled a few times from what I understand.
chambart has joined #ocaml
<Drup>
hongbo_: if you work on emiting nice code and having good FFI was generic, you wouldn't have a bigger supporter than me. My issue with you work in *entierly* on the community split (and the slight misinformation regardless to how usable bucklescript really is)
<Drup>
And I'm sure you already know that.
<Drup>
On that note, I really gtg, sorry.
<Algebr``>
Drup: I don't know how you can call it a community split. hongbo_ work on BS has created more community than jsoo has in the past six years.
<Algebr``>
ocaml024: you know that aws gives machines away for free, like if you don't use bandwidth on them, I thin kyou can ssh into them, maybe abuse that for a free linux environment
<ocaml024>
really for free?
<Algebr``>
like if you don't use bandwidth on them
<Algebr``>
for 1000 hours, something like that
<Algebr``>
or a linode machine is just $5 a month
connorjacobsen has joined #ocaml
<Algebr``>
might be easier this way than a VM, this way you could access it from anywhere, OCaml anytime
<Algebr``>
ocaml024: and then you could make an OCaml server, test it out in real time
<Algebr``>
ocaml024: see cohttp source code, has some self-contained server examples that should work out the box
<ocaml024>
I just checked out aws, it asks for payment things...
<Algebr``>
it asks for payment things if you exceed a limit, that's why I'm saying, if you don't exceed the free limit, then its free
<Algebr``>
Amazon EC2 Resizable compute capacity in the Cloud. Learn More » 750 hours per month of Linux, RHEL, or SLES t2.micro instance usage https://aws.amazon.com/free/
<ocaml024>
It seems that they ask it from the beginning so that you pay if you forget to leave
<Algebr``>
Expires 12 months after sign-up.(Long time to forget)
<Algebr``>
anyway, just one idea
connorjacobsen has quit [Ping timeout: 244 seconds]
hongbo_ has quit [Quit: Page closed]
<ocaml024>
I like the idea but I prefer not giving away my credit card number if I can :)
<Enjolras>
ocaml024: what are you using to set up a vm on windows ? if you have a licence high enough, you might be able to use hyper-v
kushal has joined #ocaml
MercurialAlchemi has quit [Ping timeout: 244 seconds]
<ocaml024>
Enjolras : virtual-box
<Enjolras>
hmm yeah not the greatest vm ever. Although i use it everyday on mac, it's not too bad, but it's slow as hell
<Algebr``>
Enjolras: I really like VMWare but sad that apparently its being killed off
<Enjolras>
but for hyperv, you need windows pro
AlexRussia has joined #ocaml
<Enjolras>
it's not available on lower licences unfortunately
<companion_cube>
Algebr``: "more users" isn't necessarily a good thing, in itself; windows and php have more users than what I use, yet I don't want to touch them
<companion_cube>
leftpad may be popular, but it doesn't make it less absurd
<Algebr``>
companion_cube: valid points.
<companion_cube>
I still doubt that many JS programmers will pick OCaml just because it's a functional lang
<Enjolras>
i doubt js programmer will pick ocaml more than backend programmers
<def`>
thx Algebr``, ok. Not sure what to think.
<Algebr``>
companion_cube: if we doubt it, don't support it, then this will be a self fulfilling prophency and OCaml will be the only loser.
<companion_cube>
(I doubt Ocaml will gain adoption anyway, but I'm pessimistic)
<Algebr``>
def`: it sucks! VMWare was the only usable VM thing I ever got to use
<Enjolras>
xen and kvm are pretty good
<Enjolras>
my laptop runs on xen for instance, and it works really well. Especially PVH
<Algebr``>
Enjolras: I'm using it on OS X
<Enjolras>
kvm is fine too. But it does not apply to the "linux on windows usecase"
<Enjolras>
yeah. I'm using virtualbox on OS X and i wish there were a better alternative. It sucks :'(
<Enjolras>
it's so slow i cry every time there is an update of core
<Algebr``>
it was ridiculously slow
<Algebr``>
and crashed too often
connorjacobsen has joined #ocaml
<Algebr``>
gotta run friends, take care all.
<def`>
see you
<Enjolras>
bye
<ocaml024>
bye
<ocaml024>
I've got a VM working now :)
al-damiri has quit [Quit: Connection closed for inactivity]
connorjacobsen has quit [Ping timeout: 252 seconds]
MercurialAlchemi has joined #ocaml
Algebr`` has quit [Ping timeout: 265 seconds]
nicholasf has quit [Remote host closed the connection]
ldopa has joined #ocaml
connorjacobsen has joined #ocaml
connorjacobsen has quit [Ping timeout: 265 seconds]
tristero has joined #ocaml
regnat has quit [Ping timeout: 276 seconds]
shinnya has joined #ocaml
AlexRussia has quit [Ping timeout: 258 seconds]
connorjacobsen has joined #ocaml
kdas_ has joined #ocaml
connorjacobsen has quit [Ping timeout: 276 seconds]
kushal has quit [Ping timeout: 265 seconds]
kushal has joined #ocaml
connorjacobsen has joined #ocaml
kdas_ has quit [Ping timeout: 276 seconds]
connorjacobsen has quit [Ping timeout: 244 seconds]
freehck has quit [Remote host closed the connection]
ocaml024 has quit [Ping timeout: 264 seconds]
connorjacobsen has joined #ocaml
uberTaco has joined #ocaml
<uberTaco>
I saw some stuff in the whitequark logs about an "OCaml Platform". Is that an ongoing effort (a la Haskell/Rust "Platforms")?
<companion_cube>
as everything that requires some consensus within the community, it is, afaik, stalled
connorjacobsen has quit [Ping timeout: 276 seconds]
<uberTaco>
ah. Yeah, I could easily see "step 1: a stdlib extension" leading to immediate bikesheddy standstill
<uberTaco>
still a laudable goal though
zpe has quit [Remote host closed the connection]
BitPuffin has quit [Read error: Connection reset by peer]
bruce_r has joined #ocaml
connorjacobsen has joined #ocaml
Simn has quit [Read error: Connection reset by peer]
Simn has joined #ocaml
connorjacobsen has quit [Ping timeout: 240 seconds]
connorjacobsen has joined #ocaml
kushal has quit [Ping timeout: 276 seconds]
connorjacobsen has quit [Ping timeout: 250 seconds]
sh0t has quit [Remote host closed the connection]
jwatzman|work has quit [Quit: jwatzman|work]
larhat has quit [Quit: Leaving.]
thizanne has quit [Ping timeout: 250 seconds]
Anarchos has joined #ocaml
connorjacobsen has joined #ocaml
bruce_r has quit [Ping timeout: 264 seconds]
AlexRussia has joined #ocaml
octachron has quit [Ping timeout: 264 seconds]
connorjacobsen has quit [Ping timeout: 240 seconds]
pyon has quit [Quit: Fix config.]
connorjacobsen has joined #ocaml
connorjacobsen has quit [Ping timeout: 255 seconds]
govg has joined #ocaml
Simn has quit [Read error: Connection reset by peer]
Simn has joined #ocaml
connorjacobsen has joined #ocaml
shinnya has quit [Ping timeout: 258 seconds]
adelbertc has joined #ocaml
sepp2k has quit [Ping timeout: 250 seconds]
chambart has quit [Ping timeout: 244 seconds]
tane has joined #ocaml
Sim_n has joined #ocaml
kdas_ has joined #ocaml
Simn has quit [Ping timeout: 265 seconds]
dmbaturin_ is now known as dmbaturin
sepp2k has joined #ocaml
kdas_ is now known as kushal
kushal has quit [Changing host]
kushal has joined #ocaml
sepp2k has quit [Quit: Leaving.]
Simn has joined #ocaml
ewanas has joined #ocaml
simn__ has joined #ocaml
mal`` has quit [Quit: Leaving]
Sim_n has quit [Ping timeout: 265 seconds]
Simn has quit [Ping timeout: 264 seconds]
govg has quit [Ping timeout: 240 seconds]
octachron has joined #ocaml
AlexDenisov has joined #ocaml
simn__ has quit [Read error: Connection reset by peer]
connorjacobsen has quit []
Simn has joined #ocaml
hcarty has joined #ocaml
govg has joined #ocaml
AlexRussia has quit [Ping timeout: 276 seconds]
ewanas has quit [Remote host closed the connection]
mal`` has joined #ocaml
companion_square has joined #ocaml
govg has quit [Ping timeout: 250 seconds]
AlexRussia has joined #ocaml
companion_square has quit [Quit: oups, reboot inopiné !]
AlexRussia has quit [Ping timeout: 244 seconds]
ygrek has joined #ocaml
Submarine has joined #ocaml
govg has joined #ocaml
AlexRussia has joined #ocaml
manizzle has joined #ocaml
kushal has quit [Ping timeout: 250 seconds]
<Bluddy[m]>
Is stdlib extension really that controversial? Maybe I'm just trolling here, but who here doesn't think Containers is currently the cleanest, best organized extension to the stdlib?
<companion_cube>
all the people who don't use it, I think
<Bluddy[m]>
And is there anyone (outside of Jane Street) who thinks List.map ~f:(fun x-> ...) is a good idea?
<Bluddy[m]>
companion_cube: I don't think so. I'm not using Containers right now, and I can objectively say that if I were to start another project today, I'd want to use it.
<companion_cube>
List.map ~f: is pretty nice actually
<companion_cube>
I regularly wish I'd gone that way
<Bluddy[m]>
Is it?
<Bluddy[m]>
Every time you want to map?
<companion_cube>
it's nice when you have `List.map foo ~f:(very long function)`
<companion_cube>
no, but quite often
<rgrinberg>
i don't understand why this stdlib thing is an issue anyway. in haskell you need much more than base to accomplish anything
<rgrinberg>
you don't even have a decent hash table bult in
<companion_cube>
and in haskell, there is cabal hell
<hcarty>
Bluddy[m]: Agreed that List.map ~f is nice. As for why not Containers - mostly naming differences w/other (dbuenzli) libraries
<companion_cube>
there might be a link
<rgrinberg>
companion_cube: cabal hell has been vanquished
<companion_cube>
not in my experience :/
<companion_cube>
stack makes it better, but not that good
<rgrinberg>
i don't know, I've yet to see a package where stack build didn't work for me
<Bluddy[m]>
hcarty: everyone knows where the function is in List.map. If I need to swap arguments, I'll use a simple argument swapping combinator.
<rgrinberg>
granted, i don't venture far out of stackage
<Bluddy[m]>
Labels are good for arguments that are hard to remember, like the zero in List.fold_left and fold_right
<Bluddy[m]>
Anyway just my opinion
<companion_cube>
sometimes I `List.iter` a very large function on a list, and it's less readable to skip 25 lines to know which list
<hcarty>
Bluddy[m]: Everyone knows it, but it is nice to be able to put the list first as companion_cube said
<companion_cube>
anyway
<companion_cube>
rgrinberg: what kind of differences?
TheLemonMan has joined #ocaml
<rgrinberg>
you mean hcarty ?
<Bluddy[m]>
hcarty: But then you use a simple flip function: let flip f x y = f y x. You can even curry it if you need to with `let flipmap = flip List.map`. No need to add a tax to every invocation of map.
shinnya has joined #ocaml
<Bluddy[m]>
I can confirm that cabal hell still exists with stack. It all depends how far down the rabbit hole of packages you reach.
<rgrinberg>
my experience shows that opam hell is far more common now :/
<rgrinberg>
opam usage still relies on having a global package db
<rgrinberg>
we just have a better constraint solver, how awesome
<hcarty>
companion_cube: print vs pp ....
<companion_cube>
ah, this
<companion_cube>
-_-
<companion_cube>
sorry for the confusion, too
<hcarty>
companion_cube: Small complaint, not a real issue with the library
<companion_cube>
I can't really break it, but it's from back when I used bprintf a lot
<Bluddy[m]>
rgrinberg: opam 2.0 should have local switches
<rgrinberg>
Bluddy[m]: that's a decent start. I just hope it won't be super annoying to use like cabal's sandboxes
<rgrinberg>
but stack is still a far more integrated solution
<hcarty>
companion_cube: Yeah, the reasoning makes sense. Format has been Super Popular more recently
<companion_cube>
yes
<companion_cube>
in particular because it got faster
<companion_cube>
at least to me
<hcarty>
Agreed
<hcarty>
When I run into opam hell it's usually due to (a) pins that I created and forgot about or (b) missing version constraints after a dependency's new API-breaking version
<Bluddy[m]>
companion_cube: I never realized how good format was. I created a really crappy print system for my language (struggling with the boxes thing), and recently I read through the compiler's pprintast and it clicked.
<companion_cube>
I wish OCaml had a cargo-like system…
<rgrinberg>
sure, cargo or stack
<rgrinberg>
clone either :P
<hcarty>
I'm not sure if this is coming in 2.0, but allowing local switches to share a compiler would save a lot of potential pain with local switches
<companion_cube>
I meant cargo also as a build system
<Bluddy[m]>
companion_cube: Like I said on reddit, fork ocamlbuild, get rid of .native and .byte, enforce hierarchies via directories... what else do you need?
<companion_cube>
there is solvuu_build which looks nice
<smondet>
Bluddy[m]: yes +1 out of JStreet: List.map ~f:(fun x-> ...): labels always make code more readable, little combinators like `flip` or `$` add annoying mental burden.
<companion_cube>
Bluddy[m]: the compiler is too complicated, imho
<rgrinberg>
Bluddy[m]: IMO those are trivial and useless additions to ocamlbuild
orbifx-m has joined #ocaml
<Bluddy[m]>
smondet: argh
<j0sh>
am i the only one who prefers the use of combinators and currying to labels?
<Bluddy[m]>
companion_cube: The compiler is heavily undocumented. Still.
<Bluddy[m]>
j0sh: I'm with you, but I think labels have their place. Is the zero the argument following the function, or following the collection in List.fold_left? ~zero to the rescue!
<smondet>
I've been trying https://github.com/solvuu/solvuu-build for new project, and it's really going in the right direction: remove all the default ocamlbuild rules + add sane ones based on a declarative but hackable `myocamlbuild.ml`
<j0sh>
Bluddy[m]: yeah, but usually the compiler will save you there? unless you're folding onto the same type as the input, i suppose...
<orbifx-m>
j0sh: is there a comparison of the two?
<companion_cube>
Bluddy[m]: the whole compilation process is too messy
<Bluddy[m]>
rgrinberg: I don't think they're useless. .native and .byte confuses beginners. a. I can't have a program that compiles to .native -- I have to do something else to get things 'just right'. b. Hierarchies are a huge annoyance in OCaml.
<j0sh>
orbifx-m: using labels and non-labels?
<rgrinberg>
j0sh: i think most of us don't care either way ^_^
<Bluddy[m]>
j0sh: Yeah can't rely on the compiler. I want to just write my code correctly. The more arcane arguments, the more labels prove their worth.
octachron has quit [Quit: octachron]
<Bluddy[m]>
companion_cube: explain
<rgrinberg>
Bluddy[m]: hierarchies would be nice, but AFAIK they don't play well with separate compilation due to the limitations of ocamldep
<rgrinberg>
so there's not much for ocamlbuild to do until that's resolved
<companion_cube>
too many file types, too many possible ways to screw up, too many moving parts (ocamlc/ocamlfind/opam…) and the whole module package is not that good w.r.t. compilation
<companion_cube>
(no namespaces, packs are horrible, and there is not an obvious mapping file -> module)
<rgrinberg>
ocamlbuild has many more real limitations. As cube said, check out solvuu_build for a serious attempt at making it usable
<rgrinberg>
it's still a horribly designed tool. Case in point: try expressing a dependency grapg where you first build a preprocessor and then apply it to the rest of your codebase.
<rgrinberg>
(that can come up quite easily if you're using ppx_driver)
<orbifx-m>
rgrinberg: does opium work with 4.03?
<j0sh>
yeah tooling needs work, especially for beginners. its hard to tell where the boundary between ocamlfind/ocamlbuild/oasis/etc is if you're not familiar with all three parts
<Bluddy[m]>
rgrinberg: OK good point. Is OMake a better starting point then?
<rgrinberg>
Bluddy[m]: no. they all suck.
<companion_cube>
^
thizanne has joined #ocaml
<companion_cube>
and I think the compiler being too flexible is one of the culprits
<rgrinberg>
you cannot build something that's as usable as stack out of any of them
<j0sh>
Reason is supposed to improve tooling... i wish they'd focus on that and forget the rather arbitrary syntax changes
<rgrinberg>
s/stack/cargo/ if yo uprefer
zpe has joined #ocaml
<rgrinberg>
j0sh: yup. ocaml's bike shed is painted vomit green, so it's too attractive a target
<rgrinberg>
like a trap
<Bluddy[m]>
It's crazy that we can't get this crap to just work.
<Bluddy[m]>
It's like the 2016 US election forever and ever.
<rgrinberg>
orbifx-m: sure does.
<companion_cube>
there is no way of achieving consensus in the community
<companion_cube>
therefore things barely move
<orbifx-m>
Ok.. it's cstruct stopping the installation. Does cstruct need some magic steps to work on macos?
<Bluddy[m]>
companion_cube: but look -- opam was able to get things moving. And opam is great.
<companion_cube>
there wasn't already several competing solutions when opam arrived
<j0sh>
godi?
<companion_cube>
for build systems and stdlibs, it's different
<rgrinberg>
there was. oasis db and godi
<companion_cube>
no one used them
<Bluddy[m]>
You don't need consensus in the community. You just need consensus between a few devs, and they create enough facts on the ground that everyone else just has to adapt.
<companion_cube>
create yet another build system?
<companion_cube>
yet another stdlib?
<Bluddy[m]>
No. Identify the weak points and fix them in a compelling way
<ggole>
New language time! Fresh start!
<rgrinberg>
there is no problem with the stdlib situation. -_-
<rgrinberg>
at least it's not any bigger than other languages
<orbifx-m>
rgrinberg: been reading your blog, as I'm deciding between opium and oscigen. Am I right in thinking that your lib focuses on doing http handling right and leaves the rest out?
<Bluddy[m]>
Like what opam did. Nobody can compete with opam because opam did things so well that nobody can object. I remember there were those who objected.
<rgrinberg>
orbifx-m: kinda, cohttp does the http handling. opium is more of a convenient wrapper with some extra structure
<orbifx-m>
Yeah
<rgrinberg>
companion_cube: and more build systems would be fine. the problem with that however is that the barrier to entry for creating a build system that is usable is way too high
<rgrinberg>
which i also blame the compiler for
<orbifx-m>
rgrinberg: Any reason one should opt for oscigen if one is making a simple webapp?
<rgrinberg>
and don't see "a few devs" resolving. Because I doubt there's more than "a few devs" that understand the problems of making a build system for OCaml well enough
<Bluddy[m]>
rgrinberg: could you elucidate on blaming the compiler?
<rgrinberg>
orbifx-m: if your app requires JS and you don't want to write any
<rgrinberg>
Bluddy[m]: well just look at the build rules for any of the big build systems out there. they're monsters
<orbifx-m>
Non issue. Anything else? :-P
<Bluddy[m]>
rgrinberg: OK. But what's missing compared to other languages?
<rgrinberg>
look at the recent problems of build systems + flambda. if alain has problems with it, i doubt many others will fare better
<Bluddy[m]>
rgrinberg: But haskell has been doing cross-module optimization for years. It's the only way they can get decent performance.
<orbifx-m>
Does anyone know if lwt can run on macos?
<rgrinberg>
orbifx-m: yes it does and no i don't know of other problems.
<rgrinberg>
Bluddy[m]: does haskell have true separate compilation?
<companion_cube>
Bluddy[m]: "the weak points" is lack of consensus and community fragmentation
<companion_cube>
how do you propose to fix this?
Submarine has quit [Remote host closed the connection]
<rgrinberg>
companion_cube: mutt-kz is dead, use neomutt :P
ewanas has joined #ocaml
<Bluddy[m]>
companion_cube: I don't think those are the real weak points. Some people are die-hard traditionalists, but most see something new and good and appreciate it. I think most OCaml programmers aren't even exposed to Containers, and if they saw it would consider it a better alternative to Batteries, for example.
<companion_cube>
rgrinberg: really?
<rgrinberg>
companion_cube: really!
<companion_cube>
I was just looking for alternatives
<companion_cube>
funny how you told me that at the precise moment I was looking for info about neomutt
<octachron>
Bluddy[m], another example of complexity transferred from the compiler to the build system: namespaces
<rgrinberg>
i'm pretty sure neomutt has all the patches from mutt-kz and many fixes
<Bluddy[m]>
companion_cube: And nobody has real dedication to a build system. Who cares about a build system? It's something you set up and never want to touch again. It needs to just work.
<companion_cube>
I would love neomutt to migrate incrementally to rust 0:-)
<companion_cube>
octachron: or lack thereof
<companion_cube>
I agree, we should have namespaces
<companion_cube>
but we should not be able to put modules anywhere
<companion_cube>
just ask for src/A/B/C.ml to hold module A.B.C
<Bluddy[m]>
yes
<octachron>
Module aliases were partially introduced as a way to improve namespacing, by giving all the work to the build system
<Bluddy[m]>
directories = hierarchies
<rgrinberg>
I don't know, I would rather focus on making something usable with what we have
<rgrinberg>
right now even mirgrating your code to aliases is a non starter for most people
<rgrinberg>
it was a totally useless feature, outside of janestreet
<Bluddy[m]>
rgrinberg: Let the build system do it.
al-damiri has joined #ocaml
<companion_cube>
I don't know, I just added no_alias_dep to my _tags
<companion_cube>
no idea if it works
<Bluddy[m]>
Directories should equal the module hierarchy. It's pretty much a programming standard at this point, and it simplifies the work for build tools.
<Bluddy[m]>
And if ocamldep doesn't work well with this, then by golly we need to fix it.
<companion_cube>
rgrinberg: ffs I have the same segfault
<rgrinberg>
haha
<Bluddy[m]>
hcarty: yes, I was referring to this vaguely above. It needs to be the default. In every build system.
<rgrinberg>
companion_cube: well the neomutt maintainer is responsive
AlexDeni_ has joined #ocaml
<chsn>
in ocaml, is it possible to dclare 'anonymous types' i..e instead of point2d { x : float, y: float} I just want to say {x : float, y : float}
jeffmo has joined #ocaml
<Bluddy[m]>
rgrinberg: thinking about it some more, the objective of building something, then preprocessing, then building the rest, is pretty complex. It needs to be built into the build tool.
AlexDenisov has quit [Read error: Connection reset by peer]
<hcarty>
chsn: Not with record types
<Bluddy[m]>
chsn: not for records, but you can use tuples.
<rgrinberg>
Bluddy[m]: oh cmon, if it's easy enough in make, it should be easy in OCaml
<hcarty>
chsn: Or objects
<rgrinberg>
s/OCaml/ocamlbuild/
<chsn>
Bluddy[m]: hcarty : 1) are tuples 'named', i.e. do they have fields x, y, or is it just Float * Float; hcarty: can you point me to an example?
<companion_cube>
rgrinberg: make is weak w.r.t dynamic dependencies,isn'tit?
<hcarty>
chsn: let f x = object method x = x end
<Bluddy[m]>
rgrinberg: that's silly. Make is a general purpose system. I wouldn't expect haskell's build tools or cargo to do this easily unless it was a common usecase. If it is one in OCaml, it needs to be built into the build tools.
<rgrinberg>
companion_cube: it is, but this is static. add a target for building a preprocessor, add it as a dep to all the sources that are being preprocessed
<j0sh>
i generally use make for everything OCaml except when packaging, then its on to oasis. the only trouble with make is the gymnastics needed if switching between native code and bytecode
<rgrinberg>
and add the -pp flag t oevery compilation
<chsn>
hcarty: how does that give me 'named tuples' ?
<j0sh>
make+ocamlfind is enough 90% of the time, at least for me
<hcarty>
chsn: It's not named tuples - it's an object
<rgrinberg>
j0sh: how do you handle optional deps and other configure related things?
<j0sh>
rgrinberg: i don't :)
<chsn>
XY problem: I want row types in ocaml. Is there a way to do that? :-)
<rgrinberg>
it's 90% enough for the grey beards.
<companion_cube>
rgrinberg: but Ocaml is full of dynamic deps
<rgrinberg>
companion_cube: that's true, but honestly I'd compromise for a static, but staged solution
<rgrinberg>
e.g. where your dependency discovery phase is separate
<companion_cube>
meh
<j0sh>
doesn't opam handle that pretty well
<companion_cube>
you'd need to run it recursively anyway
<rgrinberg>
yes it's ugly, but if it's portable, doesn't require extra deps, then fuck yeah i'll take it
<companion_cube>
j0sh: we're talking about build systems right now
<Bluddy[m]>
chsn: then you want to use objects
<companion_cube>
rgrinberg: still needs a fixpoint (think foo.mly.cppo, with some dependencies inside)
<rgrinberg>
companion_cube: also def` pointed out on the ML that writing out deps manually is back in style again
<j0sh>
companion_cube: yeah but can build particular targets based on the deps you have enabled (discovered via opam or whatever)
<rgrinberg>
i honestly wouldn't mind doing that sometimes
<Bluddy[m]>
rgrinberg: Oh god why is it back?
<Bluddy[m]>
rgrinberg: Do we need to lose even more ground to dynamic languages?
<rgrinberg>
technical reason: because it's fast, good for static analysis, and works with all languages
<rgrinberg>
real rason: because google is doing it
<j0sh>
make-style 'foo: a.ml b.ml' dependencies? agreed. ocamlbuild is too much magic
<rgrinberg>
see bazel
<j0sh>
(but maybe i'm old fashioned)
<Bluddy[m]>
rgrinberg, j0sh: it's absolutely horrible. It's the build-system equivalent of no type checking
<companion_cube>
I write 30 files, it's like 200 dependencies
Sim_n has joined #ocaml
<rgrinberg>
companion_cube: obviously it would be assisted and/or partially generated
<companion_cube>
-_-
MercurialAlchemi has quit [Ping timeout: 260 seconds]
<companion_cube>
google has crazy needs
<companion_cube>
even jenga is overkill
<Bluddy[m]>
rgrinberg: It's not just scalability. It's also the fact that if you miss one dependency, you're screwed.
<rgrinberg>
Bluddy[m]: you're talking as if ocamldep is precise
<hcarty>
chsn: objects or polymorphic variants
<rgrinberg>
this manual tweaking is sometimes required anyway. Might as well make it first class. Jenga does that well fyi
<Bluddy[m]>
rgrinberg: I've never had issues with it. If there are issues, they need to be resolved, but I would never suggest leaving the user vulnerable.
<companion_cube>
ocamldep not being precise is also totally crazy
<companion_cube>
the sign that the module system has issues
<companion_cube>
(well, `open` should die anyway)
<rgrinberg>
companion_cube: isn't local open just as much of a problem?
<companion_cube>
grr, at least `mutt` now has the sidebar
<rgrinberg>
\o/
<unbalancedparen>
companion_cube: i did not get it, could you please explain
<Bluddy[m]>
companion_cube: I wouldn't say open should die, but we need a way to import subsets of modules
<companion_cube>
and doesn't segfault
kakadu has joined #ocaml
Simn has quit [Ping timeout: 260 seconds]
<companion_cube>
actually, I'm not even sure why ocamldep is not precise? is it because it's purely syntactical and doesn't parse the .cmi files?
<rgrinberg>
companion_cube: yes
<companion_cube>
blergh
zpe has quit [Remote host closed the connection]
<Bluddy[m]>
it really sounds like ocamldep is the weakest link.
<rgrinberg>
we need someone to read jsc's recently published internal build rules
<rgrinberg>
and report on the good parts
ggole has quit []
chsn has left #ocaml [#ocaml]
<companion_cube>
ocamlfind is also the weakest link, it should be part of the compiler
_whitelogger has joined #ocaml
<companion_cube>
it introduces a difference between modules (or, imho, what should be namespaces) and libraries
<companion_cube>
of course opam adds its own notion of package on top
AlexDeni_ has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
<rgrinberg>
also, it infects the build process everywhere
<rgrinberg>
with that predicate + flags nonsense
<rgrinberg>
and requires us to generate META files for any non trivial package, or packages with optional deps
<Bluddy[m]>
rgrinberg: yeah I agree that it's another weirdness of ocaml, but... wait why is it even necessary?
<rgrinberg>
what is?
<Bluddy[m]>
ocamlfind. why can't I just point the compiler/linker to the location of the compiled packages?
<rgrinberg>
the predicate/flags nonsense is necessary b/c packages need to expose build level metadata to their consumers
<Bluddy[m]>
rgrinberg: do you have an example?
<Bluddy[m]>
what kind of metadata?
<Bluddy[m]>
this whole ocamlfind thing now seems completely useless to me
<rgrinberg>
there's plenty of examples. most prominent recent use case would be ppx_deriving
orbifx-m2 has joined #ocaml
_andre has quit [Quit: leaving]
<rgrinberg>
how does ppx_deriving know which modules to dynlink to add more derivers to its preprocessor
orbifx-m has quit [Ping timeout: 244 seconds]
<Bluddy[m]>
so ocamlfind is the metadata database?
<rgrinberg>
most of it seems to be preprocess related crud, some of it is linking tricks
<rgrinberg>
Bluddy[m]: your collection of META files is that database. ocamlfind manages that
<rgrinberg>
alright, I gotta go. I hope you all have a productive discussion :P
<Bluddy[m]>
later
<Bluddy[m]>
thanks for the info and input
orbifx-m has joined #ocaml
<Bluddy[m]>
companion_cube: so it seems like ocamlfind serves a useful function that needs serving, right? assuming we're stuck with modules and no namespaces, would you want to see module names become the entry names in ocamlfind's database?
rgrinberg has quit [Ping timeout: 258 seconds]
orbifx-m2 has quit [Ping timeout: 250 seconds]
<companion_cube>
yeah, but many things w ould move into packs
larhat has joined #ocaml
<companion_cube>
still, I think it would be better
SpiceGuid has joined #ocaml
larhat has quit [Client Quit]
<Bluddy[m]>
sorry for another basic question, but why would we need packs?
<companion_cube>
only way to emulate namespace hierarchies
orbifx-m2 has joined #ocaml
unbalanced has joined #ocaml
orbifx-m has quit [Ping timeout: 252 seconds]
<hcarty>
Bluddy[m]: packs and module aliases are two ways we can have Foo.Bar and Baz.Bar not have linking conflicts due to bothing having a 'Bar' module
<hcarty>
bothing?
<hcarty>
*both
<Bluddy[m]>
hcarty: So when you create a module that contains aliases to other modules, and compile with -no-dep-aliases, what gets created?
<hcarty>
Bluddy[m]: -no-alias-deps is a way to have something similar to packs but without requiring linking of unused aliased modules
<hcarty>
Unrelated to the compilation discussion: (Re.split Re.(compile eol) "a\nb") = ["a"; "\nb"] --- this is not what I would have expected
<companion_cube>
hmmm, maybe report
<hcarty>
companion_cube: Will do. Re.split Re.(compile @@ char '\n') "a\nb" = ["a"; "b"], which is what I would expect
<companion_cube>
indeed
<companion_cube>
eol might be a position, not a char
<companion_cube>
so it doesn't consume the \n?
<hcarty>
Doesn't look like it
<Bluddy[m]>
hcarty, companion_cube: so if I'm making a library and I want Foo.Baz and Foo.Bar to both be available, I have to use packs? And then, when I'm a user using the library and I want to use Foo.Baz, I compile with -no-alias-deps to reduce my footprint? Or is something missing here (because I know Jane Street had to change their code to make this work).
agarwal1975 has quit [Quit: agarwal1975]
<hcarty>
companion_cube: I'm not sure why \n would come after the eol position, but perhaps there's a definition which states that \n is after the end of the line
<hcarty>
Bluddy[m]: You use packs OR aliases
<hcarty>
-no-alias-deps goes with aliases
<hcarty>
With packs you always link everything in the pack
<octachron>
Bluddy[m], you can also use module aliases: use prefixed long name for inner modules and then have file foo that make the mapping long name to short name
agarwal1975 has joined #ocaml
<hcarty>
And you only need packs/aliases if you want the definition of Foo.Baz and Foo.Bar to live in different files
<companion_cube>
hcarty: well \n does not belong in the line
<companion_cube>
so I'd say eol comes before
<companion_cube>
same as word boundaries, come before spaces
fraggle_ has quit [Ping timeout: 264 seconds]
<hcarty>
companion_cube: Good point, thanks
rgrinberg has joined #ocaml
orbifx-m has joined #ocaml
<Bluddy[m]>
Thanks for the clarifications guys. And this fetish for connecting the filename to the module name is... at the compiler level?
orbifx-m2 has quit [Ping timeout: 244 seconds]
<hcarty>
The compiler says that foo.ml -> module Fooo
<hcarty>
s/Fooo/Foo/
<companion_cube>
but it doesn't say that foo/bar.ml -> Foo.Bar
<Bluddy[m]>
It seems like everything would have been so much simpler if there was a base directory, and the compiler decided that foo/bar.ml was Foo.Bar
<companion_cube>
yeah
<Bluddy[m]>
Is there any possible way in heck that we can still make this happen in some miraculous backwards-compatible way?
<companion_cube>
ahah :D
<Bluddy[m]>
Seriously, nobody wants this current system. Hacks have been built to subvert it (packs & aliases). Let's fix it people.
<companion_cube>
fixing it means breaking 99% of the existing programs, I think
<companion_cube>
so it means a big effort from maintainers
<companion_cube>
also, not everyone agrees on the solution
<Bluddy[m]>
but won't they be happy to know that their language is now a better place?
<hcarty>
Unless we do something with attributes maybe
<hcarty>
[@@@ocaml.module Foo] in the file myfile.ml
<rgrinberg>
IMO, i'd rather they made the namespace__module convention work better somehow
<hcarty>
I'm quite sure it's not that simple as far as the actual compilation process goes
<hcarty>
rgrinberg: There's some basic support there in 4.03 or 4.04 isn't there? Or maybe just for short-name selection
<companion_cube>
rgrinberg: is this a convention? oO
<rgrinberg>
hcarty: AFAIK, they have --short-paths understand this convention now. And possibly support in ocamldep
<rgrinberg>
in the -as-map
fraggle_ has joined #ocaml
<rgrinberg>
companion_cube: yeah, that's another janestreet'ism that has been unofficially blessed
<companion_cube>
ahah
<octachron>
rgrinberg, yep __ in the filename gives a -10 penalty in the short-path selection algorithm
<octachron>
rgrinberg, it is documented in the manual, so a little more than unofficial
<rgrinberg>
octachron: did you document it? if so then thanks again!
<companion_cube>
well at least we finally improved oasis' dependencies problem
<companion_cube>
sometimes things progress
<rgrinberg>
companion_cube: what happened?
<companion_cube>
well, no more camlp4
<companion_cube>
also, support for omake
<rgrinberg>
the support for omake isn't flawless, i tried it on cohttp and it failed :/
<rgrinberg>
I should make some bug reports
<rgrinberg>
one day i'll a forge account
<companion_cube>
oh
<companion_cube>
(one day the forge will finally die, and projects will move to github)
<companion_cube>
(one day, also, projects will host their doc somewhere; I'm looking at you zarith)
<hcarty>
companion_cube: Thanks for the effort toward a camlp4-less oasis!
orbifx-m2 has joined #ocaml
<hcarty>
rgrinberg: There are tasks on the oasis forge by Sylvain to move completely over to github from the forge
<octachron>
rgrinberg, after verification, yes, I was the one that wrote this part of the documentation
<companion_cube>
yay \o/
<rgrinberg>
octachron: we can't thank you enough for that!
<Bluddy[m]>
yeah good job companion_cube
<zozozo>
ideally, packages should install their doc (and/or contents of the .mli files), so as to have local doc for installed packages
orbifx-m3 has joined #ocaml
orbifx-m has quit [Read error: Connection reset by peer]
<companion_cube>
sometimes the doc is more than .mli files…
<companion_cube>
or it should be
<Bluddy[m]>
zozozo: local docs are useless if they're a pain to find
<companion_cube>
but then we'd need something (ocp-browser?) to find all the installed docs easily
<companion_cube>
^ Bluddy[m]
<rgrinberg>
or we can all just switch to rust
<rgrinberg>
(don't kill me)
<zozozo>
Bluddy[m]: right, but maybe opam and/or ocamlfind could be used to have a local db of the docs ?
<Bluddy[m]>
you know, github gives you free hosting per project. It's not hard to put the docs up there
chsn has joined #ocaml
<zozozo>
Bluddy[m]: that's what I'm doing
<companion_cube>
rgrinberg: yeah, sometimes it's tempting…
orbifx-m2 has quit [Ping timeout: 276 seconds]
<companion_cube>
(but I know I'd be far less efficient, at least at the beginning)
<companion_cube>
(and then I'd be glad about the perf, tooling and portability :/)
<companion_cube>
Bluddy[m]: but most people don't do it
<rgrinberg>
let's see how they handle this optional GC they're adding
<companion_cube>
(I'm looking at you, zarith)
<rgrinberg>
if that goes well, i would for sure be tempted
<companion_cube>
are they adding an official optional GC?
<companion_cube>
is there a nything to read?
<profan>
rgrinberg: im pretty sure they're not adding optional GC as much as a good way for it to interface with languages that require it
<profan>
(ie, js)
<profan>
making normal rust work with both the ownership system and some kind of optional gc is probably a total no-go
<chsn>
Real World Ocaml: 1 chapter done. 22 left to go. YAY!
<Bluddy[m]>
Or we could just fork everything to ocaml 2.0, fix all the legacy crap, and watch everyone who cried about how we can't fix anything drastic join us
<companion_cube>
it would be a lot of work to get a working ocaml 5.0 with, say, namespaces and ocamlfind merged (or an equivalent replacement within the compiler itself)
<rgrinberg>
As i've said, only a handful people even understand enough to tackle the build system fiasco
<companion_cube>
this Gc<> thing looks interesting, using intrinsics looks nice
johnf has quit [Remote host closed the connection]
Anarchos has quit [Ping timeout: 252 seconds]
<rgrinberg>
companion_cube: but does rust have enough features for you to do type hackery in?
yegods has quit []
<zozozo>
does rust have GADTs ?
copy` has quit [Quit: Connection closed for inactivity]
<rgrinberg>
zozozo: don't think so.
<rgrinberg>
but they're promising to add HKT one day
<companion_cube>
otoh they have traits
<zozozo>
HKT ?
<rgrinberg>
higher kinded types
octachron has joined #ocaml
<zozozo>
ok
<hcarty>
rgrinberg: Rust is wonderful, and my hope is in five years it will be as usable as OCaml is now for quickly writing code
<hcarty>
Hopefully OCaml will progress similarly over those five years
unbalanced has quit [Quit: WeeChat 1.4]
<rgrinberg>
don't laugh, but i think swift will get there first
<companion_cube>
probably not on linux, it won't feel like a first-class citizen
<rgrinberg>
i dunno, the toolchain is all llvm based right?
<rgrinberg>
apple has been pretty good with working with libclang to implement xcode
<rgrinberg>
so if you mean tooling, i think we'll have a chance to integrate with proper things on linux rather than write our own
<companion_cube>
well, does it still require xcode right now?
<rgrinberg>
nope
<rgrinberg>
it works on linux now
<rgrinberg>
and they CI it on ubuntu
nicholasf has joined #ocaml
rgrinberg has quit [Read error: Connection reset by peer]
<companion_cube>
ok, good to know
<hcarty>
No laughter here re:swift. My initial impression of the language when it was first shown was that they've done a lot right with it.
nicholasf has quit [Remote host closed the connection]
<companion_cube>
I have some stupid reluctance to use ARC, but it might work
<companion_cube>
rust still sounds more exciting
<hcarty>
Rust is pretty amazing. If/when usability is improved to the point where borrowing becomes accessible for beginners it will be pretty fantastic
john51 has joined #ocaml
<companion_cube>
Ocaml isn't accessible for beginners either, and I don't care, I want something where I'm efficient
john51_ has quit [Ping timeout: 265 seconds]
<hcarty>
companion_cube: Borrowing is differently difficult in its accessibility, at least in Rust as it exists now
<hcarty>
But I agree, efficient is the desire
nicholasf has joined #ocaml
<companion_cube>
also, wow, a stdlib with iterators
<companion_cube>
it would be like a dream
<hcarty>
companion_cube: :-)
<hcarty>
If only someone would propose such an addition in OCaml. And respond to comments, updating as the discussion moves along.
<hcarty>
...
<companion_cube>
yeah, I should add tests, but I'm not even sure anymore which solution is the right one
<companion_cube>
:-)
<companion_cube>
I meant :-( damnit
ewanas has quit [Quit: Leaving]
hcarty has quit [Ping timeout: 265 seconds]
orbifx-m3 has quit [Quit: AtomicIRC: The nuclear option.]
rgrinberg has joined #ocaml
Sim_n has quit [Quit: Leaving]
agarwal1975 has quit [Quit: agarwal1975]
agarwal1975 has joined #ocaml
rgrinberg has quit [Quit: WeeChat 1.5]
rgrinberg has joined #ocaml
TheLemonMan has quit [Quit: "It's now safe to turn off your computer."]
jeffmo has quit [Quit: jeffmo]
yegods has joined #ocaml
<chsn>
is it possible to run mirageOS directly on google app engine?
rgrinberg has quit [Ping timeout: 244 seconds]
tane has quit [Quit: Leaving]
agarwal1975 has quit [Quit: agarwal1975]
hcarty has joined #ocaml
hcarty has quit [Client Quit]
agarwal1975 has joined #ocaml
<chsn>
haskell has things like . :: (f -> g) -> (g -> h) -> (f -> h), and ($) :: (a -> b) -> a -> b
<chsn>
does ocaml have these?
<Drup>
$ is @@, . doesn't exist in the stdlib
<chsn>
Drup: thanks
<Bluddy[m]>
chsn: I use |- for haskell's . . It's easy to define and I think I saw it used elsewhere.
<chsn>
Bluddy[m]: does ocaml support unicode ?
<octachron>
chsn, not for identifiers
SpiceGuid has quit [Quit: ChatZilla 0.9.92 [SeaMonkey 2.40/20160120202951]]
kreas has joined #ocaml
octachron has quit [Quit: Leaving]
pierpa has quit [Ping timeout: 240 seconds]
kakadu has quit [Remote host closed the connection]
bruce_r has joined #ocaml
<Bluddy[m]>
Public Service Announcement: if you find a library on github without online docs, please post an issue asking to host docs on a github.io site for the project (https://pages.github.com/) with a link to the site in the readme.
<Bluddy[m]>
chsn: At what level do you need it supported? There are many libraries for handling unicode.
kreas has quit [Remote host closed the connection]