<companion_cube>
just to avoid copying it between string and array (and vector and bigarray and...)
<companion_cube>
Drup: is it free?
<whitequark>
Drup: ew.
<whitequark>
that rendering is disgusting.
<struktured>
companion_cube: your picture of a hypercube reminded me something. what was the motivation for the hypergraph module in containers? Pretty cool, but curious to know if anyone actually uses it.
<rgrinberg>
struktured: it's cruft :D
<companion_cube>
struktured: oh, it's an experiment, really. I wanted to try to write a generalized hypergraph because it's the most general structure I can think of
<companion_cube>
but it would require a lot of work to be nice
<Drup>
rgrinberg: not cruft
jabesed has joined #ocaml
<companion_cube>
that's why it's in misc/
<Drup>
it's companion_cube's playing
<Drup>
-s
<Drup>
(it's not the only thing in containers that is only toying "I wanted to write that")
Haudegen has quit [Ping timeout: 260 seconds]
<companion_cube>
struktured: can you look at containers' master's _oasis file please? i've split it into several sub-libraries
<companion_cube>
Drup: yes, it used to be a playground, and misc/ is still one
<companion_cube>
but it's written in bold in the readme.
<struktured>
companion_cube: will do although I was already a bit confused by how gen got thrown into the build system
<whitequark>
what's a hypergraph?
<companion_cube>
well, I'm thinking of removing CCGen and CCSequence since they live in their own libraries
<companion_cube>
whitequark: like a graph, but the edges are n-ary instead of binary
<struktured>
companion_cube: on another note, I almost used the regular graph, but I couldn't figure out how to distinguish nodes of the same value (for instance, how would you model the k-coloring graph problem with it) ?
<Drup>
struktured: use ocamlgraph
<Drup>
companion_cube's lazygraph is funny
Haudegen has joined #ocaml
<Drup>
but ... that's all :p
<companion_cube>
yeah, lazygraph can be fun for printing to DOT
<companion_cube>
otherwise, use ocamlgraph
<Drup>
(very funny, though)
<companion_cube>
misc/ is really for not production-ready stuff
<companion_cube>
why won't anyone comment on my split -_-
<rgrinberg>
batteries has a shit ton of tests and there's still the odd embarassing bug :/
<Drup>
rgrinberg: which one ?
<Drup>
companion_cube: told you, cooking, will do after
<companion_cube>
Drup: IO + Enum are a giant bug
<companion_cube>
"quand je veux faire passer un message, j'utilise les PTT"
<Drup>
sure, but I don't think rgrinberg is thinking about this one
<struktured>
Drup: it wasn't lazy graph, it was persistent. but thanks for the ocamlgraph recommendation. will consider it using it next time, or if I want to optimize my existing code some more
<struktured>
whitequark: a simple way to think of hyper graphs is you just circle a group of nodes together rather than draw edges between them.
<whitequark>
hmmm
<whitequark>
cool
<rgrinberg>
ok my post is ready i think
<rgrinberg>
:D
<rgrinberg>
thanks all
<companion_cube>
baaad bug
chambart has quit [Ping timeout: 272 seconds]
AltGr has joined #ocaml
samuel02 has joined #ocaml
rgrinberg has quit [Quit: Leaving.]
mcc has joined #ocaml
mcc has quit [Client Quit]
mcc has joined #ocaml
samuel02 has quit [Ping timeout: 260 seconds]
<companion_cube>
hmmm, shall I remove gen/sequence...
<Drup>
yesyesyes
<Drup>
remove them, let them live in their own packages, and don't duplicate them.
nojb has joined #ocaml
<companion_cube>
whitequark, struktured ? an opinion?
<struktured>
companion_cube: yeah just do it. I like small projects
<struktured>
companion_cube: also I sometimes get weird errors in utop when I load both cntainers and gen together anyhow
<companion_cube>
ok
<Drup>
struktured: ocamlgraph also has the benefit that most of what you want is already there
<Drup>
k-coloring is already there, for example
madroach has quit [Ping timeout: 250 seconds]
madroach has joined #ocaml
NoNNaN has quit [Remote host closed the connection]
<struktured>
struktured: that was just an example. in my case I just wanted a slightly more efficient solution for mapping polymorphic sequences to values than hashing every observed sequence in a map.
<struktured>
drup, not struktured oops
NoNNaN has joined #ocaml
thomasga has quit [Quit: Leaving.]
travisbrady has joined #ocaml
<struktured>
is there an infix operator somewhere with this signature in the main ocaml lib? 'a -> ('a -> 'b) -> 'b
<struktured>
looks like @@ is the closest. maybe I can use that
<nojb>
|>
<struktured>
nojb: nice! thanks.
<whitequark>
Drup: oh
<whitequark>
it downloaded
<Drup>
oh ?
<companion_cube>
well, next release of containers will have new sub-libraries and no gen/sequence
kakadu has quit [Remote host closed the connection]
<mcc>
...out of curiosity
<mcc>
say I have a function fun n -> match n with | 3 -> 3 | _ -> failwith "fail"
<mcc>
What is the return type of "failwith", and why does the static typer allow it?
<companion_cube>
it's 'a
struktured has quit [Ping timeout: 255 seconds]
<companion_cube>
because failwith never returns
<mcc>
ok
struktured has joined #ocaml
struktured has quit [Ping timeout: 250 seconds]
seanmcl has joined #ocaml
ontologiae_ has joined #ocaml
antinomy has quit [Ping timeout: 244 seconds]
pyon has quit [Excess Flood]
travisbrady has quit [Quit: travisbrady]
pyon has joined #ocaml
<companion_cube>
well,new logo for containers, and a bunch of breaking changes
<whitequark>
mcc: "how can I treat the return type of x?" "x never returns" "anything goes then, sweet"
<whitequark>
which is the reason it's 'a (which was unintuitive for me)
badon has quit [Quit: Leaving]
<Drup>
mcc: you can also see that with "let f () = f ()"
<Drup>
let rec*
samuel02 has joined #ocaml
<Drup>
which is happily of type unit -> 'a
nojb has quit [Quit: nojb]
samuel02 has quit [Ping timeout: 244 seconds]
antinomy has joined #ocaml
mcc has quit [Quit: This computer has gone to sleep]
<Drup>
companion_cube: why are CCKTree, CCKList separated from containers.data ?
<Drup>
why are Vector not in data ?
<Drup>
(and Heap)
<Drup>
note that, given how oasis/ocamlbuild, since everyone is in the same directory, they could pretty much depend on each other fine, subproject don't ensure non-dependency, here
<Drup>
(you have an extra "," line 94, and I'm very surprised oasis parses that)
<companion_cube>
well, vector and heap really should be in the stdlib
<companion_cube>
yeah, I'm fixing it right now
<Drup>
ok
<whitequark>
so, I unpacked all opam packages
<whitequark>
6.3G
<Drup>
outch
travisbrady has joined #ocaml
<whitequark>
huh?
<Drup>
companion_cube: containers.lwt really depends on misc ?
<whitequark>
I have a 500G SSD, I'll grep them in no time
<Drup>
whitequark: nothing, that's a lot of sources :D
<companion_cube>
Drup: there is some cruft in there
<Drup>
ok
<companion_cube>
it should be in misc.lwt really
<Drup>
companion_cube: cgi D:
<companion_cube>
rha
<Drup>
to quote whitequark
<Drup>
BURN
<companion_cube>
submit a PR to get rid of it
<whitequark>
oh god
<whitequark>
oasis uses Stream
<Drup>
oh crap
<Drup>
companion_cube: do one document.
struktured has joined #ocaml
<Drup>
there is not real point doing lot's of documents like that
<Drup>
companion_cube: you should do some index though, to make a nice intro separating the projects
<Drup>
(look at batteries or lilis or lwt for how to do it)
<companion_cube>
I always forget how to make such index files
<Drup>
also companion_cube
<Drup>
(03:26:20) companion_cube: whydid you submit a non-compiling PR? :((
<AltGr>
if the plugin by def-lkb it's better than the one shipped with ocp-indent, I guess it should replace it
<Drup>
because you have non compiling commits.
<rgrinberg>
AltGr: it has the disadvantage of depending on python
<companion_cube>
fair enough
<AltGr>
ah, right
<rgrinberg>
which is "almost" always available
<Drup>
companion_cube: look at batterie's intro.
<Drup>
(just make a better one :p)
jabesed has quit [Ping timeout: 265 seconds]
lordkryss has quit [Quit: Connection closed for inactivity]
<icicled>
Earlier today I wrote a line yielding thingie using Streams. A few of you kind folks suggested using anything but Streams :) Soo, this evening I looked into Gen & skimmed over it's source & I have to say - it's bloody simple & easier than Streams. Also it's about 2x faster according to my newbie benchmark (http://lpaste.net/3707846379033329664)!
<icicled>
Thanks! </p>
ontologiae_ has quit [Ping timeout: 244 seconds]
<Drup>
:)
<struktured>
nice
<whitequark>
>let () = ignore (Buffer.reset b) in
<whitequark>
you can do just Buffer.reset b;
<icicled>
will do!
bytbox has quit [Remote host closed the connection]
<companion_cube>
Drup: that's ok, I fixed it
<AltGr>
rgrinberg: my first goal is to make it easier to get a good setup from scratch ; I'm doing it through an opam package in the hope that it'll be reusable and will attract contributions more easily (in contrast with the previous shell-scripting hacks for opam-in-a-box with Docker, Vagrant...=
<icicled>
updated & added benchmark results
cdidd has quit [Ping timeout: 272 seconds]
<Drup>
there is no Gen.from_string ?
<Drup>
Gen.of_string
<companion_cube>
maybe in the last version
<Drup>
icicled: instead of your string_gen
<Drup>
(also, the way you do it is .. dubious :p
<Drup>
you should rather test the index against the length of the string
<Drup>
instead of using an handler
<companion_cube>
icicled: glad to hear you find gen simple :)
<companion_cube>
rgrinberg: can I put "colorize ocamldoc" on your todolist? ;)
<companion_cube>
gosh, I need a css for ocamldoc
jabesed has joined #ocaml
jabesed has quit [Client Quit]
<rgrinberg>
companion_cube: have you tried argot?
<Drup>
icicled: why do you do Some (Some ..) ?
<Drup>
you can cut one level and avoid the last part of the function completely
travisbrady has joined #ocaml
<Drup>
just do "let line = Buffer.sub b 0 (blen-2) in" instead of the current version
<whitequark>
companion_cube: use dbuenzli's
<Drup>
I don't like dbuenzli's, too light :/
<companion_cube>
yes, that's a possibility
pyon has quit [Remote host closed the connection]
cdidd has joined #ocaml
<companion_cube>
Drup: documentation is starting to look ok. So you want vector/heap to move to containers.data?
Yoric has joined #ocaml
<Drup>
I don't want, I just say it would be logical, in some sense
samuel02 has joined #ocaml
<companion_cube>
I understand the point, but otoh I feel like Heap and Vector are more fundamental than the modules from containers.data
<icicled>
thanks for the pointers Drup. I'll look into it
<icicled>
Drup: you're right about the double Some - copy/pasta at work there
seangrove has quit [Ping timeout: 255 seconds]
seangrove has joined #ocaml
alkoma has joined #ocaml
alkoma has quit [Remote host closed the connection]
alkoma has joined #ocaml
<icicled>
Also, yes, string_gen should be written w/o the try handler - I was using that as a template for when I don't know how long the source input would be (which is wrong :) )
<icicled>
thanks for having a look!
MercurialAlchemi has joined #ocaml
icicled has quit [Ping timeout: 256 seconds]
<struktured>
finally realized why ocaml often feels more difficult to me than some other languages- it's because I'm spending more of my time thinking about difficult problems and less about boiler and plumbing.
mcc has quit [Quit: This computer has gone to sleep]
samuel02 has joined #ocaml
<ggole>
Dunno, I find there's a fair amount of makework in programming ocaml.
<ggole>
Maybe a bit less than in some other languages.
<struktured>
I'm a professional java developer...so...yeah
<struktured>
python I still feel faster in than ocaml though, but not without consequence
samuel02 has quit [Ping timeout: 244 seconds]
<struktured>
ggole: in ocaml, do you design your mlis first, last, or...something else?
<ggole>
Um, depends
<ggole>
Usually I will hack for a while to figure out what the types and operations should probably be, and then add an mli
<Drup>
I design my mlis when I feel like I will not change the API completely anymore
<ggole>
Sometimes I will write the mli first if I have a particularly clear understanding of what is needed.
<struktured>
same, but sometimes I just start with a huge file ml of module type definitions until I come up with a good design, then implement after.
pyon has joined #ocaml
<ggole>
Sigh, first class polymorphism always makes me sad
<struktured>
I wonder if merlin could do something slick to keep them in sync easier
<ggole>
Going through a stupid damn record feels like such a waste of time.
kapil__ has quit [Quit: Connection closed for inactivity]
* ggole
works around it with a ridiculous hack
<struktured>
ggole: so I understand better, can you provide a simple of example of a design choice without it vs with it? and do you mean from an API standpoint, or even for internal implementation details?
<ggole>
Er, what 'it' do you mean?
<struktured>
ggole: first class polymorphism vs not using it. I assume u mean something like type foo = { f: 'a -> b} ??
<ggole>
Oh, right.
<ggole>
Say you want to pass in a choice of polymorphic comparison function
<ggole>
If you just do that directly, the argument will not be polymorphic (that's how let-polymorphism works, arguments are not generalized)
<ggole>
The solution to this in OCaml is to go through a record, fields of which can be annotated as polymorphic
<ggole>
Like this: type cmp = { 'a . 'a -> 'a -> bool }
<ggole>
Er, + field name
<struktured>
wait whats that syntax? confused by the first 'a . do you mean something like type 'a cmp = {f: 'a -> -'a -> bool} ?
<struktured>
and the "."
<ggole>
This is universal quantification.
<ggole>
It means the type of the record is a function 'a -> 'a -> bool for all 'a.
<ggole>
That is, the function must be polymorphic.
marynate has joined #ocaml
<ggole>
Read 'a . stuff as "forall 'a, stuff"
<ggole>
With the field name it would be type cmp = { f : 'a . 'a -> 'a -> bool }
alkoma has quit [Remote host closed the connection]
<struktured>
just played around with it in utop to get a feel for it. it actually prevents you from narrowing the types when you attempt to bind a function to f. that's somewhat interesting
<ggole>
Yes, that's what allows the argument to be used polymorphically within the body of a function.
marynate has quit [Ping timeout: 255 seconds]
marynate has joined #ocaml
kapil__ has joined #ocaml
slash^ has joined #ocaml
marynate has quit [Quit: Leaving]
samuel02 has joined #ocaml
<MercurialAlchemi>
ggole: while it's a bit annoying, it's not a huge increase in keystrokes compared to some other languages I know
samuel02 has quit [Ping timeout: 244 seconds]
<ggole>
It's a record definition (duplicated in the mli, possibly), a record construction at every argument site, and a field access at every call site.
<ggole>
All entirely mechanical transformations - pretty clumsy, if you ask me.
<ggole>
Fortunately the need doesn't arise often.
Anarchos has joined #ocaml
Yoric has joined #ocaml
marynate has joined #ocaml
kakadu has joined #ocaml
seangrove has quit [Ping timeout: 256 seconds]
tane has joined #ocaml
avsm has joined #ocaml
martintrojer has quit [Max SendQ exceeded]
martintrojer has joined #ocaml
samuel02 has joined #ocaml
samuel02 has quit [Ping timeout: 244 seconds]
gdsfh1 has joined #ocaml
gdsfh has quit [Ping timeout: 272 seconds]
samuel02 has joined #ocaml
<companion_cube>
struktured: I tend to write the mli first, then I alternate between changing mli and ml
<mrvn>
I usualy write .ml. And when I need to I "ocamlc -i >.mli .ml" and clean it up.
tane has quit [Quit: Verlassend]
thomasga has joined #ocaml
oscar_toro has joined #ocaml
avsm has quit [Quit: Leaving.]
marynate has quit [Read error: Connection reset by peer]
* dmbaturin
likes ocamlc -i a lot
manud___ has joined #ocaml
<ggole>
It would be more useful if it appended any missing identifiers at the end, imo
Simn has joined #ocaml
chinglish has joined #ocaml
<dmbaturin>
ggole: Missing as in referred to in the code but not defined anywhere?
<ggole>
As in, you could append new definitions to an existing .mli
<dmbaturin>
After hand editing it?
<ggole>
Sure, why not?
manud___ has quit [Client Quit]
<dmbaturin>
Just checking if I get what you mean. Agree, this would be cool.
<ggole>
Some of the appended bits would no doubt be internal stuff, but you could just delete those
<mrvn>
better make that an extra option "ocaml --update-mli" or something.
<mrvn>
or ocamlc --diff-mli
<ggole>
And leave -i as it is? That sounds sensible.
<mrvn>
Idealy I would like to not have mli at all. Mark things "protected" in the ml file, annotate the types as needed and then generate the cmi from the .ml.
Yoric has quit [Remote host closed the connection]
jao has quit [Ping timeout: 250 seconds]
tane has joined #ocaml
kapil__ has quit [Quit: Connection closed for inactivity]
<Leonidas>
agreed
<Leonidas>
annoys me to no end that once you have an mli you need to do everything twice and the signatures are so disconnected from the sources.
chambart has joined #ocaml
larhat has joined #ocaml
Yoric has joined #ocaml
psy_ has joined #ocaml
slash^ has quit [Read error: Connection reset by peer]
slash^ has joined #ocaml
nojb has joined #ocaml
milosn has quit [Quit: Lost terminal]
waneck_ has joined #ocaml
waneck has quit [Ping timeout: 245 seconds]
tane has quit [Quit: Verlassend]
nojb has quit [Quit: nojb]
psy__ has joined #ocaml
psy__ has quit [Max SendQ exceeded]
__w_a_n_e_c_k__ has joined #ocaml
psy__ has joined #ocaml
rand000 has joined #ocaml
psy__ has quit [Max SendQ exceeded]
psy__ has joined #ocaml
psy__ has quit [Read error: Connection reset by peer]
waneck_ has quit [Ping timeout: 240 seconds]
ygrek has joined #ocaml
_5kg has quit [Ping timeout: 258 seconds]
milosn has joined #ocaml
chambart has quit [Ping timeout: 260 seconds]
ontologiae_ has joined #ocaml
Anarchos has quit [Quit: Vision[0.9.7-H-20140108]: i've been blurred!]
nojb has joined #ocaml
NoNNaN has quit [Remote host closed the connection]
ygrek has quit [Ping timeout: 250 seconds]
ontologiae_ has quit [Ping timeout: 264 seconds]
chinglish has quit [Ping timeout: 245 seconds]
_5kg has joined #ocaml
nojb has quit [Quit: nojb]
Anarchos has joined #ocaml
rand000 has quit [Quit: leaving]
arj has joined #ocaml
ygrek has joined #ocaml
keen___________1 has joined #ocaml
keen___________0 has quit [Ping timeout: 256 seconds]
tane has joined #ocaml
micrypt has joined #ocaml
ygrek has quit [Ping timeout: 265 seconds]
ygrek has joined #ocaml
eyyub has joined #ocaml
AltGr has left #ocaml [#ocaml]
nojb has joined #ocaml
hugomg has joined #ocaml
q66 has joined #ocaml
samuel02 has quit [Remote host closed the connection]
arj has quit [Quit: Leaving.]
antinomy has joined #ocaml
dav_ has joined #ocaml
ygrek has quit [Remote host closed the connection]
ygrek has joined #ocaml
dav has quit [Ping timeout: 244 seconds]
chinglish has joined #ocaml
ygrek has quit [Ping timeout: 245 seconds]
samuel02 has joined #ocaml
samuel02 has quit [Remote host closed the connection]
Yoric has quit [Remote host closed the connection]
samuel02 has joined #ocaml
Yoric has joined #ocaml
Yoric has quit [Remote host closed the connection]
samuel02 has quit [Ping timeout: 240 seconds]
icicled has joined #ocaml
Hannibal_Smith has joined #ocaml
lordkryss has joined #ocaml
ingsoc has joined #ocaml
Thooms has joined #ocaml
Yoric has joined #ocaml
Yoric has quit [Ping timeout: 260 seconds]
AlexRussia has quit [Ping timeout: 250 seconds]
AlexRussia has joined #ocaml
ygrek has joined #ocaml
tani has joined #ocaml
citrucel has quit [Ping timeout: 246 seconds]
tane has quit [Ping timeout: 264 seconds]
bartholin has joined #ocaml
samuel02 has joined #ocaml
kakadu has quit [Read error: Connection reset by peer]
<hugomg>
according to the manual, the bytecode compiler should produce smaller executables than the native compiler. But my main.byte is 18.9 MB while my main.native is just 7.5MB. What gives?
<whitequark>
debug info?
<adrien>
core? :D
<mrvn>
bytecode also needs the interpreter. So for a single binary I bet that is always more.
<adrien>
not really
<adrien>
it won't get into the binary unless you use -custom
<adrien>
and
<adrien>
it's small
<mrvn>
you still need it somewhere
<adrien>
like 150K
<adrien>
it's basically the size of ocamlrun, which is 186KB on my machine
<hugomg>
hmm, let me try again without the debug flag... I also use Core_kernel but dunno if thats gonna affect the relative size
<mrvn>
-rwxr-xr-x 1 mrvn mrvn 173K Dec 13 17:40 foo*
<mrvn>
That's more than an unstripped binary
<mrvn>
-rwxr-xr-x 1 mrvn mrvn 124K Dec 13 17:41 foo*
<mrvn>
stipping doesn't save that much though
<mrvn>
hugomg: doesn't use of core pull in all of core every time?
<tyrion-mx>
it just seems the same to me, but longer
<hugomg>
@mrvn: dunno but I heard they fixed thatn inn 4.02
<ggole>
tyrion-mx: tl is bound to a different part of the list
<ggole>
In the second match, tl is bound to all of (hd'::_)
<tyrion-mx>
umh, ok! now it makes sense
<tyrion-mx>
thanks
<hugomg>
whitequark: you were right. after removing the debug info, my main.byte shrunk to 2.5 MB. The native executable remained at 7.5 MB
<hugomg>
mystery solved!
<mrvn>
tyrion-mx: read that as | hd :: ((hd' :: _) as tl) -> though.
<tyrion-mx>
yep I was confused by parenthesis
<tyrion-mx>
now for a more difficult question: is there a way to call ocaml functions from python code?
<ggole>
as is reliably confusing.
<adrien>
mrvn: is one of your tests about stripping the output of ocamlc?
<tyrion-mx>
I know that you can call ocaml functions from C, and you can call C functions from python, so that should be possible
chinglish has quit [Quit: Nettalk6 - www.ntalk.de]
<mrvn>
tyrion-mx: have fun getting the 2 GCs to play nice with each other.
<mrvn>
adrien: I only used ocamlopt
<hugomg>
tyrion-mx: the 0install author had to interoperate with the old Python version of hs program when he was rewriting it to ocaml. He preferred to use message passing via sockets instead of trying to put ocaml and python in the same process
<adrien>
ah
<hugomg>
(I also heard Python doesn't like being embedded in other languages very much)
<mrvn>
adrien: So 174K + 13K = 187K for bytecode, 124K for native.
<tyrion-mx>
thanks for the informations
<tyrion-mx>
hugomg, I wanted to do the opposite: embed ocaml in python :P (if that makes sense)
<tyrion-mx>
anyway, also java has a gc I think, and yet there is jython
rand000 has joined #ocaml
<tyrion-mx>
anyway being both a C and an OCaml newbie I guess it's a little bit too hard for me
<mrvn>
tyrion-mx: didn't say it's impossible. It's just fun to make the GCs work together (NOT).
<hugomg>
jython is a reimplementation of the python interpreter though. doesnt really count
<hugomg>
its like calling java from java :)
<tyrion-mx>
umh
<tyrion-mx>
you are right
<tyrion-mx>
so I should re implement python in OCaml! :°D
<mrvn>
tyrion-mx: if you only have simple functions passing ints back and forth or so then it's simple. When you start storing python objects in ocaml and ocaml objects in python then it gets complex.
<hugomg>
my guess is that if you want to call ocaml from python its going to be just as hard as calling ocaml from C
<mrvn>
tyrion-mx: and passing callbacks between ocaml and python
<tyrion-mx>
I really want to know more about how compilers work internally, but it is so difficult :/
Nahra has joined #ocaml
thomasga has quit [Quit: Leaving.]
<hugomg>
tyrion: you can always download the source code for ocaml. Or write your own compiler - its how Im learning ocaml :D
igitoor has quit [Ping timeout: 272 seconds]
<tyrion-mx>
hugomg, it would be nice to have something like "hy" for ocaml
<tyrion-mx>
(hy is a lisp dialect that compiles to the python AST)
<tyrion-mx>
("The readability of Scheme and the speed of Python")
igitoor has joined #ocaml
<Thooms_>
"the speed of python"
<Thooms_>
wat
<tyrion-mx>
it's sarcasm :P
<Thooms_>
oh, ok
<Thooms_>
:°
<gasche>
tyrion-mx: this exists under the form of a camlp5 preprocessing pass
<tyrion-mx>
gasche, how could I use that for python?
struktured has quit [Ping timeout: 258 seconds]
<hugomg>
i dont think he was talking about python. hes just saying that some crazy soul also decided that he wanted to compile scheme S-expressions down to ocaml
<gasche>
indeed, what I shown is a lisp syntax for OCaml, that is "something like 'hy' for ocaml"
igitoor has joined #ocaml
igitoor has quit [Changing host]
<hugomg>
tyrion: in any case, If I were you I'd seriously consider using sockets instead of trying to embed ocaml. building a pure-ocaml program using ocamlbuild is trivial but when you want to have a C interface things get more complicated...
<mrvn>
use ctype
<tyrion-mx>
hugomg, thanks for the suggestion
<hugomg>
ctype makes the C api much nicer to use but its still more complicated than not using the c api at all :)
<whitequark>
ctypes*
tharugrim has quit [Ping timeout: 264 seconds]
tharugrim has joined #ocaml
marynate has quit [Quit: Leaving]
thomasga has joined #ocaml
tani has quit [Quit: Verlassend]
<Drup>
I heard anil talk about a pytypes
<Drup>
but I don't remember if it was "working but not public" or "work in progress"
art-w has quit [Ping timeout: 260 seconds]
mcc has joined #ocaml
Thooms_ has quit [Quit: WeeChat 1.0.1]
ski has quit [Remote host closed the connection]
mcc has quit [Quit: This computer has gone to sleep]
mcc has joined #ocaml
Hannibal_Smith has joined #ocaml
ski has joined #ocaml
Yoric has joined #ocaml
tyrion-mx has quit [Quit: Leaving]
Yoric has quit [Remote host closed the connection]
Yoric has joined #ocaml
icicled has joined #ocaml
Yoric_ has joined #ocaml
Yoric has quit [Read error: No route to host]
NoNNaN has joined #ocaml
icicled has quit [Quit: WeeChat 1.0]
Yoric_ has quit [Remote host closed the connection]
manud___ has joined #ocaml
jonludlam has quit [Quit: Coyote finally caught me]
milosn has joined #ocaml
psy_ has quit [Read error: Connection timed out]
psy_ has joined #ocaml
psy_ has quit [Max SendQ exceeded]
psy_ has joined #ocaml
psy_ has quit [Client Quit]
struktured has joined #ocaml
<struktured>
companion_cube: is containers master in good shape to try now? was afraid to pin it until after the hurricane passed through
<struktured>
companion_cube: well, trying it out. will give you a run down later if I see anything odd
JokerDoom has joined #ocaml
_JokerDoom has quit [Ping timeout: 258 seconds]
<mcc>
So I have found ocamlbuild doing something PRETTY bad, I wanna file it but I'm trying to decide what tack to take
<whitequark>
what does it do?
joncfoo has joined #ocaml
rgrinberg has joined #ocaml
<mcc>
In short, it is identifying a file created by my version control system and living inside .hg as an intermediate file, because the filename ends in .a
<mcc>
It refuses to make while this intermediate file exists, and then *emits a shell script to automatically clean the file up* and suggests i run it
<mcc>
which would delete some random thing living in the depths of my VCS, possibly breaking something totally
<whitequark>
oh
<Drup>
ahah
<mcc>
so i can think of a few problems here
<whitequark>
don't bother filing a bug
<mcc>
mm?
<mcc>
there's multiple problems I see here
<Drup>
"it's not a bug" :>
<mcc>
why is ocamlbuild demanding that *ALL* files in the entire tree from pwd down be created by it? that's … scary
<whitequark>
if you want to turn this off entirely, use -no-hygiene
<mcc>
it doesn't even *write* files outside of _build, does it?
<mrvn>
never had problems with .git there
<whitequark>
if you want to turn this off only for your VCS directory, use ".hg": precious
<mcc>
hygiene seems nice i just want it to perform the hygiene in, say, _build?
<whitequark>
mcc: no, that's not what hygiene means
<mcc>
yeah, there's… another problem there actually
<whitequark>
hygiene means not having build products *outside* _build
<mcc>
what does hygiene mean?
Arsenik has joined #ocaml
<mrvn>
shouldn't hygiene only care about compiler output?
<whitequark>
mrvn: .a is compiler output, a companion to .cmxa
<mrvn>
But why would .a be under .hg?
<whitequark>
because mercurial.
<mcc>
mrvn: because .hg creates various files with various names as it sees fit
<mcc>
i'm not sure but i believe what's happening is during certain operations it might create a changelog.a, a changelog.b, a changelog.c etc
<mcc>
preparing to commit these things to its file database later
<Drup>
(it would be reasonable to have a list of cvs directories hardcoded inside ocamlbuild)
<mrvn>
ahh. yeah. that can happen
<mrvn>
Drup: .git is I believe
<rgrinberg>
Drup: awesome idea
<whitequark>
yeah, a list of vcs directories excluded from hygiene by default is useful
<mrvn>
.hg is just not too common
<whitequark>
.git is not hardcoded currently
<whitequark>
none are
<mcc>
the file doesn't always exist. there's a particular operation and if i perform it it appears then goes away on a later operation
<mcc>
my suggestions were going to be, in descending order
<mcc>
- don't screw with hidden directories
<mcc>
- don't screw with .hg, .git, .bzr, .svn
<mrvn>
whitequark: then git is sane enough to not have extensions used by compile output
<whitequark>
sure
<Drup>
mcc: you should propose option 2, I think
<mcc>
- … i'm still confused why it's hitting pwd at all. maybe this makes more sense. i'm doing this semi-unusual thing where i don't run ocalbuild from my src directory
<mcc>
ok.
<mcc>
mrvn: git was written by c developers. hg was written by python developers.
<mrvn>
mcc: hehe
<struktured>
mrvn: why mercurial in the first place, if I may ask. its way less efficient when you use branches with it
<Drup>
struktured: "if you use branches"
<whitequark>
funny how git is named after a toxic trait and hg is named after a toxic element
<mrvn>
mcc: because you might have run "ocamlc foo.ml" in the source and then have cruft lying there
<struktured>
Drup: bookmarks are ok
<ggole>
-traverse might be better than precious
<mcc>
mrvn: sure
<whitequark>
oh, right, what ggole said
<struktured>
Drup: and I did use branches at a shop with 15 devs, but the repo got real huge.
<mcc>
strktured: you don't use branches in hg; they're an old feature that has been replaced by bookmarks.
<Drup>
struktured: you point out an assumed inneficiency "if a certain feature is used"
<Drup>
which is not necesseraly the case ..
<mcc>
and the reason i use hg is because git is a torture device, an evil that should not exist in this world
<mcc>
i am literally unable to understand why one single person on earth uses git for any purpose
<mrvn>
mcc: at least git merges far better
<mcc>
i use hg because it stores files and does not make me want to quit programming forever
<ggole>
Well, of course - it's a build system.
<whitequark>
git is convenient
<mcc>
mrvn: i don't care! "merging better" doesn't help if i can't figure out how to amke mergin gwork
<whitequark>
I never have issues with git
<struktured>
git wins to me. I've used both alot. I miss the simplicity of some mercirual operations though
* whitequark
shrugs
<whitequark>
apparently I'm the only one or something
<Drup>
whitequark: no it's not, git's interface is madness
<struktured>
yeah git interface is a little extreme but the internals are solid
<mrvn>
mcc: well, if it doesn't work out of the box then geeting it to work in hg is just as bad. But with hg it happens all the time.
<whitequark>
actually, I don't even have objections to the interface
<mcc>
I do not respect your opinions, and I think defense of git makes programming a worse place to be
<Drup>
the only reason I use git is github >_>
<mcc>
drup: i use hg with github
<mrvn>
mcc: git just has a steeper learning curve than hg. But once you learned it you don't want to go back.
<struktured>
mcc: do you use bookmarks exclusively?
<mcc>
mrvn: okay, so… out of curiosity, what do you mean by hg "not merging as well"
<mcc>
struktured: yes; the "branch" feature does not work
<Drup>
(and any "git merges well" argument is a proof of lack of knowledge of darcs :D)
<mcc>
struktured: also, the bookmark feature works with the git bridge but the "branch" feature does not
<mcc>
mrvn: git is broken and not possible to learn
<mrvn>
mcc: when 2 developers commit something you quickly get ugly conflicts in hg. Git is better able to resolve them.
<struktured>
mcc: yeah but sadly branches are pretty awesome because how well it tracks lineage. too bad they bloat the repo
<mcc>
mrvn: moreover, it should *not* be learned; learning it, and thus learning to ignore its huge flaws, makes programming worse for everyone else in the world by proliferating git repositories
<mcc>
tolerance of git is an unethical act
<struktured>
lol
<mcc>
mrvn: how so?
<mrvn>
mcc: give me something better. And no, hg is not it.
<Drup>
mcc: #gitgate :3
<mcc>
mrvn: i'm working on it!
<Drup>
mrvn: darcs ? ^^'
<mrvn>
Drup: *shiver*
* mcc
is not really interested in saying anything positive about hg
<mcc>
I have a long list of complaints with it.
<Drup>
mrvn: the only moo point is that you need ghc to compile it
<mcc>
However, I assert it stores files
<Drup>
it's not that slow anymore, and commutative patchs <<3
<mcc>
mrvn: anyway, sincerely, i'm curious if your complaints with hg merging are about the proliferation of heads, or if the merge operation itself has some kind of problem
bytbox has quit [Ping timeout: 244 seconds]
<mrvn>
mcc: I did run into all sorts of problems. Getting split brain problems with heads diverging happened too
* mcc
nods
<mcc>
i think i do not use hg in a common way because i create multiple loose heads freely
<mcc>
anyway, i have a lot of opinions about what an ideal vcs would look like, but instead of implementing that i decided to write a programming language instead because i think c++ would be easier to dislodge at market than git :P
<mrvn>
The index in git takes some getting used to. But it is great to do work till you are satisfied and then commit it in logical units.
<whitequark>
mcc: lol
Thooms has joined #ocaml
<mrvn>
mcc: write a usable frontend for git. The storage engine is great.
<Drup>
irmin ? :D
<mcc>
maybe once i get the language working i can use it to write a git replacement. then i can get started on replacing X :P
<mcc>
mrvn: i've written git frontends the strange engine is baaaad
<mcc>
it's just a bunch of ad hoc binary hacks some kernel developer wrote
<thomasga>
(git is awesome)
<Drup>
thomasga: do you have a hl on irmin ? :D
<thomasga>
hl?
<struktured>
in other holy wars, anyone read rgrinbergs piece on lwt and async?
<mcc>
here is the single feature i want most in a git/hg replacement
<Drup>
thomasga: highlight
<mcc>
i want rebases with history tracking
<Drup>
mcc: why do you insist on writing replacement for bad technologies instead of using good technologies already done ? :p
<thomasga>
actually no, but I was reading the discussion on Git :p
<mrvn>
What I'm missing in git, or any other VCS, is an extra dimension. I need to be able to track and develope a feature across multiple versions of upstreams source. In git you can make a branch for every version and then cherry pick changes across all the branches on every change but that gets tiresome and is ugly.
<thomasga>
(and you mention Irmin at the same time)
<Drup>
mcc: I mean, it's quite pathological at this point :D
* Drup
sings "daaaarcs" at mrvn.
<mcc>
drup: irritation motivates me well
<Drup>
commutative patches <3
<mcc>
drup: does darcs have 2-way communication with git?
<Drup>
no fucking idea
<mcc>
drup: and does any language you'd consider good have C++ integration :P
<Drup>
the paradigm is widly different, so you will have a big impedance mismatch, I think.
<mcc>
because until someone makes a "better system" i can use with the existing systems, i can't switch over to it!
<mrvn>
Drup: that doesn't help.
<mcc>
mrvn: would allowing individual changesets to have "tags" provide this feature?
<Drup>
mcc: I think it's better to take a language and make the integration better that writing a new not-so-much-better language
<Drup>
that nobody will use
bytbox has joined #ocaml
<mcc>
Drup: It is likely! However, would YOU want to edit the LuaJIT source? That sounds scary to me D:
<Drup>
why not ?
<Drup>
I don't know how the source is
<rgrinberg>
mcc: that's why i can't wait for ocamlbuild to be split
<thomasga>
mrvn: your feature request (history with rebase) already exists, but I cannot find the ref anymore ...
<rgrinberg>
i dont want to wait for a new version of the compiler for small improvements to ocamlbuild
<mcc>
mrvn: okay. i'm trying to understand, it sounds like an interesting idea
<struktured>
hugomg: thanks was lazy :) I'm sad about the whole lwt / async. it might be my biggest concern with ocaml.
<whitequark>
rgrinberg: fork it.
<Drup>
mcc: did you take a look at it ? is it that terrible ?
<mcc>
mrvn: (although at work we recently got this by adopting this "semantic versioning" thing, which is much simpler than they describe it)
<mrvn>
Drup: because Feature A has a patch series for version 1.0, a slightly different patch series for 2.0 and yet another for 3.0. When I change patch17 in the series that change needs to happen in all series, maybe with slight variations.
<mrvn>
Drup: The problem is that you need a meta head that encompasses all the related heads in the different versions and need to be able to affect changes to them as a group.
<Drup>
you can do that in darcs, afaik
<rgrinberg>
whitequark: i dont see a need to fork just b/c the core team is taking its sweet time
<rgrinberg>
if they finally decide against it i might consider it
<Drup>
mrvn: darcs doesn't have heads or banches, the only notion is "set of patches"
<thomasga>
Drup: is that possible to force the dependency between patches in darcs?
<Drup>
you can take (and mark) any set of patches
<thomasga>
(ie. tell the tool that 2 patches do not commute)
<rgrinberg>
struktured: async vs lwt is a non issue imo
<mrvn>
Drup: but I don't have one set of patches. I have a family of sets of patches.
<Drup>
thomasga: I don't remember the details (because I don't use darcs on a daily basis ...) but the opposite would surprise me
<rgrinberg>
struktured: until someone actually starts using async
<mcc>
mrvn: have you looked into patchquilt systems?
<mrvn>
Drup: or rather a set of families of a patch.
<Drup>
mrvn: the set of patches can intersect
<struktured>
rgrinberg: in nyc there is definitely some emphasis towards async (jane street's influence I guess)
<mrvn>
Drup: can you rebase a patch set in darcs and keep the history about the changes?
<rgrinberg>
struktured: i'd blame ashish :D
* mcc
had not heard of Jane Street and was briefly very excited to learn there was an influential female ocaml developer in nyc
<mcc>
then i checked google
<struktured>
rgrinberg: ha yeah he pushed me to async personally, but now I'm wavering around like a moron between them
<rgrinberg>
struktured: anyway the situation is very different outside of NYC
<Drup>
there is no real notion of rebase, since everything commutes
hugomg has quit [Ping timeout: 245 seconds]
<Drup>
mcc: the OCaml community is unfortunately very gender-imbalanced.
<mrvn>
Drup: it only commutes if there is no conflict.
<rgrinberg>
Drup: compared to other languages?
<Drup>
rgrinberg: I think, yes
<rgrinberg>
that's very strange
<struktured>
haskell can't be much better
<mrvn>
brb, gotta go shopping
<Drup>
struktured: haskell is not much better
<Drup>
but python seems to be, for example
<rgrinberg>
Drup: python's community is so much more massive
<rgrinberg>
and more industry focused
<Drup>
sure, but I was talking proportion, not absolute number
<mcc>
The Python community has made a really intense effort to be gender inclusive
<Drup>
exactly
<mcc>
Compare Python and Ruby-- very similar languages from both a usage and market perspective, Python is significantly better on inclusion as a community than Ruby
<mcc>
Because the Python community and people at the top like Guido made conscious decisions to foster inclusion, and the Ruby community made a conscious decision not to do anything about some people near the top who were creating inclusion problems
<mcc>
But I am not quite sure how you do something like that for something like ocaml, which seems to have less of a distinct "community"
<Drup>
note that I have never seen bad behavior in the OCaml community, but I have barely seen any woman in the community to begin with ... (like, 4, in total)
<mcc>
and where you have the pair program of outreach to women for the language and outreach to women for FP itself
<whitequark>
mcc: there is a very interesting question to which I don't have an answer
<whitequark>
the ocaml community has very few resources, especially compared to, say, python
* mcc
nods
<whitequark>
how should it allocate it? should it organize something like an ocaml outreach program for women? should it focus on developing useful libraries?
<whitequark>
either way, you'll get a lot of people to criticize you
* mcc
personally perceives the haskell community as being fairly offputting overall, due to a widespread belief among the community that their way is simply superior
<mcc>
and i've been treated that way by the women as well as the men in the community. although the fact there were women *to* offput me probably should have been a flag :P
<mcc>
because of this i haven't gotten close enough to really tell what it's like in there
<whitequark>
this is something I hear a lot about haskell, from many different people
<Drup>
The fact that compsci (especially type/language theory) in academia is extremely gender imbalanced, and that OCaml is quite academia-centric doesn't help (as rgrinberg hinted)
<whitequark>
it's bad. regardless of how you like or dislike the language, it also taints many of the concepts
<mcc>
Yeah. Maybe rgrinsberg has a point you're actually more likely to get women in through industry than through academia is possibly accurate and highly alarming D:
<Drup>
(I never really understood why type/language theory attract women less than other compsci fields)
<Drup>
I mean, it's really obvious
<rgrinberg>
i'm just surprised that ocaml's syntax would be so off putting :D
<mcc>
whitequark: i definitely feel a lot of the concepts have been formulated in a way that does not make them easy to grasp on introduction.
<rgrinberg>
at least to half the world
<whitequark>
mcc: that's not quite what I mean
<whitequark>
mcc: the very fact that haskell is full of off-putting people *and* haskell is full of monads associates these two things
<mcc>
ocaml's syntax is a bit aggressively weird :P possibly no more so than c++, but… well, you have to learn c++, nobody's being forced to learn ocaml
<whitequark>
without any good reason sadly
<whitequark>
but that's how it works
<mcc>
whitequark: hm
Thooms has quit [Quit: WeeChat 1.0.1]
<whitequark>
so even if you don't have any connection to haskell or its community whatsoever, you still suffer the consequences
<rgrinberg>
"suffer the consequences" might be a little exaggerating
<Drup>
mcc: "lot of the concepts have been formulated in a way that does not make them easy to grasp on introduction" <- that depends a lot where you come from
<bartholin>
The more women in computer research, the more women in the ocaml community.
<Drup>
and it boils down to something we discussed already: math language vs management language :p
<whitequark>
rgrinberg: it's not an exaggeration
<mcc>
drup: i'm not sure about that. My introduction to category theory was not through haskell
<mcc>
also actually i do know… actually a decent number of women in type theory , more than some other research plans i can think of. i'm not sure i agree this is specifically a non-gender-diverse field
<Drup>
mcc: oh ? and you were not putt off by it at first sight ?
<rgrinberg>
whitequark: i haven't experiecned any off putting people
<rgrinberg>
in the haskell community
<mcc>
drup: of course i was put off by it at first sight! category theory is terrible!
<Drup>
right :D
<Drup>
but for people coming from a strong math background
<mcc>
when the very first people you encounter start off by describing it as "abstract nonsense" this is not a high confidence your formalisms have been primed for practical use
<Drup>
they come in haskell, and they have plenty of very familiar math concept
Yoric has joined #ocaml
<whitequark>
rgrinberg: i have not, because i haven't interacted with it almost at all. but the amount of people i met who have explicitly denounced haskell as having a community full of off-putting people is alarmingly high
<mcc>
i assure you i came in with a strong math background :P
<mcc>
i just like some of the other areas of formal logic better :P
<Drup>
mcc: I was more thinking of algebra
<mcc>
although i think i have to go thorugh category theory to get to topos which is something i really want to work with *whine*
<whitequark>
mcc: btw, have you ever looked at coq, agda or idris
<whitequark>
?
<rgrinberg>
whitequark: i've found the haskell community at least as helpful as ours. Definitely not focused on the same technical problems though
<mcc>
whitequark: not yet! i hope to soon.
<Drup>
like, "a group here, a monoid there, sure I know this things!"
<mcc>
i was thinking of algebra also!
<Hannibal_Smith>
whitequark, personally I think that these people are a minority that is particullary active on social site like Twitter
<Drup>
mcc: and to be fair, monad/functors in Haskell (and FP in general) are closer to algebraic notions than category theory
<whitequark>
Hannibal_Smith: it doesn't matter really, the result is the same
<mcc>
drup: that's an interesting comment
<mcc>
hannibal_smith: i will say #haskell on freenode here felt like a very hostile place to me. the fact people went to the bother of founding #nothaskell seems to imply i wasn't the only one
ggole has quit []
<mcc>
the #nothaskell people are making an interesting kind of effort on outreach stuff
<Drup>
mcc: I have a friend who is doing actual category theory and he told me that he don't understand FP people at all, because their use of functors/monads and other category theory concept is all weird and not at all like proper category theory
<Drup>
(note: I don't understand a thing of category theory)
* mcc
used to read a lot of John Baez.
<Hannibal_Smith>
Drup, I have also the same strong feeling, that they are using terms without the necessary knowledge. Of course this is not true in general, as Haskell community has various kind of people inside it
<Drup>
sure
<rgrinberg>
Hannibal_Smith: imo #haskell's biggest problem is the sheer amount of noise
<Hannibal_Smith>
I'm here because I used SML at univerity, houì
<Drup>
rgrinberg: I agree with you, I haven't had any issue interacting with some haskell people (I don't follow the irc channels because they mostly talk about stuff I don't care)
<Hannibal_Smith>
I loved it, and searched for a language like it that is usable
<Hannibal_Smith>
Than found that this IRC channel, is the best on Freenode
<Drup>
what, SML is not usable ? :D
<Hannibal_Smith>
Ahaha
<rgrinberg>
the haskell community on reddit is welcoming and friendly
<mcc>
Nevertheless, category theory is an unusually unpenetrable branch of math. I feel maybe some of these monad-y FP concepts would be more comprehensible if they detached from the cat theory terminology.
<Drup>
mcc: wrt to gender imbalance in type theory
<Drup>
It's very clear if you look at the member of compsci teams in a university
<Hannibal_Smith>
When I was curious about Haskell, personally I don't remember bad experience on ##Haskell, but the quality of the discussion here is way more higher. As I said my bad experience with some haskellers came from Twitter
<Drup>
and then look at the team doing heavy type theory
<mcc>
If they're not even using the category theory vocabulary in a precise way, then that seems like an even better reason not to frame things by attaching it to a theory which is more likely to scare people away than illuminate concepts...
<Drup>
all bad experiences are coming from twitter ! :D
<Drup>
mcc: well, most explanation of monads I have seen don't use the concept of categories
<Drup>
they say "it's a set, with a bunch of law and there you go" which is a good as the definition of group/ring/field in algebra
<mcc>
drup: i guess i'm not really in academia so it's harder to judge.
<Drup>
(hence why I think it's very algebraic)
<mcc>
rgrinsberg / Hannibal_Smith: One thing I'd note is that friendliness of a community is highly person dependent. Whether one finds a community immediately friendly or immediately hostile depends on a lot of ... stray things, which the community chooses to react to in different ways.
<mcc>
rgrinsberg / Hannibal_Smith: Gender is often one of these things.
<Hannibal_Smith>
mcc, I thinked on it, and yes I agree with you
<rgrinberg>
mcc: yeah that definitely seems to matter. more in person/conferences than on irc though =)
bytbox has quit [Remote host closed the connection]
manud___ has quit [Quit: Be back later ...]
<mcc>
rgrinsberg / Hannibal_Smith: One thing I definitely feel is that if you come into the Haskell community not liking certain idioms it is fond of, it will be assumed this is because you do not have sufficient background.
<mcc>
rgrinsberg / Hannibal_Smith: People making assumptions about one's background does not feel very good.
<Hannibal_Smith>
mcc, I hope to not be too disagreeable with this, but I think is good way to handle criticism. People who are behind the choices of a PL like Haskell have studied to be at that position. One has to be to the same level of knlowladge to critic their work
<Drup>
(I disagree strongly with that)
<mrvn>
Hannibal_Smith: and if you have? You still get the same treatment
nojb has joined #ocaml
<mcc>
hannibal: the problem i perceive is that even if one does have the same treatment, there will be an aggressive assumption one does not. knowledge is assumed to imply shared opinions.
<Hannibal_Smith>
mrvn, is difficoult to me to expose an opinion on that. I read very strange comment referring to people like Harper, Erik Meijer because the cririticism of aspect of Haskell
<mcc>
rgrinsberg: and yes, on irc the most common thing is to be simply assumed male anyway :P
<Hannibal_Smith>
But these comments are really from people who don't go to conference, don't contribuite to the language
<mcc>
hannibal: i'm sorry, i meant "even if one does have the level of knowledge..."
Thooms has joined #ocaml
<Drup>
mcc: yeah, I apology for that
<mcc>
drup: haha
<mcc>
i'll live
rgrinberg has quit [Quit: Leaving.]
mcc has quit [Quit: This computer has gone to sleep]
struktured has quit [Ping timeout: 250 seconds]
<gasche>
".hg": -traverse
<whitequark>
gasche: there's a good argument that this should be the default
thomasga has quit [Quit: Leaving.]
<whitequark>
I can't imagine any downsides.
<gasche>
of course
<gasche>
are you willing to submit a PR for this?
<gasche>
I'd have asked mcc
<whitequark>
PR as in pull request or problem report?
<gasche>
problem report
<gasche>
I use GPR for pull requests
<whitequark>
actually, a pull request is probably easier
<gasche>
currently the GPRs that don't have PR numbers are mildly awkward to list in the Changelog
<whitequark>
can't you just say GPR#?
<gasche>
(I'm being perfectionist here; nobody cares for new features, but for bug reports it's nice when they have an issue number)
<gasche>
I could
<whitequark>
sigh
<gasche>
(or the people that send the patch in the first place and should consider updating Changes as part of the patch, otherwise that's more work to integrate)
thomasga has joined #ocaml
<whitequark>
should it be only -traverse, or also not_hygienic?
<whitequark>
oasis uses both
alkoma has joined #ocaml
<gasche>
whitequark: oasis is taking protective action against PR#4502 which was fixed in 4.01.0
<gasche>
-traverse should be sufficient
<gasche>
(and it is the right semantics: don't look in this subdirectory *at all*)
bytbox has joined #ocaml
<whitequark>
thanks, that is exactly what I wanted to know
struktured has joined #ocaml
alkoma has quit [Remote host closed the connection]
<gasche>
whitequark: you said that GPR#110 has "zero discussion"
<MercurialAlchemi>
(though compiling to platform independent bytecode must simplify a lot of things)
ingsoc has quit [Quit: Leaving.]
<mcc>
mercurialalchemist: maven is designed for java? how well does it work with non-java languages or project components?
Yoric has joined #ocaml
Hannibal_Smith has quit [Quit: Leaving]
<struktured>
MercurialAlchemi: maven inheritance is klunky, it is very IO heavy, and xml sucks. but yeah it has some nice standardization of build concepts
<struktured>
mcc: it works fine with several languages via maven plugins and archetype definitions
Yoric has quit [Ping timeout: 256 seconds]
<struktured>
mcc: you stlil need java of course to run mvn
jao has joined #ocaml
jao has quit [Changing host]
jao has joined #ocaml
<mcc>
struktured: yes, that's… a litle bit awkward.
<mcc>
are maven plugins written in java?
<MercurialAlchemi>
mcc: it doesn't
kakadu has quit [Read error: Connection reset by peer]
<struktured>
you can embed it or something u mean?
kakadu has joined #ocaml
<whitequark>
wow, I looked into how Str is implemented
<whitequark>
it has a bytecode compiler
<MercurialAlchemi>
well, at least I've never tried it out of the JVM ecosystem
<struktured>
mcc: maven plugins are usually written in java but not necessarily (scala or clojure could be doable)
<mcc>
so "something that compiles to java bytecode" ok
<MercurialAlchemi>
I think Maven is kind of shit but the declarative build system thing works
<struktured>
MercurialAlchemi: what sorta kills me is the "everything is one package approach". it means alot of jar inspection / unpacking during build time
<mcc>
struktured: mmm. that's super cool that exists, but is it just me or did this plugin wind up being somewhat verbose :O
<mcc>
like by comparison the scons plugin for ocaml is about maybe two printed pages long. (* note: it does not work *)
slash^ has quit [Read error: Connection reset by peer]
<Drup>
mcc: how are you on the type system side now ? :p
<mcc>
rgrinberg1: yes! it's REALLY interesting
<mcc>
rgrinberg1: it's pretty close to my language, it's one of two languages that make me wonder if i'm doing the right thing creating a new language instead of extending one of those
<mcc>
(the other is Julia)
<mcc>
i get a vague sense io is sort of abandoned as a project, though?
<rgrinberg1>
mcc: abandoned vs complete depends on your perspective
<rgrinberg1>
an implementation of the VM in ocaml would be cool :D
<Drup>
(and a typesystem.)
<mcc>
drup: i'm going to do a full implementation as a dynamic language before i implement types.
<mcc>
but i don't think i'm going to put a "1.0" on it until it has types :P
<mcc>
my original goal was lua + types + c++ interop
<Drup>
I was going to say "as long as you don't except it not to change when you add types..." :p
<rgrinberg1>
there are typed luas out there i hear
<mcc>
i expect it to change when i add types! that's why i'm not going to add types until i have something stable already :P
<mcc>
rgrinberg1: yes, there's terra and i think that "typed lua" paper has an implementation now