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
<Drup> a root module ? it can't be in a library, no
<whitequark> why not?
<Drup> because it would be also prone to overwrite
<Drup> I mean, a *root* module, that can't be masked
travisbrady has joined #ocaml
rgrinberg1 has joined #ocaml
Denommus has joined #ocaml
Denommus has joined #ocaml
rgrinberg has quit [Read error: Connection reset by peer]
<whitequark> PR6705
manizzle has joined #ocaml
<jonludlam> anyone here any idea why oasis might install .ml files? Is there any use for that?
<rgrinberg1> I kind of wish that type_conv/ppx_deriving code for a type could be shipped externally from the module where the type is defined
<rgrinberg1> although i realize that breaks for abstract types
<whitequark> rgrinberg1: you realize ppx_deriving is optional?
<whitequark> for instance, you can simply make it a depopt, or you can make individual derivers like yojson depopts
manizzle has quit [Ping timeout: 240 seconds]
<whitequark> [@@deriving yojson { optional = true }]
<jonludlam> when I do 'make install' in ocaml-re, it installs one of the 9 .ml files for one of the 7 libraries
<jonludlam> weird
<jonludlam> why is re_pcre.ml special? hmm.
Denommus has quit [Ping timeout: 255 seconds]
<rgrinberg1> whitequark: I understand that. But I mean what if I wanted to generate converters without having source access. Say for Cohttp.Request.t for example.
<jonludlam> ooh
dsheets has quit [Ping timeout: 265 seconds]
<jonludlam> [jludlam@localhost lib]$ ls *.mli | wc
<jonludlam> 8 8 90
<jonludlam> [jludlam@localhost lib]$ ls *.ml | wc
<jonludlam> 9 9 93
<whitequark> rgrinberg1: ppx_deriving_cconv does that
<Drup> whitequark: only if you convince the author to use it
<Drup> you can't plug it externally
<whitequark> ppx_import does that :p
<whitequark> I've used ppx_import to great effect in [REDACTED]
<Drup> not if the type is abstract ;)
<whitequark> type position' = [%import: Lexing.position] [@@deriving show]
<whitequark> type location' = [%import: Location.t [@with Lexing.position := position']] [@@deriving show]
<whitequark> type token' = [%import: Parser.token [@with Location.t := location']] [@@deriving show]
<rgrinberg1> I'll check it out. But basically type_conv has always been irksome b/c you couldn't ship converters individually
<whitequark> my view is that combinators are useless for converters
<whitequark> because you can't customize format
<Drup> whitequark: btw, do you plan on working back on the llvm backend ? :)
<rgrinberg1> b/c sexp for example expects everything into the module
<whitequark> with ppx_deriving and ppx_import, you can
<whitequark> Drup: maybe
<whitequark> I got roped into being the reviewer for Philip Reames' GC patches
<whitequark> Drup: btw, that opam line WAS broken
<whitequark> the library is called text, not ocaml-text :p
<Drup> I was waiting for your patch to land to fix it
<whitequark> well, either that or the depopt
<whitequark> rebased and pushed, with that fix too
<Drup> and yes, it got rename a few weeks ago
Kakadu has quit [Quit: Konversation terminated!]
<Drup> whitequark: it's correct in the repository
<bernardofpc> companion> http://cedeela.fr/~simon/files/opam_system.html for anyone interested (discussion on opam-devel) -> /tmp chroot loks a lot like gentoo sandbox
<Drup> but I just noticed that the line was removed in the opam for lwt.2.4.5 in opam repository
<Drup> and i have no idea why
<Drup> 2.4.6*
<rgrinberg1> ppx shills give me your support —> https://github.com/mirage/ocaml-cohttp/issues/180#issuecomment-66713254
<rgrinberg1> ^_^
<companion_cube> what does fieldslib generate exactly?
<companion_cube> accessors for records?
struktured has joined #ocaml
<jonludlam> rgrinberg1, looks like you've added a .mli for re_pcre.ml a few days ago
<rgrinberg1> companion_cube: yeah
<companion_cube> I think optcomp/cppo is the only reasonable way, currently, to handle type_conv and ppx_deriving
<companion_cube> rgrinberg1: ppx_deriving_fields should be easy to write
<companion_cube> easier than deriving_yojson and the likes
<Drup> it's ... already written.
<companion_cube> oh, really?
<rgrinberg1> companion_cube: i don't think so fieldslib exports quite a rich interface
<companion_cube> I only noticed .crete recently
<companion_cube> create*
<rgrinberg1> jonludlam: yes i did
<Drup> if that's what I think it is, at least
<companion_cube> rgrinberg1: what does it do in addition to that?
<jonludlam> you've hidden substitute, split, quote and string_unsafe_sub - are these not to be used from outside then?
<rgrinberg1> jonludlam: whoops. my bad. I think I've re-exported a few of those in another PR
<jonludlam> ah cool, that's fine.
<rgrinberg1> but the answer to your question in general is that we should export whatever ocaml-pcre exports
<jonludlam> right
<jonludlam> the reason is I'm trying to write a spec file to make an RPM for ocaml-re
<jonludlam> and i was complaining that there was a .ml file in the
<jonludlam> *rpmlint was complaining
<rgrinberg1> companion_cube: as usual for JS it's not well documented
<rgrinberg1> a good place to start
<jonludlam> turns out this was because there wasn't an mli file
<jonludlam> anyway, I should make the mli export all the functions rather than a subset.
<Drup> rgrinberg1: "as usual for JS it's not well documented" ah. ah. ah. ah.
<companion_cube> rgrinberg1: looks like bloat.
<companion_cube> I mean, ok, a setter in additoin to the getter is fine
<companion_cube> but permissions, names,etc. ?
<companion_cube> really?
Denommus has joined #ocaml
Denommus has joined #ocaml
<companion_cube> I think ppx_deriving is a good time to get back to KISS
<Drup> rgrinberg1: What is the feature really used ?
<Drup> (also, I'm not sure how I feel about this thing, considering that a lambda will often be shorter ...)
<whitequark> Drup: so if I use a constraint with a type variable, how is it scoped?
<whitequark> like (x : 'a)
<rgrinberg1> Drup: you mean fieldslib?
<Drup> rgrinberg1: yes
<Drup> whitequark: same as variables
<rgrinberg1> first class fields are better than accessors for one
<Drup> except it doesn't go in a smaller scope
<whitequark> Drup: wat
<whitequark> I mean like
<whitequark> (x:'a) (y:'a)
<whitequark> is it the same 'a?
<Drup> yes
<companion_cube> rgrinberg1: are they kind of lenses?
<rgrinberg1> companion_cube: exactly
<companion_cube> I'd tend to think that lenses in OCaml were tedious to use
<Drup> huh, where are the combinators ?
<Drup> I mean, lenses without combinators are useless
<rgrinberg1> you can do Field.get
<Drup> except if you want to brag about point-free style
<rgrinberg1> Field.fset
Denommus has quit [Ping timeout: 244 seconds]
<rgrinberg1> i use it in opium for example to get cookies in a request or response
<Drup> rgrinberg1: is "Field.get my_field" really shorter than "fun x -> x.my_field" ? :|
<Drup> hum, I see
<Drup> ok, you use it like that
<Drup> (still lack combinators to be called "lenses" ...)
<companion_cube> rgrinberg1: what if those accessors were not generated at the type location, but like [%get my_field] record ?
thomasga has quit [Quit: Leaving.]
<Drup> companion_cube: the point is that you can take the field as argument
<rgrinberg1> Drup: it's true but writing the combinators i would say is the easy part
<companion_cube> it's not the case in this example
<companion_cube> rgrinberg1: writing usable combinators for lenses is hard
<Drup> ^
<companion_cube> if you don't have implicits...
<companion_cube> it's worse than combining printers
<companion_cube> Drup: you can give a setter (as a function) or a getter
<companion_cube> I still think generating only the setter/getter is enough (maybe a mutable setter is relevant)
<Drup> companion_cube: the point is that you can do 'fun some_field -> Fields.get my_record some_field"
<Drup> and then be parametrized over the field
<Drup> which is not possible otherwise
<companion_cube> fun some_getter ->...
<companion_cube> sure you can
<Drup> Show me. :p
<companion_cube> fun some_getter -> some_getter my_record ?
<companion_cube> same as what you wrote
<rgrinberg1> Drup: i don't want anything complicated combinator wise
madroach has joined #ocaml
<Drup> companion_cube: the getter will be essentially a function, and you can't get the name of the field, making the whole thing much more verbose
<rgrinberg1> i just want to functionally update a cookie time in a Cohttp.Request.Headers.Cookies.time without alcohol
oscar_toro has quit [Ping timeout: 264 seconds]
<Drup> I remember needing something like that, when I wanted to have the string corresponding to a field, and I ended up writing it by hand, and it was meh
<companion_cube> assuming Request, Headers and Cookies have nested records?
<rgrinberg1> request is a record
<rgrinberg1> headers is string * string list
<Drup> (still, the interface is ugly)
<rgrinberg1> cookie is a record
<companion_cube> ok, this can be neat
<rgrinberg1> Drup: in OCaml we can't have van laarhoven lenses but if objects didn't suck we could have standardized on < get .. ; set .. >
<Drup> rgrinberg1: indeed
<Drup> "if objects didn't suck"
<companion_cube> why do you think objects suck?
<Drup> because nobody cared enough to optimized them as much as pattern matching :D
<rgrinberg1> biggest problem is that they're too slow
<rgrinberg1> nobody would use them
<companion_cube> how much slower?
<rgrinberg1> in my measurements
<rgrinberg1> at the very least 2x
<Drup> *2 is acceptable
<rgrinberg1> in the best case
<Drup> but it's much slower than that, usually ...
<companion_cube> also, you can have the objects' methods return /functions/
<rgrinberg1> yes, much slower than that in other use cases
<companion_cube> those functions would be efficient
<companion_cube> let get = ((f1#compose f2)#compose f3)#get in (* use get a lot *)
<rgrinberg1> Drup: How about `Get of 'r -> 'a * 'Set of 'r -> 'a -> 'a
<rgrinberg1> janestreet style
<rgrinberg1> lol
<whitequark> oppa janestreet style
<companion_cube> I don't think it's a good idea to use records for reified Fields
<companion_cube> it locks you to one library (Core)
<rgrinberg1> companion_cube: why? fieldslib is separate from core
<companion_cube> objects returning composed functions should be as fast
<companion_cube> depends: camlp4 & ocamlfind >= 1.3.2 & type_conv >= 109.20.00 & < 112.02.00
<companion_cube> ↑ this is why
<rgrinberg1> still don't see core
<whitequark> that's not too bad actually
<whitequark> I mean, you couldn't do this without type_conv until recently
<companion_cube> ↑ this should be efficient
<rgrinberg1> zR please
<companion_cube> done
AlexRussia has joined #ocaml
<rgrinberg1> we'd need to benchmark
<companion_cube> indeed
<companion_cube> of course it's efficient if you cache the functions
<rgrinberg1> anyway, who can we whine to about making objects faster
Denommus has joined #ocaml
pyon has quit [Ping timeout: 245 seconds]
<whitequark> git
<companion_cube> let get = (f1#compose f2)#get
<rgrinberg1> also, i've been hearing about an inline ppx node
<rgrinberg1> could definitely be useful for composing lenses
<companion_cube> of course the alternative is to define the lens as a tuple
<Drup> inline ppx node ?
<companion_cube> which is also a structural type, but less convenient
<rgrinberg1> @@inline on a function i believe
<Drup> ah yeah
<Drup> not done
<rgrinberg1> maybe it was just speculation
<Drup> not really speculation
<Drup> chambart want to do it this way
<companion_cube> oh yeah.
* companion_cube wants @specialize on combinators
<companion_cube> actually the pair could make a nice lens
Denommus has quit [Ping timeout: 272 seconds]
jonludlam has quit [Quit: Coyote finally caught me]
ygrek has joined #ocaml
<companion_cube> http://vrac.cedeela.fr/foo.html pretty cool
<companion_cube> should be efficient this time
lordkryss has joined #ocaml
manud___ has joined #ocaml
<companion_cube> anyway, good night
<rgrinberg1> night
<rgrinberg1> a pair does seem ok'ish
<rgrinberg1> Drup: ?
<rgrinberg1> even without the `Get/`Set labels
<rgrinberg1> we can live without name: string for sure
<Drup> rgrinberg1: ?
<Drup> name is useful
<rgrinberg1> ('r -> 'a * 'r -> 'a -> 'a) could be a canonical ocaml lens
<Drup> (and barely cost anything if you are autogenerating it.
<whitequark> I want pattern matching on Gen.
<rgrinberg1> wait that type is wrong. should be ('r -> 'a * 'r -> 'a -> r)
<rgrinberg1> companion_cube: you still there?
<Drup> whitequark: match%gen ? :p
<whitequark> I guess
<whitequark> for quick and dirty LL parsers
<Drup> very quick and very dirty x)
<whitequark> exactly
rgrinberg1 has quit [Read error: Connection reset by peer]
rgrinberg has joined #ocaml
<rgrinberg> why so much love for for external iterators
<rgrinberg> just write folds
<whitequark> have you tried writing a parser with folds
<Drup> rgrinberg: ahah, that was a good joke
<Drup> can I have a readable version ?
<Drup> thanks.
Denommus has joined #ocaml
<Drup> the fact that several words are used for the same thing and never really defined is ...
<Drup> rgrinberg: so, the point made is right, but mostly don't apply
<Drup> yes, cursors (gen) are not the nicest, but are the most adapted for lexing.
Hannibal_Smith has quit [Quit: Leaving]
<Drup> and yes, they are slower, but not that much
<whitequark> is this very bad
antinomy has quit [Ping timeout: 272 seconds]
<Drup> rgrinberg: and going from stream/iterator/folds (it's mostly equivalent to sequence) to gen is horrible, as the scheme given is this paper shows
<Drup> I mean
<Drup> yeah, there is a way to do that
<Drup> call/cc in OCaml is possible but you don't want to use it, and it's slow as fuck
<rgrinberg> Drup: well writing complex gens in ocaml blows as well
<Drup> does it ?
Denommus has quit [Ping timeout: 256 seconds]
<Drup> [reference needed]
<Drup> I don't know what it's supposed to do and I don't know the internals of re, so ....
<rgrinberg> split an re into a gen list
<rgrinberg> split on an re*
<rgrinberg> Drup: ok here's a fold based version
<rgrinberg> hopefully it's less bewildering
<Drup> tbh, both are as arcane.
<rgrinberg> eh. i'd have to disagree
<rgrinberg> my fold version isn't clean
<Drup> sure, you wrote one of them.
<rgrinberg> but you can read it line by line
jao has joined #ocaml
jao has quit [Changing host]
jao has joined #ocaml
<rgrinberg> but ok you can argue that readability is subjective
<rgrinberg> however when 'a gen represents some resource that needs to be cleaned up
<rgrinberg> that's evil IMO
<Drup> you can argue it's evil
<Drup> but if you want to do a tokenizer
<Drup> you don't have the choice
MrScout has quit [Ping timeout: 240 seconds]
<Drup> rgrinberg: folds offer less controls, that's as simple as that
antinomy has joined #ocaml
<rgrinberg> Drup: simple folds sure
<Drup> you can't stop midway, you can't wrap the thing in a monad, you can't ...
<rgrinberg> i.e. those that don't let you terminate midway
Denommus has joined #ocaml
<Drup> rgrinberg: I argue that fold that let you terminate midway are cursors in disguise :p
<rgrinberg> you have to upgrade folds to iteratees
<rgrinberg> as long as they dont let resources leak i dont care what we call them
<struktured> rgrinberg: interesting read. thanks for posting that link
<rgrinberg> NP
<Drup> rgrinberg: you do realize that a gen can close the underlying resource when ending ?
<rgrinberg> to address the rest of Drup's concerns
<rgrinberg> Drup: the point is that the responsibility is on the caller to end the generator
<rgrinberg> a fold doesn't allow for a resource to leak. period.
<rgrinberg> ok ok there's exceptions
<rgrinberg> but apart from them
Denommus has quit [Ping timeout: 245 seconds]
<Drup> I don't see why it's the responsibility of the caller with a gen, what's the issue with closing at the end of the gen ?
<struktured> Drup: end as in what? GC?
<Drup> end as in gen is finished.
<Drup> (returns None)
<struktured> but the user might not consume it entirely
<Drup> yeah well sure, that's the point of those ...
<struktured> sure, but hey at least they aren't cursors!
<rgrinberg> Drup: there is no issue if you dont forget to do it
<Drup> gen is pretty much the same as a cursor
<rgrinberg> folds don't let you forget though
<Drup> rgrinberg: my point is that you don't have to do it yourself, the gen itself can do it at the end
<rgrinberg> sure primitive folds disallow partial consumption
<rgrinberg> e.g. file_lines_as_gen "files" |> take 5 |> iter (fun x -> … )
<rgrinberg> that's buggy
<Drup> ... why ?
<rgrinberg> you must remember to close the gen
<rgrinberg> or consume the whole stream
<rgrinberg> the bottom line is that your gen sometimes acts like a file handle and sometimes it doesn't.
<rgrinberg> at least with file handles you know the danger is always there
<Drup> Ok.
rgrinberg has quit [Quit: Leaving.]
Denommus has joined #ocaml
<Drup> I must say this presentation doesn't make a good job at showing me how iteratees are not a pita to use
<struktured> I still think there some truth to what it implies ,that cursors are abused
<whitequark> Drup: how well does OCaml compile very large match statements?
<whitequark> say, about 5900 cases
<struktured> lol using a code generator?
<Drup> O_o
<Drup> whitequark: any when guards ?
<whitequark> none
<Drup> then it's very efficient
<whitequark> cool
<Drup> whitequark: strings ?
<whitequark> integers
<Drup> only integers ?
<whitequark> only integers.
<Drup> wtf are you doing x)
<whitequark> in fact, I'm matching on one integer.
Denommus has quit [Ping timeout: 272 seconds]
<Drup> (02:51:22) Drup: wtf are you doing x)
<whitequark> will it be better than a naive binary search?
<Drup> try, look at the lambda code.
<whitequark> ew
<whitequark> i don't wanna think
<Drup> but there is nothing much better than a binary search here anyway, isn't it ?
<whitequark> well, yes, but a match can be quicker than an array maybe
<whitequark> hmmm, I can't write a binary search. fuckit, match it is
<Drup> it will be a binary search
<struktured> whitequark: hashing out of consideration?
<Drup> whitequark: but, hum, if the thing after the match is constant, an array will obviously be better.
<Drup> (assuming it's dense, int hashtbl if sparse)
<whitequark> struktured: how exactly will that help
<Drup> hell, an array of function might be better...
<struktured> yeah array really
<struktured> since its just 5600
<Drup> whitequark: no but really, what is it doing ?
<whitequark> try to guess
<whitequark> it is not very hard
<Drup> the debugger ?
<whitequark> no
<Drup> I don't know, I'm bad at riddles :(
<Drup> all my condolences.
<whitequark> lol
<Drup> does the compiler manage to compile a 5600 match case ?
<whitequark> I fixed my binary search algorithm instead
<Drup> not an array then ?
<whitequark> array
<Drup> why do you need binary search if you have an array ?
<whitequark> um.
<whitequark> because the array is sparse
<Drup> use an int hashtbl instead then.
<whitequark> I don't want to have 0x10ffff elements in it
<whitequark> wow, what a spectacularly shitty idea
<Drup> depends how sparse.
<whitequark> 5900 out of 200k or so
<Drup> then no, it's not really shit
Denommus has joined #ocaml
<whitequark> initializing 5900 elements at load, no
<whitequark> with array, it's a compiled literal
<Drup> I mean, aren't you looking for the element associated with some int ?
<Drup> or just the fact that it's there ?
<whitequark> associated
<whitequark> it's an array of more ints
<Drup> I don't even see how you are going to do that with just an array, but apparently I'm tired tonigh.
lu324_ is now known as lu324
<whitequark> let ma = [| 0x0022, [|0x0027; 0x0027; |]; 0x0025, [|0x2080; 0x002f; 0x00ba; |]; 0x0030, [|0x004f; |]; 0x0031, [|0x006c; |]; 0x0049, [|0x006c; |]; 0x0060, [|0x0027; |]; 0x006d, [|0x006e; 0x0072; |];
<Drup> ok that's hideous.
<whitequark> why?
<Drup> It's (int, data) ?
<whitequark> yes
rgrinberg has joined #ocaml
<Drup> so hum
Denommus has quit [Ping timeout: 255 seconds]
<Drup> loading 5600 into an hashtbl is instantenous.
Denommus has joined #ocaml
Denommus has quit [Changing host]
Denommus has joined #ocaml
<Drup> you might want to benchmark your binary search against a hashtbl that doesn't hash, then
<Drup> (no clue who would win, but the hashtbl is less code)
<whitequark> I already wrote the code though
<Drup> right
<mfp> whitequark: FWIW, a 5900-element array fits in a 64 KB L1 cache (64-bit arch), a 11800- one doesn't, so you're better off with a snd array and likely a single cache miss (assuming you're doing lots of lookups)
<Drup> (the loading argument was bad, though)
<whitequark> mfp: tuples require indirection anyway
<whitequark> so it's not a 11800-element array, it's a 5900-element one plus one indirection
<mfp> sorry, misread that (thought you were using odd indexes for the "key", even for value)
<whitequark> can't do that
<whitequark> (without obj.magic)
<mfp> yes indeed, /me sleepy
<mfp> not that it matters in any way, but still having 2 arrays (instead of an array of tuples) should give you fewer cache misses
<whitequark> hmmmm
<whitequark> that's not too bad
antinomy has quit [Ping timeout: 244 seconds]
<mfp> N words vs 4 N words (1 for the ref in the array, one for header, 2 for tuple) having to fit in cache
<mfp> and a 5900-elm array holding the int keys and used to find the index for the 2nd hold fits in L1 nicely
<whitequark> yes yes
darkf has joined #ocaml
ygrek has quit [Ping timeout: 252 seconds]
<mfp> hmm you can actually get rid of yet another cache miss when dereferencing the "value" array
<mfp> but we're overoptimizing at this point
robink has quit [Ping timeout: 258 seconds]
<struktured> mfp: I think I know who to go to if I have optimization issues in the future
<Drup> x)
<mfp> using a linear array holding the concatenation of all the value arrays, then encoding the offset of the value in the key (higher-order bits, seems it would fit but I'm almost zzzing)
<Drup> That's so ugly T_T
<mfp> I was going to say "put key at odd indexes, offset in value array in even", but that goes over the magic 64KB figure
robink has joined #ocaml
<mfp> so higher bits it is, you only need around 20 bits for the codepoints, right? the remaining ones should be more than enough for the offset into the value array + the subarray length
<mfp> Drup: yes but but but it's one less cache miss
<Drup> x)
<mfp> Drup: cache misses should easily dominate execution time, so it could be nearly 2X faster than an array of arrays
<mfp> (the bit shifting and stuff is essentially free)
Denommus has quit [Quit: ZNC - http://znc.in]
<Drup> mfp: wild guess, whatever whitequark is doing, the naive version would be already efficient enough and no need for any optimization =')
<mfp> too sleepy to read the Java code in http://www.unicode.org/reports/tr39/#Confusable_Detection :/
<mfp> but I'd guess confusable detection is no less expensive than iterating over the codepoints and matching against the confusable table
jwatzman|work has quit [Quit: jwatzman|work]
<mfp> so 1 cache miss / codepoint ~= 100ns /codepoints = less than 10 mega-codepoints per sec
alkoma` has joined #ocaml
alkoma` has quit [Client Quit]
<whitequark> the Java code uses ICU
<whitequark> it has no relevant details
<Drup> ICU ?
<whitequark> Java unicode lib
gdsfh1 has joined #ocaml
Denommus has joined #ocaml
gdsfh has quit [Ping timeout: 240 seconds]
<mfp> I'm being silly actually, it should be 1 L1 miss/codepoint, but it'd be a L2 hit which is like < 10ns
alkoma has joined #ocaml
q66 has quit [Quit: Leaving]
ygrek has joined #ocaml
<mfp> so it's closer to at most 100 mega-codepoints/s, ignoring other costs
kapil__ has joined #ocaml
rgrinberg has quit [Quit: Leaving.]
<xaimus_> Žg
<xaimus_> bleh, wrong window
Denommus has quit [Ping timeout: 245 seconds]
<mfp> one final silly overoptimization idea: depending on the distribution of the codepoints to match against, you can improve on binary search w/ interpolation search
<Drup> that would have been my first idea, in fact
<Drup> but it wasn't worth the effort except if you *really* need the speed, which you probably don't
<mfp> O(log n) vs O(log log n) -> 13 lookups vs uh less than half of that?
<Drup> that's not the point
<Drup> if it's 1% or your runtime speed
<Drup> yeah, cool, you splited the time taken by 1%, well done
<mfp> Drup: my bet would be that the confusables thing is for usernames and speed is totally irrelevant
<mfp> so yeah, massively overoptimizing
<Drup> I would rather see that after doing benchmarks.
<Drup> or, I misread "relevant"
<Drup> then yeah :p
<Drup> (you can see that I'm not a low level guy, my first instinct was to go for the asymptotic optimization :p)
<mfp> the nice thing about things dominated by cache misses is that relative performance is fairly easy to predict
<mfp> you go from 2 misses to 1, you get up to 2X speed boost :-P
<Drup> mfp: gonna be honest, I don't have the mental model for it.
<Drup> like, not at all
<mfp> as far as OCaml is concerned, you just need to know how values are represented (the "interfacing with C" section of the manual) & keep in mind the "latencies any programmer should know"
<mfp> not even all of them, just like 1 mem access ~= 100ns, branch mispredict ~= 10-20 cycles, simple integer ops = peanuts
<mfp> if you're mem latency-bound, you're lucky, you can just reason in terms of how many indirections are needed according to the OCaml value representation for each alternative encoding
<Drup> (I would rather apply "the rule of optimization")
<mfp> well yes, this would all come *after* you've decided that something is worth optimizing
<Drup> which is mostly never the case :D
<mfp> all in generic cases like Hashtbl (of course you want hashtbl to be fast, why wouldn't you :)
<Drup> speaking of that
<Drup> how is the lwt/ssl patch comming ?
<mfp> actually Hashtbl is very easy to improve upon in many ways: keeping the hashes for faster resizing, open addressing for fewer indirections, etc. etc.
<mfp> Drup: blocked waiting for ocaml-ssl to accept the patch to write from/into bigarrays
<Drup> ok
<mfp> Drup: there are a couple other ocaml-ssl PRs awaiting merging (for a few months now)
<mfp> for POODLE and ciphersuite ordering
<mfp> do you happen to have access to Samuel Mimram or somebody who can ping him?
Yoric has joined #ocaml
<Drup> I don't
<Drup> but I'm pretty sure people on #mirage would
<Drup> oh, that's ocaml-ssl, not tls
<Drup> then no
<mfp> FWIW, the PR got two +1s https://github.com/savonet/ocaml-ssl/pull/15 it's quite trivial & immediately usable in Lwt_ssl and higher, and could have quite some effect on the performance of most OCaml programs doing SSL/TLS
Denommus has joined #ocaml
<Drup> sorry, can't help you
<Drup> he doesn't seem very active
<mfp> I haven't bm'ed ocsigenserver w/ patched ocaml-ssl (+ Lwt_ssl), but considering like 50% of CPU when serving static stuff was spent doing major heap GCing, it could be quite a lot
<Drup> yeah
Yoric has quit [Ping timeout: 260 seconds]
Denommus has quit [Ping timeout: 264 seconds]
rgrinberg has joined #ocaml
WraithM has quit [Remote host closed the connection]
Denommus has joined #ocaml
Denommus has quit [Ping timeout: 258 seconds]
Denommus has joined #ocaml
travisbrady has quit [Quit: travisbrady]
manud___ has quit [Quit: Be back later ...]
robink has quit [Ping timeout: 258 seconds]
Denommus has quit [Ping timeout: 258 seconds]
Denommus has joined #ocaml
badkins has quit []
pyon has joined #ocaml
rgrinberg has quit [Quit: Leaving.]
Denommus has quit [Quit: ZNC - http://znc.in]
Denommus has joined #ocaml
Denommus has quit [Quit: ZNC - http://znc.in]
shinnya has quit [Ping timeout: 245 seconds]
Denommus has joined #ocaml
lordkryss has quit [Quit: Connection closed for inactivity]
badon has quit [Read error: Connection reset by peer]
badon has joined #ocaml
msch has quit [Ping timeout: 244 seconds]
c74d has quit [Killed (holmes.freenode.net (Nickname regained by services))]
msch has joined #ocaml
lopex has joined #ocaml
zozozo has quit [Ping timeout: 244 seconds]
leifw has joined #ocaml
zozozo has joined #ocaml
c74d has joined #ocaml
Denommus has quit [Quit: ZNC - http://znc.in]
Denommus has joined #ocaml
Denommus has quit [Ping timeout: 240 seconds]
Denommus has joined #ocaml
larhat has quit [Quit: Leaving.]
alkoma has left #ocaml ["ERC Version 5.3 (IRC client for Emacs)"]
Denommus has quit [Ping timeout: 240 seconds]
kapil__ has quit [Quit: Connection closed for inactivity]
Denommus has joined #ocaml
kapil__ has joined #ocaml
ygrek has quit [Ping timeout: 245 seconds]
libertas has quit [Ping timeout: 240 seconds]
AlexRussia has quit [Ping timeout: 264 seconds]
libertas has joined #ocaml
AlexRussia has joined #ocaml
keen___________ has joined #ocaml
keen__________ has quit [Ping timeout: 245 seconds]
rgrinberg has joined #ocaml
robink has joined #ocaml
AlexRussia has quit [Ping timeout: 256 seconds]
matason has joined #ocaml
ggole has joined #ocaml
matason has quit [Client Quit]
matason has joined #ocaml
ygrek has joined #ocaml
jao has quit [Ping timeout: 264 seconds]
AlexRussia has joined #ocaml
rgrinberg has quit [Quit: Leaving.]
MercurialAlchemi has joined #ocaml
robink has quit [Ping timeout: 258 seconds]
robink has joined #ocaml
Denommus has quit [Ping timeout: 250 seconds]
Denommus has joined #ocaml
robink has quit [Ping timeout: 244 seconds]
rgrinberg has joined #ocaml
marynate has joined #ocaml
marynate has quit [Max SendQ exceeded]
marynate has joined #ocaml
marynate has quit [Max SendQ exceeded]
matason has quit [Ping timeout: 272 seconds]
marynate has joined #ocaml
larhat has joined #ocaml
chambart has joined #ocaml
manud___ has joined #ocaml
keen____________ has joined #ocaml
larhat1 has joined #ocaml
dinosaure1 has joined #ocaml
larhat has quit [Read error: Connection reset by peer]
|jbrown| has joined #ocaml
chris2_ has joined #ocaml
mcc has joined #ocaml
keen___________ has quit [*.net *.split]
contempt has quit [*.net *.split]
dinosaure has quit [*.net *.split]
vincom2 has quit [*.net *.split]
vincom2 has joined #ocaml
contempt has joined #ocaml
oscar_toro has joined #ocaml
keen___________0 has joined #ocaml
keen____________ has quit [Ping timeout: 264 seconds]
maufred has quit [Ping timeout: 264 seconds]
milosn has quit [Ping timeout: 258 seconds]
<mcc> Hellos
<mcc> Can anyone help me make sense of this error? I think I am using "match" wrong. http://pastie.org/9775792
<mcc> Basically, I have a list, I have special knowledge of the number of members the list has. I want to break out the members into variables like I'm just doing a python a, b = list
maufred has joined #ocaml
<rgrinberg> mcc: i think you mean [a; b]
<ggole> mcc: , instead of ;, I think
<mcc> aaa yes ok cool
<ggole> You can also use function there to make it a bit shorter
<ggole> (But that's not really important.)
<MercurialAlchemi> the ; vs , still trips me sometimes
oscar_toro has quit [Ping timeout: 240 seconds]
thomasga has joined #ocaml
<mcc> ggole: how so?
<def`> fun l -> match l with <branches>
<def`> is equivalent to
<def`> function <branches>
<def`> (assuming l is not a free variable of <branches>)
<ggole> ^
myyst has joined #ocaml
<ggole> Ooh, modular implicits creep ever closer
<MercurialAlchemi> ggole: where? where?
<MercurialAlchemi> ggole: or rather where? when?
arj has joined #ocaml
mcc has quit [Quit: This computer has gone to sleep]
<ggole> Dunno about when, although apparently there's an opam switch you can try out.
Kakadu has joined #ocaml
<MercurialAlchemi> I know about the switch, yes
matason has joined #ocaml
chris2_ is now known as chris2
Yoric has joined #ocaml
matason has quit [Quit: leaving]
matason has joined #ocaml
Denommus has quit [Quit: ZNC - http://znc.in]
Denommus has joined #ocaml
ollehar has joined #ocaml
oscar_toro has joined #ocaml
milosn has joined #ocaml
Yoric has quit [Remote host closed the connection]
Yoric has joined #ocaml
Yoric has quit [Ping timeout: 260 seconds]
lordkryss has joined #ocaml
Simn has joined #ocaml
manud___ has quit [Quit: Be back later ...]
oscar_toro has quit [Ping timeout: 250 seconds]
matason has quit [Ping timeout: 244 seconds]
<companion_cube> rgrinberg: I never remember: "external" iterators are sequence?
<rgrinberg> external is gen
<rgrinberg> their state is managed externally - e.g. the caller
<companion_cube> ok
<companion_cube> they are more powerful than sequence
<rgrinberg> goto is even more powerful
<companion_cube> goto? not really
<rgrinberg> anyway i meant that it's not what we should measure
<rgrinberg> imo they are easily misused and awkward to write in ocaml
oscar_toro has joined #ocaml
oscar_toro has quit [Ping timeout: 244 seconds]
rgrinberg has quit [Quit: Leaving.]
chambart has quit [Ping timeout: 244 seconds]
ygrek has quit [Ping timeout: 250 seconds]
dsheets has joined #ocaml
larhat1 has quit [Read error: Connection reset by peer]
larhat has joined #ocaml
Yoric has joined #ocaml
oscar_toro has joined #ocaml
davine has joined #ocaml
davine has left #ocaml [#ocaml]
thorsten` has quit [Ping timeout: 265 seconds]
Yoric has quit [Remote host closed the connection]
matason has joined #ocaml
<companion_cube> external iterators aren't more complicated in OCaml than in, say, java
chinglish has joined #ocaml
<companion_cube> ok, you need small internal state machines (but you should check BatEnum to see what complicated iterators are)
thorsten` has joined #ocaml
hugomg has joined #ocaml
emery has quit [Remote host closed the connection]
gdsfh1 has quit [Ping timeout: 265 seconds]
emery has joined #ocaml
Yoric has joined #ocaml
gdsfh has joined #ocaml
ddosia has joined #ocaml
<nicoo> companion_cube: rgrinberg isn't here anymore
tane has joined #ocaml
psy_ has quit [Remote host closed the connection]
nojb has joined #ocaml
Denommus has quit [Ping timeout: 256 seconds]
Denommus has joined #ocaml
Hannibal_Smith has joined #ocaml
oscar_toro has quit [Ping timeout: 264 seconds]
mehdi___ has joined #ocaml
jgjl has joined #ocaml
BitPuffin has joined #ocaml
jonludlam has joined #ocaml
Thooms has joined #ocaml
nojb has quit [Quit: nojb]
<companion_cube> awww
Yoric has quit [Remote host closed the connection]
badon has quit [Ping timeout: 245 seconds]
tane has quit [Quit: Verlassend]
matason has quit [Ping timeout: 244 seconds]
ebzzry has quit [Remote host closed the connection]
BitPuffin has quit [Read error: Connection reset by peer]
BitPuffin has joined #ocaml
badon has joined #ocaml
marynate has quit [Ping timeout: 244 seconds]
Denommus has quit [Max SendQ exceeded]
tom39291 has left #ocaml [#ocaml]
Denommus has joined #ocaml
<companion_cube> http://vrac.cedeela.fr/foo2.html <--- Drup: a way to represent fields
<companion_cube> (first class modules...)
struktured has quit [Ping timeout: 258 seconds]
tane has joined #ocaml
|jbrown| has quit [Remote host closed the connection]
Denommus has quit [Quit: ZNC - http://znc.in]
Denommus has joined #ocaml
psy_ has joined #ocaml
Denommus has quit [Ping timeout: 260 seconds]
Denommus has joined #ocaml
travisbrady has joined #ocaml
struktured has joined #ocaml
rand000 has joined #ocaml
antinomy has joined #ocaml
WraithM has joined #ocaml
struktured has quit [Ping timeout: 258 seconds]
ingsoc has joined #ocaml
myyst has quit [Read error: Connection reset by peer]
milosn has quit [Ping timeout: 256 seconds]
Haudegen has quit [Read error: Connection reset by peer]
dsheets has quit [Quit: Leaving]
dsheets has joined #ocaml
avsm has joined #ocaml
ygrek has joined #ocaml
myyst has joined #ocaml
arj has quit [Quit: Leaving.]
marynate has joined #ocaml
darkf has quit [Quit: Leaving]
slash^ has joined #ocaml
Haudegen has joined #ocaml
shinnya has joined #ocaml
mauborgne has quit [Quit: Page closed]
Simn has quit [Ping timeout: 260 seconds]
ontologiae has joined #ocaml
samuel02 has joined #ocaml
Simn has joined #ocaml
jao has joined #ocaml
jao has quit [Changing host]
jao has joined #ocaml
psy_ has quit [Read error: Connection timed out]
<whitequark> Drup: ARGH
<whitequark> i TOLD you it was deprecated
<whitequark> thank you for making me do more work.
<companion_cube> lwt.text was deprecated in the end?
<whitequark> yes, Jerome said so
avsm has quit [Quit: Leaving.]
ollehar has quit [Ping timeout: 245 seconds]
badkins has joined #ocaml
<companion_cube> I see.
Denommus has quit [Quit: ZNC - http://znc.in]
Denommus has joined #ocaml
Thooms has quit [Quit: WeeChat 1.0.1]
seanmcl has joined #ocaml
<companion_cube> hmmm, no-alias-dep is weird
milosn has joined #ocaml
nojb has joined #ocaml
nojb has quit [Client Quit]
ebzzry has joined #ocaml
nojb has joined #ocaml
badkins has quit [Read error: Connection reset by peer]
travisbrady has quit [Quit: travisbrady]
badkins has joined #ocaml
arj has joined #ocaml
jgjl has quit [Quit: Textual IRC Client: www.textualapp.com]
nojb has quit [Quit: nojb]
myyst has quit [Read error: Connection reset by peer]
ia0 has quit [Quit: leaving]
ia0 has joined #ocaml
myyst has joined #ocaml
Yoric has joined #ocaml
<Drup> whitequark: it's still not marked in the right places !
<whitequark> hm?
<whitequark> I don't know what you want from me.
arj has quit [Quit: Leaving.]
<Drup> My point was that, as opposed to other libraries you removed, it was not clear than lwt.text was deprecated. Proof: I managed to convince you it was not.
<Drup> (and there is no replacement)
<Drup> If jerome consider that we can remove it, why not, but I disagree x)
<whitequark> you didn't convince me
<whitequark> I was tired of a PR dragging on for two months and requiring more and more work with every day
samuel02 has quit [Remote host closed the connection]
<Drup> Sorry for wanting not to drop libraries arbitrarily >_>
<whitequark> yes. yes, you should be.
<Drup> Or not.
<companion_cube> Drup: the question is, why did Jérome deprecate lwt.text ?
<Drup> I have no idea.
<companion_cube> wow, latin1 again...
<companion_cube> why is latin1 not deprecated in the compiler, I can't understand
jao has quit [Ping timeout: 260 seconds]
<Drup> latin1 in identifiers is already deprecated
<Drup> (and raise a warning)
<whitequark> companion_cube: wait a bit, I need to boil my oil
<companion_cube> ah, neat.
<companion_cube> now we must sneak some utf8 validation function in the compiler so that unicode string literals are accepted
<companion_cube> (I mean, so that the semantics of string literals is utf8)
* whitequark sighs
<Drup> I don't agree =')
oscar_toro has joined #ocaml
<companion_cube> why not?
<Drup> companion_cube: we will have UChar in the stdlib, apparently
<companion_cube> that's a good step towards this end
<whitequark> needs UString
<companion_cube> is it because Damien agreed?
<Drup> yeah
<companion_cube> type UString = private String
<companion_cube> -capitalization
<companion_cube> would be nice actually
fraggle-boate has joined #ocaml
<Drup> not really
<Drup> I agree with bunzli on this one, it's fine outside of the compiler.
<whitequark> it's not
<Drup> (and yes, I know your issue whitequark about non-ascii identifiers in ocaml files)
<whitequark> not only the compiler itself should handle utf properly, not only stdlib should have common structures for thus, but also there should be unicode identifiers
<whitequark> bunzli's claim that it is too hard is FUD
<Drup> my opposition is different.
<whitequark> oh?
<Drup> having seen how unicode identifiers is used in Scala/Haskell/Agda, I just think it's a "bad idea"™
<whitequark> it's not about math symbols
<Drup> I know
<Drup> but it will become about it
<whitequark> which aren't even necessarily valid
<Drup> and people will start using it like that
<whitequark> people already use point-free style *shrug*
<Drup> not that much in OCaml
<Drup> and really, it's just one order of magnitude more terrible
<whitequark> what makes you think math symbols will gain more following?
<Drup> because I would use them, even if I know it's a bad idea ecosystem-wise x)
<Drup> I mean, individually, utf8 names are always a good idea
<Drup> "yeah, this utf8 symbol is exactly the right symbol for my thing"
<Drup> The problem is at the ecosystem level
<Drup> everything becomes a fucking mess of utf8
<jerith> Non-ASCII characters are not always easy to type for everyone.
<whitequark> s/utf8/core/
<jerith> So I'm not going to be happy using a library that requires me to do so.
<Drup> and when you look at a library and it uses this very fancy and appropriate utf8 chars in a function name, yeah, great, you have to go to the documentation and copy paste.
<MercurialAlchemi> having seen code with a mix of French and English identifier, I don't think that encouraging people to use anything else than English in a program (outside of strings) is a good idea
<MercurialAlchemi> being able to have utf-8 symbols in strings, on the other hand, is an excellent idea
badkins has quit [Read error: Connection reset by peer]
<Drup> MercurialAlchemi: I tend to agree, but apparently, it's a delicate topic.
<jerith> Language is a different thing entirely. I can type German and Italian and French fine (as long as they don't use accented characters) even if I don't understand the words.
<Drup> jerith: you do realize that french minus accents is ascii ? :D
<whitequark> MercurialAlchemi: "hi, i know english, the language of the people who fucked most of the world in the ass! also i think your culture is irrelevant and you should forget even the idea of using it in something that permeates your daily live now"
<Hannibal_Smith> Drup, same for italian
<Drup> (delicate as in, whitequark start spiting at you)
<jerith> Drup: Yes, I deliberately used those languages rather than Japanese and Amharic. :-)
<Drup> but ß :p
<ggole> Let's have emoji-only identifiers, problem solved
<Drup> ggole: ☺
chinglish has quit [Quit: Nettalk6 - www.ntalk.de]
chinglish has joined #ocaml
<whitequark> like, there are many arguments for and against utf-8 identifiers, good or not. the best ones include the fact that multiple similar scripts can be confusing
thomasga has quit [Quit: Leaving.]
<whitequark> but "I don't like it, therefore everyone else also doesn't get it" is quite possibly the worst one you can come up with
<Drup> that's not what I said
<jerith> If you decide that ⋸ is the perfect way to spell an operator, I'm going to really struggle to use it.
<ggole> I don't think the "this is hard to type" is much of an argument
<whitequark> jerith: don't use the library; problem solved
<jerith> There aren't any buttons on my keyboard for that.
<ggole> If a library is hard to use, just don't use it.
<whitequark> for library authors: provide english aliases
<jerith> whitequark: Yes, that's my point.
<ggole> Just as if it's poorly written.
<whitequark> what ggole said.
<jerith> Sorry, I didn't actually make my point.
chinglish has quit [Client Quit]
<Drup> whitequark: I never said that I didn't like it, I said it was a bad idea, ecosystem wise, which is quite different
<jerith> My point is that libraries that use non-ASCII characters in ways that make it hard for people to use them won't be used very much.
<Drup> I actually like it, from a down-to-the-code point of view
<whitequark> Drup: it wasn't a response to you actually
<Drup> ok
<Drup> it was not obvious.
<jerith> I think supporting non-ASCII identifiers and such is a good thing.
<whitequark> the argument for not using mathy utf-8 stuff is not that bad
<whitequark> again, ecosystem-wise, not language-wise
<tobiasBora> Hello !
<Drup> whitequark: the issue is that mathy stuff is not completely disjoint from language stuff
<Drup> see ø
<whitequark> O.o
<whitequark> that's not an empty set, that's a letter
<Drup> yes, my point.
<jerith> Drup: Is that a mathematical symbol or a Swedish letter?
<whitequark> um
<whitequark> and?
<Drup> you can't say "only language stuff, not mathy stuff"
<tobiasBora> Do you know if it's possible to create/remove a SQL table in Ocaml (I tried to look at Macaque but I don't see this function...)
MrScout has joined #ocaml
<Drup> since the two are loosely mixed
<adrien> main reason to forbid unicode is to prevent the birth of ocaml-apl
<whitequark> Drup: actually, yes, you can
<Drup> really ?
thomasga has joined #ocaml
<Drup> whitequark: it goes without saying that you wouldn't modify the authorized chars for operators, of course ? :D
<whitequark> ∅ is U+2205 in general category Sm. ø is U+00F8 in general category Ll
<whitequark> U+2205 is neither ID_Start nor ID_Continue, actually.
<jerith> Anyway, I don't really like the idea of aliasing things.
<whitequark> Drup: for many reasons, mainly because of priorities
<Drup> You assume people will not use one for the other, which I'm afraid they would x)
<whitequark> Drup: well, they could for several decades now
<whitequark> ø is valid OCaml identifier right now
<Drup> O_o
<whitequark> is there any code using it for an empty set?
<whitequark> yes, yes it is
<jerith> Multiple different spellings for the same thing makes code hard to understand.
Denommus has quit [Quit: ZNC - http://znc.in]
<ggole> Warning 3: deprecated: ISO-Latin1 characters in identifiers
<Drup> whitequark: not in my top level
<Drup> it errors
<whitequark> Drup: camlp4 I think
<ggole> In source, too
<Drup> no camlp4
<whitequark> oh, right
<Drup> it warns then error
<whitequark> the source needs to be in latin-1
<Drup> Oh.
<whitequark> which is to say, for most of ocaml life, the default encoding in west WAS latin-1
<whitequark> and still no one used it.
<whitequark> utf-8 got 50% in the web in what, 2006?
<Drup> whitequark: maybe I'm just pessimistic about encoding x)
<Drup> (but really, the scala and haskell community are terrifying, from this point of view)
<ggole> They do horrific things even with ascii.
<whitequark> haskell community is terrifying even without utf8
<whitequark> exactly
<Drup> Agda is even worse, but nobody cares about the ecosystem in Agda, so it's not important
<companion_cube> < ggole> Let's have emoji-only identifiers, problem solved <--- ♥
<Drup> (in agda, x+y=y+x is a valid identifier, and is commonly use for, let's say, the proof that addition is commutative.)
<Drup> (it's glorious)
<ggole> Anybody for unicode prolog? ✂ would be super readable.
<companion_cube> :D
<companion_cube> ggole: you're the devil
<Drup> ggole: ♥
<whitequark> Drup: holy crap
<companion_cube> I'm not sure whether unicode identifiers would be a good idea; however having utf8 string literals definitely is
<Drup> whitequark: I told you, it's glorious
<Drup> whitequark: you combine that with the fact that they have mixins
<Drup> so they can define, in the language, multi-word constructors like if _ then _ else _
<Drup> you end up with something crazy
q66 has joined #ocaml
<ggole> Reminds me of lisp a bit.
<Drup> (I rather like mixins isolated)
<ggole> |This is a valid lisp identifier.|
<Drup> ggole: I rather like the fact that you can have "?" inside an identifier
<ggole> I think it's less problematic there, though
<Drup> "empty?" is nice :)
<ggole> Yeah
<ggole> Earmuffs a bit less nice.
<Drup> earmuffs ?
<ggole> When you mark a special variable by surrounding it with *
<ggole> *current-open-file*
<Drup> what is it for ?
<ggole> It's a convention to make uses of dynamic scope more apparent.
<Drup> I see.
<dmbaturin> Drup: ♥ suffix could be used to indicate a side-effect free function in an otherwise imperative language.
<companion_cube> val print♥ : Format.formatter → t -> unit
<whitequark> no no
<whitequark> val print♥ : Format.formatter → ♥ → unit
<Hannibal_Smith> ♥ strong
<companion_cube> let rec gen♥ () = Some "♥"
tharugrim has quit [Ping timeout: 250 seconds]
<ggole> let ↻ f x y = f y x
tharugrim has joined #ocaml
<ggole> Gc.♻
<ggole> The possibilities are endless.
<companion_cube> nice
MrScout has quit [Remote host closed the connection]
MrScout has joined #ocaml
rgrinberg has joined #ocaml
MrScout has quit [Remote host closed the connection]
MrScout has joined #ocaml
rgrinberg has quit [Client Quit]
jonludlam has quit [Quit: Coyote finally caught me]
samuel02 has joined #ocaml
<Drup> what have I done.
axiles has quit [Ping timeout: 264 seconds]
marynate has quit [Quit: Leaving]
<Hannibal_Smith> Thinking about it, one can even introduce ∧, ∨ without shortcircuit so real logic connectives
ygrek has quit [Ping timeout: 245 seconds]
<Hannibal_Smith> I'm unsure how a language can change with this things
mcc has joined #ocaml
rgrinberg has joined #ocaml
<mcc> Hi so... I am in a situation. I have sprinkled my code with internalFail() calls that calls a failWith "message".
mcclurmc has joined #ocaml
<Drup> that was a remarkably bad idea.
<mcc> I now find the program failing with Fatal error: exception Failure("message"), and I don't know which internalFail call it's failing on.
<Drup> s/k/c/
<ggole> mcc: this is a very familiar complaint
<mcc> well, i think you know what's coming
<mcc> but i basically just want to know where the exception was thrown from
<Drup> mcc: run your program with "OCAMLPARAM=b", it will help
<ggole> You could try compiling everything under the bytecode compiler with -g, and then run that to get a backtrace.
<mcc> and it looks like… there's two ways to do it?
<mcc> or three?
<whitequark> two ways?
<Drup> ggole: no need for bytecode, no ?
<ggole> Did that change?
travisbrady has joined #ocaml
<mcc> the two ways i can think of are OCAMLPARAM=b and bytecode + ocamldebug, which stackoverflow suggested, and somehow get a __PRETTY_FUNCTION__ or something that i pass into internalFail each time
<ggole> __LOC__
<Drup> mcc: just do OCAMLPARAM=b and see if it solves your issue
<Drup> or at least, gives you a backtrace
<Drup> most of the time, it will
<mcc> actually, it did nothing. i don't have to compile special do I? I'm using ocamlopt.
<Drup> you have to compile with -g
<mcc> ok
<ggole> You have to compile with debugging on, that is, -g
<Drup> but most sane build systems do it by default =')
<mcc> and uh i could probably figure this out on my own, but if i'm compiling with ocamlbuild...?
<mcc> flag -g
<ggole> -cflag -g
<mcc> cool
<mcc> oh! when i invoke ocamlbuild
<mcc> i thought i would have to modify _tags.
<ggole> You might need -lflag -g as well, can't recall
<Drup> you could also say "true: debug" in your _tags
<Drup> which may be easier, in the end
ygrek has joined #ocaml
nojb has joined #ocaml
<mcc> Yeah, nothing. You're sure this works with ocamlopt?
axiles has joined #ocaml
<Drup> yes
<Drup> you cleaned and all that before ?
<mcc> good question, but yes.
<ggole> How are you invoking ocamlbuild?
<Drup> and you have OCAMLRUNPARAM=b in the env where you are executing the program ?
samuel02 has quit [Ping timeout: 245 seconds]
chambart has joined #ocaml
<Drup> hum
<Drup> let me check if it's with RUN or without, I have a doubt
<mcc> oh. ha!
<Drup> yes, it's "OCAMLRUNPARAM"
<mcc> no, i don't have RUNPARAM.
<mcc> i have PARAM.
<mcc> nice!
<whitequark> I second "true: debug"
<ggole> Wish backtraces worked in the toplevel.
<whitequark> also, note you can build debug versions by changing the name
<whitequark> i.e. ocamlbuild foo.d.byte vs foo.byte
* ggole mumbles something about slime for ocaml again
<whitequark> also, note that backtraces of ocamlopt often appear incomplete due to inlining (it's optimizing, after all)
<Drup> whitequark: are there any reason not to put debug on by default for everyone and be done with it
<whitequark> I usually run bytecode versions of the programs I want to debug.
* pippijn slimes all over ggole
<whitequark> Drup: I wonder how much does it slow down the compiler
<pippijn> whitequark: I usually pass -inline 0 to programs I want to debug
remyzorg_ has joined #ocaml
remyzorg_ has quit [Client Quit]
* ggole finds all users of pippijn and deletes them
<pippijn> whitequark: because I like gdb
<mcc> yes, it is incomplete.
<mcc> maybe i will just use the __LOC__ thing.
<companion_cube> whitequark: your proposal for unicode identifiers would require unicode capitalization in the compiler?
<Drup> mcc: "assert false" would be pretty much equivalent ;)
<whitequark> companion_cube: obviously.
<mcc> drup: that will emebd __LOC__, it is a macro or something?
<whitequark> but it, by itself, is not a significant addition, as I already need unicode tables for other things.
<Drup> it's not a macro, and it will report the precise line
<ggole> assert false will give you source locations
<mcc> oh so THAT'S what whitequark has been tweeting about
<mcc> ggole: ok cool
<ggole> Although it won't say what's wrong, so consider a comment beside it
<Drup> mcc: beware that assert false is for things that should never happen because of things you can't encode in the type system
<Drup> it's not for error reporting
<Drup> use custom exceptions instead, it's much better.
<ggole> Yeah, users should not see assert false firing
<rgrinberg> or at least failwith "xxx"
<ggole> But for development I think it's ok
<companion_cube> whitequark: I think the chances for this to be merged is low :/
<Drup> (I think everytime you use failwith, you should use a custom exception instead, but that's just my opinion)
<rgrinberg> Drup: indeed but it's still better than misusing assert false
<Drup> yeah
<Drup> rgrinberg: I looked into iteratees
<Drup> it look indeed powerful, and a huge pain in the ass to use
<rgrinberg> yeah, for what it's worth the haskell guys figured that out as well
<rgrinberg> after a few years
<MercurialAlchemi> Drup: that's mine too
<MercurialAlchemi> well, except for quick and dirty things
<rgrinberg> the API is subpar but has been generalized and improved
<Drup> rgrinberg: well, I looked at the API defined by the main iteratee library in haskell
<Drup> and it doesn't look "figured out"
<Drup> the API is extremly complicated
<rgrinberg> which library is that?
<MercurialAlchemi> Drup: did you look at pipes?
<Drup> hum, "iteratee"
<rgrinberg> yes, "pipes" is the spiritual and functional successor to iteratees
<rgrinberg> with many intermediate forms along the way :D
<MercurialAlchemi> yeah, last time I looked the API was still busy evolving
<Drup> (also, I'm a bit wary of things "the haskell community figured out")
<Drup> (/me look at lenses)
<MercurialAlchemi> still beats ASCII-art conduits, if you ask me
<rgrinberg> Drup: me too, b/c the solution isn't ideal for ocaml
<Drup> that, and also because they tend to make thing widly overcomplicated
<rgrinberg> that too
<rgrinberg> :D
<MercurialAlchemi> the 'lens' package is indeed interesting
<rgrinberg> iteratees have been implemented in ocaml as well btw
<MercurialAlchemi> but you have other simpler lens packages
<Drup> rgrinberg: I couldn't find a package
<Drup> do you have a source ?
<ggole> Drup: cmon, don't you love those 7-argument type constructors?
<rgrinberg> i don't have much interest in oleg's traditional iteratees anymore however
<Drup> rgrinberg: as opposed to ?
<rgrinberg> pipes :)
<Drup> I mean, you linked them as "fold are powerful enough", so ... :D
<rgrinberg> as awkward as they may seem
<companion_cube> http://vrac.cedeela.fr/foo.html rgrinberg
<companion_cube> speaking about lenses/fields
<rgrinberg> ggole: you may not need the 7th parameter for an ocaml pipe. No need for specifying the effect with a monad
<rgrinberg> no?
<MercurialAlchemi> there is 'streams' too
Kakadu has quit [Quit: Page closed]
<Drup> MercurialAlchemi: streams are the start of the discussion, and what rgrinberg said was crap :p
<MercurialAlchemi> Drup: Haskell streams or OCaml streams?
<companion_cube> ↑ I meant this
<rgrinberg> they're not crap. more like better in small doses :D
<Drup> rgrinberg: you said it was terrible and should not be used ever :D
<Drup> rgrinberg: link to an understandable presentation of pipes ?
<Drup> rgrinberg: (and a short description of how it's better than iteratees)
<rgrinberg> the last one is easy to answer
<rgrinberg> you have 1 type rather than 3
<MercurialAlchemi> rgrinberg: you mean https://hackage.haskell.org/package/io-streams, right?
<mcc> drup / ggole: at the moment this is only for things a user should never see-- i'm frankly surprised i saw one myself
<rgrinberg> MercurialAlchemi: hmm no, i have no problems against io-streams
<Drup> whitequark: ahah, I was expecting that
<whitequark> Drup: expecting what?
<rgrinberg> companion_cube: why do you need the module encoding?
<MercurialAlchemi> it's probably my fault, I mis-remembered the name of the package
<companion_cube> it's a nice way to have a structural type
<companion_cube> I have an alternative presentation using tuples
<MercurialAlchemi> I like the "fuck it, let's do everything in the IO monad" thing
<Drup> whitequark: the custom ocaml frontend
<rgrinberg> MercurialAlchemi: indeed. I've contributed a little to io-streams
<rgrinberg> its' very nice
<Drup> oh, it's not exactly how you do it
<rgrinberg> MercurialAlchemi: even have an ocaml port lying around. Although there's little point to it i think
<rgrinberg> apart from the pushack
<rgrinberg> pushback
<rgrinberg> Drup: trying to find you my most readable reference for pipes
<rgrinberg> not easy :D
<Drup> ahah
<Drup> I tend to think that concepts you can't explain simply are bad concepts :>
<rgrinberg> Drup: you can explain pipes simply with code i think
<rgrinberg> :D
<Drup> that's fine, show me
<rgrinberg> best material i've found
<rgrinberg> a bit oddly presented though
martintrojer has quit [Ping timeout: 264 seconds]
citrucel has joined #ocaml
badkins has joined #ocaml
martintrojer has joined #ocaml
<rgrinberg> whitequark: you forgot to add a disclaimer to m17n
<rgrinberg> to never ever use it that is
<Drup> x)
<def`> :D
BitPuffin has quit [Ping timeout: 256 seconds]
emias has quit [Ping timeout: 250 seconds]
<whitequark> rgrinberg: nope
<whitequark> rgrinberg: actually, I added a disclaimer, F5 it.
<rgrinberg> lol
jwatzman|work has joined #ocaml
<rgrinberg> anyway, kudos for attempting to wipe out the latin1 at least
<companion_cube> whitequark: do you intend to use Uutf/Uucd?
mcc has quit [Quit: This computer has gone to sleep]
ontologiae_ has joined #ocaml
<Drup> rgrinberg: 6 one-letters parameters
<Drup> . . .
<MercurialAlchemi> Drup: patience
<MercurialAlchemi> soon to be replaced by 6 one-unicode letter parameters
<whitequark> companion_cube: I already did
<companion_cube> I meant in your PR
* MercurialAlchemi shoots latin1 in the head
<companion_cube> i didn't see unicode per se
ontologiae has quit [Ping timeout: 256 seconds]
<whitequark> companion_cube: the PR does not include unicode
<whitequark> I'm going to wait until maintainers say something before shoehorning bunzli's libraries into the compiler
<Drup> assuming they want utf8 in the compiler
<rgrinberg> Drup: it's ok, soon we'll have rust to copy abstractions from
<rgrinberg> ;D
<companion_cube> rust provides external iterators :p
<Drup> rgrinberg: their iterators are great
<companion_cube> because they are safe, with lifetimes
<Drup> but they use linear typing heavily
<Drup> can't copy that :(
<rgrinberg> agreed
<companion_cube> that's the point of linear typing
<MercurialAlchemi> companion_cube: don't they make for 'interesting' signatures, though?
<rgrinberg> we should copy their crate system :(
<companion_cube> MercurialAlchemi: well, signatures are sprinkled with lifetimes
<companion_cube> but it's still nice
AlexRussia has quit [Ping timeout: 258 seconds]
<Drup> rgrinberg: did you took a look at the namespace proposal ?
<rgrinberg> Drup: rust's? no.
<Drup> no, OCP's :p
<rgrinberg> where is it?
<Drup> hum, it's on various places
<Drup> there was a presentation in english at icfp
<rgrinberg> is it anywhere in writing?
MrScout_ has joined #ocaml
<rgrinberg> preferrably accessable via hyperlink
<rgrinberg> :D
<rgrinberg> awesome
<rgrinberg> thanks
<chambart> And in french on the irill website: http://www.irill.org/videos/oups-december-2014/Namespace
<rgrinberg> btw, why the fuck are the world's ruby/node/python web devs jumping onto rust?
<Drup> rgrinberg: they are ?
<rgrinberg> what good could manual memory management could there. use ocaml ffs
<Drup> My impression is that they were jumping on Go
<Drup> because obviously Go is a fantastic dynamicaly typed language.
<rgrinberg> either go or rust
<whitequark> Drup: we'll see if they do
<rgrinberg> one is the wrong tool for the job, the other is the wrong tool period
<whitequark> Drup: it's interesting how windows support *already* pulls in some utf-8 into the compiler
<def`> Charybde & Scylla :P
<whitequark> Drup: they are, somehow
<whitequark> I don't understand it, but they do
<Drup> rgrinberg: typical bandwagon behavior ?
ingsoc has quit [Quit: Leaving.]
MrScout has quit [Ping timeout: 258 seconds]
<def`> whitequark: funny, what do you mean?
<rgrinberg> Drup: yes but why can't that wind ever blow in our direction :/
<Drup> rgrinberg: I would like that too
<rgrinberg> i blame makefiles and not being able to printf debug :/
MrScout_ has quit [Ping timeout: 258 seconds]
<whitequark> def`: by which exactly?
<Drup> however, it the community were to grow spectacularly in the next few years, the core team and the current developement model of the compiler would explode, though.
<whitequark> it already creaks imo
<Drup> (I will not say if I think it's a good or bad thing)
<def`> whitequark: pulling in utf8
<whitequark> def`: widechar paths
<whitequark> currently you get garbage for unicode in paths
<Drup> whitequark: agreed, but ...
<companion_cube> rgrinberg: do you really want node.js developers to invade our nice OCaml community? :p
<rgrinberg> companion_cube: it will be easy to clean up their mess with ocamlc on your side
<whitequark> Drup: I have some interesting ideas for the ocaml development that address, for example
<whitequark> the concern behind putting uutf inside ocamlc
<Drup> the issue is not about having interesting ideas
<whitequark> I'm sure they will never be implemented though due to extreme inertia
<def`> right, widechars… I didn't look how this is implemented
<whitequark> def`: PR3771
<whitequark> it's not lol
<whitequark> it uses ASCII functions, which return the data in local codepage
<Hannibal_Smith> rgrinberg> btw, why the fuck are the world's ruby/node/python web devs jumping onto rust? <-They hope to be called system programmers, but without the necessary knowloadge. So they belive that all they needs is learning another language, who will for sure kill C++
<whitequark> meh
<Drup> rgrinberg: ok, saw the presentation, link to a clean pipes implementation now ?
<Hannibal_Smith> And there was a "terrorism" about the use of dynamic languages, OOP and so
<companion_cube> are they going to add dynamic types to rust? :(((
<whitequark> wat
<whitequark> and wat
<ggole> Yeah, you've lost me there.
<whitequark> rust won't probably even have a gc
<rgrinberg> Drup: do you think the core team is hopeless?
<Drup> I didn't say that
<Hannibal_Smith> whitequark, not by Rust team, but in the "brogrammer" community
ygrek has quit [Ping timeout: 255 seconds]
<whitequark> wat
<Drup> rgrinberg: I don't know what means "hopeless" in this context
<Hannibal_Smith> whitequark, it's good to hear that some discussion are not really so widespread
<rgrinberg> Drup: i mean "cannot improve"
<Drup> rgrinberg: they improved already
<Drup> just ... not fast
<rgrinberg> did the janestreet money showers help?
<Drup> you could say that, in the fact that it created ocamllabs and finance half of ocaml-pro :D
<companion_cube> I'd like the compiler to be maintained by the community or ocamllabs
<Drup> companion_cube: I don't agree with either
<ggole> Hmm, tail calls in a trace compiler are really easy.
<companion_cube> but my biggest fear would be to see it controlled by JST :(
<ggole> I thought there would be some evil trick necessary, but no.
<whitequark> Drup: I don't agree with the compiler maintained by a few people in their unpaid time
<whitequark> *anything* is better than that
<Drup> what I would rather like is nobody having a veto right to say "no" for compiler inclusions, and the current mindset of "external contributions are always crap" to change.
<Drup> whitequark: yeah, sure
<rgrinberg> whitequark: yes b/c in practice that's the same as not maintaining at all
<rgrinberg> in the long run at least
<whitequark> Drup: wanna fork ocamlc
<whitequark> :]
larhat has quit [Quit: Leaving.]
<Drup> whitequark: No.
<whitequark> (it wasn't a serious suggestion)
<companion_cube> :D
<ggole> "I'm gonna make my own ML, with bl... never mind."
<companion_cube> whitequark: wanna fork+exec ocamlopt?
<rgrinberg> the movement towards making the core smaller was good though
<rgrinberg> whatever happened to kicking out ocamlbuild :(
<whitequark> I'm thinking you can make a "community edition" of the compiler, using compiler-libs and such, with opam
<whitequark> so you would technically have the same compiler, but you will also be able to have things like Uutf in the stdlib
<Drup> whitequark: yeah, you could do that, and it's a terrible idea
<whitequark> ruby did that after years of struggling with an enormous stdlib
rgrinberg has quit [Read error: Connection reset by peer]
<whitequark> rust, hmmm, not sure what they do *now*, might want to check it
rgrinberg1 has joined #ocaml
<Drup> I mean, the stdlib issue is not an issue anymore
<companion_cube> it is, but it matters less
<whitequark> of course it is, there are still people disliking *ocamlfind*
<Drup> there is a lot to dislike in ocamlfind
<rgrinberg1> *me*
<Drup> I don't care if they dislike it, as long as they use it
<companion_cube> ocamlfind > no ocamlfind
<rgrinberg1> why does it need to exist?
<rgrinberg1> imo opam should subsume it
<whitequark> opam?!
<whitequark> how the hell is it related to opam at all
<whitequark> the compiler should, of course
<rgrinberg1> first of all, opam is open to contributions
<rgrinberg1> second of all, it doesn't use svn or mantis
<whitequark> well, maybe not, rust seems to do well with cargo being separate from rustc
<whitequark> who cares about svn or mantis, really
<whitequark> git svn checkout ...
<Drup> whitequark: what is the issue with opam replacing ocamlfind ?
<whitequark> Drup: 1) no opam on windows
<whitequark> 2) the dependencies become even wider and more entangled
<Drup> ?
<whitequark> ocamlbuild will have to depend on opam now
<Drup> oh, I see
<Drup> ocamlbuild doesn't depend on ocamlfind, so ...
<whitequark> it does for me :]
samuel02 has joined #ocaml
<rgrinberg1> ocamlbuild could use a few dependencies from opam
<Drup> it does not "formally" ;)
<rgrinberg1> like a modern cli interface with cmdliner :D
<Drup> whitequark: (note: with the namespace proposal, ocamlfind becomes mostly useless)
<Armael> when I'm on my university computers, where only the ocaml debian package is installed
<whitequark> namespace proposal?
<Armael> i'm happy to have ocamlbuild
<Armael> and opam is a bit more complicated to deploy for them
<Drup> whitequark: grep namespace earlier
<whitequark> oh
<rgrinberg1> Armael: as unfortunate as your use case imo it should not be the focus
dsheets has quit [Ping timeout: 272 seconds]
<Drup> Armael: let me translate you that in non bullshit adminsys language: "I don't want to do it"
<Armael> install opam?
<Drup> yes
<rgrinberg1> i run opam with user permissions on osx
<rgrinberg1> wtf is the problem again?
<Drup> rgrinberg1: very low quotas in universities for disk space
<whitequark> I'm not sure how I feel about it
<Armael> users have quotas
<Drup> and lazy sysadmin
AlexRussia has joined #ocaml
<whitequark> Drup: the namespace thing
<Armael> why lazy
<Drup> Armael: it's perfectly possible to set up opam for student to use ...
<Armael> given the quotas, i don't know what to do either
<whitequark> it's interesting to see what will happen with it
<Drup> whitequark: It solves several long standing issues
<Drup> like "how do I do when I have part of my libraries that are optionally built"
samuel02 has quit [Ping timeout: 250 seconds]
<whitequark> hmmmmm
<Drup> "how do I improve on a general ecosystem"
<Drup> (for example, everyone contributing to a "Lwt" ecosystem, without to build stuff weirdly)
<Drup> name sutff weirdly*
<whitequark> right
<Drup> it helps eliom a bit, by using a "Client" and a "Server" namespace
<Drup> (that's a bonus)
<Drup> (and it simplify the ocamlfind story, which is a good thing too)
<rgrinberg1> still, obtaining dependencies with opam and using them (under completely different names) with ocamlfind is ass backwards imo
<Drup> that's clearly true
<rgrinberg1> i've seen this reaction a lot from people I've showed ocaml to
<whitequark> namespaces will not help such things like ppx
<Drup> whitequark: actually, it would
<whitequark> how so?
<Drup> not directly, it needs a bit more work
<Drup> whitequark: by using the same design as for rust's macro: you can say "by importing this namespace, you enable the ppx that goes with it". basically what you do with ocamlfind packages currently
<Drup> oh also, it would allows to infer dependencies from sources
<Drup> like, properly.
<whitequark> Drup: that needs a retargetable compiler then...
<Drup> or ocamldep doing it's job
<whitequark> no, for cross-compiling
<Drup> Oh.
<Drup> I'm afraid to say it's out of my area of expertise, I will let that to people who know about it =')
<whitequark> the macro should be executed on the host
<whitequark> the rest, on target
<whitequark> rust uhhhhhh
<whitequark> doesn't deal with it i think
<Drup> don't we have the same issue currently ?
MercurialAlchemi has quit [Remote host closed the connection]
<whitequark> yes, but it can be solved more easily
<Drup> ok
<whitequark> it's just a matter of shuffling METAs the right way
<Drup> well, this time you will shuffle namespace directories the right way ? :D
MercurialAlchemi has joined #ocaml
<whitequark> if you can.
<whitequark> which is not necessarily the case.
<Drup> but sure, it's a good objection, but it doesn't seem undoable
emias has joined #ocaml
Kakadu has joined #ocaml
slash^ has quit [Read error: Connection reset by peer]
<MercurialAlchemi> this namespace thing doesn't look too bad
<Drup> "rgrinberg: ok, saw the presentation, link to a clean pipes implementation now ?"
<MercurialAlchemi> not sure I really understand the last slides though
Anarchos has joined #ocaml
<hugomg> this Str regular expression library is making me pull my hair out. Why does the callback to global_substitute receive the whole string as a parameter instead of only the matched substring?
<MercurialAlchemi> hugomg: Str is terrible
<Drup> hugomg: use Re.
<hugomg> Does Re have that function? I was using Re2 but Ill have to drop it bc it looks loike its not available on windows
<whitequark> yes, it has now
<hugomg> what do you mean by "now"? :)
<whitequark> it was just merged to Re
<whitequark> a few hours ago
<hugomg> does that mean its available via opam/wodi?
<rgrinberg1> you will have to opam pin
badkins has quit [*.net *.split]
axiles has quit [*.net *.split]
waneck has quit [*.net *.split]
srcerer has quit [*.net *.split]
oscar_toro has quit [*.net *.split]
Simn has quit [*.net *.split]
Haudegen has quit [*.net *.split]
chris2 has quit [*.net *.split]
c74d has quit [*.net *.split]
demonimin has quit [*.net *.split]
hannes has quit [*.net *.split]
fraggle_ has quit [*.net *.split]
mfp has quit [*.net *.split]
j0sh_ has quit [*.net *.split]
lu324 has quit [*.net *.split]
andreypopp_ has quit [*.net *.split]
art-w has quit [*.net *.split]
nox has quit [*.net *.split]
bobpoekert has quit [*.net *.split]
jeroud has quit [*.net *.split]
dch has quit [*.net *.split]
abbe has quit [*.net *.split]
antinomy has quit [*.net *.split]
contempt has quit [*.net *.split]
dinosaure1 has quit [*.net *.split]
zozozo has quit [*.net *.split]
msch has quit [*.net *.split]
jcloud has quit [*.net *.split]
dmiles_afk has quit [*.net *.split]
luigy has quit [*.net *.split]
mehdi___ has quit [*.net *.split]
cantstanya has quit [*.net *.split]
thomasga has quit [*.net *.split]
ebzzry has quit [*.net *.split]
shinnya has quit [*.net *.split]
rand000 has quit [*.net *.split]
badon has quit [*.net *.split]
Hannibal_Smith has quit [*.net *.split]
ggole has quit [*.net *.split]
pgas has quit [*.net *.split]
jerith has quit [*.net *.split]
emery has quit [*.net *.split]
nicoo has quit [*.net *.split]
rgrinberg1 has quit [*.net *.split]
martintrojer has quit [*.net *.split]
tharugrim has quit [*.net *.split]
thorsten` has quit [*.net *.split]
Valdo has quit [*.net *.split]
testcocoon has quit [*.net *.split]
wting_ has quit [*.net *.split]
ontologiae_ has quit [*.net *.split]
mcclurmc has quit [*.net *.split]
keen___________0 has quit [*.net *.split]
araujo has quit [*.net *.split]
teiresias has quit [*.net *.split]
segmond has quit [*.net *.split]
wormphle1m has quit [*.net *.split]
rwmjones has quit [*.net *.split]
bjorkintosh has quit [*.net *.split]
gasche has quit [*.net *.split]
bernardofpc has quit [*.net *.split]
vbmithr has quit [*.net *.split]
`micro_ has quit [*.net *.split]
mrvn has quit [*.net *.split]
n0v has quit [*.net *.split]
cthuluh has quit [*.net *.split]
Ptishell has quit [*.net *.split]
Anarchos has quit [*.net *.split]
tane has quit [*.net *.split]
pyon has quit [*.net *.split]
hellome has quit [*.net *.split]
dav has quit [*.net *.split]
PM has quit [*.net *.split]
bugabinga has quit [*.net *.split]
girrig has quit [*.net *.split]
IbnFirnas has quit [*.net *.split]
ohama has quit [*.net *.split]
voglerr has quit [*.net *.split]
sivoais has quit [*.net *.split]
sh1ken has quit [*.net *.split]
ruoso has quit [*.net *.split]
adrien has quit [*.net *.split]
milosn has quit [*.net *.split]
tristero has quit [*.net *.split]
Intensity has quit [*.net *.split]
companion_cube has quit [*.net *.split]
jave has quit [*.net *.split]
pii4 has quit [*.net *.split]
Snark has quit [*.net *.split]
Khady has quit [*.net *.split]
engil has quit [*.net *.split]
jwatzman|work has quit [*.net *.split]
chambart has quit [*.net *.split]
myyst has quit [*.net *.split]
seanmcl has quit [*.net *.split]
libertas has quit [*.net *.split]
kapil__ has quit [*.net *.split]
_JokerDoom has quit [*.net *.split]
_5kg has quit [*.net *.split]
rfv has quit [*.net *.split]
bitbckt has quit [*.net *.split]
mawuli has quit [*.net *.split]
kandu has quit [*.net *.split]
emmanueloga has quit [*.net *.split]
acieroid has quit [*.net *.split]
mekaj has quit [*.net *.split]
rom1504 has quit [*.net *.split]
kerneis_ has quit [*.net *.split]
zapu has quit [*.net *.split]
hcarty has quit [*.net *.split]
seliopou has quit [*.net *.split]
hugomg has quit [*.net *.split]
seangrove has quit [*.net *.split]
brendan has quit [*.net *.split]
relrod has quit [*.net *.split]
mk270 has quit [*.net *.split]
Plazma has quit [*.net *.split]
hsuh has quit [*.net *.split]
SHODAN has quit [*.net *.split]
nickmeharry has quit [*.net *.split]
hnrgrgr has quit [*.net *.split]
alinab has quit [*.net *.split]
eikke has quit [*.net *.split]
nojb has quit [*.net *.split]
lopex has quit [*.net *.split]
bytbox has quit [*.net *.split]
__marius______ has quit [*.net *.split]
Leonidas has quit [*.net *.split]
flux has quit [*.net *.split]
majoh has quit [*.net *.split]
averell has quit [*.net *.split]
ddosia has quit [*.net *.split]
gdsfh has quit [*.net *.split]
lordkryss has quit [*.net *.split]
leifw has quit [*.net *.split]
mearnsh has quit [*.net *.split]
n1ftyn8 has quit [*.net *.split]
myst|work has quit [*.net *.split]
iZsh has quit [*.net *.split]
def` has quit [*.net *.split]
_2can has quit [*.net *.split]
sirssi has quit [*.net *.split]
igitoor has quit [*.net *.split]
tov has quit [*.net *.split]
gperetin has quit [*.net *.split]
Asmadeus has quit [*.net *.split]
Kakadu has quit [*.net *.split]
travisbrady has quit [*.net *.split]
Yoric has quit [*.net *.split]
vincom2 has quit [*.net *.split]
jlouis has quit [*.net *.split]
johnelse has quit [*.net *.split]
maurer has quit [*.net *.split]
so has quit [*.net *.split]
gustav___ has quit [*.net *.split]
reynir has quit [*.net *.split]
tizoc has quit [*.net *.split]
SuperNoeMan has quit [*.net *.split]
fold has quit [*.net *.split]
cross has quit [*.net *.split]
sigjuice has quit [*.net *.split]
mal`` has quit [*.net *.split]
bcuccioli has quit [*.net *.split]
ttm has quit [*.net *.split]
diginux has quit [*.net *.split]
gridaphobe has quit [*.net *.split]
bacam has quit [*.net *.split]
Ptival has quit [*.net *.split]
osheeta has quit [*.net *.split]
Armael has quit [*.net *.split]
stux|away has quit [*.net *.split]
Antoine59 has quit [*.net *.split]
orbitz has quit [*.net *.split]
amiller has quit [*.net *.split]
npouillard has quit [*.net *.split]
pippijn has quit [*.net *.split]
citrucel has quit [*.net *.split]
struk|work has quit [*.net *.split]
emias has quit [*.net *.split]
MercurialAlchemi has quit [*.net *.split]
AlexRussia has quit [*.net *.split]
q66 has quit [*.net *.split]
fraggle-boate has quit [*.net *.split]
ia0 has quit [*.net *.split]
WraithM has quit [*.net *.split]
maufred has quit [*.net *.split]
madroach has quit [*.net *.split]
vpm has quit [*.net *.split]
q66[lap] has quit [*.net *.split]
S11001001 has quit [*.net *.split]
xorpse has quit [*.net *.split]
inr_ has quit [*.net *.split]
burgobianco has quit [*.net *.split]
srax has quit [*.net *.split]
thizanne has quit [*.net *.split]
pollux has quit [*.net *.split]
smondet has quit [*.net *.split]
tobiasBora has quit [*.net *.split]
gargawel has quit [*.net *.split]
xaimus_ has quit [*.net *.split]
binarybitme has quit [*.net *.split]
Drup has quit [*.net *.split]
_whitelogger has joined #ocaml
<Drup> you mean, currently ?
<Drup> we don't have the same definition of "community-maintained" then
<gasche> well
<gasche> we could certainly have more people from the community contributing
<Drup> (or the same definition of "community")
<gasche> (... assuming working on the core distribution is the best way for them to improve the aspect they care about; an assumption which I suspect we tend to over-make)
<gasche> well
<gasche> concretely, which changes would you suggest?
<gasche> (or, in another way, what's your constructive proof that this is far from being the case?)
<whitequark> to get people from community, you need a reasonably quick feedback loop
<gasche> (not saying there are none, but I think discussing the specifics is more interesting)
<whitequark> this is really the only complaint I have
<gasche> but is that related to being "community-maintained"?
<whitequark> there is usually some resistance to new stuff, but it is reasonable to expect from a language from 1996, as opposed to something that's not even 1.0 yet.
<gasche> Batteries is community-maintained and I waited for weeks to get a clear opinion on my bytes-port proposal
<gasche> the problem was a lack of interested workforce at that point in time, not project governance
<whitequark> exactly
<Drup> I agree with whitequark on the quick feedback loop
<whitequark> gasche: I don't say ocamlc is not community-maintained, actually
<gasche> well
<gasche> to help move the discussion forward, I'll propose my own falsity-witness suggestion: the decision process is not always very transparent
<Drup> ahah
<whitequark> personally, I'm comparing ocamlc mainly with rust, as the latter seems to have closest to a perfect community-maintained language
<Drup> it's fun that you say that, considering you have a much better access to most of the core team than other people
<gasche> I do disapprove of this, but on the other hand my personal experience with this is that it's mostly a matter of lack of workforce again
<whitequark> what gasche said, basically.
<Drup> gasche: on the other hand, is the core team really ready to accept more worforce ?
<gasche> why not?
<Drup> It's not like ocaml-pro didn't try.
<gasche> well
<Drup> there *are* people actually being paid to work on the compiler
<gasche> Wojciech, Benedikt, Jérémie and myself were accepted without much fuss
<Drup> not in the core team, and their patch are barely looked at *cough*.
<gasche> there is a bootstrapping issue here (the reviewer bandwith is scarce to start with)
<gasche> and it's one person and two patchsets
chambart has quit [Ping timeout: 258 seconds]
<whitequark> gasche: side note, I was surprised to hear you didn't even heard about expunging
<Drup> Not one, no
<Drup> Also, if you don't review things, stall merges, don't answer people and say in a public presentations "most patches are bad anyway". Yeah, people are not very motivated.
<gasche> which presentation are you thinking of?
<Drup> yours.
<Drup> yes, you said that.
<Drup> (at icfp)
<Drup> (you said it as a joke, I find it particularly shocking, and I'm pretty sure I told you already)
<gasche> I don't think this or remember saying it
<gasche> at an OUPS meeting I said that most feature requests are hard and stressful to evaluate
<gasche> not matter what I may have said, it should be pretty clear that the talk was *not* about discouraging people from participating, on the contrary
<Drup> well, you also highlighted in this talk that you were pretty much the only one to answer on github. It's better since, but it was quite true, and it was a big issue.
WraithM has quit [Quit: leaving]
<Drup> sorry, but no, the talk was not a great way to show how warmly welcoming compiler patch were, pretty much the opposite
nojb has quit [Ping timeout: 265 seconds]
robink has joined #ocaml
<gasche> well
<Drup> (I mean, I really heard someone a few hours later, talking about OCaml "the language seems great but oh my god, the development model, I don't want to work with that".
<gasche> if being transparent about the state of the development workflow as I see it discourages people, what can I do
<whitequark> improve the workflow.
<Drup> ^
<gasche> of course
travisbrady has quit [Quit: travisbrady]
<MercurialAlchemi> Is it that difficult to get more people into the core team?
<Drup> MercurialAlchemi: it's a mind set issue
<gasche> (again I don't think I ever said that most patches are bad; Drup, I think you are misrembering things)
nojb has joined #ocaml
<gasche> I think the best way to improve the workflow is to have more people from the community contributing
<MercurialAlchemi> but didn't you just say there was a reviewer bandwidth issue?
<gasche> yes, so we need more reviewers
<gasche> you can become one
<mrvn> fork, patch, push, repeat, grow
<Drup> said reviewers who don't have the tiny bit of weight on the end decision
<Drup> great
<Drup> I really want to do that, it's very rewarding
<gasche> I don't know why you have this impression, because that's not how it works
<Drup> Can you guess why ? :)
<whitequark> gasche: I don't think there is a problematic lack of reviewers.
<gasche> well
<whitequark> I think there is a problematic lack of people who can decide on what happens to the compiler.
<Drup> exactly
eyyub has joined #ocaml
<whitequark> i.e. you either have time or authority.
<gasche> this is a subset of the reviewers
<whitequark> which you cannot really join easily.
<gasche> it cannot improve without having more reviewers
* mrvn joins time
<Drup> I mean
<mrvn> time can outwait authority
<gasche> I don't see any other way to get authority to make decisions than invest time in contributing without having that authority, as a first step
ggole has quit []
<gasche> if you never contribute and just complains, that's certainly not necessarily helpful
<whitequark> we have a conflation of two roles here.
<gasche> whitequark has done some interesting contributions recently, that's quite nice
<whitequark> role A: "can write a reasonable patch"
<whitequark> role B: "invested years or even decades in the ocaml core development workflow"
<whitequark> so for patches by role A to be merged, they have to be reviewed by someone in role B
<whitequark> but you just essentially asked anyone interested in patches being merged to aim for role B themselves.
<whitequark> that's... that's not constructuve, even.
<gasche> well
<gasche> I don't think so
<whitequark> on what part?
<gasche> because there is a gradation, it's not a binary split
<gasche> for example am I an A or B?
nojb has quit [Ping timeout: 264 seconds]
<whitequark> let me explain it another way
<gasche> if you never did A you certainly cannot expect to magically gain a share of B-ness
<gasche> hm
<Drup> gasche: please explain to me why alain's patches are sometimes rejected and asked to be re implemented from scratch, years after years, while damien can land a feature without any on-mantis preliminary discussion ?
<gasche> here I mean A "help with patches", not necessarily write them
<Drup> this is a concrete example of the workflow begin wrong
<Drup> and don't tell me alain doesn't have experience with the compiler ...
<whitequark> my claim is that since patches by people in role A right now hardly get merged, the workflow is broken. responding to this with "either invest many years into becoming someone the core team accepts or quit complaining"
<gasche> alain is part of the core team, I'm not sure what you're talking about Drup
<whitequark> is what I call not constructive
<gasche> whitequark: you don't need to be a B to get *your* patches merged
<gasche> but we need more people to need *patches*, not *their own* patches
<Drup> alain doesn't land features in the tree arbitrarly, never.
<whitequark> let me just silently point you to fifty two PRs and a few more dozen patches in the mantis
<gasche> Drup: inline records argument certainly are still a controversial feature
<whitequark> there are so, so many small patches in mantis with little controversy which just sit there for years
<gasche> at some point Alain decided to ignore the disagrement and merge it anyway
<Drup> did he ?
<gasche> that's not "arbitrary" but that's a decision
<Drup> my impression was more than people finally agreed that it was mergeable
<adrien> Drup: Alain pushes many large things; Damien, far fewer
<gasche> I think your impression was wrong
<Drup> (and anyway, my point was more about the lack of preliminary discussion on -safe-string)
<adrien> and I've seen Alain push things at once and I've been quite surprised
<adrien> also
<gasche> whitequark: please, send me a list of those PRs/patches
<adrien> notice how many "oops, last commit borked everything" he does
<Drup> adrien: that's another issue, I don't say I agree with that.
<whitequark> gasche: ok, next time I encouter one I will
<whitequark> this happens quite often.
<gasche> Drup: come on, we've been saying that having string mutable is a mistake for years
<adrien> Drup: I doubt there would be that many if everything he pushed was checked by someone else
<Drup> gasche: and ?
<Drup> there was a discussion after the fact.
thomasga has quit [Quit: Leaving.]
<gasche> Damien and Alain realized there was an opportunity to implement something without breaking backward-compat, they agreed on an idea, and Damien pushed it
<gasche> (I think there were some other people involved, but don't remember right now)
<Drup> IRL, without public discussion
<Drup> My fucking point: wrong workflow
<Drup> it's a closed process between a few people
<adrien> it happens
<adrien> everywhere
<adrien> is it the norm? not so much
<Drup> and it's still a bad thing.
<adrien> sure
<adrien> but you know what happen when you want to make sure nothing bad happens
emias has quit [Quit: Reboot.]
<Drup> adrien: don't do the cliché about doing nothing is better than doing bad things, please.
<gasche> (or the reverse?)
<Drup> whichever :p
<adrien> :)
<adrien> but it's quite true: what do you propose to fix that?
<adrien> what would have prevented this issue?
<gasche> some people in the core team have the perception that bike-shedding can kill good work because there are exponentially many more people that will be judgmental about things rather than actually contributing useful work and progress
<adrien> requiring discussion on a public bugtracker? but can you _enforce_ it?
<Drup> gasche: and yet, every things about syntaxes is bikeshed to death :D
<gasche> we're lucky of that, otherwise the syntax would be even more of a quagmire than it is today
<Drup> (and some other things too)
<whitequark> adrien: enforcing is a silly word for a community-led effort
<adrien> that's my point
<whitequark> however, setting an example is only more important because of it.
<whitequark> and arguably ocaml core team sets an example of being opaque.
<whitequark> ruby-core discusses it in japanese, but at least it's in public :]
<whitequark> (ruby has a completely abysmal transparency track, much worse than ocaml.)
<gasche> I agree the -devel list should be public, but that's a controversial point
<gasche> (because of what I described above on the bike-shedding perception)
<Drup> why is ti controversial ?
<Drup> make it read only ?
<gasche> nowadays most discussion happens in mantis anyway
<whitequark> wait, there's a -devel list?
<Drup> yes
nojb has joined #ocaml
<whitequark> ha.
<Drup> yeah.
<rgrinberg> to add to whitequark list of pr's: https://github.com/ocaml/ocaml/pull/79
<whitequark> right, I missed it narrowly
<whitequark> there are some more on mantis but I don't have time to crawl it right now.
<Drup> gasche: a retranscription of the developer meeting. In the last one, there was a resume, which is at least something (it was the first time, afaict)
<gasche> #2 should be closed as "won't fix" for the reasons explained in mantis
<adrien> s/resume/summary/
<gasche> I can ask for this
<Drup> yes, thanks :p
<gasche> I agree #57 is mergeable, on my list
<gasche> nowadays most discussion happens in mantis anyway
<gasche> #79 and #84 are not no-braineers (changing the stdlib never is)
<Anarchos> i have a total comfidence in the ocaml developer team and i understand they need some privacy on their mailing list to be able to share honestly their views. Why should i look at it to comment , as i know i am not skilled enough ? People complaining about lack of transparency are just unfair to dedicated and skilled people. Just wait and see what they deliver is much enough from my point of view.
<gasche> and I actually kept #94 open because Grégoire and myself agreed there is no clearly-good solution there
<Drup> Anarchos: I don't do blind faith, sorry.
<rgrinberg> Drup: you're a bad serf :(
<Anarchos> Drup sure but the subversion repo is available for reading :)
nojb has quit [Ping timeout: 256 seconds]
travisbrady has joined #ocaml
<Drup> O_°
<gasche> my vision is that people should contribute with work before requesting other people to change
<MercurialAlchemi> open development seems to be the norm for Rust, as far as I can tell
<MercurialAlchemi> with logs of dev team meetings, RFCs as pull requests discussed on Github, this kind of thing
<gasche> honestly I try to follow Rust and it's quite hard to find one's way in the maze of PR acted upon by bots and links to IRC transcripts
<gasche> I have no idea how many things are done via inter-person email, maybe little, but it's still quite hard to have a coherent view from the outside
<MercurialAlchemi> well, I'm not under impression that OCaml suffers from the bot problem
<rgrinberg> well rust's sheer volume of activity dwarves ocaml's
<MercurialAlchemi> but, well, it's possible to get something like "this week in Rust" and links to public discussions on a given feature
<gasche> MercurialAlchemi: we have a weekly Caml newsletter as well
<gasche> I read both and they're both fantastic
oscar_toro has quit [Read error: Connection reset by peer]
<gasche> (the CWN is less language-focused because they wouldn't be much to say)
<travisbrady> rgrinberg: any thoughts on lwt vs async for cohttp use? Normally I’d use async but last I looked it seemed lwt was further along
<Drup> weekly Caml newsletter is more a resume of the mailing list, though.
<Drup> a summary* grmbl
<rgrinberg> travisbrady: use lwt
<gasche> Rust has several full-time people working on the language and its ecosystem
oscar_toro has joined #ocaml
<gasche> (same with Go for example)
<adrien> Drup: \o/
<gasche> and also many volunteers
<travisbrady> rgrinberg: dang, thought you’d say that.
<rgrinberg> travisbrady: from a technical perspective both are equally far along though
<MercurialAlchemi> well, there is a summary of the mailing list, but it doesn't really speak of what happens in the trenches, IMHO
acieroid has quit [Ping timeout: 258 seconds]
<travisbrady> Any reason why lwt wouldn’t behave with core?
<Drup> gasche: My opinion is that, if the development model was more open in OCaml, there would be more volunteers.
<rgrinberg> travisbrady: lwt should work just fine with core
<MercurialAlchemi> agreed with Drup
<gasche> Drup: sometimes I wonder whether that's not an excuse people use not to contribute
<MercurialAlchemi> moving to !SVN and !Mantis would help too
<whitequark> I don't think these are a problem
rgrinberg has quit [Read error: Connection reset by peer]
rgrinberg1 has joined #ocaml
<gasche> I'm going away, please use mails for the next ones whitequark
<MercurialAlchemi> one thing I noticed on the otherwise great ocaml.org website
<adrien> mantis is _great_ for managing large number of bugs and releases
<MercurialAlchemi> is there is no "hack on this fantastic language" section
<Drup> adrien: it's great for forgetting bugs too :D
<whitequark> gasche: ok
<adrien> Drup: entirely different matter though
<travisbrady> rgrinberg: are you using your opium stuff in production? I could probably use it at work, but I nearly did and then hit a hard crash with async-cohttp on large POSTs so I skipped it and used Go.
<Drup> travisbrady: *cringes*
<rgrinberg1> travisbrady: opium is getting ported to lwt soon enough
<MercurialAlchemi> one thing to be said for Github is that the review process is fairly frictionless
<rgrinberg1> travisbrady: is there a ticket for that? it's likely a cohttp bug
<rgrinberg1> I remember fixing something to that effect not too long ago
<whitequark> MercurialAlchemi: we do have review on github.
<gasche> I'm also mildly irritated Drup that you would both complain about lack of openness and misrepresent my own efforts to provide and improve transparency
<Drup> misrepresent ?
<gasche> (I watched a bit of the OCaml'14 video just to make sure: I never said that patches were bad!)
<MercurialAlchemi> the bugtracker is a bit shite, but you can label issues and there are milestones
<MercurialAlchemi> whitequark: we do?
<gasche> if you want things to improve, do contribute work, rather than opinions from the backseat
<MercurialAlchemi> that's kind of split-brain development...
<travisbrady> rgrinberg1: yes, I filed it back in the summer, I think you fixed it actually. Was like “hello-world crashes on large POSTs” or something
<gasche> whitequark: actually the work you just did to re-triage PRs and PRs is very helpful and could see more of
<rgrinberg1> travisbrady: yep. more bug reports are very welcome!
<gasche> if you feel motivated to do something similar on a weekly/monthly/whatever basis, I'd be glad
icicled has joined #ocaml
<whitequark> gasche: okay, I will
<gasche> the only part I had in the last development meeting was selecting PRs that should be discussed, and... it worked, the PRs were discussed
<Drup> gasche: Please. It's not like I never do anything related to the compiler and stay in my chair.
<travisbrady> Anybody have thoughts on the best tools to write http microservices with?
<Drup> (well, I do like my chair)
<rgrinberg1> in OCaml I assume? I say use something light on top of cohttp. Use Lwt.
<travisbrady> Drup: *cringing* at Go? Or the bug I’d mentioned?
<rgrinberg1> opium lwt will be ready very soon
<Drup> travisbrady: Go :)
acieroid has joined #ocaml
<travisbrady> Drup: don’t entirely disagree, though Go does make it trivial to write these little microservices and they usually live happily within 2MB of memory on a tiny ec2 node
<travisbrady> rgrinberg1: I’ll give that a shot.
<Drup> That's not a Go big point
<rgrinberg1> travisbrady: yep. please keep up updated with your experiences.
<rgrinberg1> cohttp's biggest problem is lack of real world usage
<MercurialAlchemi> gasche: what would be a good thing to do to help all these open PRs go from 'open' to 'either pulled or refused'?
badkins has quit []
Hannibal_Smith has quit [Quit: Leaving]
<Drup> gasche: I can't find it again, but yeah, I was shocked enough when you said it, so I'm pretty sure it happened
myyst has quit [Remote host closed the connection]
MrScout has joined #ocaml
<icicled> newb here. I was wondering if someone could review my code (a streaming line yielder thing) & point out anything I could do better? http://lpaste.net/3707846379033329664
<icicled> it's copy/pastable into utop
myyst has joined #ocaml
icicled has quit [Remote host closed the connection]
<whitequark> 1) don't use Stream. ever.
<whitequark> https://github.com/c-cube/gen is a good replacement for Stream
<whitequark> but in this case, you probably want to look into Lwt, as your code will change rather dramatically when you add I/O
<Simn> (What's wrong with Stream?)
<whitequark> it's too complex and it has weird semantics
<Simn> Complex usage-wise or complex in its implementation?
<Drup> both
travisbrady has quit [Quit: travisbrady]
icicled has joined #ocaml
manud___ has joined #ocaml
<Simn> Uhm okay, I'll refrain from fishing for details I guess.
<rgrinberg1> Drup, whitequark have you guys suggested deprecating Stream on mantis?
struktured_ has quit [Ping timeout: 258 seconds]
<rgrinberg1> with @@deprecated and such
<whitequark> hmmm, good idea
<whitequark> Drup: can you write up your problems with Stream coherently?
<whitequark> I can try, but most likely it will result in just "more fire"
<icicled> It seems like it solves a good problem
<whitequark> it doesn't `solve' it
<rgrinberg1> icicled: there's better solutions than stream
<whitequark> inasmuch as in solving one problem and creating two more is a solution
struktured has joined #ocaml
<icicled> so then why is it in the stdlib?
<whitequark> hysterical raisins
<Drup> give me a sac
<whitequark> I mean, historical reasons.
<rgrinberg1> there's lots of cruft in the stdlib
<rgrinberg1> str is another example
<Drup> Sorry, was on phone
<Drup> It's actually quite a good idea
<MercurialAlchemi> (quite amazing for such a small library)
<icicled> what's bad about str?
<whitequark> have you seen it?
<rgrinberg1> icicled: global state
<whitequark> latin-1, too
<Drup> MercurialAlchemi: it's actually easy: it's from, what, 15 years ago ?
<rgrinberg1> there's also really random stuff like http://caml.inria.fr/pub/docs/manual-ocaml/libref/Event.html
<rgrinberg1> i've never seen event used in the wild
<MercurialAlchemi> Drup: yes, I know
<MercurialAlchemi> well, don't we have deprecation annotations nowadays
<MercurialAlchemi> ?
<MercurialAlchemi> couldn't a lot of the cruft be sunsetted?
<icicled> Is there a list of libraries that one should use over the rest?
<rgrinberg1> icicled: str and stream really glaring bad examples
<rgrinberg1> everything else should be ok in general
<MercurialAlchemi> of course it would force the stdlib to grow replacements
<rgrinberg1> icicled: use batteries or core if you want something complete
<icicled> rgrinberg1, no one has said why stream is bad
<whitequark> rgrinberg1: Num.
<Drup> icicled: give me a sec, I'm writing it
<rgrinberg1> icicled: try writing Stream.cons
milosn has quit [Ping timeout: 240 seconds]
<rgrinberg1> also Arg sucks
<rgrinberg1> but functional at least
<Drup> it's very very bad that Arg doesn't enforce -- for long arguments
kakadu has quit [Remote host closed the connection]
<rgrinberg1> graphics also deserves to get booted
<whitequark> not stdlib
<Drup> graphics is fine
<Drup> it's toyish, but fine
<icicled> Someone should write something up about all the stuff you "shouldn't" use and the reasons as to why
<icicled> and list the alternatives
thomasga has joined #ocaml
<rgrinberg1> icicled: yeah can't hurt. we'd have a much shorter list than python at least
<icicled> it's a bit confusing as a newbie to ocaml
<Anarchos> rgrinberg1 why is Stream.cons bad ?
<Simn> People with a lot of experience just tend to overreact when you use suboptimal approaches.
<Simn> I kind of do the same in my "own" language. ;)
kakadu has joined #ocaml
<icicled> ok, so from what I can gather [from the API docs] Gen is a much more complete version of Stream..
<whitequark> yep
<whitequark> and it's nice.
<icicled> is there some documentation for it besides the api docs?
chambart has joined #ocaml
<whitequark> um, what else do you want?
<Simn> Assuming I'm having an implementation using Stream which has been working fine for years, what would be the benefits of replacing it with Gen?
<icicled> whitequark, some examples would be nice =]
<Drup> Simn: simpler code.
<Drup> and speed
arj has joined #ocaml
<Drup> icicled: actually, gen is much simpler, just that there are auxiliary functions ^^'
milosn has joined #ocaml
rgrinberg1 has quit [Quit: Leaving.]
<icicled> Drup, it does look like it - I can see how to use it looking at the tests +1
Anarchos has quit [Quit: Vision[0.9.7-H-20140108]: i've been blurred!]
<icicled> I supposed I'm a bit spoiled coming from python land where most libraries have docs in (they might not always have tests heh)
<icicled> and the docs don't look like they're from the 90s hehe
<Drup> (to be completly fair, I find most python docs lacking because of the lack of precise types)
<Drup> (but I do agree, tutorials should be the norm)
<Drup> (do not confuse tutorials and documentations, though ;)
<icicled> yep, of course not
<MercurialAlchemi> well, Python has Sphinx, and that's pretty nice
<icicled> I do think the ocaml api doc generator is in need of a decent facelift
<icicled> whatever it may be (haven't gotten around to using it yet)
<Drup> icicled: it's being worked on
<Drup> (a wild dsheets appears)
<Simn> From my experience API documentation looks like garbage in a lot of languages. But it also never really bothered me as long as the content is there.
<MercurialAlchemi> yeah
<MercurialAlchemi> well
<Drup> whitequark: http://pastebin.com/nCAFRxM4
<Drup> opinions ?
<MercurialAlchemi> some libs have decent documentation coverage
<MercurialAlchemi> other libs have read-the-mli coverage
<Drup> =')
<whitequark> Drup: ++
<Drup> Simn: are you convinced ? :p
<MercurialAlchemi> they're rarely replete with examples and tend to be under-specified at times
<icicled> Drup, that helps
<smondet> Drup: complexe → complex, semantic → semantics,
<Drup> (yes, I'm doing the spellchecking, thanks)
<Simn> The Obj remark is what I was looking for, I didn't know it used that internally.
<Simn> The rest can pretty much be summarized as "it's complex and outdated and I don't like it" though. ;)
<Drup> Simn: well, I have benches were there other libraries outspeed Stream by an order of magnitude
<Drup> -there
<Drup> that's not "I don't like it"
<icicled> Drup, you should add that to the list
<Drup> It's *really* slow.
<Simn> Okay but you didn't say that or refer to these benches.
<Drup> I said the other were betters, but you are right
<icicled> examples are always nice ;)
<MercurialAlchemi> well, you do say Streams is slow
<Simn> Sure, but saying that something is slow is only interesting when you also say that there's an alternative which is faster.
<whitequark> Simn: "complex and outdated" is an excellent reason to deprecate something
<Drup> the argument "is not used inside the compiler" is also an important one, given there are better alternatives
<Drup> "It can be implemented outside, hence it should" is a recurrent argument against inclusion in the stdlib.
<Simn> Yes, I like using that argument as well.
<Simn> Though if you're consistent with that you might end up with a _very_ slim stdlib.
rgrinberg has joined #ocaml
<Drup> well ...
<Simn> Anyway, thanks for the insights. We're still using camlp4 so I suppose we'll stick with Stream as well for the time being.
<MercurialAlchemi> "newcomers"
<Simn> Oh wow, these benches really do make Stream look bad. :)
<Simn> If our parsing time was more significant I would seriously consider moving away from it soon.
<companion_cube> Drup: \o/
<companion_cube> kill Stream!
<Drup> Simn: in parsing time, it's less important, since have IO and actual parsing too
<Drup> I mean, it's still ten time slower, but it's in the middle of a bunch of stuff so you don't see it that much
<companion_cube> I like this proposal
travisbrady has joined #ocaml
<Drup> huum, If someone want to contribute how bad Genlex is
<Drup> (because they go together, obviously)
<companion_cube> I'm thinking of asking ocaml/ocaml whether a PR adding iterators to Map/Set/Hashtbl would have even the slightest chancee to be merged
Yoric has quit [Remote host closed the connection]
<Drup> gen-like, or sequence-like ?
<Simn> *checks what genlex is*
<companion_cube> gen
<Drup> whitequark: do you have stricking arguments for genlex ?
<Drup> well, against it
<companion_cube> it's more powerful
<Drup> companion_cube: I think we should wait a bit more for that
<companion_cube> :(
<companion_cube> until stream is removed?
<Drup> until I investigate pipes to see if it's better or not =')
<Drup> I'm not sure how I feel about gen on structure that can mutates, too
<companion_cube> wait, pipes is only interesting for IO
<Drup> is it ?
<companion_cube> it involves a monad
<companion_cube> so there's going to be an overhead in OCaml
<Drup> It seemed interesting on it's own
seanmcl has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
<Simn> Genlex looks kind of cute.
SHODAN has quit [Ping timeout: 255 seconds]
<Drup> As cute as a baby rocked too close to a wall.
emias has joined #ocaml
<companion_cube> yield :: Monad m => a -> Pipe x a m () ← yes, it's monadic
manud___ has quit [Quit: Be back later ...]
<companion_cube> probably an interesting abstraction for Lwt, but not for iterating over the stdlib's data structures
<Drup> companion_cube: I don't see the issue with it being monadic
<companion_cube> the overhead?
<companion_cube> it's fine for IO, I don't say
<Drup> there isn't necessarily one.
<companion_cube> but I don't see why Map/Set/Hashtbl should export this kind of stuff
<companion_cube> come one.
<Drup> let me investigate, ok ? :p
<companion_cube> -e
<rgrinberg> companion_cube: to be clear that m is a monad specifying the effect
<rgrinberg> it's not clear to me it would be necessary in an ocaml port
<Drup> rgrinberg: still waiting for a link though ;D
<rgrinberg> link for what?
struktured has quit [Remote host closed the connection]
<Drup> rgrinberg: the "good" pipes library, as I assume there are several one
<rgrinberg> there's only one
<rgrinberg> fundamental type
<Drup> that's .. surprising
<rgrinberg> also pipes are very well documented in comparison to the alternatives
kapil__ has quit [Quit: Connection closed for inactivity]
<companion_cube> 6 type parameters.
<whitequark> hmmmm, genlex
<companion_cube> I mean, come on.
<whitequark> it uses stream
icicled has quit [Quit: Leaving]
<rgrinberg> companion_cube: it's really not that bad :D
<whitequark> and it is trivial to replace it outside stdlib
<rgrinberg> 2 params for upstream input/output
<rgrinberg> 2 params for downstream input/output
<rgrinberg> 1 for result type
<rgrinberg> 1 for effect
<companion_cube> it's going to be a nightmare in OCaml
<Drup> whitequark: I already did the pr for that :D
<companion_cube> also, functor, because of lack of rank-2 types
<rgrinberg> you mean hkt?
<rgrinberg> proxy is indeed a monad transformer
<rgrinberg> so it will need a functor for a faithful port
<companion_cube> so, well, nope
<rgrinberg> but like i said i don't tihnk its completely necessary to track the effect in ocaml
* companion_cube won't do it
<Drup> rgrinberg: the thing I don't understand, is why you need *two* inputs/outputs
<Drup> it's not very well explained
<rgrinberg> companion_cube's link is very thorough no?
<rgrinberg> in particular
<whitequark> wow, that whole file
<whitequark> Core.hs
SHODAN has joined #ocaml
SHODAN has quit [Changing host]
SHODAN has joined #ocaml
<Drup> rgrinberg: you may have missed that ^
struk|work has quit [Quit: Page closed]
<MercurialAlchemi> "other, better ways"
<companion_cube> "This also means"
<MercurialAlchemi> "its camlp4 extension"
<MercurialAlchemi> "still mentions"
<Drup> é_è
<rgrinberg> Drup: +1
<rgrinberg> let's see if this one gets ignored :D
<Drup> (thanks for the corrections)
<MercurialAlchemi> np
<rgrinberg> companion_cube, Drup i have a blog post almost ready denouncing async
<companion_cube> denouncing in what sense?
<rgrinberg> try not to smirk too hard :D
* Drup tries very hard.
<rgrinberg> companion_cube: dropping its usage
<companion_cube> I mean, why?
<rgrinberg> companion_cube: the blog post will explain
<companion_cube> ok
<Drup> whitequark: could you have a way to check the usage of Stream and Genlex in opam libraries ?
<Drup> like, by crawling or something
<companion_cube> oh, right, if you have access to all the archives...
* whitequark sighs
<companion_cube> that would also be a good way to know whether BatEnum, BatIO, etc. are used
<companion_cube> "grep opam" as a service
<Drup> "opam grep"
<Drup> I want that
<whitequark> well, I can do that
<companion_cube> ohhh
<companion_cube> because we'd like to decide whether BatEnum can die peacefully :
<Drup> I will wait that before opening the bug then
<companion_cube> :>
<whitequark> no, open the bug.
<Drup> okay
<rgrinberg> merlin already allows you to open any opam module btw with :ML in vim
<whitequark> this will finish in several hours
<whitequark> optimistically
<whitequark> wow, so many broken checksums
<companion_cube> rgrinberg: we need to check all packages
shinnya has quit [Ping timeout: 250 seconds]
Yoric has joined #ocaml
<Drup> (I eagerly impatient on which point I'm going to get burn, on this one x)
<Drup> I'm*
<whitequark> yay, downloading every version of async in existence
<Drup> you could restrict yourself to last versions
<companion_cube> whitequark: you download the full cache of opam?
<whitequark> yes
WraithM has joined #ocaml
fraggle_laptop has joined #ocaml
shinnya has joined #ocaml
NoNNaN has joined #ocaml
MercurialAlchemi has quit [Ping timeout: 250 seconds]
samuel02 has quit [Remote host closed the connection]
dsheets has quit [Ping timeout: 240 seconds]
<rgrinberg> Drup, companion_cube, et all: http://rgrinberg.com/blog/2014/12/11/abandoning-async/
<rgrinberg> early preview
<rgrinberg> technical review is welcome
<rgrinberg> plz dont link
<whitequark> you do realize this channel is publicly logged and indexed, right?
<Drup> and contains 237 members.
<rgrinberg> I do
<Drup> :D
<rgrinberg> i'm just saying please dont hackernews or reddit, etc.
<Drup> ok
<rgrinberg> need to fix embarassing grammar/technical errors first :D
<Simn> "The result of this is a split OCaml world with almost no interoperability and duplication of efforts." I parse that as `not (interop && duplication_of_efforts)`
rand000 has quit [Quit: leaving]
<rgrinberg> Simn: That was a ninja edit I've made. Will fix.
<Drup> rgrinberg: I highly doubt that Lwt runs on OCaml-java
<rgrinberg> Drup: damn.
<rgrinberg> would ocaml -> js -> nashorn work?
<Drup> err, I wouldn't do it
<rgrinberg> lol
<whitequark> lwt doesn't run on ocamljava
<Drup> rgrinberg: It doesn't mean it's not portable to it, with a bit of effort, but yeah, don't think it does
<rgrinberg> whitequark: not even in my suggested pipeline?
<Drup> (you could hint that lwt is part of the ocsigen project, You already talk about it anyway :p)
<rgrinberg> Drup: yeah but I don't want to put lwt under a particular group
<Drup> sure
<rgrinberg> b/c lwt IS the de-factor concurrency lib for ocaml
<rgrinberg> de-facto*
<companion_cube> you can mention that lwt%try is similar to the regular OCaml try, only monadic
<companion_cube> about the error model
emery has quit [Remote host closed the connection]
<Drup> but I mean, lwt doesn't run on js_of_ocaml just by chance ^^'
<rgrinberg> companion_cube: does lwt ship with that extension yet?
<whitequark> rgrinberg: I don't think anyone ever tried that
<Drup> yep
<Drup> rgrinberg: it's in the last version of lwt
<rgrinberg> which is not available on osx :D
<Drup> oh, yeah
<Drup> this should be fixed
<rgrinberg> but anyway, i will mention that there's a syntax extension that helps
<companion_cube> it looks ok to me
<rgrinberg> although its not even a new thing
<Drup> rgrinberg: note that it's a direct ppx translation of the try_lwt in the camlp4 syntax extension
<rgrinberg> there was always one before
<companion_cube> rgrinberg: there's try_lwt too
<companion_cube> for older version with camlp4
<companion_cube> what I mean is, handling exceptions in Lwt is reasonable
<companion_cube> interleaving errors and concurrency is often useful
<Drup> backtraces are akward, though
<Drup> (and if something raise a non-lwt exception, hell breaks loose)
<whitequark> not really hell
<whitequark> it will travel up to the nearest bind
<companion_cube> Lwt.catch is pretty reasonable
<Drup> let's say the behavior can be surprising :D
<rgrinberg> yeah although my post states that these fine points end up having little effect at the end :/
<Drup> this fine points make writing code that runs in both horrible, but you already said that :D
<companion_cube> wtf, async_kernel depends on core
<companion_cube> such *bloat*
<Drup> companion_cube: so kernel :3
<companion_cube> it's ridiculous.
<companion_cube> so, I'm playing with the idea of writing an IRC bot
<rgrinberg> companion_cube: wait for nano_micro_async_kernel_lite
<Drup> rgrinberg: the interop Lwt<->React is cool too
<companion_cube> rgrinberg: only 10 dependencies!
<rgrinberg> Drup: yeah, it's trivial to port to async however as well
<Drup> yep
<rgrinberg> better just having it available and documented though :D
<rgrinberg> there's also the custom event loops
<rgrinberg> and gtk support for the crazies
Yoric has quit [Remote host closed the connection]
Yoric has joined #ocaml
<Drup> rgrinberg: it's good to have a blog post giving the technical differences between the two, though.
<rgrinberg> Drup: yeah but I'm not qualified to do it
<Drup> I talked with anil two days ago, and he said the exact two same things
oscar_toro has quit [Ping timeout: 255 seconds]
<Drup> 4 days ago actually
<rgrinberg> which 2 things?
<Drup> time >_>
<Drup> bind that yields and exceptions with monitors
Simn has quit [Quit: Leaving]
icicled has joined #ocaml
<rgrinberg> diml's linked post is probably the best technical comparison
Yoric has quit [Ping timeout: 260 seconds]
<Drup> considering he's the maintainer of both ... :D
<Drup> (that is still going to make me chuckle n_n)
travisbrady has quit [Quit: travisbrady]
<companion_cube> anyway, it's clear Lwt "won" the community
<rgrinberg> won by the other side pretty much forfeiting
<rgrinberg> but hey we'll take it :D
<companion_cube> can't wait to be able to say the same of core
<companion_cube> (which is the reason why I'm ready to work a bit on batteries)
<rgrinberg> companion_cube: yeah you gave up on batteries a bit too soon
<rgrinberg> just proceed with the trimming and we'll do the arguing with gasche
<rgrinberg> :D
arj has quit [Quit: Leaving.]
<companion_cube> I'm going to work with him next saturday
<rgrinberg> imo you should cut shit aggressively and only reintroduce parts that people care about
<companion_cube> I'dl like to try to separate Enum/IO from the "core" modules
fraggle_laptop has quit [Remote host closed the connection]
<rgrinberg> care enough to complain
<companion_cube> I'd like to
<companion_cube> but he wants retrocompatibility
<companion_cube> even for fucking *Enum*
<rgrinberg> its bs. nobody uses that crud
struktured has joined #ocaml
<companion_cube> we'd need a proof :/
<rgrinberg> batargs, batparser, etc.
<companion_cube> yeah
<rgrinberg> nah, we need you to proceed
<companion_cube> many things are better implemented by other libs on opam
<rgrinberg> and apologize later
<rgrinberg> :D
<whitequark> why do you even do something with batteries
<companion_cube> it's cool, but I won't spend time to do work that won't get merged
<companion_cube> whitequark: batteries is still more respectable than containers, which will remain lightweight
<rgrinberg> companion_cube: if it doesn't get merged people will just use your fork
<rgrinberg> release it as xbatteries eventually or something
<whitequark> companion_cube: yes. yes, that's the point
<companion_cube> I didn't want to fork batteries :/
<whitequark> I never wanted Core or Batteries. I totally wanted containers
<Drup> I personally would like lot of little libraries.
<companion_cube> Drup: how little? like one package for CCOpt (or BatOption)?
<Drup> like, one gen, one sequence, one stdlib' (only for enhancement over the respectable stdlib modules), and so on
<rgrinberg> i would say that's too much
<Drup> and after that, one cconv
<companion_cube> heh.
<companion_cube> one stdlib' is quite close to containers
<Drup> opam handle dependencies perfectly fine
<companion_cube> although I should split it more
<Drup> companion_cube: not really anymore :)
<companion_cube> give me 5 minutes
<Drup> it would really work fine, imho, and it would be better
<Drup> containers is starting to be a bit of a bazaar, with lot's of unreleated thing
<companion_cube> ok ok
<Drup> (exceptionally, this is something gasche and me agree on :D)
<rgrinberg> thats my problem with containers as well
<companion_cube> I'm going to make smaller sub-libraries
<Drup> \o/
<whitequark> I actually don't care, as long as it compiles quickly
<companion_cube> but still as findlib sub-libraries
<companion_cube> not separate packages
<rgrinberg> whitequark: is batteries slow for you?
<companion_cube> current batteries is a bit bloated
<Drup> companion_cube: why not
<Drup> I would go all the way to packages
<Drup> (especially sequence and gen, since they live in other repositories ...)
<Drup> (no need to reinclude them in containers ...)
<whitequark> no, I don't like the design of batteries
<whitequark> and core is really slow in multiple respects
<whitequark> I'm more or less ok with many parts of their design
<rgrinberg> whitequark: what parts of batteries you dont like?
<rgrinberg> we've listed many bad parts we'd remove
<rgrinberg> e.g. enum, printers, cruft
<rgrinberg> otherwise batteries seems pretty lean to me
<rgrinberg> and well tested
<rgrinberg> and supported by a ton of contributors
<Drup> rgrinberg: io O_O
<whitequark> io.
<whitequark> also I've never installed anything that depended on batteries
<rgrinberg> that's a subset of cruft
<companion_cube> Drup: I could consider removing Gen and Sequnence, indeed
<companion_cube> since they are structural types anyway
<Drup> whitequark: not even postgres ?
<whitequark> postgres?
<whitequark> oh, the gem
<whitequark> errr
<rgrinberg> how does batteries manage to have 2 logging modules
<Drup> the gem ? what ?
<whitequark> the ...
<whitequark> how do you call ocaml libraries
<Drup> ahah xD
<whitequark> the ocaml library.
<whitequark> gem is ruby.
<Drup> exactly :D
<whitequark> I have muscle memory for that
<Drup> we totally need to come up with a good pun for that
<Drup> oasis is already taken, and caravan doesn't have a nice ring to it
<companion_cube> I'll push a first draft of splitting in a few minutes
<whitequark> hump?
<Drup> guaranteed 100% outdated.
<rgrinberg> ah the good old sourceforge days
<rgrinberg> rubyforge for whitequark :D
<whitequark> i was on sf too, before ruby
<whitequark> rubyforge is so dead
tane has quit [Quit: Verlassend]
<rgrinberg> ocamlforge is getting there
<rgrinberg> slowly dying...
<companion_cube> Drup, whitequark: can you please check the last commit on containers?
<companion_cube> I've split "containers" into several libraries
<Drup> in the category of terrible ideas
<Drup> I wonder if you could port metaocaml to javascript by using eval
<Drup> :>
<companion_cube> rgrinberg: aww
<companion_cube> thanks for reminding me that -_-
<companion_cube> I think batteries needs: 1/ a voting process so that no single maintainer can veto changes 2/ frequent releases (even bugfix releases)
<rgrinberg> companion_cube: indeed
<companion_cube> and the mailing list is pretty much dead :(
<rgrinberg> yes but imo that comes after
<rgrinberg> batteries needs to reinvent itself as a non massive hairball of broken crap
<companion_cube> heh.
<companion_cube> but, you know, retrocompatibility
<rgrinberg> so that respectable projects would not be so scared of taking it as a dependency
<companion_cube> also, you should pay only for what you use
<rgrinberg> especially the people out there who just need a List.make or something like that in their code
<companion_cube> which was the point of batteries-light :/
<companion_cube> yeah
<rgrinberg> companion_cube: 1 -> 2 had a massive haircut
<rgrinberg> 2 -> 3 could be on a similar scale
<companion_cube> I'm wondering whether containers can be a credible alternative, actually
samuel02 has joined #ocaml
<companion_cube> for the "extension of stdlib" part, which is the only thing batteries should do anyway
<rgrinberg> companion_cube: there's a couple of essential things beyond stdlib replacements
<companion_cube> logging: dolog, IO: lwt, iterators: anything but Enum, parser combinators: many other libs, unicode: ucorelib/uu*
<rgrinberg> batsubstring, batresult
<companion_cube> sure
<companion_cube> that should be in the stdlib
<Drup> (loggin: Lwt_log)
<Drup> logging*
<companion_cube> not sure batsubstring is that essential
<companion_cube> Drup: yeah, if you use Lwt it's great
<rgrinberg> companion_cube: core has it :D
<companion_cube> anyway.
<rgrinberg> but imo batteries approach to substring is wrong too
<rgrinberg> it should be a functor over the base type
<companion_cube> rgrinberg: CCString.Sub :p
<companion_cube> well
<companion_cube> yeah, it's not clear yet how to abstract on strings properly
<Drup> what is BatSubString ?
<Drup> I never used it
<rgrinberg> string * int * int
<companion_cube> a slice, I think
<Drup> ah
<companion_cube> Drup: plz look at containers/_oasis
<Drup> so yeah, BatSlice.Make, clearly
<Drup> companion_cube: later, I'm cooking :<
<rgrinberg> companion_cube: its more useful for having slices on bigarrays, arrays, etc.
<rgrinberg> i mean its already useful
<rgrinberg> anyway, imo containers is the wrong way to go
<rgrinberg> since its the fut: https://github.com/dbuenzli/fut of stdlibs
<whitequark> huh?
<whitequark> what's wrong with it?
<companion_cube> why so?
<rgrinberg> i just dont think it will gain as much mindshare as lwt for example
<whitequark> it doesn't have to, though
<whitequark> CCList doesn't infest your external interface
<rgrinberg> neither does BatList
<companion_cube> I don't think containers will be the one true stdlib
<companion_cube> but slowly, it might become respectable compared to batteris
<companion_cube> +e
<Drup> if there is such thing
<rgrinberg> i guess my points is that I think that batteries CAN become the one true stdlib
<rgrinberg> al least among the community
<companion_cube> well, for this it needs to change
<companion_cube> really*
<companion_cube> to become smaller, to evolve more quickly
<companion_cube> to be more modular
<whitequark> to drop the fugly Bat prefix
<companion_cube> to remove the cruft
<companion_cube> whitequark: I like the prefix :D
<whitequark> this is 70% of the reason I never use it
<whitequark> the other 30% is the logo
<rgrinberg> CC is that much better than Bat?
<Drup> I like Bat too :D
<companion_cube> whitequark: wow, you really make choices based on strange criteria
<companion_cube> Drup: problem: should the parameter of slice be polymorphic (array) or monomorphic (string)?
<rgrinberg> companion_cube: mono please
<companion_cube> well that rules out array slices
<rgrinberg> rules out generic array slices
<companion_cube> yes
<Drup> companion_cube: ah, yeah, that's annoying
<rgrinberg> companion_cube: i've tried the polymorphic approach before
<rgrinberg> i was not satisfied
<Drup> I would tend to say both :x
<Drup> (there is no unicode character depicting a bat :( )
<companion_cube> hmmm, should I try a first-class module to represent the sliced stuff
<rgrinberg> companion_cube: how would that help?