<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]
<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?
<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>
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)
<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)
<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]
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]
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.
<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
<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."
<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
<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
<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>
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]
<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.
<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
<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
<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