Algebr` has quit [Remote host closed the connection]
yegods has joined #ocaml
<hxegon>
are there functions that you *have* to use label's for? I keep running into some errors using core that are resolved only when using labels
unbalancedparen has quit [Quit: WeeChat 1.4]
<struk|desk>
hxegon: yes although I have yet to determine a universal rule for predicing when they are required
<hxegon>
struk|desk: hmm, maybe it shows up in the type sig.?
<hxegon>
trying to find some optional labels in Core
pierpa has joined #ocaml
bba has quit [Read error: Connection reset by peer]
mistermetaphor has joined #ocaml
<struk|desk>
hxegon: of the course sig will show it. but you don't always have to specify a labeled argument even if it is actually labeled. optional labeled arguments are always optional, of course though
<struk|desk>
hxegon: eg List.map : 'a list -> f:('a -> 'b) -> 'b list = <fun>
<hxegon>
struk|desk That's what I'm saying, does the signature show if the label is optional?
misterme_ has joined #ocaml
bba has joined #ocaml
<hxegon>
I don't think it does, looking around
<struk|desk>
hxegon: yes like this: val f : ?flag:bool -> int -> string . flag is not required
<hxegon>
ahh, nice. Thanks!
<struk|desk>
fyi in the case of List.map: you could do "List.map [] (fun x -> x)" and it will still execute even without labeling f
kamog has quit [Read error: Connection reset by peer]
antkong has quit [Quit: antkong]
mistermetaphor has quit [Ping timeout: 260 seconds]
<hxegon>
There's another question... There isn't a std identity function? I mean, it's literally the easiest function to implement, but I just don't get why languages don't implement that for convenience.
antkong has joined #ocaml
dsheets has joined #ocaml
hxegon has quit [Ping timeout: 240 seconds]
dsheets has quit [Ping timeout: 250 seconds]
yegods has quit [Read error: Connection reset by peer]
hcarty has joined #ocaml
yegods has joined #ocaml
mettekou has joined #ocaml
hcarty has quit [Ping timeout: 276 seconds]
mettekou has quit [Ping timeout: 246 seconds]
dexterph has joined #ocaml
FreeBirdLjj has joined #ocaml
mistermetaphor has joined #ocaml
misterme_ has quit [Ping timeout: 246 seconds]
mistermetaphor has quit [Remote host closed the connection]
dexterph has quit [Remote host closed the connection]
mistermetaphor has joined #ocaml
kamog has joined #ocaml
mistermetaphor has quit [Remote host closed the connection]
ygrek_ has quit [Ping timeout: 250 seconds]
mistermetaphor has joined #ocaml
<pierpa>
It was true!
rgrinberg has joined #ocaml
mistermetaphor has quit [Ping timeout: 246 seconds]
<pierpa>
REALLY Str sucks!
yegods has quit [Ping timeout: 268 seconds]
<pierpa>
what were they smoking?
hxegon has joined #ocaml
Reshi has quit [Ping timeout: 268 seconds]
noddy has quit [Ping timeout: 250 seconds]
Reshi has joined #ocaml
yegods has joined #ocaml
dsheets has joined #ocaml
Reshi has quit [Ping timeout: 244 seconds]
dsheets has quit [Ping timeout: 250 seconds]
hxegon has quit [Quit: BRB]
JacobEdelman_ has joined #ocaml
Reshi has joined #ocaml
Sorella has joined #ocaml
wolfcore has quit [Ping timeout: 250 seconds]
wolfcore has joined #ocaml
johnelse has quit [Ping timeout: 276 seconds]
hxegon has joined #ocaml
rgrinberg has quit [Ping timeout: 246 seconds]
johnelse has joined #ocaml
iZsh has quit [Ping timeout: 246 seconds]
iZsh has joined #ocaml
hxegon has quit [Quit: BRB]
hxegon has joined #ocaml
kushal has joined #ocaml
Kyo9142 has joined #ocaml
yegods has quit [Read error: Connection reset by peer]
cow-orke1 has quit [Ping timeout: 244 seconds]
cow-orker has joined #ocaml
hxegon is now known as hxegon_AFK
yegods has joined #ocaml
cdidd has quit [Remote host closed the connection]
cdidd has joined #ocaml
hxegon_AFK is now known as hxegon
hxegon is now known as hxegon_AFK
hxegon_AFK is now known as hxegon
rgrinberg has joined #ocaml
FreeBirdLjj has quit [Remote host closed the connection]
FreeBirdLjj has joined #ocaml
dsheets has joined #ocaml
dsheets has quit [Ping timeout: 250 seconds]
Guest55577 is now known as kandu
MercurialAlchemi has joined #ocaml
<flux>
pierpa, I hope you were atleast warned, I always try to do my best?-}
<pierpa>
I had heard something about it. But I didn't believe it :)
<pierpa>
flux: I thought people were whining about some unimportant detail. How wrong I was! :)
iorivur has quit [Ping timeout: 246 seconds]
Reshi has quit [Ping timeout: 260 seconds]
copy` has quit [Quit: Connection closed for inactivity]
nnhb has joined #ocaml
antkong has quit [Quit: antkong]
iorivur has joined #ocaml
MercurialAlchemi has quit [Ping timeout: 252 seconds]
hxegon has quit [Quit: BRB]
MercurialAlchemi has joined #ocaml
yegods has quit [Read error: Connection reset by peer]
antkong has joined #ocaml
<flux>
hmm, kakadu's fragment doesn't compile on my 4.02.3? the code doesn't seem to use any implicit stuff so I think there's no reason why it shouldn't?
<flux>
also isn't the part of [%expr ..] from ppx_tools.metaquot, or is it in compiler-libs.common as well..
yegods has joined #ocaml
JacobEdelman_ has quit [Quit: Connection closed for inactivity]
Kyo9142 has quit [Ping timeout: 260 seconds]
Reshi has joined #ocaml
rgrinberg has quit [Ping timeout: 250 seconds]
FreeBirdLjj has quit [Remote host closed the connection]
FreeBirdLjj has joined #ocaml
zpe has joined #ocaml
TheLemonMan has joined #ocaml
<twobitsprite>
ok, so this is probably a dumb question... but in utop, with topfind, why can't I use/require/open/whatever a compiled module file in the current directory?
<twobitsprite>
I have .cmo, .cmi, cma, .cmx, .cmxa, .cmxs, .ml, and .o versions of my module in the current directory...
<destrius>
did you try #load?
<twobitsprite>
ah ha!
<twobitsprite>
that did it, thanks
<twobitsprite>
one more question... I just randomly guessed to #load the .cma file... and it worked... but what are all these other files for?
<flux>
.cma files are built out of .cmo files
<flux>
so you can load either a bunch of .cmo-files or one .cma
<flux>
.cmxa and .cmx are the same way, but for native code. they don't work with the (standard) toplevel, only for native compilation.
<flux>
.o are also for the native code, the bits that are directly linkable with a C linker
<flux>
also .cmi files are for finding the interfaces for modules
<flux>
if there is no foo.cmi, you won't be able to access the module Foo
<twobitsprite>
ahh, very interesting...
<twobitsprite>
I suspected the cmx* files had something to do with native code
Reshi has quit [Ping timeout: 252 seconds]
ygrek_ has joined #ocaml
bba has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
yegods has quit [Read error: Connection reset by peer]
badon has quit [Disconnected by services]
badon_ has joined #ocaml
badon_ is now known as badon
zpe has quit [Remote host closed the connection]
yegods has joined #ocaml
nullcatxxx_ has quit [Ping timeout: 244 seconds]
vodkaInferno has quit [Read error: Connection reset by peer]
vodkaInferno has joined #ocaml
sigjuice has quit [Ping timeout: 252 seconds]
nullcatxxx_ has joined #ocaml
sigjuice has joined #ocaml
yegods has quit [Remote host closed the connection]
bba has joined #ocaml
bba has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
sepp2k has joined #ocaml
<companion_cube>
pierpa: good thing that good alternatives to Str exist
* adrien
is writing a script with #load "str.cma";;
<companion_cube>
yeah but you like dirty technology
antkong has quit [Quit: antkong]
<adrien>
if only something better was in the base installation
<companion_cube>
^^
<adrien>
otoh
<adrien>
let paren_space = Str.regexp ") " in
<companion_cube>
:D
<flux>
does the compiler use the Str-module?
<flux>
now that we've been so happy to remove stuff from the standard distribution (ocamlbuild), maybe we should give str the boot as well.. ;)
<flux>
I guess the Graphics module is still with the ocaml distro
<companion_cube>
seems like ocamldoc uses Str
<pierpa>
companion_cube: but the standard library should be amended :(
<companion_cube>
we all agree on this
<companion_cube>
well, not "all"
<companion_cube>
but it's one of the things people complain about the most
dsheets has joined #ocaml
<companion_cube>
I mean, OCaml is a great language, but it's in spite of its stdlib, not thanks to it
<companion_cube>
(I find some parts of the stdlib great, btw)
<pierpa>
in the case of Str it's really difficult to understand the rationale of this implementation
<adrien>
"I only need this much for that small thing"
<adrien>
rince and repeat a few times
<pierpa>
hmmm
<companion_cube>
I don't even think the stdlib should necessarily contain a regex lib
<companion_cube>
but it should have a much richer String module
noddy has joined #ocaml
<pierpa>
unicode based
<companion_cube>
well, I'm not sure, it would break too many things
<companion_cube>
String is a sequence of bytes
<pierpa>
surely is better than *everything broken* as is now
<companion_cube>
then, of course, a UString module would not hurt
<pierpa>
not using unicode in 2016 is completely broken
<companion_cube>
well you can store utf8 in string
<companion_cube>
and use uutf & al
<pierpa>
it should be in the standard library
<companion_cube>
a "problem" is that there are too many unicode things that could/should go in the stdlib (like normalization, comparison, etc.)
<companion_cube>
but at least, yeah, some UString type + iteration would be nice
<pierpa>
unicode is complex, sure
silver has joined #ocaml
<flux>
pierpa, you know what else is broken? tools that don't work with files in the file system because they don't happen to be utf8-encoded ;)
<_y>
does that ever exist?
<flux>
linux filesystems (except jfs) just store file names as a sequence of bytes.
<pierpa>
flux, that can be solved easily: encode everything in utf-8
<flux>
they are not utf8-encoded. if they are, it's because the applicatino decided to encode that in utf-8.
<flux>
pierpa, so you have this scanner tool and user does touch $(echo "don't touch thiäs" | iconv -f utf8 -t iso-8859-15) and boom ;)
<companion_cube>
gah, can't find a mail on the archive
<mrvn>
flux: and file not found errors because you can't type in some of the forms ebcause the software will write it differently
<pierpa>
file systems could offer a string api and a byte api
<mrvn>
pierpa: no
<pierpa>
why
<mrvn>
because the byte api is universal
<_y>
where you would have discarded compatibility with any previous charset, reordered the code points in a smart and neat way, removed duplicates, maybe even removed the precomposed graphems, etc·?
<companion_cube>
we have to deal with the current state of things, not try to revolutionize file systems and OSes
<companion_cube>
_y: it would be nice in theory, but terrible in practice
<mrvn>
pierpa: parse the utf-8 to bytes in libc if you want
<pierpa>
the byte api is exactly for dealing with the current state
<_y>
companion_cube, yes of course, because of the complete incompatibility and the shift effort required
<companion_cube>
exactly
<companion_cube>
so let's not even discuss this :p
badon has quit [Quit: Leaving]
<_y>
but still i would like to know if the complexity of unicode is intrinsic or is only a technical debt
<pierpa>
(then people wonders why ocaml has not conquered the world :)
<mrvn>
_y: it's both
<_y>
s/technical/historical/
<pierpa>
is mostly intrinsic
<pierpa>
only minor details could have been done better
<mrvn>
_y: it's not historical since it was made from scratch
<mrvn>
well, apart from embedding ascii and that's not the problem.
<_y>
mrvn, well, it was made to be compatible with ascii, latin1, and other encodings if i’m not misleaded (at least include all the existing characters of the previous charsets)
<companion_cube>
pierpa: heh, libraries and build systems are probably what make the learning curve so steep
<mrvn>
_y: it's only compatible with ascii
<_y>
mrvn, you are speaking of utf8
<companion_cube>
latin1 should die anyway
<mrvn>
_y: yes. the only thing that matters for files
<pierpa>
something we can agree upon :)
<_y>
mrvn, do you know utf16 is much more interesting for all the asiatic people out there?
<pierpa>
it is interesting if they don't want to write international software
<mrvn>
_y: It isn't. it's wastefull fgor anything english and not enough for anything else.
<mrvn>
_y: also you are never supposed to care. the library takes care of that for you.
<pierpa>
actually the first 40000 unicode chars are enough for almost every living language
<mrvn>
pierpa: and UTF-16 only has 32767 I believe
<pierpa>
no
<pierpa>
more
badon has joined #ocaml
<pierpa>
has 2**16 - a few thousand
<pierpa>
and to be exact, we are talking of ucs-2
<pierpa>
utf-16 can represent all of unicode
<_y>
in fact, the fixed part of utf-16 is exactly sufficient to code all of the “almost every living language” part of unicode
<_y>
there may be additional math symbols beyond U+FFFF, but the common mathematical blocks are below
<mrvn>
You have to parse them as uint16_t and can't store them in C char *.
jwatzman|work has joined #ocaml
<pierpa>
big loss :)
<mrvn>
If you are Windows you can just rewrite the world and make everything use wchar. But the rest is stuck with bytes.
<pierpa>
hence the success of utf-8
<_y>
10:53 <mrvn> _y: It isn't. it's wastefull fgor anything english and not enough for anything else. → utf8 is only more interesting for latin‐based alphabets, not even greek, cyrillic or arabic
<adrien>
but even for others, the size increase is moderate
<_y>
and its variability sucks
<mrvn>
also: "UTF-16 and UTF-32 do not have endianness defined, so a byte order must be selected when receiving them over a byte-oriented network or reading them from a byte-oriented file."
<_y>
adrien, the others are a large majority of humanity
<mrvn>
_y: shoudl have said everything else, not anything else.
<mrvn>
_y: utf-16 is variable length too. high/low surrogates AND combining characters. You just notice later that your code is bogus when you screw that up.
<companion_cube>
_y: how is utf8's variability a problem?
<_y>
mrvn, but it varies less, and you can rather reasonably choose to use ucs-2
<mrvn>
_y: no, you can't just assume it's fixed length. That will break horrible. And if you have to handle variable length then utf-8 or utf-16 makes no difference.
<_y>
i said ucs-2, not utf-16
<_y>
oh well, no emoji…
<mrvn>
_y: same thing
<mrvn>
you always have combining characters screwing you over
<pierpa>
ucs-2 is BMP only, so is ficed length
<pierpa>
*fixed
bba has joined #ocaml
Simn has joined #ocaml
<mrvn>
oh, you mean the earlier fixed with one. "once it became clear that a fixed-width 2-byte encoding could not encode enough characters to be truly universal."
<mrvn>
still screwed
anoisz has joined #ocaml
<_y>
companion_cube, true
<companion_cube>
so, anyway.
<pierpa>
can't encode egyptian hierogliphs chinese characters that nobody has ever used in the last 1000 years, and the like
<companion_cube>
come on, unicode support means supporting everything, otherwise there really is no point
<mrvn>
did ucs-2 realy have no composition?
<pierpa>
composition are present also in ascii
<pierpa>
if I write gl this is one sound to me
<mrvn>
pierpa: but no precomposition so that is ok.
<pierpa>
right
<_y>
my thoughts were more about making software a minima unicode‐aware without caring to much about all of unicode features
<_y>
that would already be great
<mrvn>
The need to normalize is the biggest problems I have with universal language support
<companion_cube>
_y: so, just support utf8 :p
<companion_cube>
there is UChar now, and we need UString imho
<pierpa>
you can normalize on input, then use only operations which maintains the normalization
jimt has joined #ocaml
<mrvn>
wee need a standard module, 3 different modules are insane. Lets write one covering them all.
<mrvn>
.oO(Oh, we have 4 modules)
<pierpa>
:)
<pierpa>
that's the reason it must be in the standard library
<_y>
companion_cube, ”s[i] — oh shit what is happening” :s
<mrvn>
all 3 still have problems I think. so which one do you pick?
<companion_cube>
_y: UString should not provide this, of course.
<mrvn>
_y: we already have String and Byte causing that problem.
<mrvn>
what's one more?
<_y>
so let’s not solve it?
<companion_cube>
I think we should have, in UString, type t = private string
<companion_cube>
and only iteration, printing, concatenation, etc. functions
<companion_cube>
not random access
<companion_cube>
String is still very useful
<mrvn>
companion_cube: I think UString should provide them, as in "open UString" or "UString.[]"
<companion_cube>
no!
<companion_cube>
indexing on unicode strings is slow
<companion_cube>
and it doesn't make much sense anyway
<flux>
it makes point to index by iterator ;)
<pierpa>
it depends on the representation
<mrvn>
companion_cube: one could use normalizes ucs-32 with only precompositions
<companion_cube>
;_;
<flux>
I mean it's a super-common way to access substrings: find a character, index by the character at -1, 0, or +1 offset
<companion_cube>
please please please make UString compatible with String, as in utf8
<mrvn>
flux: index#prev, index#next
<pierpa>
you can have strings as vectors of scalar values, like Racket does. Or strings as utf-8 sequences not addressable directly, like Go does.
<companion_cube>
utf8 sequences are much better, you can keep all the old IO libraries, for instance
<companion_cube>
you don't have to allocate and copy twice as much
<companion_cube>
you can directly output strings
<mrvn>
companion_cube: only if your API speaks utf-8
<companion_cube>
my API speaks bytes
<mrvn>
companion_cube: your display api, your xterm
<companion_cube>
and it should not speak anything but utf8 in practice
<companion_cube>
well, obviously
<mrvn>
except windows speaks utf-16
<pierpa>
bytes api can be retired :)
kamog has quit [Remote host closed the connection]
<adrien>
afaik it's not exactly even ucs-2
<mrvn>
adrien: it wouldn't be microsoft if they would follow a standard.
<adrien>
_y: but afaik, for typical cases, utf-8 isn't bigger because data is often mixed with markup which is ascii
<companion_cube>
pierpa: are you kidding
ygrek_ has quit [Ping timeout: 276 seconds]
<adrien>
mrvn: well, to their discharge, they implemented that really early
<companion_cube>
no byte API => no posix compatibility
<mrvn>
no byte API => files become unreadable and unreachable.
<companion_cube>
this discussion is yet another argument in favor of keeping unicode out of the stdlib :
<companion_cube>
:(
<_y>
adrien, you hit a point
<_y>
adrien, how is Windows not implementing ucs-2 properly?
<adrien>
but in any case, it's cat pictures which clog the internet tubes, not text :P
Reshi has quit [Ping timeout: 250 seconds]
<adrien>
_y: trying to find references
<pierpa>
bytes apis will be handled as bytes. If you want to open a file giving a string as name, the api will have to do the conversion. If a file name is not a valid string the one will have to use the byte api
<pierpa>
-the+then
<pierpa>
and since using the byte api will be a pita this will be a great incentive to let it die :)
<companion_cube>
good luck with your alternative standard library ;-)
<pierpa>
I don't have the power to do it
<companion_cube>
then this will not happen, because I don't think the OCaml maintainers will break every single OCaml program by removing bytes APIs
<mrvn>
pierpa: on the other hand the bytes only api walks flawlessly with utf-8 and everyone will just always use bytes.
<mrvn>
s/walks/works/
<companion_cube>
yep
<companion_cube>
utf8 is the way to go
<pierpa>
isn't your objection to unicode that filenames are bytes and not utf-8?
<mrvn>
pierpa: no
<pierpa>
so they don't work flawlessly together
<companion_cube>
filenames, IOs, every C call, etc.
<pierpa>
ok, I said filenames to be short
Reshi has joined #ocaml
<mrvn>
every utf-8 string is bytes, not every bytes is an utf-8 string.
<pierpa>
yes
<companion_cube>
afaik, rust uses utf8 almost everywhere
<companion_cube>
and they have [u8] for low level byte manipulation
<mrvn>
and usualy you just ignore that fact.
nnhb has quit [Ping timeout: 250 seconds]
iorivur has quit [Ping timeout: 268 seconds]
<_y>
do you think the galactic empire computers will still use ascii-compatible encodings?
<_y>
without even knowing where such a weird thing comes from, nor what “ascii” means
<Drup>
_y: wrt to the galactic empire, I'm far more scared about date and hour libraries in the presence of relativistic travels.
<pierpa>
that will be a mess :)
FreeBirdLjj has quit [Read error: Connection reset by peer]
FreeBirdLjj has joined #ocaml
antkong has joined #ocaml
<_y>
the galactic empire should write hangul in my opinion
vcfg has joined #ocaml
<_y>
Drup, very true
yegods has joined #ocaml
zpe has quit [Remote host closed the connection]
<_y>
Drup, so a timestamp would become a four‐dimensional space‐time point
<_y>
and we would have one locale per planet
<mrvn>
_y: that's how stardates work
<_y>
sounds so fun
<_y>
i can’t wait
<mrvn>
everybody has their own time and as you travel from A to B time adjusts. Now when you pass close to C along the way time can go back and forth.
<_y>
i though you couldn’t go back in time, whatever path and with you follow
<chelfi>
(ocaml beginner here) is there some canonical place where one can find the equivalent of monad, applicative, traversable and other instances for commonly used types ?
<_y>
-and with
<_y>
and that you could only have your local time advance faster or slower
<mrvn>
_y: like they do in half the movies?
<mrvn>
_y: they can go back in time, that's how they explain why certain episodes happen at the same time at different places. :)
<_y>
oh, you were talking about stargate :p
rossberg has quit [Ping timeout: 264 seconds]
<mrvn>
_y: no, startrek
<_y>
oops
<mrvn>
Stargate runs on earth time or something. It's never mentioned I think.
<_y>
mrvn, there is an episode with a black hole in which they see people trapped and moving moore and mooooore sloooowly juste before the planet they are on is destroyed
<mrvn>
_y: doesn't affect their time system.
<_y>
but apart from that the wole concept around the stargate is unrealistic at possible
<mrvn>
_y: the navigation (picking 6 stars on the sides of a cube and then you go to the center of it) makes no sense.
A1977494 has joined #ocaml
A19774941 has quit [Ping timeout: 250 seconds]
bba has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
rossberg has joined #ocaml
dsheets has quit [Remote host closed the connection]
dsheets has joined #ocaml
Reshi has quit [Ping timeout: 244 seconds]
noddy has quit [Ping timeout: 250 seconds]
Kakadu has joined #ocaml
yegods has quit [Remote host closed the connection]
<_y>
exactly
<_y>
but you are distorting the truth
<_y>
there are six symbols for the destination
<_y>
plus
<_y>
one
<_y>
for the starting point
bba has joined #ocaml
noddy has joined #ocaml
noddy has quit [Ping timeout: 268 seconds]
zaquest has quit [Ping timeout: 250 seconds]
copy` has joined #ocaml
noddy has joined #ocaml
dsheets has quit [Remote host closed the connection]
bba has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
Reshi has joined #ocaml
yegods has joined #ocaml
fraggle_ has quit [Remote host closed the connection]
<seliopou>
companion_cube: any idea what the userbase of batteries is?
ohama has joined #ocaml
<seliopou>
size-wise, i mean.
hxegon_AFK has quit [Quit: BRB]
gasche has joined #ocaml
<flux>
probably very difficult to come up with any numbers describing any ocaml package or even the ocaml compiler itself :)
<companion_cube>
I don't know :/
<companion_cube>
but it's certainly used
<gasche>
seliopou: could you come up with performance numbers backing up your claim that going through a Buffer would be unreasonable for your use-case?
hxegon has joined #ocaml
<companion_cube>
o/ gasche
vcfg has quit [Quit: Page closed]
<seliopou>
gasche: in a week or two. the library that would use this is not done yet, but will likely be used to replace the parse/serialization layer of cohttp
<seangrove>
seliopou: You know better than I do, but I'm pretty dubious about the mixing of mutable/immutable structures in ocaml
<companion_cube>
gasche: it's probably obvious, but I suppose the switch to result in batteries is for 3.0?
<seliopou>
it's all possible without this, it's just a nicer interface for the users of the library.
<gasche>
companion_cube:
<companion_cube>
seliopou: that's what I like :D
<gasche>
yes, so the idea is to release 3.0 around 4.03
<seliopou>
seangrove: what are you referring to?
<companion_cube>
but you would rely on the 'result' package, wouldn't you?
<companion_cube>
(or cppo magic)
<gasche>
I don't know
<seangrove>
seliopou: Sorry, might have misunderstood - what library and safety were you referring to?
<seliopou>
seangrove, it's a pr to the ocaml compiler to change the format api
<gasche>
companion_cube: I haven't looked at the details, but there is KC's pull request
<seliopou>
to support a serialization library that i'm writing
<gasche>
I have limited time to work on the 3.0 release, so any outside help is warmly welcome
<seliopou>
or more precisely, to support a nice interface that doesn't block unnecessarily for the users of the serialization library
<gasche>
thanks for the listing of issues to take action on, by the way
<seangrove>
seliopou: Misunderstood, sorry
<seliopou>
no prob bob
<companion_cube>
✔
Reshi has quit [Quit: WeeChat 1.4]
<companion_cube>
so I am also in the process of releasing containers soon...
<gasche>
the main Batteries issue for 4.03 is that we used our own 'result' type for a while, and of course the constructor names are not the same as 4.03's result
<gasche>
which means that users using 'BatPervasives.result' will have to adapt their code
<gasche>
that's what you get for being in advance on your time :-^
dexterph has quit [Remote host closed the connection]
dexterph has joined #ocaml
<companion_cube>
yeah I know
<companion_cube>
it's tedious, but unavoidable
<companion_cube>
I wonder if a ocp-sed could be done, since ocp-grep exists :D
<companion_cube>
to replace BatResult.Bad by BatResult.Error automatically
<gasche>
I'm been asking for someone to implement this for ages
<gasche>
and had a in-depth discussion about this with def`
<gasche>
I want a printer that takes an AST that we know is closed to the result of parsing a given file, and prints it back into source code with the guarantee that the parts that are not modified (from the original file) are printed in exactly the same way
<gasche>
that's the hard part
hxegon is now known as hxegon_AFK
<gasche>
(in other words: you know that if you run a textual "diff", only the parts that were modified will show up)
hxegon_AFK is now known as hxegon
<companion_cube>
ah, right
<gasche>
once you have that, "go fix" is easy
<companion_cube>
(also, needs to preserve comments)
dexterph has quit [Remote host closed the connection]
<companion_cube>
hmm, I understand this feature request, and its goal, but I think that's just delaying the problem
<companion_cube>
(unrelated: glad that Damien agrees on stdlib discussions, we had one here this morning on unicode strings...)
hcarty has quit [Ping timeout: 252 seconds]
dexterph has quit [Remote host closed the connection]
dexterph has joined #ocaml
<gasche>
seliopou: if I understand correctly, you could work with `pp_print_flush` from now on, do measurements once your library is testable, and come back with hard numbers of the impact of the extra explicit flush
<gasche>
(I hope that it also wouldn't be too much work for you to switch, for testing purposes, to a Buffer-ing implementation at that time.)
<seliopou>
gasche: thanks for the concise summary on the discussion. pretty much nailed it.
seangrove has quit [Remote host closed the connection]
<seliopou>
gasche: I could do that.
seangrove has joined #ocaml
<seliopou>
I get the distinct impression, though, that I will get run in circles regardless. :/
hcarty has joined #ocaml
hxegon is now known as hxegon_AFK
<seliopou>
To be clear though, the library would ship without the format-based API. I'd do all this afterwards in a fork or two to do the comparison.
dexterph has quit [Remote host closed the connection]
dexterph has joined #ocaml
noddy has quit [Ping timeout: 246 seconds]
<gasche>
It's not always easy to discuss with Pierre, but I'm not sure why you get that impression. In any case, clarifying this point is a rather good thing (if only because it generates some knowledge about how Format works in the community).
hxegon_AFK is now known as hxegon
<gasche>
(please don't forget to include the PR discussion with any decision/plan you have; we shouldn't have information on IRC only)
<gasche>
s/include/update/
<Drup>
"we are shooting for a shorter release cycle next time" <- I remember this sentence in the last release too :D
<gasche>
not sure which release you are referring to, but the time span between 4.02.3 and 4.03 is rather reasonable
rgrinberg has joined #ocaml
<Drup>
I know, I know, it's just a joke (about the 4.03 timeline that keep getting pushed a bit more)
<gasche>
note that external contributors can help making the release happen faster
<gasche>
one method is to go to Mantis, set filter options to see only options assigned to the upcoming release (Target Version = 4.0x+dev), and comment on those that you think it would be reasonable to delay to the next version
<gasche>
(or submit patches for the one that are easy to implement)
<gasche>
Damien is doing this work currently, but it could move faster with external help
<gasche>
(I'm sure anyone doing this efficiently could be given Mantis rights to triage the issues themselves directly)
<gasche>
maybe I should write this information in CONTRIBUTING.md?
MercurialAlchemi has quit [Ping timeout: 276 seconds]
<Drup>
Maybe, difficult to say. Triaging requires a good amount of inside knowledge
<gasche>
I'm not sure about that
MercurialAlchemi has joined #ocaml
Anarchos has joined #ocaml
<hcarty>
gasche: Having that information available would be good. Even better would be that information + a direct link to an appropriate mantis URL with filters applied
<hcarty>
Navigating/figuring out mantis can be a blocker on its own for more casual contributors
<gasche>
indeed
<gasche>
I could try to write some more information on how to use Mantis
<gasche>
(eg.: use google "site:caml.inria.fr/mantis" to look for similar issues)
yomimono has joined #ocaml
<hxegon>
That feeling when you first start seriously practicing FP, and go to work and start thinking about how something would be great to model with types, but your work lang won't cut it >:|
<Drup>
Nothing like java code written by an functional programmer :p
<companion_cube>
java is getting better though, with lambdas and streams
seangrove has quit [Ping timeout: 260 seconds]
bba has joined #ocaml
<hxegon>
I'm using ruby, so I'm not totally high and dry, but algebraic types though.
<gasche>
companion_cube: that's the kind of positive attitude I had before having to use the language for teaching
<companion_cube>
wow, you would teach java8 ?
<gasche>
I think that people considering using a language in a project should have to teach programming with it to first-year university students for a semester
<gasche>
well Java becomes annoying to teach a long time before you can even talk of lambda or streams (or objects, for that matter)
<hxegon>
gasche I feel like your soft skills would atrophy in that kind of environment
<companion_cube>
gasche: I taught a bit with caml light, and it was not glorious :s
<thizanne>
so you don't consider using caml light in a projet ?
<companion_cube>
nope :D
<gasche>
I seem to remember that you replaced me on an OCaml class once
<gasche>
(not sure whether it was OCaml or Caml Light, in fact)
<gasche>
but you should try to teach C or Java, and then compare
bba has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
bba has joined #ocaml
mistermetaphor has joined #ocaml
Anarchos has quit []
BitPuffin has quit [Ping timeout: 240 seconds]
slash^ has joined #ocaml
jeffmo has joined #ocaml
Kyo9142 has joined #ocaml
<hcarty>
gasche: Thanks!
gasche has left #ocaml [#ocaml]
bba has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
bba has joined #ocaml
darkf has quit [Quit: Leaving]
bba has quit [Max SendQ exceeded]
yegods has joined #ocaml
yegods has quit [Remote host closed the connection]
toolslive has quit [Ping timeout: 250 seconds]
yegods has joined #ocaml
tane has quit [Quit: Verlassend]
seangrove has joined #ocaml
yegods has quit [Remote host closed the connection]
hcarty1 has joined #ocaml
yegods has joined #ocaml
hcarty has quit [Ping timeout: 240 seconds]
yegods has quit [Ping timeout: 250 seconds]
leyyin has joined #ocaml
octachron has quit [Quit: Page closed]
toolslive has joined #ocaml
jwatzman|work has quit [Quit: jwatzman|work]
Ch0c0late has joined #ocaml
yomimono has quit [Quit: Leaving]
Kyo9142 has quit [Ping timeout: 244 seconds]
dsheets has quit [Remote host closed the connection]
dsheets has joined #ocaml
bba has joined #ocaml
Ch0c0late has quit [Read error: Connection reset by peer]
seangrove has quit [Ping timeout: 268 seconds]
bba has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
seangrove has joined #ocaml
TheLemonMan has quit [Quit: "It's now safe to turn off your computer."]
yegods has joined #ocaml
bba has joined #ocaml
Ninja123 has quit [Ping timeout: 276 seconds]
dsheets has quit [Remote host closed the connection]
lokien_ has joined #ocaml
seangrove has quit [Ping timeout: 276 seconds]
Kyo9142 has joined #ocaml
shinnya has joined #ocaml
dsheets has joined #ocaml
yegods has quit [Remote host closed the connection]
Kyo9142 has quit [Ping timeout: 244 seconds]
ygrek_ has joined #ocaml
seangrove has joined #ocaml
<flux>
ooh, will ocaml 4.03.0 be released soon?! "I'm really wary of introducing an incompatibility a few hours before the release, .."
Kyo9142 has joined #ocaml
dsheets has quit [Remote host closed the connection]
dsheets has joined #ocaml
sepp2k has quit [Quit: Leaving.]
dsheets_ has joined #ocaml
dsheets has quit [Ping timeout: 276 seconds]
dsheets_ has quit [Ping timeout: 260 seconds]
dsheets has joined #ocaml
dsheets has quit [Ping timeout: 260 seconds]
copy` has quit [Quit: Connection closed for inactivity]
ygrek_ has quit [Ping timeout: 246 seconds]
Ch0c0late has joined #ocaml
<Kakadu>
flux: yesterday link was saying that normal compiler gives an error when implicit compiler hangs
seangrove has quit [Ping timeout: 244 seconds]
ygrek_ has joined #ocaml
shinnya has quit [Ping timeout: 250 seconds]
tane has joined #ocaml
dsheets has joined #ocaml
nicoo has quit [Remote host closed the connection]
copy` has joined #ocaml
Kakadu has quit [Quit: Page closed]
ollehar has joined #ocaml
dsheets has quit [Remote host closed the connection]
iorivur has joined #ocaml
nicoo has joined #ocaml
lokien_ has quit [Quit: Connection closed for inactivity]
Ch0c0late has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
<twobitsprite>
what kind of libraries are available for ocaml for dealing with large, multi-dimensional arrays of arbitrary structures, especially with persistence? I'm aware of the HDF5 library, and there is an Ocaml binding for it, but I was just wondering if there were alternatives, or if there was something more Ocaml-specific...
<twobitsprite>
I assume since Ocaml is common in academia and scientific settings that there would be a lot of libraries like this, but I can't seem to find any...
<companion_cube>
it's not that common in scientific computing
<companion_cube>
more in symbolic processing
<companion_cube>
(but then I don't know)
<twobitsprite>
oh... I just thought I remember seeing a lot of articles about Ocaml that seemed to have a scientific bent...
<twobitsprite>
by symbolic processing, you mean AI systems and compilers/parsers/etc?
<companion_cube>
compilers, parsers, provers...
<companion_cube>
there are some people using it for bioinfo or ML though
<twobitsprite>
ML? (I assume you mean "ML" as something other than the ML language family...)
<_y>
machine learning
<twobitsprite>
ahh, of course, derp
Kyo9142 has quit [Ping timeout: 276 seconds]
<companion_cube>
using ML for ML, what's the problem? :p
<twobitsprite>
hahah
manizzle has quit [Ping timeout: 260 seconds]
<twobitsprite>
I've actually thought about writing a stack-based language that compiles to OpenCL/LLVM to run genetic algorithms on GPUs...
<Drup>
that domain is actually a bit populated in OCaml
<twobitsprite>
Drup: oh?
<Drup>
(the llvm bindings are decent, and wrt to GPGPUs, there is SPOC)
<companion_cube>
OCaml should be nice for writing a language, yeah
<companion_cube>
Drup: tbh I'm not sure spoc is production ready
<companion_cube>
it really looks like a research prototype
<Drup>
it probably isn't, but regardless, it's interesting if you are going to spend time working on something similar
<twobitsprite>
yeah, I've seen SPOC, but, yeah, it seems kind of toy-ish... also, nothing about stack-based languages or GA
ollehar has quit [Quit: ollehar]
<twobitsprite>
meh, it's mostly just something I think about casually, not something I've seriously considered doing... I don't even know what I would do with it...
<twobitsprite>
I've thought about writing a system that learns to play Go, but unfortunately, GAs are notoriously bad at highly complex goals...
<companion_cube>
Drup: I don't know, there is room for several ideas in this space :)
<companion_cube>
I like the stack language idea actually
<twobitsprite>
stack languages are much easier to mutate and merge
<twobitsprite>
the problem is, the only useful work in stack languages can be done by augmenting the language with syntax and non-stack storage... trying to do complicated computations purely on the stack quickly becomes extremely ineffecient...
Anarchos has joined #ocaml
<companion_cube>
I read something about a stack language designed for GA, some time ago
<companion_cube>
pop3, I think it was called
Anarchos has quit [Client Quit]
Anarchos has joined #ocaml
<twobitsprite>
yeah, it has separate stacks for each base data type... i.e., an int stack, a float stack, etc... so any operation that deals with floats doesn't accidentally pull an int off the stack, etc
<companion_cube>
yeah
<twobitsprite>
pretty novel concept... but again, it's a way of trying to get stack languages to work without doing everything on the (one) stack... if you look at any real program written in something like Forth, you'll see they make extensive use of syntax extensions and non-stack storage like variables and heap memory... which defeats the simplicity of stack based languages that GAs rely on.
<Drup>
"real program written in something like Forth" :d
<twobitsprite>
Drup: your BIOS is likely written in something like Forth...
<Anarchos>
Drup openboot ?
<twobitsprite>
Stack-based languages are very popular for embedded systems without an OS... Forth-derived languages are very simple to compile and very efficient without OS/runtime support.
<Drup>
twobitsprite: can I have a reference for the BIOS ?
<Drup>
(not that I don't believe you, I'm actually curious)