zzing has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
yacks has joined #ocaml
zzing has joined #ocaml
tlockney is now known as tlockney_away
iorivur has joined #ocaml
iorivur has quit [Ping timeout: 240 seconds]
elfring has joined #ocaml
Kakadu has joined #ocaml
<elfring>
Will OCaml compilers support cross-compilation?
iorivur has joined #ocaml
<adrien>
yes
<adrien>
(after 4.02)
<elfring>
Where should I read more the upcoming support for cross-compilation?
<adrien>
there's not much to read unfortunately; it's scattered around: bug reports and mailing-lists mostly
<ruzu>
does ocaml have csp (concurrecy) support in std lib, or maintained libs?
<whitequark>
ruzu: take a look at jocaml
<elfring>
I am also curious how the upcoming support for cross-compilation will trigger improvements for software libraries and corresponding build tools for OCaml.
Anarchos has joined #ocaml
ygrek has quit [Ping timeout: 258 seconds]
<adrien>
if your question is whether the tools will follow, then yes, they will
<adrien>
it will obviously be a bit after the compiler has the cross-compilation but the hope is to get both aspects done mostly in sync
<adrien>
it's worth noting that ocamlfind does a very good job at handling cross-compilation already
studybot_ has quit [Read error: Connection reset by peer]
shinnya has joined #ocaml
dapz has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
iorivur has quit [Ping timeout: 265 seconds]
<Anarchos>
where can i find good practices about interfacing an ocaml program to a GUI ?
<Kakadu>
Anarchos: CoqIDE for some extend
<Anarchos>
Kakadu thanks.
<Kakadu>
but it is a little bit buggy^W strange
<Kakadu>
There are solutions without GTK
<Anarchos>
Kakadu i have a clean pure ocaml program, i want to be able to drive it from a gui.
<Kakadu>
target platforms?
ygrek has joined #ocaml
<Anarchos>
Kakadu HaikuOS :)
<Kakadu>
are wxwidgets/EFL/Qt available there?
dapz has joined #ocaml
<Kakadu>
well, if it is Haiku than it is your toy project (no offense!). Is seems that lablgtk will be enough. When you will find it inconvenient I will answer are lablqt questions
<Kakadu>
s/are/all/
rgrinberg has quit [Quit: Leaving.]
<ruzu>
"lol @ haiku", says kakadu :-)
<Kakadu>
ruzu: from 4.01 (@@) !
<elfring>
Anarchos: Do you want that a graphical user interface will be developed in the same programming language as the OCaml program?
<adrien>
08:23 Anarchos : Kakadu i have a clean pure ocaml program, i want to be able to drive it from a gui.
<adrien>
FRP ^
ggole has joined #ocaml
<adrien>
+ state machine
<adrien>
(imho)
iorivur has joined #ocaml
dapz has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
<Kakadu>
If I'm using trunk version of compiler where should I get camlp4?
iorivur has quit [Ping timeout: 258 seconds]
sgnb has joined #ocaml
<Anarchos>
elfring the problem is more : how do you interface ocaml programs to GUIS, wether or not they are written in ocaml too.
<adrien>
Anarchos: FRP and I do with state machines on top of that
_habnabit has quit [Ping timeout: 258 seconds]
_habnabit has joined #ocaml
_habnabit has quit [Changing host]
_habnabit has joined #ocaml
johnelse has quit [Ping timeout: 258 seconds]
<Anarchos>
adrien what is FRP ?
<adrien>
big words, lots of papers
johnelse has joined #ocaml
<adrien>
and in summary, a way to put functional code inside a mutable environment
NoNNaN has quit [Ping timeout: 272 seconds]
<ggole>
whitequark: Nice. There's a few missing details, like how very long arg lists are handled.
<ggole>
There's some caml_extra_params junk for that.
<whitequark>
hrm
<whitequark>
ggole: that's only on i386
<whitequark>
let's just murder i386 already
<ggole>
:)
araujo has quit [Quit: Leaving]
<ggole>
(I never understood the rationale for caml_extra_params.)
<whitequark>
"derp"
<whitequark>
*cough*
<elfring>
Anarchos: There are a lot of software tools available to develop a graphical user interface. Have you got any specific requirements for your "GUI" in mind?
<whitequark>
ggole: ... seems like caml_extra_params is where negative register numbers go
<whitequark>
let emit_reg = function
<whitequark>
| { loc = Stack(Incoming n | Outgoing n) } when n < 0 ->
<ggole>
This helps motivate the all-regs-callee-save thing, too
<whitequark>
"meagre supply of registers" bwahaha
<whitequark>
I wonder how concurrent-ocaml interacts with this
<whitequark>
well, it could be made thread_local... but that limits the number of platforms, requires a recent linker and is, in general, slower
Simn has joined #ocaml
yacks has quit [Ping timeout: 240 seconds]
<Anarchos>
elfring no : my program is in ocaml, it is a first order verifier. I want to be able to input text in latex formulas , but i don't know how to interact with ocaml programs. I tried to run an interactive loop inside the GUI to get access to the ocaml layer, but it is not satisfactory.
<ggole>
So amd64 eats the lack of TCO for many-argument functions?
<ggole>
I guess it isn't an issue in practice
<whitequark>
ggole: everyone except i386, I guess
<ggole>
Good old i386, engendering bizarre hacks everywhere it goes.
<whitequark>
on amd64 you have ten registers for arguments, on arm you have eight
<whitequark>
the rest is on stack.
<whitequark>
I'm a bit horrified thinking about a recursive function with eight arguments.
<Anarchos>
ggole what is TCO ?
<whitequark>
tail call optimization
<Anarchos>
whitequark ok
<ggole>
whitequark: I can imagine lambda lifting producing such a function
<ggole>
Writing one by hand though... blurgh.
<whitequark>
well, you *have* to stop somewhere
<elfring>
Anarchos: Would you eventually like to make your tool accessible by internet interfaces?
<Anarchos>
elfring could be nice indeed
<Anarchos>
elfring the problem is that my verifier is coded without an event loop.
<whitequark>
ggole: even on i386, you won't be able to pass more than 70 arguments with TCO
<ggole>
Oh damn, my plans are ruined.
<ggole>
Is caml_extra_params 64 entries long?
<whitequark>
hm, 64 byte long in fact
<whitequark>
so, more than 18 arguments
<whitequark>
er
<whitequark>
(16+6) arguments. I can't compute
<elfring>
Anarchos: Can your tool be handled as every command-line program at the beginning?
<Anarchos>
elfring yes.
<adrien>
Anarchos: the state machine will be your event loop
<ggole>
Happily codegens 40 args
<ggole>
And presumably, does bad things at runtime
<elfring>
Anarchos: So you are free to choose how an improved graphical user interface should be designed for your application, aren't you?
<ggole>
Interestingly, compilation becomes quite slow: bet there's a quadratic algo in there somewhere
<Anarchos>
elfring suppose i have a gui in c++, how to interact with the ocaml code ?
<adrien>
elfring: the issue is that the GUI will be using "mutation" (the user and the screen) while the caml code is immutable
<gasche>
message passing would be the simplest solution
<adrien>
and then both clash
<adrien>
there is a need for a layer between the two
<gasche>
write your OCaml program as a child program that receives queries and answers them
<gasche>
just like Merlin, which is an OCaml program with an Elisp/Vimscript GUI layer
<Anarchos>
gasche you receive queries from a socket ?
<adrien>
socket/pipe
<Anarchos>
adrien with a userdefined or xml format ?
<adrien>
using companion_cube's Bencode obviously
<Anarchos>
adrien any hyperlinks ?
<adrien>
(he's going to hate me)
<adrien>
Anarchos: use whatever serialization format you like)
<Anarchos>
adrien formulas are input in latex syntax.
<adrien>
whatever you like
<adrien>
(I think the separate process is pretty much the same as the frp + state machine I mentioned earlier: with the separate process there will be a state machine (-like)
<adrien>
in one of the processes too)
Simn has quit [Quit: Leaving]
<adrien>
(reading from a pipe is like waiting for the next event for a state machineà
<adrien>
)
<elfring>
Anarchos: I assume that you imagine a more fancy user interface than an implementation by a shell script for a text display. Do you "play" with ASCII art? ;-)
<Anarchos>
elfring i have a pretty good rendering since i ported latex to Haiku ;)
NoNNaN has joined #ocaml
dapz has joined #ocaml
zxqdms has joined #ocaml
<elfring>
Anarchos: Have you got any preferences for your graphical user interface?
<Anarchos>
elfring it will be done in C++ with the Haiku API.
<elfring>
Anarchos: Would you like to reuse any class libraries for your graphical user interface then?
<Anarchos>
elfring writing the GUI is not my issue, it is the communication with an elaborated ocaml program.
marr has joined #ocaml
<elfring>
Anarchos: Where do you see software development difficulties to call command-line programs?
<Anarchos>
elfring i will add an event loop on the ocaml side, reading from a socket. And i will define a protocol syntax for the messages passing by the socket. Thanks for the help.
<Anarchos>
gasche why not use ocaml values which are marshalled over the network ?
<gasche>
if your GUI is written in OCaml, sure
<gasche>
but then why would you need separate processes in the first place?
<Anarchos>
gasche to isolate the kernel (my first order verifier)
dapz has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
<elfring>
Anarchos: Is your OCaml program just another implementation for a portable software library?
<Anarchos>
elfring no, it is a program i wrote.
<gasche>
Anarchos: I suspect that's overkill (you could do as well with API abstract, unless you plan to have segfaults all over the place)
<gasche>
but ok, if both producers and consumers are OCaml, you can use the built-in value serialization
<gasche>
you should be careful to have versionning before the OCaml values however
<Anarchos>
gasche before ?
<gasche>
because you *will* encounter situations where both sides don't expect the exact same types
<gasche>
hm
<gasche>
I mean first send a version number, then the serialized values
iorivur has joined #ocaml
<gasche>
and make the other end reject if the version doesn't match
<gasche>
(or devise compatibility layers but that is a pain)
<elfring>
Anarchos: Does your program provide a portable application programming interface (besides the command line)?
<Anarchos>
elfring it should i guess, but for now i have just modules i know how to call from the ocaml toplevel, that is why i integrated pipes in the GUI to interact with an ocaml toplevel running in a separate thread. But it is not clean design, since i have no need for a full toplevel running aside.
<Anarchos>
gasche a version number of the ocaml version or of my application ?
<gasche>
of the datatypes you serialize
<gasche>
each time a part of the datatype definition changes, bump the number
<gasche>
(note that using a dedicated serialization layer doesn't require this because well-formedness-checking is embedded in the parser)
<gasche>
(so eg. sexplib will be easier to use safely than input_value/output_value)
<Anarchos>
thanks for the help.
pminten has joined #ocaml
dapz has joined #ocaml
everyonemines has joined #ocaml
dapz has quit [Client Quit]
yacks has joined #ocaml
shinnya has quit [Ping timeout: 258 seconds]
thorsten` has joined #ocaml
thorsten` has quit [Client Quit]
dapz has joined #ocaml
elfring has quit [Quit: Konversation terminated!]
ikaros has joined #ocaml
tautologico has quit [Quit: Connection closed for inactivity]
everyonemines has quit [Quit: Leaving.]
Anarchos has quit [Quit: Vision[0.9.7-H-20140108]: i've been blurred!]
thorsten` has joined #ocaml
<whitequark>
a wise man once said, "x86_64 is your face when you have to work with that" ;_;
<ousado>
heh
iorivur has quit [Ping timeout: 258 seconds]
iorivur has joined #ocaml
<whitequark>
X86ISelLowering.cpp is 20682 lines long. It is not autogenerated O_o
<Kakadu>
whitequark: Happy hacking!
<whitequark>
Kakadu: thanks :)
<whitequark>
I'm almost finished actually
<whitequark>
the amount of changes to LLVM required for it to support OCaml's ABI is... insignificant
* companion_cube
happy that adrien saw the light and adopted bencode into his heart
<whitequark>
bencode is yet another binary json. meh.
<companion_cube>
nah
<companion_cube>
it's pure text
<companion_cube>
but much simpler to parse ;)
<whitequark>
hm? are we talking about the same format? torrent's bencode
<companion_cube>
you can embed bitstrings in it, but the format itself is plain text
<whitequark>
oh
<companion_cube>
that's why it's used for bittorrent, I believe
ikaros has quit [Quit: Ex-Chat]
marr has quit [Ping timeout: 240 seconds]
divyanshu has quit [Quit: Computer has gone to sleep.]
* ggole
wonders how ugly hand-coded graph pattern matching in C++ could be
<whitequark>
I *think* pattern matching is generated by tblgen
<whitequark>
I mean, that file lowers LLVM IR into SelectionDAG
<ggole>
Tree matching gets you quite a long way
divyanshu has joined #ocaml
<ggole>
Wonder how much benefit there is in using a DAG
<whitequark>
tblgen-generated code is an abomination of its own kind though
<whitequark>
tblgen is quite scarcely documented, indeed
<whitequark>
ggole: oh nevermind, it's debug info mainly. the Release version is 2.3M
<ggole>
When I tried writing selectors (on three-address code), I found the main difficulty was how to tell when an operation could be fused into a more efficient instruction without generating a namable value (ie, in a register)
<ggole>
But you can do it pretty easily by keeping coverage information
<ggole>
Dunno how to extend that scheme to DAGs though
<gasche>
tell us if you find us change to the -dcmm printer that would make re-parsing easier
<gasche>
(I think there was a Cmm parser in the compiler but I'm not sure it has been maintained)
<gasche>
(by "make re-parsing easier" I think mostly of information that would be lost during pretty-printing)
slash^ has joined #ocaml
<nicoo>
whitequark: 'kay
ygrek has quit [Ping timeout: 276 seconds]
<whitequark>
gasche: no, actually the printer preserves everything, including debug info
<whitequark>
the parser lags behind, but modifying it to be up-to-date is trivial
<whitequark>
anyway, -dcmm is very much a temporary solution
dapz has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
elfring has joined #ocaml
ygrek has joined #ocaml
<elfring>
Which data formats do you prefer to implement the techniques "remote function call" and/or "remote method invocation" in your software applications?
<Drup>
Ajax.
<def-lkb>
session types \o/
<def-lkb>
(underlying data format left to functor)
<whitequark>
Drup: but Ajax is not a data format?
ygrek has quit [Ping timeout: 265 seconds]
<Drup>
Don't minimize Ajax's bloatiness
<Drup>
(but you are right, it's just an over complicated xml format)
<Drup>
(over http)
tobiasBora has joined #ocaml
<companion_cube>
elfring: bencode, obviously ^^
<nicoo>
Drup: AJAX doesn't need to be XML. One could use Bencode :>
<whitequark>
anything more than two minor LLVM versions ago is irrelevant
<whitequark>
in this case anything... except LLVM trunk is irrelevant, because I need new calling conventions
<elfring>
The program "ocamlopt.opt" can also be executed in a Cygwin environment. Do generated OCaml archive files contain dependencies on software components from Cygwin in
<elfring>
this configuration?
<elfring>
How will libraries be categorised in this variant? (Windows API or POSIX compatible?)
<adrien>
no
<Axman6>
anything one version old is either catching up or dying
<adrien>
elfring: again, read "README.win32" in the ocaml sources!
slash^ has quit [Remote host closed the connection]
<whitequark>
it's fun to watch how "let square x = x *. x" gets exploded into 26 LLVM instructions
<whitequark>
also, I believe LLVM will not suffer from the issue that >10 arguments forbid TCO
<whitequark>
at least I do not see a concrete reason why it would.
<companion_cube>
does llvm *allow* tco ?
<whitequark>
sure
<companion_cube>
go on then ^^
<whitequark>
I mean, TCO is not exactly hard to support
<whitequark>
the issue is that you need callee to pop its arguments, and practically every convention is incompatible with that
<whitequark>
on x86 the only conventions supporting TCO are "fastcc" (LLVM's "whatever I like most today" convention), ghc and hipe conventions
Submarine has joined #ocaml
Submarine has quit [Changing host]
Submarine has joined #ocaml
<Axman6>
ruse ghc then =)
<Axman6>
-r
<whitequark>
ghc solves it in a radical way, its calls never return, and arguments never spill on stack
<whitequark>
I believe that instead of spilling, a higher level translator (Core->STG?) will insert thunks
<whitequark>
so it essentially spills on heap
<Axman6>
yeah I seem to remember it was pretty weird. I've read some ghc output LLVM code and it's not pretty trying to figure out what's what is hard when the names are bangled and most of the arguments are all the same for evert single call
<whitequark>
yes, that's how you implement register pinning in LLVM, pass them explicitly around
<whitequark>
it translates into literally no machine code, but the IR is unwieldy
<whitequark>
hipe inserts some weird stack manipulation crap into prologue, so can't use that either
<Axman6>
there's some issues on OS X with a lack of register pinning of TLS data, means things can be up to 20% slower when using OS X/LLVM
<Axman6>
GHC didn't have those issues, it implements TLS with a pinned register
<Axman6>
or something like that, I wasn't too deep into that discussion
<whitequark>
I can see why would that happen
<whitequark>
normally, tls on x86 is performed via %fs:0 (or %gs:0 on 32-bit)
<Axman6>
I've been told OS X defines it differently
<whitequark>
sure
Muzer has quit [Excess Flood]
Muzer has joined #ocaml
studybot has joined #ocaml
studybot_ has joined #ocaml
studybot has quit [Ping timeout: 245 seconds]
nikki93 has quit [Remote host closed the connection]
<whitequark>
typename llvm::cast_retty<X, Y*>::ret_type llvm::cast(Y*) [with X = llvm::PointerType; Y = const llvm::Type; typename llvm::cast_retty<X, Y*>::ret_type = const llvm::PointerType*]: Assertion `isa<X>(Val) && "cast<Ty>() argument of incompatible type!"' failed.
<whitequark>
(╯°□°）╯︵ ┻━┻
<whitequark>
writing things for LLVM is 20% writing code, 80% staring at messages like a goat
<Drup>
whitequark: I'm starting to work on the llvm part of my project next week, thanks for the reassuring words x)
<whitequark>
well, the good part is that it practically never segfaults
<Drup>
that's nice
<whitequark>
I mean, asserts at least point you in the right direction
iorivur has joined #ocaml
tobiasBora has quit [Ping timeout: 276 seconds]
<whitequark>
Drup: really, the most valuable tool so far was gdb. make it print a backtrace at abort, and you have most of the info, ahem, you will ever have
<whitequark>
I wish OCaml added DWARF information for lvars and arguments. another thing that LLVM can easily do..
<NoNNaN>
whitequark: that's not a bad ratio, i have similar (but worse ratio) experience with llvm
divyanshu has quit [Ping timeout: 276 seconds]
keep_learning has joined #ocaml
<keep_learning>
Hello all,
nikki93 has joined #ocaml
<keep_learning>
Could some one please tell me why I am getting Unbound value check_unary for this code http://lpaste.net/102938
<keep_learning>
I have just defined the function check_unary after the typechecking function.
yezariaely has joined #ocaml
yezariaely has quit [Client Quit]
arj has joined #ocaml
<Drup>
let .. and ... is // declaration
<Drup>
you need a rec if you want those to call each other
<Drup>
or just declare check_unary before
tobiasBora has joined #ocaml
<keep_learning>
Drup: Thank you.
arj has quit [Remote host closed the connection]
Anarchos has joined #ocaml
rgrinberg has joined #ocaml
tautologico has joined #ocaml
michael_lee has joined #ocaml
Anarchos has quit [Quit: Vision[0.9.7-H-20140108]: i've been blurred!]
Anarchos has joined #ocaml
<whitequark>
argh, Cmm does (+ i -2), where i is of type addr
<whitequark>
it's even worse than C
<whitequark>
... fortunately, LLVM has an instruction which performs exactly reverse transformation!
<whitequark>
-_-'
<adrien>
ocaml outputs assembly :)
<adrien>
all the dirty tricks you wished you couldn't think of
<whitequark>
Cmm isn't really assembly, it's a typed IR
<whitequark>
it's just... weakly typed, and in all the wrong places
<whitequark>
well, it's the last machine-independent IR of ocamlopt, to be specific
<whitequark>
Cmm means C-- (google that)
<tautologico>
but there's actually a language called C--
<whitequark>
yep, Cmm is modelled around that
<tautologico>
right
<Anarchos>
the same as in compcert ?
<whitequark>
compcert uses Cminor, whatever that is
avsm has joined #ocaml
<tautologico>
Clight
<tautologico>
another subset of C, created for different reasons. Clight is for easier verification, C-- is created to be an IR for compilers
<tautologico>
*is intended
shinnya has quit [Ping timeout: 240 seconds]
elfring has quit [Quit: Konversation terminated!]
zpe has quit [Remote host closed the connection]
zpe has joined #ocaml
nikki93 has quit [Remote host closed the connection]
zpe has quit [Ping timeout: 252 seconds]
keep_learning has quit [Quit: Page closed]
nikki93 has joined #ocaml
clan has quit [Quit: clan]
<gasche>
16:45 < whitequark> I wish OCaml added DWARF information for lvars and arguments. another thing that LLVM can easily do..
<gasche>
Mark Shinwell has a branch doing that
iorivur has quit [Ping timeout: 245 seconds]
<Drup>
gasche: I tried to prevent batteries from executing some Weak functions, in order for companion_cube's branch to load out of the box in js_of_ocaml
<Drup>
I couldn't figure out the path were it was executed
<Drup>
if you have though about it and have an idea, it would be welcome
<Drup>
where*
tlockney_away is now known as tlockney
<mrvn>
gasche: and the GC could use DWARF info so valued wouldn't have to be boxed across allocations.
Don_Pellegrino has quit [Quit: Konversation terminated!]
slash^ has joined #ocaml
<gasche>
iirc one reason Mark didn't worry too much is that "perf" still doesn't support DWARF (I think), so the use-case they were interested in pretty much still requires frame pointers
<gasche>
Drup: I have no idea what you're talking about but I don't mind having a look if you tell me how to test for the bad event happening
<Drup>
gasche: when you load a program using unknown primitives in js_of_ocaml
<Drup>
it generate stubs that just raise an exception
<Drup>
as long as it's not used, you're fine
<Drup>
the issue is that batteries as some effectful stuff
<Drup>
this was the reason Unix had to go away, not because Unix is impossible to use in js_of_ocaml, but because it was effectful
<Drup>
and apparently, there is the same issue with Weak stuff
<gasche>
well
<gasche>
there is an instantiation of the Weak.Make functor at the toplevel of BatInnerWeakTbl
<Drup>
yes, I looked at it
<Drup>
my first try was to wrap every Weak thingy in a lazy
<companion_cube>
InnerWeakTbl must die!
<Drup>
but it's not enough
<companion_cube>
(sorry)
<Drup>
something is really executing it :/
* adrien
tazes companion_cube
<companion_cube>
8/
<gasche>
what is the name of the function called?
cyborks has quit [Ping timeout: 252 seconds]
<Drup>
the primitive is caml_weak_create
<Drup>
don't have more than that
<Drup>
(which explain the difficulties ..)
<gasche>
placeholder_in in BatInnerIO
cyborks has joined #ocaml
<Drup>
yeah, I wrapped the weak part in a lazy
<gasche>
that won't help if input_channel is called
<Drup>
why would it be called ?
<Drup>
I'm not using it
<gasche>
how can I test your problem at home?
<Drup>
I think you need companion_cube's version, in order not to have Unix
<Drup>
and them, something like "ocamlbuild -package batteries.core foo.ml && js_of_ocaml foo.byte -o foo.js"
<Drup>
with some stupid foo.ml calling whatever batteries stuff unreleated to IO
<Drup>
foo.byte* not foo.ml
<gasche>
will any version of jsoo do?
<Drup>
It should, yes
<Drup>
(but I only tried with 2)
<Drup>
and after that, just tried to execute the js in your browser, and watch it explode in your console
<ygrek>
gasche, companion_cube: I use oasis in dynamic mode and _tags contains empty #OASIS_START #OASIS_STOP plus my own stuff
<ygrek>
it regenerates that section at build time
<Drup>
same here
<Drup>
it's quite nice
<companion_cube>
ygrek: dynamic mode makes oasis not overwrite files?
<ygrek>
it makes setup.ml small
<Drup>
no
<Drup>
companion_cube: I have a patch for batteries-light to use it
<ygrek>
almost everything is generated at compile time
<Drup>
I'm just waiting for something else to pull-request
<ygrek>
and then restored back after build
<Drup>
it's very clean, yeah
<companion_cube>
oh
<Drup>
and with the last oasis, there is an alpha feature so that the setup is compiled
<Drup>
so it's fast too
<Drup>
(you can offer cookies to jpdeplaix for that)
<companion_cube>
:)
<companion_cube>
documentation should build in v3-alpha now
rgrinberg has joined #ocaml
<jpdeplaix>
Drup: I don't know :/ caml_failwith should be included in the runtime :/
<Drup>
that's what I though too
cthuluh has joined #ocaml
maattdd has joined #ocaml
ygrek has quit [Ping timeout: 240 seconds]
yacks has joined #ocaml
<tautologico>
rgrinberg: possible, yes, but I don't know if it would be much useful
<rgrinberg>
tautologico: i'm not looking to use it in any real code. I'm mostly interested in how you can emulate rank 2 polymorphism in OCaml
arj has joined #ocaml
cthuluh has quit [Ping timeout: 276 seconds]
zpe has quit [Remote host closed the connection]
cthuluh has joined #ocaml
zpe has joined #ocaml
zpe has quit [Read error: Connection reset by peer]
zpe has joined #ocaml
<gasche>
Drup: the invocation indeed comes from the functor I pointed to
<gasche>
more precisely, the line "let emptybucket = weak_create 0" in stdlib/weak.ml
<Drup>
huum, ok
<Drup>
did you managed to fix it by wrapping up in lazy or is it hopeless ?
<gasche>
I didn't try
<Drup>
ok
<gasche>
it wouldn't be very hard to fix the stdlib to not do the invocation until either "create" or "clear" is called
zpe has quit [Remote host closed the connection]
<Drup>
oh, so you think the fix should be in the stdlib ? ok
<gasche>
I'm not saying that
zpe has joined #ocaml
<gasche>
another solution would be to add a caml_weak_create primitive in js_of_ocaml
<gasche>
you could make it work when called on size 0, and fail otherwise
<Drup>
there is one, not part of the base runtime
<Drup>
there is a "dummy" implementation which is basically not weak
<Drup>
but we shouldn't need it if weak is not used ...
<gasche>
is there any downside in using it?
<companion_cube>
basically there is no reason to need Weak if one only uses basic features of batteries
<Drup>
gasche: more unneeded javascript ?
<Drup>
I mean, javascript is quite strongly space-constrained, the less you need, the better
<companion_cube>
I doubt many people actually use the weirds BatIO wrappers that require weak sets...
<Drup>
this is why I dislike effectful modules. Even with deadcode elimination, you can't discard those, and it's wrong.
<ggole>
You gotta have at least one
zpe has quit [Ping timeout: 245 seconds]
<Drup>
ggole: my point is that you shouldn't have any in a *library*
<adrien>
unless you discard everything
<adrien>
instant load time and instant run time
dapz has joined #ocaml
<gasche>
calling caml_weak_create is not effectful
<Drup>
then we don't agree with the definition of effectful :p
<ggole>
Creating some initial objects isn't really a bad thing to do in a module
<ggole>
And it's only problematic here because JS is such a horrible environment
<Drup>
ggole: vanilla batteries is calling Unix stuff as a side effect
<Drup>
I mean, however you look at it, it shouldn't be the case in a library
<ggole>
Libraries shouldn't depend on other things?
<Drup>
I never said depend
<Drup>
I said executing
<Drup>
you load BatUnix, it executes unix-dependent code
<adrien>
you load lablgtk's auto-init stuff, it requires X11
<Drup>
adrien : well at least, the name is obvious in this case
<gasche>
I don't see the problem with initialization as long as it's observationally pure
<adrien>
obvious because I made it obvious :D
<adrien>
used to be gtkInit.cmo
<tautologico>
BatUnix, the unix used by Batman
<Drup>
gasche: the fact that a js_of_ocaml program using BatList doesn't even load is not a problem ? :)
<Drup>
that's not because you don't use js_of_ocaml that you shouldn't care
<Drup>
anyway, thanks for the investigation, I will see what I can do about it.
<gasche>
I would like js_of_ocaml to run
<gasche>
but don't make it look like running stuff in a module is a bad thing
<gasche>
you are discovering that stuff is bloated by trying to run in a naked environment
<gasche>
let's fix it if we can, but please a little less contempt for the work of the people that introduced some of the bloat to solve actual problems with code contributions
sgnb has quit [Remote host closed the connection]
sgnb` has joined #ocaml
<gasche>
creating an empty (weak) table at program startup is *not* a grave design mistake
<gasche>
even if it means the simplest fix would indeed to add support for this in the javascript runtime
tlockney is now known as tlockney_away
<gasche>
(papering over the fact that JS does not have weak sets; or does that mean everyone using weak sets in OCaml is making design mistakes as well?)
<gasche>
next time we'll be hearing that writing code that is O(1) memory usage because of tail calls is "effectful" because in JS there are no tail calls and stack-overflow is an observable effect
<companion_cube>
in this case I think the weak table is totally overkill anyway
<gasche>
I couldn't tell, I have no idea what that part of IO does
<companion_cube>
well it builds outputs/inputs by wrapping other channels, and registers the wrapper so it gets closed when the original channel is closed
<companion_cube>
for instance you could wrap stdout into a new output channel that compresses on the fly
<companion_cube>
that's the kind of things Gerd does in ocamlnet afaik
<gasche>
the problems generally are with the auto-close semantics
<companion_cube>
it's pretty close, yes
<companion_cube>
because here stdout would have a weak pointer to the wrapper
<companion_cube>
otoh I'm afraid no one is able to maintain InnerWeakTbl, because it's really *ugly*
<companion_cube>
(starts with "open Obj"...)
<gasche>
I don't see much of a problem with InnerWeakTbl
slash^ has quit [Ping timeout: 258 seconds]
<gasche>
I have never been convinced by BatIO, but that is something else
<gasche>
(and the idea of a higher-level IO layer certainly seems nice; it's more the idea of renaming existing functions to work on an incompatible type that I find very debatable)
slash^_ has joined #ocaml
<companion_cube>
the problem is that standard IO channels are too specific, you can't write a common printer for all of them
<companion_cube>
apart from that BatIO is too complicated imgo
<companion_cube>
imho
<gasche>
in any case
<gasche>
it makes sense for IO to use weak sets here
<gasche>
and the right thing to do, if you wanted to use IO from js_of_ocaml, would be to revert to non-weak sets and be careful to close stuff more explicitly
<gasche>
now the question is: "why would IO be linked if I only want to use BatList"?
cthuluh has quit [Ping timeout: 240 seconds]
<gasche>
either you remove BatList.print from the interface, or you improve the dead-code elimination of js_of_ocaml
<gasche>
I think the latter would be the better choice
<gasche>
and that's not a concern with Batteries itself
slash^_ is now known as slash^
nikki93 has quit [Remote host closed the connection]
<companion_cube>
then it prevents batteries from being used with js_of_ocaml, forever
<gasche>
I don't follow, wouldn't using a dummy stub for caml_weak_create solve that problem for the short term?
cthuluh has joined #ocaml
<companion_cube>
gasche: I think it's another occurrence of the "batteries has a lot of old-ish, not very maintained stuff that is very complex but unremovable"
<gasche>
hm
<gasche>
if I understand correctly there are basically three options
<gasche>
(1) improve js-of-ocaml's dead-code elimination to cut BatIO from batteries-program that don't actually need it (hard work, but benefits all users of js-of-ocaml, Batteries or otherwise)
<gasche>
(2) ask users of Batteries + js_of_ocaml to include a dummy javascript stup (... mildly unpleasant?)
Anarchos has quit [Quit: Vision[0.9.7-H-20140108]: i've been blurred!]
<gasche>
(3) hack and slash through Batteries interface (breaks users code)
Anarchos has joined #ocaml
<companion_cube>
(4) fork? :D
<gasche>
well
<gasche>
if you don't think that (1) is a valuable time investment for any of you
<gasche>
hm
<companion_cube>
I'm not convinced it would work
<companion_cube>
I mean, woudl it be after linking?
<gasche>
dead-code elimination is whole-program already
<companion_cube>
the problem is also the rest of the ugly, old complicated stuff of batteries... which includes Enum
<companion_cube>
(and in a lesser extend IO)
<companion_cube>
(and batDigest)
<adrien>
you've already started something; I'd say: continue and once you get something you like, see how you can bridge the gap between the two versions
<adrien>
(right now you look like politicians :] )
<companion_cube>
adrien: I fear the gap will become too large
<companion_cube>
it may already be with the removal of Enum
<adrien>
there might be some work to make that bridge but you'll only know later on
<gasche>
my understanding is that companion_cube is not willing to do any compromise to bridge that gap
<companion_cube>
gasche: indeed, I'm not super enthusiastic about reverting the hundred of lines that replace Enum with Gen
<companion_cube>
hundreds*
<gasche>
(going back to format+gadts)
zpe has joined #ocaml
zpe has quit [Ping timeout: 240 seconds]
dapz has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
dapz has joined #ocaml
zxqdms has quit [Ping timeout: 240 seconds]
zxqdms has joined #ocaml
slash^ has quit [Remote host closed the connection]
lostcuaz has joined #ocaml
dapz has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
dapz has joined #ocaml
avsm has quit [Quit: Leaving.]
Submarine has quit [Quit: Leaving]
avsm has joined #ocaml
dapz has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
johnelse_ is now known as johnelse
dapz has joined #ocaml
arj has quit [Remote host closed the connection]
dapz has quit [Client Quit]
dapz has joined #ocaml
ggole has quit []
dapz has quit [Client Quit]
ollehar has joined #ocaml
acieroid has quit [Ping timeout: 240 seconds]
acieroid has joined #ocaml
ollehar has quit [Ping timeout: 240 seconds]
arthurb has joined #ocaml
dapz has joined #ocaml
<arthurb>
It's a bit of a dumb question but I haven't touched ocaml in a long time... When you write a module, the clean thing to do is to give the module it's own ml file and to give its signature its own mli file... What do you do when you write a functor? Just embed it into some other .ml file? Will that file be compiled as a module? How does it work?
<Drup>
yes, you put the functor inside another module
ollehar has joined #ocaml
<Drup>
not sure what more information you want :p
dapz has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
dapz has joined #ocaml
Kakadu has quit [Quit: Konversation terminated!]
axiles has quit [Remote host closed the connection]
ollehar has quit [Ping timeout: 240 seconds]
nikki93 has joined #ocaml
<arthurb>
Drup:well then do I have a mli file at all?
<arthurb>
and can I name my functor the same as the file?
<Drup>
you have a .mli file for the whole module
Muzer has quit [Excess Flood]
<Drup>
which functor is inside
Muzer has joined #ocaml
dapz has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
<arthurb>
uh but there's nothing else in the module
<arthurb>
just a functor
<Drup>
yes, that's not a problem
<Drup>
just put the functor of the mli :)
<Drup>
grmbl
<Drup>
just put the signature of the functor in the mli*
<Anarchos>
Drup what is the signature of a functor like ?
<Drup>
module Foo (Bar : S) : sig .... end
<Drup>
with S being a module signature
<arthurb>
k thanks
lostcuaz has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<Anarchos>
Drup ok.
johnf has quit [Read error: Connection reset by peer]
johnf has joined #ocaml
Thooms has quit [Ping timeout: 252 seconds]
tobiasBora has quit [Quit: Konversation terminated!]
dapz has joined #ocaml
pdewacht has joined #ocaml
ollehar has joined #ocaml
rgrinberg has quit [Quit: Leaving.]
tlockney_away is now known as tlockney
cesar_ has joined #ocaml
cesar_ is now known as Guest17064
Anarchos has quit [Quit: Vision[0.9.7-H-20140108]: i've been blurred!]
darkf has joined #ocaml
rgrinberg has joined #ocaml
avsm has quit [Quit: Leaving.]
avsm has joined #ocaml
madroach has quit [Ping timeout: 252 seconds]
ollehar has quit [Ping timeout: 240 seconds]
madroach has joined #ocaml
NoNNaN has quit [Remote host closed the connection]