studybot has quit [Remote host closed the connection]
studybot has joined #ocaml
studybot has quit [Read error: Connection reset by peer]
berkedur has joined #ocaml
<berkedur>
does 4.x have natdynlink on ARM?
tlockney_away is now known as tlockney
iorivur has joined #ocaml
ygrek has joined #ocaml
<berkedur>
i know 3.12 doesn't support natdynlink on arm.... and i know there is a patch for 3.12. I'm just wondering if ARM native dynamic linking super had been integrated into the mainline
studybot has joined #ocaml
studybot_ has joined #ocaml
studybot has quit [Ping timeout: 252 seconds]
struktured has quit [Ping timeout: 245 seconds]
studybot_ has quit [Ping timeout: 245 seconds]
studybot has joined #ocaml
studybot_ has joined #ocaml
jbrown has quit [Remote host closed the connection]
pyon-fire has quit [Quit: brb]
studybot has quit [Ping timeout: 258 seconds]
berkedur has quit [Ping timeout: 240 seconds]
nikki93 has quit [Remote host closed the connection]
tautologico has joined #ocaml
<tautologico>
whitequark: in your ppx post, first sentence of the "Packaging" section, broken link to opam
<whitequark>
there's another project, https://github.com/raph-amiard/CamllVM, which does the translation in *really* odd way (bytecode --C++--> LLVM JIT), and has performance way inferior compared to ocamlopt. again, weird.
<whitequark>
Colin's approach was the one I liked, translating Cmm->LLVM IR
<whitequark>
though it is again odd, because he generates the IR as text...
divyanshu has joined #ocaml
<whitequark>
screw it, I'm going to write a proper backend right now
<whitequark>
mrvn: by the way, OCaml *does* handle roots in registers. caml_call_gc pushes everything on stack.
<whitequark>
see amd64.S:281
<whitequark>
so, OCaml doesn't treat calls to caml_alloc* as regular calls into C *or* into OCaml
cmcq has quit [Quit: cmcq]
tlockney is now known as tlockney_away
yezariaely has joined #ocaml
axiles has joined #ocaml
studybot has joined #ocaml
yezariaely is now known as arj
iorivur has quit [Ping timeout: 245 seconds]
Simn has joined #ocaml
ygrek has quit [Ping timeout: 250 seconds]
iorivur has joined #ocaml
manizzle has joined #ocaml
yezariaely has joined #ocaml
arj has quit [Ping timeout: 240 seconds]
clan has quit [Quit: clan]
yezariaely is now known as arj
tobiasBora has joined #ocaml
tane has joined #ocaml
iorivur has quit [Ping timeout: 252 seconds]
iorivur has joined #ocaml
ggole has joined #ocaml
clan has joined #ocaml
rgrinberg has quit [Quit: Leaving.]
siddharthv_away is now known as siddharthv
studybot has quit [Read error: Connection reset by peer]
studybot has joined #ocaml
studybot has quit [Remote host closed the connection]
studybot has joined #ocaml
studybot has quit [Remote host closed the connection]
studybot has joined #ocaml
ygrek has joined #ocaml
nikki93 has quit [Remote host closed the connection]
nikki93 has joined #ocaml
zarul has joined #ocaml
zarul has quit [Changing host]
zarul has joined #ocaml
nikki93 has quit [Ping timeout: 240 seconds]
AltGr has joined #ocaml
amiller has quit [Ping timeout: 250 seconds]
alex_nx has quit [Ping timeout: 250 seconds]
nikki93 has joined #ocaml
alex_nx has joined #ocaml
Guest64460 has joined #ocaml
nikki93 has quit [Ping timeout: 258 seconds]
iorivur has quit [Ping timeout: 240 seconds]
iorivur has joined #ocaml
nikki93 has joined #ocaml
iZsh has quit [Ping timeout: 240 seconds]
nikki93 has quit [Ping timeout: 276 seconds]
ikaros has joined #ocaml
nikki93 has joined #ocaml
nikki93 has quit [Ping timeout: 245 seconds]
nikki93 has joined #ocaml
ddosia has quit [Quit: Leaving.]
nikki93 has quit [Ping timeout: 265 seconds]
divyanshu has quit [Quit: Computer has gone to sleep.]
Kakadu has joined #ocaml
nikki93 has joined #ocaml
ddosia has joined #ocaml
nikki93 has quit [Ping timeout: 276 seconds]
avsm has joined #ocaml
maattdd has joined #ocaml
avsm has quit [Quit: Leaving.]
divyanshu has joined #ocaml
rossberg has joined #ocaml
nikki93 has joined #ocaml
nikki93 has quit [Ping timeout: 276 seconds]
Thooms has joined #ocaml
iorivur has quit [Ping timeout: 240 seconds]
zpe has joined #ocaml
Thooms has quit [Quit: WeeChat 0.3.8]
darkf has quit [Ping timeout: 258 seconds]
studybot has quit [Read error: Connection reset by peer]
darkf has joined #ocaml
ollehar has joined #ocaml
thomasga has joined #ocaml
tobiasBora has quit [Ping timeout: 246 seconds]
jonludlam has joined #ocaml
nikki93 has joined #ocaml
<whitequark>
why does ocamlc code frequently use Hashtbl.create 17 ?
<adrien_oww>
good question :D
<flux>
17 is the magic number.. 18 is too much, 16 is too little. obvious, really.
<pippijn>
17 is a prime number
<pippijn>
=> less collisions
<pippijn>
it could be 19, though :)
<companion_cube>
it's weird
<pippijn>
I guess someone decided 17 looks nice
<pippijn>
and then everybody just kept it
<companion_cube>
the code for hashtbl.create rounds it to a power of two
<flux>
does it really affect the hashtbl functionality so?
<companion_cube>
let s = power_2_above 16 initial_size
<pippijn>
companion_cube: that's stupid then :)
<companion_cube>
:D
<adrien_oww>
:D
<companion_cube>
it must have been changed afterwards
<flux>
yeah, legacy is the best explanation
<flux>
and then on people just copied it
<companion_cube>
I do it pretty often :3
<flux>
the initial values should be based on profiling results :)
<companion_cube>
profiling the impact of every single hashtable creation point?
<companion_cube>
tough
<flux>
you would profile how the big the hash tables created by each different place grows
<flux>
and then use some suitable metric, like, sqrt(s), max(x, sqrt(s)) or something
<flux>
and use gradient descent to find the numbers resulting in optimal performance :)
<companion_cube>
my concern is more about memory usage, because I tend to create a lot of small tables
nikki93 has quit [Ping timeout: 276 seconds]
<ggole>
CS textbooks used to recommend prime table sizes in order to improve distribution
arj has quit [Quit: Leaving.]
choeger_tu has joined #ocaml
<flux>
it depends on how you choose the bucket really
<flux>
it doesn't need to be simply hash%number_of_buckets
<whitequark>
what have I started...
<ggole>
But the modulo operation is too expensive. You really want a nice cheap operation for that.
<choeger_tu>
gildor?
<flux>
and therefore we use 2^n buckets?
<ggole>
Thus, power of two sizes (allowing % to be an and)
<flux>
so I'm not sure what you are arguing for ;-)
<Drup>
whitequark: do you plan to start on top of pierre's branch ?
<choeger_tu>
is anyone of you familiar with oasis
<choeger_tu>
?
<adrien_oww>
just ask your question :)
<choeger_tu>
I need to link against an external C-library
<choeger_tu>
and this usually requires a -L flag
<choeger_tu>
how to I get that flag from the user?
<Drup>
you can pass flags with CCOpt and CCLib
<adrien_oww>
"from the user"?
<adrien_oww>
also, the -l will be stored in the cma file and reused when linking against it
avsm has joined #ocaml
<choeger_tu>
I know about the CCOpt stuff, but inside _oasis I have to give a concrete path
<choeger_tu>
so when a user gets my software and wants to compile it with library X somewhere, this user needs to be able to pass the value of the -L flag to the build process
<adrien_oww>
the C library is installed system-wide or?
<choeger_tu>
no
<choeger_tu>
not necessarily
<whitequark>
Drup: hang on, pierre's branch?
<Drup>
whitequark: pierre chambart, working on the flambda intermediate representation and inlining
<whitequark>
Drup: well... so far, from the official trunk. I'm only using Cmm, so I could easily plug it in later
<whitequark>
the three things I think LLVM will do best are:
<Drup>
stable as "I can compile lilis (which has batteries, cairo2 and lablgtk as dependencies)"
<whitequark>
1) SIMD 2) inlining 3) LTO together with C code
<whitequark>
i.e. I want to remove as much assembly as possible and expose such things like caml_allocN via LLVM IR so they will be inlined as well
<Drup>
whitequark: do you really feel it's a good choice to pay the cost of a full fork of the compiler ?
<Drup>
(let's be reasonable : it's never going to be merged ;))
<whitequark>
why wouldn't it be?
<Drup>
you could start from the bytecode, it's easier to maintain
thomasga has quit [Quit: Leaving.]
<pippijn>
bc_of_ocaml?
<whitequark>
but if I put it into the compiler, it's easier to use. `opam switch 4.01.0+llvm
<Drup>
whitequark: "opam install whatever_of_ocaml", same difference
nikki93 has joined #ocaml
studybot has joined #ocaml
<whitequark>
Drup: quite big difference in that you could then just continue installing stuff and it will be built properly
<Drup>
except that you don't have to synchronise with the compiler and keep up with the changes anymore, or very marginaly so
<Drup>
all the major fork of the compiler are all dead or outdated
thomasga has joined #ocaml
maattdd has joined #ocaml
<whitequark>
Drup: btw, why are you so sure it won't be merged?
<whitequark>
considering there is substantial improvement and the code is of high quality
<Drup>
you would need to have something perfect with no regression whatsoever, and I don't believe it. I will be ever happy if you proove me wrong :)
<Drup>
very happy*
<flux>
so is it a new target or a wholesale replacement of a big chunk of code?
<whitequark>
flux: it *almost* fits as a new target
<flux>
I think the ocaml compiler folks might not be that happy just swapping out code they know with a bunch of code they don't know
<flux>
in addition to introducing a dependency to LLVM, am I reading right?
<whitequark>
flux: nonono, I'm not going to remove anything. ocamlopt stays.
iorivur has joined #ocaml
<flux>
well, that's more reasonable then I think
<flux>
but, js_of_ocaml isn't merged ;)
<Drup>
there is no point of merging js_of_ocaml
<Drup>
it doesn't touch the compiler
<whitequark>
flux: the idea is that I add, say, llvmcomp/ next to asmcomp/, and that defines its own Asm_gen and Asm_link
<flux>
right
<flux>
I'm not sure if these things should be merged as soon as they are ready. but when they have been battle proven ;)
<whitequark>
then you could use a switch in ocamlopt driver, or just have an ocamlllvm driver and use the findlib switch
<choeger_tu>
so it is generally impossible to link against a c-library in a non-standard directory using oasis ?
<NoNNaN>
a more modular / extensible compiler will speed up the compiler development, even if it external
<whitequark>
flux: the only place where it would touch the core of the compiler is a few places where it queries target-specific stuff... like pointer size
<Drup>
NoNNaN: that's what is doing chambart
thomasga has quit [Quit: Leaving.]
<whitequark>
flux: right now it's hardcoded, I'll have to change it to function calls, because the LLVM backend doesn't need / have / makes sense to hardcode target-specific data
<whitequark>
it can build for anything
<whitequark>
the reason for adding variants of Asm_gen and Asm_link are, less importantly, the fact that you probably shouldn't roundtrip through text if you can avoid it, and more importantly, LTO
thomasga has joined #ocaml
nikki93 has quit [Ping timeout: 245 seconds]
<NoNNaN>
Drup: and I welcome every compiler development
<whitequark>
I feel like ocaml's ecosystem is a perfect fit for doing LTO of OCaml and C code. OCaml likes to statically link, the compiler invocation is (almost?) always done via ocaml toolchain, the linking is done in ocaml too
<NoNNaN>
whitequark: the ocaml native codes will be compiled with clang ?
<whitequark>
NoNNaN: that's the idea. (if clang is available, that is)
<flux>
with clang? or llvm?
<whitequark>
flux: clang would compile libasmrun and stubs
<NoNNaN>
whitequark: you mean direct integration with libclang or as an external tool ?
<whitequark>
NoNNaN: as an external tool. just as ocamlc can invoke gcc now.
<flux>
whitequark, does it use the llvm assembler for something?
<whitequark>
flux: what does?
<flux>
whitequark, the fork :)
<flux>
of ocaml
<flux>
the thing you're discussing :)
<flux>
I mean it sounds like it does involved things
<NoNNaN>
whitequark: what is you plan with non x86 architectures?
<flux>
but how does it get SIMD support for ocaml code with clang? it generates c-code?
<whitequark>
guys, guys, there is only one of me :)
<flux>
well you should find a mate and fork!
<whitequark>
lol
<whitequark>
flux: so... clang is not directly used by ocamlc. clang will only be used by ocamlc to compile C stubs, just as ocamlc uses gcc now.
<flux>
right
<whitequark>
the idea that you first compile every module to a .o file which actually contains LLVM IR
<flux>
ok, so that not big a difference
<NoNNaN>
flux: it generated llvm ir, and llvm ir translated to vectorized code
<whitequark>
then at *link time*, you perform inlining and stuff
<whitequark>
what NoNNaN says is correct.
<whitequark>
I'm pretty sure mirage will like that, with it handling network packets and the like :p
<flux>
ah, so a big difference after all :)
contempt has quit [Changing host]
contempt has joined #ocaml
<whitequark>
flux: (involved things) really not. there is an Cmm->LLVM IR translator. it's... frustratingly trivial
<flux>
it still uses the same garbage collector?
<whitequark>
absolutely same
<whitequark>
in fact, LLVM-generated code will be ABI-compatible with ocamlopt-generated code
<whitequark>
you could in theory link those together, though I'm a bit lost as to why would you want it
<whitequark>
I'll write an LLVM plugin in C++ that handles OCaml's calling convention
<NoNNaN>
whitequark: as far as I know, ocaml has a special calling convention, what is your plan about this ?
<whitequark>
I just answered :)
<NoNNaN>
whitequark: you answered my question, before I posted it
<flux>
well, I think I would like to see that in OCaml proper. but I'm afraid it needs to be 'ready' before integration :).
<NoNNaN>
whitequark: please let me know, when your development is available, I am interested
<flux>
but if there are people calling for wider participation in OCaml compiler development
<flux>
I think this would be a one ticket for it
<flux>
as many people know and are interested in doing LLVM-related development
<whitequark>
flux: I absolutely agree. most of my thoughts about this backend concern clean integration into existing codebase
<flux>
actually I as well have done some LLVM work
<whitequark>
I think I'm also probably the most suited person to do this, as the current maintainer of ocaml llvm bindings :p
<Drup>
whitequark: if you are doing it like that, I get back what I said about integration
<NoNNaN>
whitequark: Apple just released an aarch64 target (64 bit arm) for llvm
<flux>
(both at the IR and the libclang level)
<Drup>
whitequark: I was only taking javaocaml as exemple :)
<whitequark>
Drup: \o/
<Drup>
talking*
<whitequark>
NoNNaN: I know, it's a bit of a mess
<whitequark>
LLVM currently has two 64-bit ARM targets
<Drup>
whitequark: javaocaml changes the whole chain, I think, so it's not an additional target.
<whitequark>
this is about 2x more than the current amount of 64-bit ARM processors on market
<avsm>
whitequark: what's the state of llvm's precise gc support? i've seen patches, but unsure about upstream
<whitequark>
avsm: isn't needed here.
choeger_tu has left #ocaml []
<whitequark>
at least from what I understand so far
* avsm
hasn't read the backtrace. just keyed off 'llvm' and assumed it meant an ocamlopt backend
<whitequark>
Drup: unlike js_of_ocaml and javaocaml, llvm backend is immediately useful for most of ocaml ecosystem, if it works right. an instant "make it fast" button
<Drup>
whitequark: "if it works right" is a big assumption :3
<avsm>
whitequark: so this might be a bit radical, but I wonder if breaking the ffi in an llvm backend is now viable if we hook in the right ctypes layer
<whitequark>
Drup: it's really much easier than it first seems
<avsm>
whitequark: but how can you get away without precise gc support in llvm?
<whitequark>
avsm: this means that the only thing I need to guarantee is that everything in registers is spilled to stack. in asmrun it's done in caml_call_gc
<whitequark>
it doesn't even need a special calling convention (the c/c is useful for fast exception handling, since you don't need to spill/mop stuff to/from the stack)
<NoNNaN>
probably in ocaml verifiable transformations are more welcomed than a huge amount of c++ code as dependency
<whitequark>
NoNNaN: you already depend on a huge amount of C code, it's called gcc
ollehar has quit [Ping timeout: 250 seconds]
<whitequark>
I mean, if there were no C stubs, you'd maybe were right. but with C stubs, of which there are plenty, all bets are off.
<NoNNaN>
whitequark: probably compcert is not yet compile the ocaml c runtime, but it will
<whitequark>
NoNNaN: it's mostly pointless though
<whitequark>
well, I mean, what do you gain? you verify the runtime but OCaml itself doesn't even have formal semantics
<NoNNaN>
but the bitcode has
<NoNNaN>
so does the transformations on bitcode
<whitequark>
does it even make sense to say "some parts of our toolchain were formally verified"?
<whitequark>
I mean, it's not a significantly stronger statement than "all of our toolchain is used daily by a lot of people"
<Drup>
(I'm surprised that mrvn is not participating in this conversation :D)
<whitequark>
NoNNaN: re other platforms: well, all platforms currently supported by ocaml are supported by llvm
maattdd has quit [Ping timeout: 250 seconds]
<whitequark>
and llvm supports a few more, e.g. ocaml will gain mips
<whitequark>
and arm64
<whitequark>
and maybe, if you export llvmcomp via compiler-libs, you could even compile graphics kernels with nvptx or r600
<NoNNaN>
whitequark: nvptx, hsail backand are also available
<whitequark>
seems I have already answered your question before you even said it :p
<NoNNaN>
whitequark: do you plan to support pncal ?
<gasche>
OCaml has mips and arm64 backends
<whitequark>
gasche: oh?
<gasche>
the mips one was removed from the distribution to reduce maintenance
<whitequark>
gasche: I believe I can fold all/most of it into IR, and then it will be almost entirely arch-independent
<gasche>
re. formal semantics: comiing up with a formal semantics for OCaml would be part of a compcert-for-OCaml effort
<gasche>
but it should not be very hard, because they have been formalizations of significant subsets already
<gasche>
much easier than, say, C++
_andre has joined #ocaml
<gasche>
whitequark: I warmly welcome any good work towards an LLVM backend for OCaml
<whitequark>
gasche: I'm really glad to hear that.
zpe has quit [Remote host closed the connection]
zpe has joined #ocaml
nikki93 has joined #ocaml
<avsm>
whitequark: likewise (my query about the precise gc support was more to do with needing to calculate stack maps and insert write barriers and so on)
<whitequark>
so far I do not see how ocaml generates or uses gc stack maps at all.
<whitequark>
it appears that it uses a conservative approximation of stack roots, like Boehm
<gasche>
there is the Azul guy working on a better GC support for LLVM
nikki93 has quit [Ping timeout: 276 seconds]
* whitequark
nods
yezariaely has joined #ocaml
<gasche>
whitequark: conservative in what sense? with the tagging and heap pages map
<whitequark>
gasche: it looks at every word in the stack and compares it against registered heap regions to determine whether it is a pointer to object
<NoNNaN>
avsm: this is the softcore that is developed in bluespec for BERI/CHERI?
<gasche>
whitequark: so there is no overapproximation
<whitequark>
gasche: compared to emitting maps of stack frames and then looking at those maps when one needs to get the local roots
<gasche>
ok
<gasche>
you mean the *scanning* is approximated to the whole stack
<whitequark>
yep
<avsm>
oh that's true
<avsm>
NoNNaN: yep
<whitequark>
gasche: by the way, there could be an overapproximation
<whitequark>
I heard int64 can be unboxed?
<avsm>
meeting, will catch up on this later. interesting stuff!
avsm has quit [Quit: Leaving.]
keen____ has joined #ocaml
claudiuc has quit [Remote host closed the connection]
<whitequark>
if yes, it could be placed on stack and mistaken for a pointer. considering that ocaml's gc moves, that would be disastrous.
<whitequark>
I wonder how ocaml avoids it
ccasin has quit [Ping timeout: 264 seconds]
keen___ has quit [Ping timeout: 250 seconds]
nikki93 has joined #ocaml
dzhulk has joined #ocaml
Thooms has joined #ocaml
<whitequark>
ah! nevermind, I was wrong. asmrun.c/caml_init_frame_descriptors
nikki93 has quit [Ping timeout: 258 seconds]
ocp has joined #ocaml
<whitequark>
so it is precise after all. it doesn't matter frankly, since LLVM's example GC emits specifically ocaml-compatible frame descriptors
<whitequark>
and whatever deficiencies it has can be fixed with more C++ :p
maattdd has joined #ocaml
tane has quit [Quit: Verlassend]
yezariaely has quit [Quit: Leaving.]
arj has joined #ocaml
<whitequark>
so... if I wanted to reuse existing infrastructure, I would need to manually spill all values to stack slots marked with @llvm.gcroot
<whitequark>
before every call that may allocate
maattdd has quit [Ping timeout: 265 seconds]
<whitequark>
this is not a problem at all, because ocaml uses a calling convention that spills everything anyway
nikki93 has joined #ocaml
<whitequark>
Colin Benner's implementation appears to use this as well
nikki93 has quit [Ping timeout: 240 seconds]
maattdd has joined #ocaml
dsheets has quit [Ping timeout: 245 seconds]
zpe has joined #ocaml
zpe has quit [Ping timeout: 245 seconds]
thomasga has quit [Quit: Leaving.]
eizo has joined #ocaml
tobiasBora has joined #ocaml
jonludlam has quit [Ping timeout: 245 seconds]
nikki93 has joined #ocaml
zpe has joined #ocaml
nikki93 has quit [Ping timeout: 252 seconds]
studybot has quit [Remote host closed the connection]
<jpeeters>
I want to catch sum type arguments using the as keyword
<jpeeters>
no one ?
<companion_cube>
you can do it
<companion_cube>
ah
<companion_cube>
you want to catch it as a tuple ?
<mrvn>
ousado: preventing a second thread from breaking the output_channel
<whitequark>
mrvn: evidently!
<mrvn>
jpeeters: you can't I believe. But Obj.magic will work.
<Drup>
mrvn: stop advising Obj.magic to beginners
<Drup>
please
<Drup>
T__T
<mrvn>
Drup: you are no fun
<companion_cube>
...
<Drup>
just in order for me to stop yelling each time you do it
<whitequark>
"malicious advice mrvn" ?
<mrvn>
whitequark: I don't get it though. Printf.printf sees the %s and calls unsafe_output -> caml_ml_output which gets the lock, outputs the whole string and releases the lock.
<ggole>
mrvn: might be trying to get the mutex a bunch of times, failing N times, and then aquiring it and doing the write?
<whitequark>
it could just use cc to assemble stuff :(
<mrvn>
adrien: why not call "CC tmp/fkgd.S"?
<adrien>
I don't' think that usually works
<adrien>
with gcc, yeah
<mrvn>
works totaly. Also has the added effect that cpp is used.
<adrien>
with all C compilers? doubtful
<mrvn>
adrien: oh, yeah. maybe not on !gcc.
<adrien>
and ocaml supports many other C compilers
<adrien>
although with the recent move to C99, that list is probably smalle
<adrien>
r
_andre has quit [Quit: leaving]
<adrien>
hmmmmmmmm
<elfring>
Can the file name "as" be sufficient to call the GNU assembler?
<elfring>
When do you need to specify a specific path explicitly?
<adrien>
when as cannot be found in the PATH environment variable
<adrien>
like with any executable
zpe has joined #ocaml
<adrien>
so you probably don't have to think about it
<adrien>
gasche: I just thought ./configure needed to be shrunk a bit probably with the move to C99; especially with things like: WARNING: you are using gcc version 2.7.2.1 on an Intel x86 processor.
<elfring>
Do you know the conditions when the file name "i686-w64-mingw32-as" would be used?
<adrien>
this name is useful when assemblers for several targets are available
<adrien>
this is the case for cross-compilation but not only
<whitequark>
adrien: do you think there'll ever be any progress on the cross-compile branch, now?
<adrien>
I'll be back on it at full speed after I get the new version of win-builds.org out
<mrvn>
adrien: do you own a raspberry Pi?
<adrien>
no
<mrvn>
adrien: any other arm?
<adrien>
I have access to a number of board though
<whitequark>
adrien: awesome \o/
<adrien>
mrvn: here at home, a sterllaris
<adrien>
actually, two
<mrvn>
adrien: Wandboard? Udoo? Pengpod?
* whitequark
could set up an ARM buildserver for the community or two, if such need arises
<adrien>
none of these I think but I have access to a wide range of arm boards
<elfring>
When should the file name "i686-w64-mingw32-as" be transformed into a path specification like "i686-w64-mingw32\bin\as" for the GNU assembler?
<mrvn>
adrien: currently I run ocamlopt in qemu-user-static to build my arm ocaml binaries.
<mrvn>
adrien: that is surprisingly simple too.
<adrien>
elfring: do *NOT* use that path
<adrien>
elfring: this is for internal use of the toolchain
rand000 has joined #ocaml
<adrien>
elfring: use "i686-w64-mingw32-as" or "as" if you are doing native builds (usually the case)
claudiuc has joined #ocaml
<elfring>
I stumbled over the situation that the file name "i686-w64-mingw32-as" is referenced by an OCaml compiler implementation.
<adrien>
the ocaml toolchain is meant to run under cygwin
<adrien>
but it generates native windows executables
<adrien>
in other words, this is cross-compilation
jpeeters has left #ocaml []
maattdd has joined #ocaml
thomasga has quit [Quit: Leaving.]
avsm has joined #ocaml
<elfring>
Are there any chances to get the interface (or port) "MinGW-w64" better supported?
ggole has quit [Ping timeout: 250 seconds]
<adrien>
elfring: it is fully supported
<adrien>
what is your issue with it?
maattdd has quit [Ping timeout: 265 seconds]
ocp has quit [Quit: Leaving.]
<elfring>
The default directory hierarchy from MinGW-w64 builds does not provide file names like "i686-w64-mingw32-as", "i686-w64-mingw32-ar" and "i686-w64-mingw32-ranlib".
<adrien>
install the compiler tools through cygwin instead
<adrien>
and actually
<adrien>
Jonathan's Protzenko's installer does it
<adrien>
honest question: why are you trying with mingw-builds?
ollehar has joined #ocaml
eizo has quit [Ping timeout: 240 seconds]
Submarine has joined #ocaml
Submarine has quit [Changing host]
Submarine has joined #ocaml
ollehar has quit [Ping timeout: 240 seconds]
dapz has joined #ocaml
<dapz>
Is there an R/Pandas like dataframe library for Ocaml?
<elfring>
I tried out the interface "MinGW-w64" because it is supported by the integrated development environment "Qt Creator 3.1.0" with default settings.
rgrinberg has quit [Quit: Leaving.]
dapz has quit [Client Quit]
clan has quit [Quit: clan]
ccasin has quit [Quit: Lost terminal]
<tautologico>
a dataframe library would be useful
<elfring>
The IDE "Qt Creator" supports also the building of software with the tool "CMake".
dapz has joined #ocaml
dapz has quit [Client Quit]
dapz has joined #ocaml
<dapz>
stupid wifi bs
clan has joined #ocaml
<adrien>
elfring: I see; I have no idea whether ocaml in QtCreator under windows is something that actually works
<tautologico>
dapz: I don't think so
<dapz>
Do you know of a clean way to call Python from Ocaml?
<dapz>
I kinda want to replace Python with something statically typed
<dapz>
but still want to do statistics/data science stuff
<mrvn>
Ok. I'm seeing a bit of a bad behaviour here. Printf.printf enters a blocking section with the channel mutex locked. My 2 test threads calculate fib(n) and print it. So thread 1 runs, starts to print the result, schedule(), thread2 wants to lock the channel and can't, schedule(), thread1 releases the lock, schedule(), thread2 can print. And the whole thing repeats with the roles reversed.
<pippijn>
pycaml maybe
<pippijn>
but it seems unmaintained
<Drup>
last time I looked at it, pycaml wasn't in very good shape :/
<dapz>
Ocaml R bindings..maybe this is what I need
<mrvn>
I think I need different thread queues for blocked and ready threads.
<tautologico>
dapz: I think this is unmaintained too
<dapz>
heh
<tautologico>
must not be very hard to interoperate with R though
<tautologico>
I'm also interested in doing this kind of thing in ocaml
Submarine has quit [Quit: Leaving]
<tautologico>
dapz: have you looked at F# though? they seem to have better libraries for this application area, including a dataframes lib (using type providers)
Kakadu has quit [Quit: Konversation terminated!]
<dapz>
I'm happy to give it a shot, but was a bit concerned about being tied to windows
<tautologico>
it has improved a lot recently
<tautologico>
I used it a few months ago
<dapz>
On windows or mac/linux?
<tautologico>
there are still uses because it seems 90% of the userbase is on windows, but it's getting better... it's kind of a mirror of the ocaml situation, where most of the userbase is on os x/linux so windows support is not as good
<tautologico>
dapz: OS X
<tautologico>
*there are still issues
<Drup>
there is one big issue
<Drup>
mono is shit.
<tautologico>
mono also improved a lot
<Drup>
maybe, I only tested one or two years ago
nikki93 has joined #ocaml
<tautologico>
yeah, it has come a long way
<Drup>
nice understatement :D
<dapz>
Alright, I guess in the short term I'll just stick with python. But going forward I'll investigate seeing if I can do this stuff in ocaml or something
<Drup>
dapz: you may be interested to look at julia
elfring has quit [Read error: Connection reset by peer]
<Drup>
it's not statically typed
<tautologico>
dapz: I'm thinking about doing some work in this area, maybe check back after a few months
<dapz>
I want static typing though
<tautologico>
Julia is cool
<Drup>
but it's certainly better that python
<Drup>
far better
<companion_cube>
dapz: there's an interesting blog from someone who switched from python to ocaml
<dapz>
Yeah, I saw that
<dapz>
the guy rewrote some python installer library in ocaml
<tautologico>
certainly a lot better than R/matlab... a bit better than python, especially the kind of things people do with numpy (like specifying matrices using strings, brrr)
<mrvn>
Why are ocaml signal numbers negative?
<mrvn>
tautologico: that doesn't work multi-core.
<tautologico>
mrvn: what doesn't work?
<mrvn>
tautologico: using strings in interfaces to other language.
<mrvn>
tautologico: with a string you can't release the runtime lock
<tautologico>
mrvn: I was talking about Julia vs. numpy
<mrvn>
then never mind
zpe has quit [Remote host closed the connection]
<tautologico>
today I learned that a compiled/packaged Julia is actually GPL, though the Julia code itself is MIT (Julia uses the Rmath library from R which is GPL)
zpe has joined #ocaml
<Drup>
:/
yacks has quit [Quit: Leaving]
<whitequark>
hmm, are ocaml's floating point comparisons ordered or unordered?
<adrien>
gasche: went through ./configure, removed what I thought was too old to be supported; ended up with this diffstat: 1 file changed, 3 insertions(+), 142 deletions(-)
zpe has quit [Ping timeout: 258 seconds]
Simn has quit [Quit: Leaving]
maattdd has joined #ocaml
arj has joined #ocaml
dapz has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
dapz has joined #ocaml
maattdd has quit [Ping timeout: 240 seconds]
dapz has quit [Client Quit]
dapz has joined #ocaml
rgrinberg has joined #ocaml
maattdd has joined #ocaml
troydm has quit [Ping timeout: 252 seconds]
troydm has joined #ocaml
<dapz>
Can you guys recommend an IDE for Ocaml?
<Drup>
emacs + merlin
<Drup>
(or vim + merlin, I don't care :p)
rand000 has quit [Quit: leaving]
* whitequark
uses Sublime Text with sublime-ocp-index
<Drup>
merlin is just too nice :p
avsm has quit [Quit: Leaving.]
<dapz>
I'll try both
arj has quit [Quit: Leaving.]
<rgrinberg>
Drup: ocp-index isn't bad actually
<rgrinberg>
it's considerably faster
<rgrinberg>
and it never crashes
<rgrinberg>
i still prefer merlin as well :D
<Drup>
:p
<Drup>
I didn't say ocp-index was bad
<Drup>
In particular, I like ocp-browse a lot
<Drup>
it's very usefull to search for a specific function very quickly, or to look inside a module
<rgrinberg>
Drup: never heard of ocp-browse? is it its own opam package?
<Drup>
no, it's inside ocp-index
<Drup>
if you have curses installed
<Drup>
I need to work on a new version, it's on my todo list
<Drup>
it's not really visible, I stumbled on it by mistake
<rgrinberg>
cool, let's check it out. sneaky depopts
<Drup>
it's basically a ncurse version of ocamlbrowser
<rgrinberg>
so you're implying that it's usable
<Drup>
I wouldn't go that far
<Drup>
because curse is a terrible library
zpe has joined #ocaml
<Drup>
so it's full of quirks
<Drup>
(hence the need for a rewrite, based on lambda-term)
<Drup>
(which I started, but didn't allocated enough time)
Thooms has quit [Quit: WeeChat 0.3.8]
<Drup>
but yes, it's quite cool :p
<nicoo>
Drup: Is your lambda-term-based rewrite somewhere else than your laptop?
<rgrinberg>
would be cool if it was part of utop
<Drup>
nicoo: of course
<Drup>
I don't keep anything on my laptop more than a week
<Drup>
I'm not sure META.foo are queried by ocamlfind
<Drup>
shouldn't be inside the main META
<Drup>
?
<whitequark>
oh... it tries stat("/home/whitequark/.opam/4.01.0/lib/llvm_X86/META and stat("/home/whitequark/.opam/4.01.0/lib/META.llvm_X86
<whitequark>
crap
<whitequark>
I wonder why and how it worked before
<Drup>
no one ever used it ? :p
<whitequark>
I did
<Drup>
I don't know then :p
<whitequark>
ahh, right, OCAMLPATH
<whitequark>
hum... this needs to be fixed upstream :/
nikki93 has joined #ocaml
<whitequark>
can't remember why the hell didn't I make it so already
S11001001 has joined #ocaml
S11001001 has quit [Changing host]
S11001001 has joined #ocaml
nikki93 has quit [Remote host closed the connection]
<whitequark>
gah! .native doesn't have a working ocaml backtrace, and .byte doesn't allow me to see what ocaml code caused llvm to assert
<whitequark>
this is *so* annoying
claudiuc has quit [Remote host closed the connection]
<whitequark>
btw, if I ever finish this, I should teach OCaml to emit proper DWARF, and burn its own backtracing code with a flamethrower. you'll get proper backtraces which respect inlining *and* interleaved C frames