ChanServ changed the topic of #ocaml to: Discussions about the OCaml programming language | http://www.ocaml.org | OCaml 4.02.1 announcement at http://ocaml.org/releases/4.02.html | Public channel logs at http://irclog.whitequark.org/ocaml
reem has quit [Remote host closed the connection]
reem has joined #ocaml
<Leonidas> haesbaert: function_names_are_written_with_underscores_in_ocaml_usually
thomasga has joined #ocaml
reem has quit [Remote host closed the connection]
<Leonidas> Async Pipe is a really verbose way to simulate lazy lists
<Drup> Leonidas: and a very bad way, especially since Lazylist is in Core
<Drup> or maybe not
<Drup> weird, I remember it
<Drup> well, there is Core_kernel.Sequence (which is different from companion_cube's sequence)
<Leonidas> Drup: I was very confused, since I couldn't find it
vanila has quit [Quit: Leaving]
<Leonidas> but I'm not using the newest docs
<Drup> (actually, it's pretty similar)
<Leonidas> yes, looks good
<Drup> I find sequence nicer
bytbox has quit [Ping timeout: 245 seconds]
<Leonidas> I'm already using Core in that program, might as well.
<Drup> using core doesn't prevent using the rest of the world
<Leonidas> yes, but introducing another dependency when the library I am using provides a decent enough implementation on its own is rather pointless :-)
<Leonidas> rewrote the code with Sequence, much saner, nice
govg has quit [Quit: leaving]
psy_ has quit [Ping timeout: 265 seconds]
<struktured> Leonidas: nice! can I see that?
reem has joined #ocaml
antkong has joined #ocaml
<Leonidas> struktured: what exactly?
<struktured> Leonidas: the aformentioned rewrite w/sequence, if you can link to source?
reem has quit [Remote host closed the connection]
madroach has quit [Ping timeout: 264 seconds]
<Leonidas> I actually thought about using async_parallel, just for fun, but then it is just a very silly example
<Leonidas> I got nerdsniped by a friend learning ocaml to implement the Unix which command and I couldn't stop
madroach has joined #ocaml
laughing-octo-sh has quit [Ping timeout: 256 seconds]
<dmbaturin> Leonidas: Maybe not stop here and implement a whole coreutils? :)
<dmbaturin> Looks a bit empty.
yaewa has joined #ocaml
moei has quit [Ping timeout: 240 seconds]
<Leonidas> let's see how many coreutils there are in total :-)
<dmbaturin> (number of BSD forks in existence) + epsilon
<Leonidas> ocaml nproc would be print_endline "1" ;)
<dmbaturin> Speaking of which, is there a good explanation of the runtime lock anywhere?
<dmbaturin> What exactly gets giant locked and what does not.
Simn has quit [Quit: Leaving]
<struktured> Leonidas: I couldn't get async parallel working on multiple servers :(
<whitequark> the lock must be held while ocaml code is executing. it is force-released when thread switching by SIGVTALRM. it is also released around unix calls, allowing the threads to switch as well
cateches has joined #ocaml
<cateches> can anyone here help with cohttp issues?
<Leonidas> struktured: this would've been local :-)
<cateches> and I run run `curl -X POST -d 'foo bar' http://localhost:8080` and it posts, but as soon as I try to hit it with ab, I get apr_socket_recv: Connection refused (61)
<cateches> 100% of the time
<struktured> Leonidas: that I got working which did get me psyched up for a bit
<cateches> and then a minute later, the whole process dies with a huge stacktrace
<cateches> nvm, I think this is an ab bug
<cateches> I don't get this issue with wrk
cateches has quit [Quit: Page closed]
travisbrady has joined #ocaml
yomimono has quit [Ping timeout: 246 seconds]
antkong has quit [Quit: antkong]
thomasga has quit [Quit: Leaving.]
MrScout has quit [Ping timeout: 250 seconds]
captain_furious has quit [Ping timeout: 244 seconds]
<jpdeplaix> whitequark: is it normal that the private linkage semantics when linked has changed in 3.6 ?
ghostpl_ has quit [Remote host closed the connection]
<jpdeplaix> if I have one module with only private functions and globals, they are not added anymore to the other module when linked with it
reem has joined #ocaml
travisbrady has quit [Quit: travisbrady]
reem has quit [Remote host closed the connection]
huza has joined #ocaml
jao has quit [Ping timeout: 252 seconds]
Thooms has quit [Quit: WeeChat 1.0.1]
swgillespie has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
bytbox has joined #ocaml
yaewa has quit [Quit: Leaving...]
moei has joined #ocaml
travisbrady has joined #ocaml
darkf has joined #ocaml
lordkryss has quit [Quit: Connection closed for inactivity]
<whitequark> ask on #llvm i think
<whitequark> it's certainly possible
deMoivre has joined #ocaml
hilquias has joined #ocaml
<deMoivre> The first three lines of my function are:
<deMoivre> let rec mandelbrot (sextuple : float * float * float * float * int * string) : (float * float * float * float * int * string) =
<deMoivre> let (cre, cim, zre, zim, its, retChar) = sextuple in
<deMoivre> let (magn: float) = (zre * zre + zim * zim) in
<deMoivre> And it's throwing an error on compilation at "zre" on the 3rd line
<deMoivre> why?
<deMoivre> it says Error: This expression has type float but an expression was expected of type
<deMoivre> int
ollehar1 has quit [Remote host closed the connection]
<dmbaturin> deMoivre: Because * is not overloaded, it's int -> int -> int.
<dmbaturin> Use *. for floats.
<dmbaturin> + isn't overloaded either.
<deMoivre> OH.
* deMoivre corrects...
<deMoivre> I think we've got something =)
<deMoivre> Thank you!
yaewa has joined #ocaml
moei has quit [Ping timeout: 255 seconds]
swgillespie has joined #ocaml
<struktured> deMoivre: it's classic ocaml gotcha, due to ultrastrict type system
<struktured> deMoivre: also, you might want to use labeled arguments and/or records for tuples that complex and with the repeated types of same value
<dmbaturin> Ultra-violent type system. ;)
<dmbaturin> But yeah, there is no overloading whatsoever (on the other hand there is no need for type signatures either).
antkong has joined #ocaml
travisbrady has quit [Quit: travisbrady]
<deMoivre> Great job, guys
<deMoivre> I'll post the link to my bitbucket repo for this in a minute
<dmbaturin> Does it produce pretty pictures?
reem has joined #ocaml
yminsky has joined #ocaml
olauzon has quit [Quit: olauzon]
<deMoivre> in ASCII, yes
<deMoivre> it's just a benchmark that I've been implementing in lots of languages to compare runtime performance for basic operations
<deMoivre> So far, I've ported it to Java, C++, Fortran, Ada, Go, Haskell, and now OCaml
<struktured> deMoivre: sweet, mandelbrot's spirit lives on
<deMoivre> in a chain of recursive function calls in OCaml, what's the expected difference between defining the function as taking in a tuple vs currying?
<dmbaturin> There should be very little difference.
<deMoivre> I wonder why my OCaml code is benchmarking at 2m24s
<deMoivre> instead of in the neighborhood of 9s as my very similar Haskell code does
reem has quit [Remote host closed the connection]
huza has quit [Quit: WeeChat 0.3.8]
<deMoivre> vs
<dmbaturin> The most imperative ocaml I've ever seen. :)
reem_ has joined #ocaml
<deMoivre> heh
<deMoivre> yeah yeah
<dmbaturin> Why in von Numan's sake you'd add autogenerated .s and the .ali to an Ada source repository?
<dmbaturin> * Neuman's
<deMoivre> dmbaturin: paranoia
<deMoivre> I couldn't remember offhand which files were important or if there'd be anything worth looking at again later
<dmbaturin> They'll be overwritten on rebuild anyway.
<sheijk> or deployment/dependencies on tools
<dmbaturin> Well, autogenerated stuff is rarely worth adding to a repo.
<yminsky> I just built it on my laptop. It ran in 9s.
<deMoivre> yminsky: My OCaml code?
<yminsky> How did you compile it?
<yminsky> Yup.
<deMoivre> How did you compile it?
<yminsky> ocamlc or ocamlopt?
<deMoivre> I just ran it with ocamlc with no parameters
<yminsky> Oh. Yeah, that’s the bytecode compiler.
<yminsky> Try native code.
<deMoivre> huh.
<yminsky> Just “ocamlopt foo.ml -o foo”
<deMoivre> I guess their bytecode compiler is nowhere near as quick as Java's Hotspot
<deMoivre> ok
Algebr has quit [Ping timeout: 252 seconds]
<yminsky> bytecode is portable, but not built for speed. Java bytecode is the only target they have, and there’s a JIT madly compiling to native code.
<deMoivre> right
<deMoivre> ahhhh
<deMoivre> 7.416s
<deMoivre> NOT BAD
<deMoivre> Not bad, at all
<deMoivre> Java is around 9, Go is around 4.5
<yminsky> FWIW, the code looks a little strange. Certianly, currying (and naming variables) is more normal.
<deMoivre> C is about 4.1
antkong has quit [Ping timeout: 272 seconds]
<deMoivre> Haskell is around 9.6, I think
<deMoivre> yminsky: Yes...I'm working on a currying version right now as we speakj
<deMoivre> -j
<deMoivre> I was aware of the same thing in Haskell
<dmbaturin> deMoivre: Well, it was never meant to be. The bytecode compiler is the last resort for architectures with no native compiler yet, the bootstrap tool, and a debug aid (the REPL uses bytecode libraries).
<deMoivre> it's more idiomatic to use currying than tuples in that language as well
<deMoivre> Also --
reem_ has quit [Ping timeout: 265 seconds]
<tokenrove> deMoivre: be sure to try SML with MLton, too
<deMoivre> The text output is all occuring at the very end of the computation
<deMoivre> Is there a way to make it output in the middle?
<deMoivre> as it's computing?
<yminsky> Sure. You can call print_string whenever you want.
<deMoivre> I am
<tokenrove> deMoivre: be sure to flush your output.
<deMoivre> and it's only *Actually*...
<deMoivre> ahhh
* deMoivre looks that up
<tokenrove> flush stdout
<deMoivre> ok
<deMoivre> in Haskell, a different print function did that flushing for me
<dmbaturin> I wonder if MLton solves currying efficiency problems that made SML authors use tuples all over the standard library.
<yminsky> I also note you’re not using OCaml’s Complex module. That might make for cleaner, shorter code. Not sure about the performance.
<deMoivre> right
<deMoivre> I'm choosing not to use any complex numbers explicitly in any of these programs
<deMoivre> because it's not always available in a given language
<yminsky> This might be a nice implementation to steal from too: http://www.ffconsultancy.com/ocaml/mandelbrot/
<deMoivre> I'm trying to make the code be as directly comparable as possible between languages
<deMoivre> yminsky: Yes; I've already looked at that page. Thank you, though. =)
badon has quit [Quit: Leaving]
<deMoivre> tokenrove: that flush studout didn't seem to do the trick
<tokenrove> deMoivre: after each print_string?
<yminsky> Works for me.
<yminsky> Just put “flush stdout” right after the print_string line (after a semicolon)
<deMoivre> right
<tokenrove> i'm not sure that forcing every language to use the same approach to the problem makes for useful comparisons.
<deMoivre> after a semicolon...
<deMoivre> hmm
<deMoivre> tokenrove: I'm going to construct alternative versions where I try to accomplish the task in as little time as possible, no matter how it's implemented in each language
<deMoivre> because I agree in a sense =)
<tokenrove> as soon as you do your 6502 assembly and brainfuck implementations of the problem, you'll have to downgrade all the others to use fixed point arithmetic or worse.
<deMoivre> heh
<tokenrove> jon harrop, the author of that aforementioned mandelbrot page, went on a "compare all the languages" crusade for a while, too. i don't know if you looked at his raytracer stuff.
<sheijk> hm. don't benchmark stuff which prints unless you want to benchmark the io libraries
<deMoivre> tokenrove: Not yet.
<deMoivre> sheijk: The I/O is an insignificant contribution to this
<deMoivre> That's why I ramped the iteration limit to 1000000
<deMoivre> to ensure that
<sheijk> ah, ok
<deMoivre> AHHHHHHHhhhhhhhh
<deMoivre> perfect!!
reem has joined #ocaml
<yminsky> I made a few trivial syntactic transformations to your code to clean it up.
<yminsky> It should be a touch faster too.
<deMoivre> makes sense
<deMoivre> Thanks =)
<deMoivre> This has been a success...
<deMoivre> next stop, either Clojure or Scheme
<deMoivre> both of which I've failed at before
<deMoivre> but I now know enough about how to implement a nice little recursive function in the total absense of imperative style loops in order to do it
badon has joined #ocaml
reem has quit [Ping timeout: 265 seconds]
<deMoivre> I implemented my own 'for' idiom via a function in Scheme, at least
<deMoivre> anyway
<deMoivre> Thanks again, ladies/gentlemen.
<yminsky> Oh, and now it’s slightly faster: http://pastebin.com/7PJm7H1z
<yminsky> Cheers.
<dmbaturin> deMoivre: ALso, you may try using while instead of for.
<dmbaturin> Also, why would you do for in Scheme via function rather than a macro? :)
<dmbaturin> Also #2, both ocaml and scheme do tail call elimination.
<dmbaturin> Clojure doesn't, but there's special syntax for tail-call style jump instead of normal JVM call.
claudiuc_ has quit [Remote host closed the connection]
antkong has joined #ocaml
yminsky has quit [Quit: yminsky]
yminsky has joined #ocaml
dav has quit [Ping timeout: 250 seconds]
hilquias has quit [Ping timeout: 245 seconds]
dav has joined #ocaml
yminsky has quit [Quit: yminsky]
dav_ has joined #ocaml
dav has quit [Ping timeout: 256 seconds]
travisbrady has joined #ocaml
contempt has quit [Ping timeout: 265 seconds]
travisbrady has quit [Quit: travisbrady]
reem has joined #ocaml
contempt has joined #ocaml
psy_ has joined #ocaml
xaimus has quit [Ping timeout: 252 seconds]
Algebr has joined #ocaml
moei has joined #ocaml
yaewa has quit [Ping timeout: 264 seconds]
antkong has quit [Quit: antkong]
swgillespie has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
Algebr has quit [Ping timeout: 256 seconds]
reem has quit [Remote host closed the connection]
reem has joined #ocaml
mpmcsweeney has joined #ocaml
AlexRussia has quit [Ping timeout: 245 seconds]
mpmcsweeney is now known as chinglish
chinglish has left #ocaml [#ocaml]
antkong has joined #ocaml
reem has quit [Remote host closed the connection]
ptc has joined #ocaml
ptc is now known as Guest14573
ned- has joined #ocaml
psy_ has quit [Ping timeout: 272 seconds]
Guest59124 has quit [Ping timeout: 255 seconds]
Guest14573 has quit [Ping timeout: 265 seconds]
psy_ has joined #ocaml
psy_ has quit [Max SendQ exceeded]
psy_ has joined #ocaml
brendan has joined #ocaml
brendan has quit [Client Quit]
brendan has joined #ocaml
brendan has quit [Client Quit]
brendan has joined #ocaml
antkong has quit [Ping timeout: 264 seconds]
reem has joined #ocaml
ygrek has joined #ocaml
xaimus has joined #ocaml
ygrek has quit [Remote host closed the connection]
reem has quit [Remote host closed the connection]
ygrek has joined #ocaml
yomimono has joined #ocaml
reem has joined #ocaml
reem has quit [Remote host closed the connection]
slash^ has joined #ocaml
AlexRussia has joined #ocaml
reem has joined #ocaml
yomimono has quit [Ping timeout: 252 seconds]
ygrek has quit [Ping timeout: 255 seconds]
<ousado> Hi merlin users.. - I'm trying to set up merlin and the haxe compiler
<ousado> there are source files in the project root and in libs/*/*
MercurialAlchemi has joined #ocaml
<ousado> I've added those to the .merlin file in the project root
<ousado> but when I save the buffer I still get many errors related to those modules not being known to merlin
<ousado> is there anything else besides :Reload I have to to?
oscar_toro has joined #ocaml
<def`> can you share the .merlin? (and do you hace the latest version?)
<ousado> I just updated merlin via opam
<ousado> oh, now :Errors is much smaller
<ousado> sec
<def`> 1. merlin look for cmi file, so the project must be built
<def`> 2. it looks for cmt files for navigation features, add -bin-annot flag to.the compiler
<ousado> here: that's all I have/thought I need: https://gist.github.com/ousado/d8335aefd0e52c87344d
<ousado> haxe uses a makefile to build, does that matter?
<def`> no, that's the purpose of the .merlin, describing peoject independently of a build system
<def`> what are the remaining errors ?
<ousado> now after rebuilding haxe it's Cmi_format.Error all over the place
moei has quit [Quit: Leaving...]
reem has quit [Remote host closed the connection]
swgillespie has joined #ocaml
<def`> hmm sounds like a wrong version of ocaml is used
swgillespie has quit [Client Quit]
<ousado> I'll make sure it uses the opam switch version
<ousado> this is an attempt to create a local copyable haxe development environment
<def`> I can take a look on my computer if you have somethung distributable now
<ousado> not really yet, but I'll prepare something so I don't eat too much of your time
<ousado> at this point I have separate local installs of haxe and opam/ocaml - I have to add vim to that mix and deal with $HOME somehow
idem-pyon-tent has quit [Quit: I'm sorry but... I don't have any interest in three-dimensional girls.]
moei has joined #ocaml
reem has joined #ocaml
reem has quit [Remote host closed the connection]
idem-pyon-tent has joined #ocaml
reem has joined #ocaml
reem has quit [Remote host closed the connection]
reem has joined #ocaml
mitrul has joined #ocaml
avsm has joined #ocaml
ggole has joined #ocaml
segmond has quit [Ping timeout: 246 seconds]
wwilly has joined #ocaml
<ousado> def`: I've stripped it down to a single file and the libs/extlib directory, and put it into this tar.gz https://mega.co.nz/#!zAw3SQQZ!mdO9ss52WxBbOKulOnRc0e0pBrC2UDw0FhkEiom0x2M
mitrul has quit [Ping timeout: 246 seconds]
<ousado> I still get "Unbound module PMap"
segmond has joined #ocaml
<def`> it works here (after rm *.cm* *.o then make extlib)
<ousado> thanks a lot. Are there any logs of ocamlmerlin somewhere?
<ousado> or some mode so I can see what it does/tries to do?
<def`> export MERLIN_LOG=~/somefile
<def`> and then rerun, but it might be a bit cryptic :P
<def`> we don't have a clean log format yet.
<def`> (the only problem with your setup seems that merlin and ocaml version doesn't match)
<ousado> I guess I've written C++ long enough to be prepared :)
<ousado> you mean merlin is compiled with a wrong version?
<ousado> maybe I should try an opam switch to a new compiler version and reinstall merlin there
<def`> pMap.cmi was likely built with a different version of ocaml than the one used to compile merlin
<def`> what is your current switch?
<ousado> 4.00.1
<def`> and ocamlmerlin -version ?
<ousado> I'm also a bit puzzled because 4.02.1 isn't in the list of options in opam
<ousado> The Merlin toolkit version 1.4.1, for Ocaml 4.00.1
<def`> :D
<def`> completely outdated
<def`> first, update opam
<ousado> oh
<def`> you need at least opam --version >= 1.2.0
<ousado> OK
<ousado> opam can't update itself, right?
reem has quit [Remote host closed the connection]
<def`> I don't think so. But if you put a new binary version, it might be able to migrate the old state.
reem has joined #ocaml
tane has joined #ocaml
reem has quit [Remote host closed the connection]
pakchoi2 has joined #ocaml
pakchoi2 has quit [Max SendQ exceeded]
pakchoi2 has joined #ocaml
pakchoi2 has quit [Max SendQ exceeded]
pakchoi2 has joined #ocaml
pakchoi2 has quit [Max SendQ exceeded]
pakchoi2 has joined #ocaml
AltGr has left #ocaml [#ocaml]
<ousado> hm, why does opam not list 4.02 ?
<ousado> (I've version 1.2.1 now)
Kakadu has joined #ocaml
<ggole> Doesn't list 4.02.0?
<ousado> ok, I've completely killed all old shared/opam/* state and initialized it new and now all seems fine
<def`> maybe the package repository still pointing to older one
<ousado> I sincerely hope there's nothing left of the old install :)
reem has joined #ocaml
<def`> at least you have a chance to get things to work now :)
<ousado> opams 'make cold CONFIGURE_ARGS="--prefix /local/path"' is awsome, btw
reem has quit [Remote host closed the connection]
<ousado> the 1.2.0 tar.gz lacked the opam-installer script, so I used the github version
<def`> I found the script separately on opam website
<ousado> I didin't want to risk yet another version mismatch :)
segmond has quit [Ping timeout: 252 seconds]
reem has joined #ocaml
<ousado> O_O
<def`> (o_o)
<ousado> I got a billion String.[create|unsafe_set] warnings
<def`> while doing what?
<ousado> compiling extlib
<def`> yep normal
<def`> string type is being slightly changed, functions are deprecated
<ousado> oh my.. well, I guess there's an opam switch for that (in case haxe uses them a lot, too)
<def`> or you can just live with it, nothing incompatible has been introduced yet
<ousado> sweet jesus the test project works
<ousado> oh no.. since when are camlp4 and ocaml no longer in sync?
<ggole> Fairly recently
<ggole> Breakage ahoy
<ousado> but I can just opam install it, I hope :)
<ggole> Yeah
<ggole> There might be a bit of said breakage if you install a very recent (unreleased) ocaml though
<ousado> I won't do that, the main haxe dev is still on 3.11
<ggole> Yikes, that's a ways back
<ousado> due to windows
<ggole> I think the split is 4.02 or so, but don't quote me on that.
<ousado> seems to work now
mort___ has joined #ocaml
segmond has joined #ocaml
<ousado> oh man am I looking forward to jumping to that line the compiler reports
<ousado> ok thanks everyone!!!
<ousado> I'm glad to report the ultimate victory
laughing-octo-sh has joined #ocaml
reem has quit [Remote host closed the connection]
<def`> :D
<ousado> def`: :D
<ousado> this is a little too good to be true
reem has joined #ocaml
<ousado> I hope I don't wake up in 5 minutes
Haudegen has quit [Ping timeout: 272 seconds]
Haudegen has joined #ocaml
reem has quit [Remote host closed the connection]
segmond has quit [Ping timeout: 265 seconds]
reem has joined #ocaml
reem has quit [Remote host closed the connection]
dsheets_ has joined #ocaml
segmond has joined #ocaml
reem has joined #ocaml
reem has quit [Remote host closed the connection]
reem has joined #ocaml
reem has quit [Remote host closed the connection]
reem has joined #ocaml
Simn has joined #ocaml
reem has quit [Remote host closed the connection]
reem has joined #ocaml
reem has quit [Remote host closed the connection]
reem has joined #ocaml
reem has quit [Remote host closed the connection]
reem has joined #ocaml
reem has quit [Remote host closed the connection]
reem has joined #ocaml
reem has quit [Remote host closed the connection]
reem has joined #ocaml
reem has quit [Remote host closed the connection]
reem has joined #ocaml
A1977494 has joined #ocaml
<A1977494> help me please i need convert string from utf-8 to cp1251
reem has quit [Remote host closed the connection]
<A1977494> my code
<A1977494> BatUTF8.validate content_body;
<A1977494> BatUTF8.iter (fun c -> print_string(c)) content_body;
pakchoi2 has quit [Ping timeout: 245 seconds]
avsm has quit [Quit: Leaving.]
<Kakadu> I think that you neeed some function at the bottom of http://batteries.forge.ocamlcore.org/doc.preview:batteries-alpha3/html/api/CharEncodings.html
pakchoi2 has joined #ocaml
mort___ has quit [Quit: Leaving.]
<A1977494> thank you <Kakadu>
freling has joined #ocaml
testcocoon has quit [Quit: Coyote finally caught me]
captain_furious has joined #ocaml
monod has joined #ocaml
SkoAleVal has joined #ocaml
SkoAleVal has quit [Client Quit]
SkoAleVal has joined #ocaml
testcocoon has joined #ocaml
Haudegen has quit [Ping timeout: 240 seconds]
yminsky has joined #ocaml
Haudegen has joined #ocaml
freling has quit [Quit: Leaving.]
reem has joined #ocaml
captain_furious has quit [Quit: Leaving.]
reem has quit [Remote host closed the connection]
lordkryss has joined #ocaml
HenriMorlaye has joined #ocaml
reem has joined #ocaml
reem has quit [Remote host closed the connection]
reem has joined #ocaml
raphaelss has joined #ocaml
reem has quit [Remote host closed the connection]
<companion_cube> http://erratique.ch/software/bos/doc/Bos.html ← looks like Bünzli is ready to take over another fragment of OCaml
bytbox has quit [Remote host closed the connection]
alpen has quit [Quit: ZNC - http://znc.in]
<companion_cube> sadly he's not on IRC, afaik
freling has joined #ocaml
raphaelss has left #ocaml [#ocaml]
<yminsky> I’m sad to see him using polymorphic variants everywhere.
<yminsky> Better to coordinate. For example, we’d be happy to break out our Result.t into a tiny module that could be shared amongst many users.
monod has quit [Ping timeout: 256 seconds]
<companion_cube> it's a bit too late - would be ok if it was in the stdlib though
<companion_cube> (trolling on both irc and twitter, nice)
<yminsky> Polymorphic variants are complex, and the type discipline around them is error prone. Now that we have type-directed constructor disambiguation, I mostly prefer ordinary variants.
<yminsky> Hey, you asked.
<companion_cube> ^^
<yminsky> I thought this would be a more useful place to chat.
<companion_cube> indeed
<yminsky> Why too late?
<yminsky> Isn’t Bos new?
<companion_cube> I mean, for Result.t
<yminsky> Why too late?
<companion_cube> if eeryone agreed on it 10 years ago, it would be cool
<yminsky> We could factor it out to a tiny library now.
<yminsky> Huh? We can do it now. We can add it to the stdlib now. There’s no barrier.
reem has joined #ocaml
<yminsky> If there was an existing Result.t, with the same definition that anyone defined, we could all share it.
<yminsky> This is similar to Sexplib. Core_kernel uses Sexplib’s Sexp.t, and integrates it into its core-like view of the world. But you can use Sexplib on its own.
<yminsky> Anyway, I’ll email bunzli and see what he thinks.
<bernardofpc> I am especially boggled by Bos.Path.ext
reem has quit [Remote host closed the connection]
<companion_cube> it's still big imho (Sexplib)
<companion_cube> would be nice to have just the type def somewhere
<companion_cube> poly variants are nice because they don't force you to have a common dep just to talk about the same type
<tane> i noticed d.b. using a lot of polymorphic variants and wondered if there is any point why he's doing that? any ideas?
<ia0> the common dep does not look like a good argument for poly variants
<companion_cube> because all his projects use the same definition for errors, but they don't have dependencies (in general)
<ia0> this is a architecture design problem
<companion_cube> ia0: if there was another way, I'd use it
<companion_cube> the point is, I don't want to depend on Core (or batteries) just for their definition of Result
<companion_cube> (which is incompatible anyway)
<ia0> you may split type definitions from function definitions
<companion_cube> sure
<companion_cube> if people did that, it would be neat
<companion_cube> or if OCaml had a way to have some structural typing with regular variants
<ia0> the only "good" point I see for poly variants is the fact that it's an open type
<companion_cube> (meaning: types that are isomorphic can be converted)
<companion_cube> open and structural, yes
<ia0> what do you mean by structural?
<companion_cube> two definitions of the "same" type are equivalent
<companion_cube> I write type 'a or_error = [`Ok of 'a | `Error of string]
<companion_cube> Bünzli writes type 'a result = [`Error of string | `Ok of 'a] (say)
<companion_cube> those are the same type
<yminsky> I agree that Sexplib isn’t tiny.
<yminsky> But it shows the principle.
<companion_cube> yminsky: why not make a proposal on caml-list for exporting types?
<companion_cube> like, opam packages named "ty-foo"
<companion_cube> that only contain type definition(s)
<yminsky> One could break out just the type definition if you had a type definition worth sharing.
<companion_cube> very simple and ligthweigth dependencies
<companion_cube> yes
<companion_cube> that would be very interesting, or at least worhty of discussion
<yminsky> Indeed. I’m curious to see what I hear back from Daniel.
<yminsky> It’s worth noting that there aren’t a lot of types that this is an obvious win for. And maybe we should just put all the ones we want in the standard lib.
<yminsky> Other than Result.t, and maybe Sexp.t, I see on obvious suggestions from the Core world.
<companion_cube> well, UChar seems to have troubles being included
<companion_cube> why not Core.Sequence? (although I have my own iterators)
<companion_cube> I see, for instance: Result, Sexp, UChar, LazyList, Core.Sequence, some UTF8 string, some UTF8 rope...
<yminsky> The UTF8 ones seem good. I’m less convinced about Core.Sequence.
<yminsky> I like the fact that the type there is abstract, and this only makes sense for non-abstract types.
larhat has joined #ocaml
segmond has quit [Ping timeout: 246 seconds]
<companion_cube> maybe so
<companion_cube> it's harder for external code to define iterators then, but ok
A1977494 has quit [Quit: Page closed]
SkoAleVal has quit [Quit: ChatZilla 0.9.91.1 [SeaMonkey 2.32.1/20150204202218]]
<yminsky> Sure, there’s a tradeoff there.
larhat has quit [Quit: Leaving.]
bytbox has joined #ocaml
<tokenrove> yminsky: i'm not sure if you're the right person to ask, but is there any interest in getting jenga working on windows?
<yminsky> Eventually I’d like to get Jenga and Async working on Windows.
<yminsky> But it will take time. The next version of Async_kernel doesn’t depend on Core anymore (just Core_kernel), so it should be portable.
<yminsky> We’ll need some work to write a scheduler based on libuv or something like that to get Windows to happen. I don’t think we’ll do that work intenrally at JS, but I’m hoping we can get it to happen.
<tokenrove> so Async's portability is a problem for porting Jenga right now?
<yminsky> Indeed. Jenga uses Async internally.
<yminsky> But Jenga can generate makefiles which are portable.
<yminsky> So if you use Jenga, you should be able to create packages that build anywhere.
<tokenrove> well, i only just started looking at it yesterday, but i might have an opportunity to hack on it next month. i had counted on having to reimplement stuff like inotify but i didn't think about Async.
<yminsky> But it’s not good for development on Windows.
<yminsky> Well, Async_kernel will run on Windows in the next release...
<tokenrove> ok, maybe i should just wait and see what happens, then
<yminsky> But really, Jenga is not yet in a state where we can recommend it for external use.
<yminsky> It’s absolutely great for our use, but we haven’t yet done enough to make it suitable for other people’s workflows.
segmond has joined #ocaml
<prsn> hi! I'm having trouble getting the Tuareg repl set up in the same namespace as the project I'm working with. #load-ing each file sort of works, but there are dozens
<Drup> (13:20:28) yminsky: Better to coordinate. For example, we’d be happy to break out our Result.t into a tiny module that could be shared amongst many users. <- for once, I agree with you yminsky :D
<prsn> and they also depend on installed libraries outside the project directory which would be annoying to track down
<yminsky> Drup: For once? What are the other terrible things I say?
vanila has joined #ocaml
<Drup> oh, I just don't agree with Core and Async architecture in general
<prsn> i feel like I should be able to just point to .. something .. and have it load everything needed recursively? Is that possible?
idem-pyon-tent has quit [Quit: I'm sorry but... I don't have any interest in three-dimensional girls.]
<Drup> and the way jst tends to interact (library wise) with the rest of the community
<Drup> but on the whole "let's use structural types to be compatible between various libraries", I think it's just show a terrible lack of synchronisation (and a terrible amount of NIH) from the various people in the community
<yminsky> Well, not liking Core’s design is fine. Design is a thing about which opinions will differ.
segmond has quit [Ping timeout: 246 seconds]
<Drup> sure
<Drup> but one thing has been proven about monolithic libraries in the ocaml ecosystem: parts of them are reinvented elsewhere, not always better, but at the end the smaller part is usually used because it's not enormous
<companion_cube> the compatibility-through-structural-types wouldn't have happened if the stdlib had accepted those types
<companion_cube> and only the types
tnguyen has quit [Read error: Connection reset by peer]
<yminsky> Maybe. Lwt is pretty big, but is used in lots of places.
<companion_cube> is it that big?
tnguyen has joined #ocaml
<Drup> it's smaller than async.
<yminsky> And Core is getting smaller in the next release. With module alises, you no longer need to link in the whole thing.
<Drup> (examples includes ocamlnet - eliom - cohttp/uri/etc)
slash^ has quit [Read error: Connection reset by peer]
<yminsky> That should come in the next release or two.
<Drup> (Core - basilions of litte things everywhere, cmdliner for example)
<companion_cube> lwt.cma weights 372kB here, that's not big
slash^ has joined #ocaml
<Drup> (eliom - opium, in a certain extend, is another example)
<yminsky> There’s no question that Core_kernel is bigger than those other things. But increasingly, you’ll be able to link in only the parts you actually want to use.
<Drup> sure, the point is that people keep redoing things between using just one thing that is part of Core is too costly if you don't use Core already
<yminsky> It’s still not perfect: there are some pieces that are hard to avoid, like Result.t, Error.t, Sexp.t, etc, since lots of basic things use them.
<companion_cube> unless you have a quasi-flat dependency graph, that won't happen with current ocaml
<Drup> s/between/because/
<Drup> (and Error/Result should be in a small independent library)
<yminsky> I agree that Core_kernel is a bit of a take-it-or-leave-it experience. But I think there’s a lot of value if you do take it.
<Drup> (said library was already done, btw, by smondet)
<yminsky> Which library?
<Drup> let me find you the name
<companion_cube> yminsky: there's the part of the ecosystem that uses core, and the part that doesn't, and the divide is pretty clear
<companion_cube> Drup: I still think there should be a lib (or a stdlib module) with only the type def
<companion_cube> so you don't have to like the lib interface to use it
<Drup> companion_cube: for error and result, having the whole thing is fine, there is basically nothing opiniated in the library
<yminsky> For exposed types, like Result.t, this works.
<yminsky> For abstract types, like Error.t, it can't.
<companion_cube> wait, this uses poly variants
<yminsky> Indeed.
<Drup> yes, it keeps using polyvariants for your famous compatibility issue
<yminsky> I thing breaking out Result.t to share it amongst multiple libraries that want it is a lovely idea, assuming someone else would be willing to share.
<Drup> (basically, because dbunzli's lib)
monod has joined #ocaml
<Drup> yminsky: I think it's slightly to late for Result.t
<companion_cube> yminsky: I think this discussion should happen on caml-list: you want to have the opinions of Bünzli, smondet, {core,batteries}-{users,developpers}, and so on
<Drup> well, maybe not actually
<Drup> the main one that would need to change things is bunzli
<companion_cube> the others would have to replace type 'a result = .... with type 'a result = 'a Result.t = ....
<companion_cube> or something like this
<companion_cube> which is pretty ok
<yminsky> Indeed.
<Drup> yep
<companion_cube> I would have to change things too :>
<yminsky> I emailed Bunzli.
<Drup> (Batteries uses Ok | Bad
<Drup> :/
<companion_cube> arf
<companion_cube> dooooooomed by retrocompat.
<Drup> as always in batteries
<yminsky> Right. To the degree that people like [type (‘a,’b) t = Ok of ‘a | Error of ‘b], we can share.
<yminsky> But otherwise, not so much.
<Drup> companion_cube: you would have to change containers too
<companion_cube> I can manage the transition from poly variants with sed
<companion_cube> yes, that's why I said I had to change things too
<Drup> it's not about you, it's about users :p
<ia0> :-)
<companion_cube> users include me! :p
<Drup> but are not limited to.
segmond has joined #ocaml
<companion_cube> well, that would be a major release, sure
<yminsky> Containers is still pretty young, and OCaml makes this kind of refactoring pretty easy.
<companion_cube> also, same thing with S-expressions
<Drup> yminsky: what's the plan for ppx ?
<companion_cube> yes yes, I'm not afraid to break a bit of compat when it makes sense to
<yminsky> Sure, if folks wanted to share the core s-expression type without sexplib, that’s doable too.
<yminsky> drup: we’re actively working on converting all of our syntax extensions to ppx.
<Drup> well, it will be necessary for any ppx_sexp.
<yminsky> We’re going to drop camlp4 like a hot rock.
<companion_cube> I'd be interested, I have an alternative streaming parser for S-epxressions
psy_ has quit [Ping timeout: 272 seconds]
<companion_cube> (that I'm probably the only one to use)
<yminsky> The old syntax extensions will still work, but we won’t use them.
<Drup> yminsky: are you using ppx_deriving ?
<Drup> (please do, please do, please do)
<Drup> (for the community's sake, please do)
<yminsky> Not clear yet. Jeremie Dimino has had some back and forth with whitequark.
<yminsky> If the design works, we’d like to share it. But it may not be a match.
<Drup> then modify ppx_deriving
<ggole> How did camlp4 ever get to the state its in? Vast, undocumented, and relied on are a bad combination.
<yminsky> The early design definitely wasn’t a good match, but some things have improved.
<yminsky> camlp4 provided absolutely critical functionality. There were no alternatives.
<Drup> and it was good enough to work
<ggole> I suppose that paring down to the necessary parts and documenting everything was never going to happen
<Drup> yminsky: having two library for deriving-like annotations would have exactly the same effect than the current lwt/async situation
<yminsky> Agreed. There are one of two outcomes: we either can agree on a single design, or we can’t.
<companion_cube> Drup: in a lower extend, it doesn't pose problems at link time
<yminsky> If we can, then, yay! If not, well, that’s how open source works. Different people try different things, and you see what turns out to work.
<yminsky> Yeah, it is nice that you can mix and match. We build all of our libraries using camlp4, but you don’t have to use camlp4 yourself to use them.
<Drup> hum, actually.
<Drup> you do.
<yminsky> How so?
<companion_cube> well, you have to install camlp4
<Drup> core loads some pa_* for you
<Drup> in particular, pa_ounit
<Drup> so, it forces you to use camlp4 even if you don't need it
<yminsky> Core doesn’t force you to build with syntax extensions.
<yminsky> You have to build core with them, but you can link to Core without them.
<companion_cube> yminsky: if you end with something different from ppx_deriving, please split it into small libraries ^^
<yminsky> Of course. As we did with type_conv.
<yminsky> We have to. Since Core_kernel is built with these syntax extensions, the extensions can’t depend on Core_kernel.
<Drup> yminsky: but some syntax extensions are explicit dependencies
<Drup> not only build-with
<yminsky> Name one.
<Drup> pa_ounit.
<yminsky> Are you saying that you need to enable the pa_ounit syntax extension to link against Core_kernel?
<yminsky> I can’t even imagine what mechanism there is to require that…
<Drup> Xmetarequires contains pa_bench, pa_ounit, pa_test,
<tokenrove> prsn: does #directory do what you need?
<yminsky> I’m afraid I don’t fully understand the opam invocations here. But surely I can call ocamlbuild against Core without invoking syntax extensions.
<yminsky> What does XMETAREQUIRES actually mean?
<Drup> it's for ocamlfind
<Drup> it tells the dependency of the ocamlfind package so that ocamlfind recursively links all the dependencies
<Drup> (but actually, I linked the wrong thing)
<Drup> (this one is ok, it's the runtime part of the said libraries)
<yminsky> Yup. That part makes sense.
<Drup> let me find the exact issue we had, some times ago
<yminsky> If there’s something like this that you think is crazy about the design of Core, you should totally email the list.
<prsn> tokenrove: partially, it looks like
<haesbaert> anyway to modify the --help option in Cmdliner ? I want it to default to "plain" and to work with either -h or --help
<prsn> tokenrove: it's kind weird actually, it seems to be able to #load a.cmo which previously broke on a dependency on b.cmo, but it still can't #load b.cmo because of a dependency on a library installed with opam
<Drup> pa_pipebang has no runtime part, it's purely a syntax extension
<prsn> tokenrove: but also maybe i don't need to #load things anymore? i don't really know exactly what #directory is doing
<tokenrove> prsn: you can setup a .ocamlinit file in your project's directory that specifies your #directory and #require statements as needed
<yminsky> Drop: So, what’s the concrete problem? Do you believe that if I build with ocamlfind against Core, that it will force you to build with camlp4?
<Drup> that's ... not the exact issue
<yminsky> Drup: If you think that’s the case, it’s a bug, and we’d appreciate a bug report.
<yminsky> Drup: Ah, so can you describe the exact misbehavior?
<tokenrove> prsn: (use #require to load the library you need)
<prsn> tokenrove: #require in the repl says 'unknown directive require'
<Drup> if you build with core *and* camlp4, it will bring uninvited syntax extension that may not be compatible with other (namely, deriving), even if you don't use the core syntax extensions
<yminsky> Drup: Great. That also sounds like a bug. Could you report it on github?
<Drup> yes
<yminsky> Awesome.
<Drup> (but I'm pretty sure a bug report about that was done some month ago, not by me though)
<tokenrove> prsn: oh sorry, #use "topfind";; first
<yminsky> Drup: If you can find the report and show it to me, I’d like to see it.
segmond has quit [Ping timeout: 244 seconds]
<prsn> tokenrove: ok, that worked, but "#require Sedlexing", which is the opam-installed module I need, says no such package
<prsn> do i need to set up a path?
<Drup> prsn: "#require sedlex"
<yminsky> Final thought before I go: we’re actively working on making Core_kernel and the rest of our stack more lightweight. Module aliases will take us a step in the right direction, allowing one to actually pull in only the modules that you actually need to use whatever functionality you want from Core_kernel. The Async_kernel change is another one. It will take some time, but we hope to make it a lot better in this regard in the
<yminsky> year or so.
<yminsky> Cheers all.
yminsky has quit [Quit: yminsky]
<prsn> tokenrove: ah. Anyway i can know the package name from the error "reference to undefined global Sedlexing" that i got from trying to #load the module?
<prsn> *Any way
<Drup> no, you can't :)
<Drup> that's the module name, not the package name
TheCommieDuck has joined #ocaml
<TheCommieDuck> Hey. Can I do some kind of match x with Foo(bar) with baz=5 | Foo2(bar, baz) -> ... ?
<companion_cube> replace 'with' with 'when' and you're good to go
<TheCommieDuck> woo, thanks :)
<companion_cube> also, if you have one argument, Foo bar is as good as Foo (bar)
<ggole> If the baz there isn't the same identifier.
<TheCommieDuck> the actual code is type x = Foo of bar | Foo2 of bar * baz, so I wanted to be able to have an inline default variable.
<ggole> Hmm, write a function to map an x to a pair of bar, baz
<ggole> eg let f = function Foo bar -> bar, 5 | Foo2 (bar, baz) -> bar, baz
<TheCommieDuck> a better idea
segmond has joined #ocaml
dav has joined #ocaml
dav_ has quit [Ping timeout: 246 seconds]
vpm has quit [Quit: WeeChat 1.1.1]
vpm has joined #ocaml
ddosia has joined #ocaml
ned- has quit [Ping timeout: 244 seconds]
Thooms has joined #ocaml
pyon has joined #ocaml
bjorkintosh has quit [Ping timeout: 252 seconds]
leowzukw has joined #ocaml
yminsky has joined #ocaml
travisbrady has joined #ocaml
Algebr has joined #ocaml
HenriMorlaye is now known as Ansnum
Ansnum has left #ocaml [#ocaml]
Ansnum has joined #ocaml
captain_furious has joined #ocaml
travisbrady has quit [Quit: travisbrady]
Thooms has quit [Ping timeout: 256 seconds]
mort___ has joined #ocaml
struktured has quit [Ping timeout: 250 seconds]
darkf has quit [Quit: Leaving]
<def`> TheCommieDuck: match x, 5 with Foo bar, baz | Foo2 (bar, baz), _ -> …
<ia0> nice
<ia0> and does a tuple for (x, 5) be created? or is this technique costless?
<Drup> the tuple is created
<ia0> :-( but still nice
<Drup> let f bar baz = ..... in match x with Foo bar -> f bar 5 | Foo2 (bar, baz) -> f bar baz
<ia0> Yes, that what I usually do
<ggole> The compiler should do forwarding -_-
<def`> Drup: the tuple is created ?
<Drup> pretty sure it is, yes
<ggole> Actually I think for immediate match it isn't
<Drup> there was a similar issue at some point
struk|dtut has joined #ocaml
<def`> "pretty sure" means no then.
<def`> I am pretty sure it doesn't allocate :-)
captain_furious has quit [Quit: Leaving.]
<def`> (even in bytecode)
<ggole> Looks like it doesn't in 4.02.1
<def`> Drup: I remember the issue you mention, its only in a let that it is allocated, for match it is not
<Drup> hum, ok
<Drup> I though naively that it was the same behavior
<def`> (because there is a different path when match have the form a, b and the pair is not bound to a name)
<ggole> A bit like the tuple arguments thing
mort___ has quit [Quit: Leaving.]
<Drup> still weird that match with one branch do not behave the same as let bindings
freling has quit [Quit: Leaving.]
<def`> I agree
<ggole> What's the difference?
<def`> tuple is allocated in a let
<def`> let x, y = 1, 2 in …
<def`> :'(
<ggole> Oh :(
<mrvn> and in match (1, 2) in (x, y) -> ... it is not?
<def`> yes
<ggole> If the tuple isn't named
pakchoi2 has quit [Quit: Leaving.]
<mrvn> what about: match foo () in (x, y) ->?
<def`> lol
<whitequark> uh
<ggole> Always allocated (unless inlined, I suppose)
<mrvn> figures
* Drup starts doing the pierre approved inlining dance.
<def`> :D
<mrvn> .oO(And here I was using -fno-inline with gcc)
<ggole> It'll be interesting to see in how many cases more aggressive inlining lowers performance
larhat has joined #ocaml
<mrvn> ggole: I've recently looked at a lot of arm-none-eabi-gcc output and it is amazing how bad optimized code is.
<whitequark> clang?
<mrvn> have to try and compare that one day
dav has quit [Ping timeout: 255 seconds]
<def`> almost no peephole optimization are made?
<def`> (because it's often counter-intuitive what code is "good" for the processor :))
<ggole> Yeah
<ggole> Workarounds for false dependencies can look quite ridiculous until you understand why they are there, for example
struktured has joined #ocaml
dav has joined #ocaml
<whitequark> arm1176 isn't even out-of-order (almost)
<mrvn> def`: I've looked at different code for bzero(). Just a simple loops to clear the memory in C. Depending on how I wrote the C code I got up to 4 times as many opcodes.
<mrvn> including the function pre/posfix.
<whitequark> I would be interested in the comparison
matason has joined #ocaml
<mrvn> and none of them would unroll the loop and use stm (store multiple registers).
matason has quit [Client Quit]
<whitequark> that's not necessarily faster
<mrvn> you have to spill a few regs for it but above 64 byte or so you are faster.
ned has joined #ocaml
ned is now known as Guest80118
<Algebr> Why do people get so excited over list comprehensions? Somewhat overrated methinks.
<Drup> because they are used to it from python/LINQs, I guess
<Drup> probably because it's impossible to write proper functional transformations in those langauges
<vanila> in general people go crazy for being able to do a normal thing very slightly shorter
<vanila> remember all the fuss about arc for the amazing contribution of shortening 'define' to 'def'
pakchoi2 has joined #ocaml
<Algebr> I use it a lot in python but I've never been like I need a list comprehension in ocaml
<vanila> I thinnk it's just easier to get excited about a O(n) save you can understand now rather than something complex that will really matter in the long term
pakchoi2 has quit [Client Quit]
badkins has joined #ocaml
<mrvn> Algebr: What? YOu never used List.map, List.iter or List.fold_left/right?
yminsky has quit [Quit: yminsky]
<Algebr> Of course I have, but I mean stuff like these syntax extensions [g | t <- ts; g <- functions t] (Ripped from the latest ocaml question on stack))
<mrvn> What is that supposed to do? That's totaly unreadable.
<mrvn> pythons [foo(x) for x in list] is at least understandable just by looking at it
mort___ has joined #ocaml
Nahra has quit [Remote host closed the connection]
<dmbaturin> Algebr: In sane use cases "map f xs" or "filter p xs" tend to be shorter than list comprehensions, and cases where list comprehensions are shorter tend to be borderline obfuscation IMHO.
<mrvn> One thing though is nice. The list comprehension in python constructs a list from an itrable. The source doesn't have to be a list.
<dmbaturin> mrvn: True.
<Drup> (you can do that in ocaml too)
<mrvn> So it's more like: List.of_enum + map + filter
ddub has joined #ocaml
<Algebr> Hmm, don't see List.of_enum
<Algebr> is that part of batteries
<Drup> yes
<Drup> don't use enum
<Drup> use sequence
<mrvn> since the standard lib doesn't have any enums ...
<Algebr> I'm kind of moving away from using core, its a bit heavy weight.
<Drup> mrvn: that's not *exactly* true.
<Drup> Algebr: sequence is a (small) independent library
<mrvn> Drup: it has other things but not enum. And as you said: use sequence
<mrvn> Somehow enums have come and gone before I started to actualy use them. :)
<struk|dtut> those poor, neglected enums
AlexRussia has quit [Quit: WeeChat 1.2-dev]
<mrvn> They can form a line to get some condolences
ygrek has joined #ocaml
yminsky has joined #ocaml
<Algebr> does batteries have C dependencies?
<Drup> Is the question "will it work in js_of_ocaml ?" ?
yminsky has quit [Client Quit]
<Algebr> lol yes.
<Drup> then no, not for now
<Drup> at least, not very well
<Drup> use containers if you want an stdlib extension jsoo-proof
ddosia has quit [Quit: Connection closed for inactivity]
pyon is now known as pyon-as-a-brick
<dmbaturin> Someone will make JS of C eventually.
<Drup> sure, it's call emscripten
larhat has quit [Quit: Leaving.]
<ddub> hallo, I am trying to port an ocaml application from a docker to a rocket container but it gives me an unclear error when executing
<ddub> it references camlinternal, given I don't really know the externals I am feeling out of my depth and would appreciate any suggestions to try and find the source of the error
<dmbaturin> ddub: Well, without application source it's not possible to tell anything.
<ddub> the application source is here; https://github.com/savonet/liquidsoap/
<dmbaturin> And without knowing what exactly /run/liquidsoap.aci is doing.
ptc has joined #ocaml
ptc is now known as Guest81763
ygrek has quit [Ping timeout: 250 seconds]
<ddub> no way to find out what is Not_found?
Guest81763 has quit [Ping timeout: 246 seconds]
<dmbaturin> ddub: Not_found is a very generic exception name, functions like List.find or, in this case, Map.find raise it when an element is not found.
martintrojer has quit [Ping timeout: 240 seconds]
ptc_ has joined #ocaml
martintrojer has joined #ocaml
martintrojer has quit [Max SendQ exceeded]
martintrojer has joined #ocaml
yminsky has joined #ocaml
<dmbaturin> adrien: What if we make an install script for lablgtk on windows that takes ocaml and GTK installation paths as arguments?
martintrojer has quit [Max SendQ exceeded]
<dmbaturin> Will you merge such a thing?
martintrojer has joined #ocaml
<adrien_znc> dmbaturin: I'd do something based on win-builds
<dmbaturin> Win-builds?
<adrien_znc> at that point I'd much prefer to work on the ocaml cross-compiler for windows
<adrien_znc> but that's a bit further
<adrien_znc> dmbaturin: http://win-builds.org
martintrojer has quit [Max SendQ exceeded]
mort___ has quit [Quit: Leaving.]
<adrien_znc> (btw, I'm on shared satellite connection through a ZNC so I might not properly see all messages (arriving at home in 3 to 4 hours though)
martintrojer has joined #ocaml
tane has quit [Ping timeout: 246 seconds]
tane has joined #ocaml
martintrojer has quit [Max SendQ exceeded]
martintrojer has joined #ocaml
<dmbaturin> Oh, interesting. Didn't know of it.
<adrien_znc> I'll need to tatoo the link on my back and run naked during a football game I guess
<dmbaturin> I lack knowledge to work on windows cross-compilation, but maybe I can do something with that win-builds tool.
martintrojer has quit [Max SendQ exceeded]
martintrojer has joined #ocaml
<adrien_znc> it already provides the GTK+2 stuff and it should be fairly simple to package the various pieces together
<reynir> adrien_znc: that would be interesting
<adrien_znc> I'd say the timeframe for cross-compiled lablgtk is roughly end of the year
martintrojer has quit [Max SendQ exceeded]
<adrien_znc> (I mean, for it to be good enough to be officially distributed)
martintrojer has joined #ocaml
<adrien_znc> so that leaves a lot of need meanwhile
Mandus has joined #ocaml
yminsky has quit [Quit: yminsky]
alpen has joined #ocaml
seangrov` has joined #ocaml
seangrove has quit [Ping timeout: 244 seconds]
dav has quit [Ping timeout: 256 seconds]
mort___ has joined #ocaml
<tokenrove> if i'm working with local modifications of an opam package, do i want "opam init default ." or "opam pin add ."?
TheCommieDuck has left #ocaml ["Once you know what it is you want to be true, instinct is a very useful device for enabling you to know that it is"]
dav has joined #ocaml
struk|dtut has quit [Ping timeout: 246 seconds]
Kakadu has quit [Quit: Page closed]
struktured has quit [Ping timeout: 256 seconds]
Anarchos has joined #ocaml
Guest80118 is now known as ned
AlexRussia has joined #ocaml
<Drup> tokenrove: later
<dmbaturin> Why utop may not see the module names after I #load "foo/bar.cmo" ?
seangrov` has quit [Ping timeout: 256 seconds]
<ggole> Use #directory to add foo (iirc)
vanila has quit [Quit: Leaving]
ptc_ has quit [Ping timeout: 240 seconds]
struktured has joined #ocaml
mort___ has quit [Quit: Leaving.]
swgillespie has joined #ocaml
willy_ has joined #ocaml
wwilly has quit [Ping timeout: 244 seconds]
nullcat_ has joined #ocaml
SkoAleVal has joined #ocaml
jao has joined #ocaml
jao has quit [Changing host]
jao has joined #ocaml
Kakadu has joined #ocaml
Haudegen has quit [Ping timeout: 244 seconds]
swgillespie has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
<whitequark> yes
<tokenrove> is there a good example of a library exposing its ctypes types to other libraries that depend on the same types?
Haudegen has joined #ocaml
segmond has quit [Ping timeout: 264 seconds]
hilquias has joined #ocaml
<whitequark> what's the problem?
<whitequark> it should just work as usual
Haudegen has quit [Ping timeout: 255 seconds]
<def`> hmm, you might want to expose the ctypes type witnesses (which are values as far as ocaml is concerned) in the interface too
Haudegen has joined #ocaml
nopf has joined #ocaml
segmond has joined #ocaml
Haudegen has quit [Ping timeout: 264 seconds]
seangrove has joined #ocaml
Haudegen has joined #ocaml
ptc has joined #ocaml
ptc is now known as Guest51991
hilquias has quit [Ping timeout: 255 seconds]
swgillespie has joined #ocaml
Guest51991 has quit [Ping timeout: 264 seconds]
yomimono has joined #ocaml
ptc_ has joined #ocaml
pyon-as-a-brick is now known as pyon-k
yomimono has quit [Ping timeout: 256 seconds]
rand000 has joined #ocaml
bjorkintosh has joined #ocaml
mort___ has joined #ocaml
antkong has joined #ocaml
<tokenrove> whitequark: no problem, just trying to figure out what the best practices were in terms of how much one exposes in the interface
Submarine has joined #ocaml
Submarine has joined #ocaml
sivoais has quit [Ping timeout: 255 seconds]
Guest11627 has quit [Ping timeout: 252 seconds]
ggole has quit []
slash^ has quit [Read error: Connection reset by peer]
diethyl has joined #ocaml
<Anarchos> tokenrove i would say : you expose only the minimum required
diethyl has quit [Ping timeout: 265 seconds]
Haudegen has quit [Ping timeout: 264 seconds]
diethyl has joined #ocaml
Haudegen has joined #ocaml
<Algebr> Why does ocamlc complain about unbound modules if one does give the flag for -linkpkg?
<whitequark> the order is important
<Algebr> order of what, the flags to ocamlc?
<whitequark> order of modules being linked. but it should be unlikely that you get that error
<whitequark> can you be more specific?
swgillespie has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
<Algebr> sorry, I was doing ocamlfind ocamlc -g json_data.ml -package yojson -o Foo.
<whitequark> but that doesn't have -linkpkg
<Algebr> where json_data.ml is a small thing using yojson and it craps out if I don't give -linkpkg
<whitequark> oh
<Algebr> I'm asking why does it need it?
<whitequark> does NOT give the flag for -linkpkg
<Algebr> oh oops, I forgot to write does not
<Algebr> sorry
<whitequark> well, it has to link Yojson into the final executable
<companion_cube> I think the -package yojson might have to be before the module name
<whitequark> companion_cube: no, that doesn't matter
<companion_cube> I'm never sure with this
<Algebr> so is -linkpkg always needed for executables?
<whitequark> normally, -package just adds an include path
<whitequark> but with -linkpkg, it specifies the .cma's
<whitequark> yes
<companion_cube> Algebr: it's needed for executables, but not for libraries
<Algebr> but it still craps out if I dont give the -o flag
sivoais has joined #ocaml
sivoais has quit [Changing host]
sivoais has joined #ocaml
<whitequark> "craps out" is not an error message.
<Algebr> Error: Error while linking json_data.cmo: Reference to undefined global `Yojson' That is with ocamlfind ocamlc -g json_data.ml -package yojson
<companion_cube> well yes, you need -linkpkg
<Algebr> then how does one make a library
<whitequark> ocamlc -a
A1977494 has joined #ocaml
MercurialAlchemi has quit [Ping timeout: 256 seconds]
A1977494 has left #ocaml [#ocaml]
MercurialAlchemi has joined #ocaml
SkoAleVal has quit [Read error: Connection reset by peer]
antkong has quit [Quit: antkong]
monod has quit [Ping timeout: 250 seconds]
dsheets_ has quit [Ping timeout: 250 seconds]
antkong has joined #ocaml
<Algebr> Is there something higher level than Unix.localtime? Something that will give me back "Jan 20 2001" for example given the float that localtime expects
MercurialAlchemi has quit [Ping timeout: 252 seconds]
* Kakadu remembers something called 'calendarlib'
<companion_cube> calendar, odate... look on opam
<def`> Core also has a date api
MercurialAlchemi has joined #ocaml
<def`> calendar is rich, but the api is hmm, verbose and not always following best practices
<companion_cube> are there really explicit "best practices" in OCaml?
<def`> no.
<def`> but global state will never be one of them
<companion_cube> oh.
<companion_cube> there's global state in calendar? sad
<def`> the timezone
<companion_cube> oh.
willy_ has quit [Quit: This computer has gone to sleep]
<adrien> C \o/
monod has joined #ocaml
<Algebr> I'm trying to use it the calendar package in the top level, either utop or ocaml. I'm doing #require "calendar";; and then open Time but still get unbound Module errors. Also added #require "calendar" opaminit, is more required?
<companion_cube> sounds stupid, but did you install calendar first?
<Algebr> yea, it was already installed
<Algebr> I guess something else had a dependency and I see the line that it was loaded by ocaml
<def`> everything is a submodule of calendar something
<companion_cube> maybe it's Calendar.Time
<def`> yep
<Kakadu> CalendarLib.Time;;
<companion_cube> utop autocompletes, you should try
mort___ has quit [Quit: Leaving.]
<companion_cube> def`: do you think the author of calendar would accept patches to improve the interface?
<Algebr> oh, but ocp-browser had Time as its own module
<def`> companion_cube: I don't know him at all
<companion_cube> oh, he's a guy working on frama-C at CEA, I think
<def`> but the API evolved a bit over time, so, maybe.
<companion_cube> bad news is, it's on the forge, it might not be easy to contact him about this
<companion_cube> I think there are some libs that are nice but have bad interface
<companion_cube> e.g., to.ml
<def`> not via pullrequest, but maybe an email :D ?
<MercurialAlchemi> Lwt.Canceled
<def`> I don't remember what is to.ml
<def`> ?
<def`> lwt cancel semantics are broke :D
<MercurialAlchemi> wrong copy-paste :)
<def`> it's not nice, but it is a bad interface =)
<companion_cube> a toml parser/printer
<def`> (:
<def`> Ok.
<Algebr> okay, this is too much of a hassle, will just write code =/
<companion_cube> I don't know whether odate is good
Kakadu has quit [Remote host closed the connection]
dsheets_ has joined #ocaml
travisbrady has joined #ocaml
yomimono has joined #ocaml
swgillespie has joined #ocaml
swgillespie has quit [Client Quit]
reem has joined #ocaml
martintrojer has quit [Max SendQ exceeded]
martintrojer has joined #ocaml
martintrojer has quit [Max SendQ exceeded]
martintrojer has joined #ocaml
<MercurialAlchemi> companion_cube: looks like it makes it easy to mix dates with different (or no) timezone
BitPuffin has joined #ocaml
<companion_cube> I don't know dates well enough :/
swgillespie has joined #ocaml
ollehar1 has joined #ocaml
<companion_cube> I'd think everything would be in unix timestamps, and timezones would be used only when printing to human readable form
<def`> dates are always more complicated that we assume :)
antkong has quit [Ping timeout: 256 seconds]
<Drup> that reminds me an article about what programmers assume about (postal) addresses
<companion_cube> or mail addresses
<companion_cube> just accept any string with an @ inside
travisbrady has quit [Quit: travisbrady]
Ansnum_ has joined #ocaml
<dmbaturin> Drup: Got a link?
Ansnum has quit [Ping timeout: 256 seconds]
Ansnum_ is now known as Ansnum
<Anarchos> companion_cube unix timestamps are false reference for time : you miss the supplementary seconds....
<dmbaturin> I used to think it's reasonable to make postal code in address forms mandatory until I had to enter a Hong Kong postal address in a form. :)
<companion_cube> Anarchos: -_-
travisbrady has joined #ocaml
dbp has quit [Quit: ZNC - http://znc.in]
ruoso has quit [Remote host closed the connection]
tnguyen has quit [Quit: tnguyen]
<MercurialAlchemi> you can't have everything in utc all the time
<whitequark> of course you can
<whitequark> convert data to utc immediately after input / from utc immediately before output
<whitequark> similarly to utf8\
<MercurialAlchemi> you can't as in "if you base your library on this idea, you're doing it wrong"
<companion_cube> whitequark: yeah, it sounds so reasonable
<whitequark> a library that enforces keeping everything in utc is, obviously, a good library
<MercurialAlchemi> no, it's a library by people who don't need naive dates
<companion_cube> whitequark: so, would you think a lib dealing with file paths, should deal only with absolute paths?
<MercurialAlchemi> you may also need dates which are valid in a single timezone
<companion_cube> convert into absolute path on input, then deal only with those
<whitequark> companion_cube: the concept of a current directory is quite awful, actually
<companion_cube> yes
<companion_cube> it's a big global variable
<whitequark> and you don't need it outside of a shell
<whitequark> MercurialAlchemi: "naive" ?
<companion_cube> well you can emulate it easily, using a context, and so on
<companion_cube> but still, I think it's the same kind of idea
<companion_cube> I need to keep working on CCIO.File, which does this
<MercurialAlchemi> whitequark: dates with no timezone info associated
<whitequark> yes, you don't need naive dates. it's not data that makes any sense
<whitequark> like text without associated encoding
<MercurialAlchemi> yeah, right
<companion_cube> MercurialAlchemi: use the current timezone in this case
<companion_cube> but once you've entered the date, the timezone is explicit
<companion_cube> (same as curdir/absolute path)
<MercurialAlchemi> haha
<MercurialAlchemi> seriously, no
<companion_cube> well, when I mean "friday 13th, feb 2015" I mean in my timezone
<companion_cube> otherwise I'd specify the timezone
<whitequark> a date without a timezone doesn't specify a point in time. it doesn't allow you to safely perform any operations on it
<whitequark> except store as-is and display back as-is
<whitequark> quite similar to text without encoding, actually
mengu__ has joined #ocaml
<MercurialAlchemi> companion_cube: when you get an icalendar invitation, you may get a DATE
<MercurialAlchemi> meaning it's a fullday event on a given day, regardless of the timezone
<whitequark> so, it's 48 hour long?
<MercurialAlchemi> in general, I wouldn't suggest implementing a time library without looking at RFC 5545
<whitequark> to cover all the timezones.
keen__________75 has joined #ocaml
<MercurialAlchemi> whitequark: maybe it's your birthday
keen__________74 has quit [Ping timeout: 244 seconds]
<MercurialAlchemi> it's the same date, regardless of your timezone at the moment
<companion_cube> a birthday is an informal date
hilquias has joined #ocaml
<companion_cube> if you want to be specific, it's a time interval in a specific timezone
<companion_cube> (unless the baby is born in a plane crossing timezones?)
<companion_cube> (aww)
<MercurialAlchemi> well, it may be an "informal" date, but you still need to have this notion :)
<companion_cube> yes
<companion_cube> but it means 'where I am'
<whitequark> actually, your example doesn't work. if I was planning anything for my birthday, I would surely take timezones into account, for I know a lot of people in US
<companion_cube> basically
<MercurialAlchemi> yes
tane has quit [Quit: Verlassend]
<MercurialAlchemi> that's why something like this wouldn't have a specific tz
<whitequark> and I was born in a specific place and timezone, for that matter
<companion_cube> MercurialAlchemi: this would be a "symbolic" date
<companion_cube> something that needs to be evaluated
<companion_cube> but isn't a proper value
<companion_cube> it's an expression
<MercurialAlchemi> There are two kinds of date and time objects: “naive” and “aware”.
<MercurialAlchemi> A naive object does not contain enough information to unambiguously locate itself relative to other date/time objects.
<MercurialAlchemi> (from the Python docs)
<companion_cube> so what's a naive object good for?
<MercurialAlchemi> of course, it introduces a good deal of complexity, but welcome to the real world
<companion_cube> I think we should divide into: 1/ a precise representation of time intervals/instants in the referential of Earth
<whitequark> so you're saying essentially the same. you can't perform any operations on that
<whitequark> it's basically an opaque string that is formatted like a date.
<companion_cube> 2/ an expression language for representing dates that are symbolic
<companion_cube> like "next friday"
<companion_cube> those expresions would have to be evaluated in some specific timezone, etc.
<whitequark> companion_cube: relative to a specific date (which implies a timezone)
<MercurialAlchemi> whitequark: nothing prevents you from adding days to a naive date
<companion_cube> whitequark: I mean, things like "Easter day" are symbolic dates
<companion_cube> but they should not belong to the same language as precise dates
<companion_cube> they should evaluate to precise dates, every year (in this example)
<whitequark> MercurialAlchemi: calendar switches, for example
<MercurialAlchemi> calendar switches?
<whitequark> yes. old/new style dates
<MercurialAlchemi> hm
<MercurialAlchemi> like switching to the gregorian calendar?
<whitequark> yeah
<MercurialAlchemi> I don't think you should take that into account
<whitequark> it would probably work if you add something like "after 1970", and even then I'm not sure
<MercurialAlchemi> not aware we changed calendars after 1970 :)
<MercurialAlchemi> of course, if you also want non-naive dates to work with, say, the russian orthodox calendar, you're going to have fun
<whitequark> tzdata already handles that
<MercurialAlchemi> (in a type safe way, that is)
reem has quit [Remote host closed the connection]
<MercurialAlchemi> I guess you could represent that as a special timezone...
<whitequark> nah, you just use the regular, say, Europe/Moscow
antkong has joined #ocaml
<whitequark> and you get a discontinuous (local) timeline
<whitequark> all UTC points map to some local point, but some local points never happened
<MercurialAlchemi> right
ptc_ has quit [Ping timeout: 265 seconds]
<MercurialAlchemi> anyway, it's messy
<MercurialAlchemi> DST is a pain too
<whitequark> and there are still people alive whose birthday was before the switch
ghostpl_ has joined #ocaml
<MercurialAlchemi> I must confess that I don't know when DST started
<MercurialAlchemi> before WWII?
travisbrady has quit [Quit: travisbrady]
<dmbaturin> MercurialAlchemi: In some XIX century.
<whitequark> in Russia?
<MercurialAlchemi> in general :)
<dmbaturin> Different countries started and stopped using it at different time though. I think the US might be the first country to do it.
<MercurialAlchemi> I assume that like women voting, it took some time to propagate
dbp has joined #ocaml
<dmbaturin> Yes, DST is a serious but slowly spreading disease. ;)
<whitequark> "Germany and Austria-Hungary organized the first implementation, starting on 30 April 1916."
<whitequark> spreading?
<whitequark> more like contracting
<MercurialAlchemi> oh, that's what WWI was all about
ollehar1 has quit [Quit: ollehar1]
<dmbaturin> MercurialAlchemi: From this point of view, we all lost the battle for continuos time.
<MercurialAlchemi> yeah
<dmbaturin> Aztecs and maya had calendars very similar to UNIX timestamps, just with funny formatting and really ancient epoch start date.
hilquias has quit [Remote host closed the connection]
antkong has quit [Ping timeout: 244 seconds]
Haudegen has quit [Ping timeout: 245 seconds]
Haudegen has joined #ocaml
Anarchos has quit [Quit: Vision[0.9.7-H-20140108]: i've been blurred!]
<MercurialAlchemi> :)
Ansnum has quit [Ping timeout: 265 seconds]
myst|work has quit [Ping timeout: 252 seconds]
Anarchos has joined #ocaml
myst|work has joined #ocaml
reem has joined #ocaml
mcc has joined #ocaml
reem has quit [Remote host closed the connection]
<tokenrove> is there any way to ensure a value is stack allocated? particularly, is it possible to declare a foreign struct allocated by ctypes to have dynamic extent?
MercurialAlchemi has quit [Ping timeout: 246 seconds]
Anarchos has quit [Quit: Vision[0.9.7-H-20140108]: i've been blurred!]
reem has joined #ocaml
badon has quit [Quit: Leaving]
<whitequark> dynamic extent?
<whitequark> ctypes does not allocate values on stack
nullcat_ has quit [Quit: gone...]
<whitequark> and all values allocated by ctypes are freed when finalized by GC, you can't do that explicitly
mcc has quit [Quit: This computer has gone to sleep]
rand000 has quit [Quit: leaving]
Simn has quit [Quit: Leaving]
laughing-octo-sh has quit [Ping timeout: 252 seconds]
reem has quit [Remote host closed the connection]
reem has joined #ocaml
reem has quit [Remote host closed the connection]
reem has joined #ocaml
<tokenrove> sorry, dynamic extent is a lispism, i guess. anyway, that's unfortunate.