jonasb has quit [Read error: 113 (No route to host)]
alexyk has quit []
<Yoric[DT]>
'night everyone
Yoric[DT] has quit ["Ex-Chat"]
ched has quit ["Ex-Chat"]
alexyk has joined #ocaml
ofaurax has quit ["Leaving"]
Amorphous has quit [Read error: 110 (Connection timed out)]
alexyk has quit []
alexyk has joined #ocaml
Amorphous has joined #ocaml
Stefan_vK has quit [Read error: 110 (Connection timed out)]
alexyk has quit []
ary1 has joined #ocaml
gildor has quit [Read error: 104 (Connection reset by peer)]
gildor has joined #ocaml
alexyk has joined #ocaml
alexyk has quit [Client Quit]
ary1 has left #ocaml []
Waleee has joined #ocaml
sporkmonger has quit []
sporkmonger has joined #ocaml
<tsuyoshi>
so what's the difference between omake and ocamlbuild?
sporkmonger has quit []
Waleee has quit []
rogo has quit [Read error: 113 (No route to host)]
palomer has joined #ocaml
<palomer>
hey guys
<palomer>
I want to use the FFI to interface ocaml with a really, really small subset of QT
<palomer>
but I need to pass lambdas to the functions
<flux>
tsuyoshi, doesn't omake use a Makefile of sorts, while ocamlbuild is a program you extend with your own code?
<palomer>
stuff like (unit -> unit)
<palomer>
is this possible?
<flux>
yes
<palomer>
oh, woops, section 18.7, right?
<flux>
I'd imagine so, yes
<palomer>
caml_callback(f, a) <--how do you apply f to () ?
<flux>
() is a value as the others
<palomer>
ahh, Val_int(0)
<flux>
use Val_unit, iirc
<palomer>
weee
<palomer>
do you guys think this is dangerous?
<palomer>
ie, qt won't work nicely with the ocaml garbage collector?
<flux>
I don't know how QT works, but likely it is manageable
<palomer>
sweet
<flux>
if you do that, you will likely need to use caml_register_global_root or something like that
<palomer>
can't believe I didn't think of this before!
<palomer>
oh, but my global variables never die
<palomer>
so it shouldn't be a problem
<flux>
the addresses outside ocaml's heap that point inside it need to be registered
<palomer>
gotcha
<palomer>
wee, this is so exciting
<flux>
:)
<flux>
no commits to qt-caml for a while..
<palomer>
so if I use a KDSearchableListBox to display different actions a user can perform
<palomer>
ill need to store those different actions
<palomer>
as closures
<palomer>
so I need to tell the garbage collector that Im
<palomer>
I'm pointing to those closures, right?
<flux>
yes
<palomer>
the tricky part will be displaying a string, I guess
<palomer>
do I convert it to a C++ string?
<flux>
a closure?
<palomer>
no, a string
<flux>
it depends what kind of string you mean
<palomer>
say I want to tell qt "display a label with text 'boom'"
<flux>
QT likely has its own string class
<palomer>
but im calling it from ocaml
<palomer>
so I need to copy the string?
<flux>
maybe
<flux>
ocaml strings are char*-compatible
<flux>
but if QT uses something else than char*, you may need to call something
<palomer>
if qt does use char*, then I would need to tell ocaml that im pointing to the string, right?
<flux>
most likely what is going to happen is that you call your own c(++) code that then again calls QT
<palomer>
right
<flux>
in ocaml-yourcode you use standard ocaml conventions for passing parameters of the proper type, and when calling QT you use QT conventions
<palomer>
I guess that string can get freed without changing anything
<palomer>
oh my oh my
<palomer>
well, im gonna code like a madman tomorrow
<palomer>
wee
<palomer>
cya
palomer has quit ["Leaving"]
tonyIII has joined #ocaml
Stefan_vK has joined #ocaml
ygrek has joined #ocaml
<flux>
hmph, pgocaml isn't very convenient when used on toplevel, if you make mistakes
<flux>
the connection gets stuck, and ctrl-c kills the toplevel
<flux>
anyone having the same experience? (pgsql 8.1 here)
ttamttam has joined #ocaml
<flux>
actually that might be a general limitation of using syntax extensions in the top level?
<flux>
I remember someone mentioning a similar issue with some other syntax extension..
Camarade_Tux has joined #ocaml
mamie_cracra has joined #ocaml
middayc_ has joined #ocaml
ched has joined #ocaml
pango has quit [Remote closed the connection]
pango has joined #ocaml
<yziquel_>
flux: pgocaml is synchronous, so you cannot avoid that easily. maybe using a dedicated thread might solve the problem, taking care of timeouts within the syntax extension?
slash_ has joined #ocaml
slash__ has joined #ocaml
slash_ has quit [Read error: 110 (Connection timed out)]
slash__ is now known as slash_
Yoric[DT] has joined #ocaml
bzzbzz has quit [Read error: 60 (Operation timed out)]
Cheshire has joined #ocaml
Cheshire has quit [Read error: 113 (No route to host)]
Cheshire has joined #ocaml
sporkmonger has joined #ocaml
jlouis has quit ["Lost terminal"]
sporkmonger has quit []
bzzbzz has joined #ocaml
<thelema>
Yoric[DT]: when you push your changes, if you find new patches in the repo, you pull, merge, and then push again, no? Instead, I'm asking you to pull, rebase (same syntax as merge) and push.
<Yoric[DT]>
Where does this start?
<Yoric[DT]>
I mean, I'm ready to push, I have committed my changes.
<Yoric[DT]>
Now, I should pull, rebase, push, is that it?
<thelema>
yes, and then you try to push, but find that the head has moved since you made your changes.
<thelema>
i.e. someone else has pushed to the repo.
<Yoric[DT]>
ok
<Yoric[DT]>
I'll try and stick to this.
<thelema>
when you start making changes, those changes are based off some revision.
<thelema>
pull the new changes, and instead of merging with them, rebase
<thelema>
the difference is that the second one rewrites your changes so that they look like they were based off the current master, not whatever older version you had really started with.
<Yoric[DT]>
Ok.
<Yoric[DT]>
Don't hesitate to bug me if I forget to do it:)
<thelema>
once I see you've not done it, it's kinda too late, but I'll poke you to remind to try it the next time.
<Yoric[DT]>
ok :)
Lockless has joined #ocaml
<mfp>
it is only recently that I have realized the extent of the linking problem with Batteries
<mfp>
let () = args () |> map Shell.files_of |> Enum.flatten |> iter print_endline
<mfp>
=> 4327217 byte executable
<mfp>
(vs. 200371 with "old style" code)
<Camarade_Tux>
mfp, does stripping help ?
<mfp>
barely
<mfp>
3277584 vs. 146288
<mfp>
and the bad news is that this can only get worse as more libs are integrated in Batteries
<thelema>
all modules have to be linked in because any of them could have side effects that are needed for expected program execution
<mfp>
the Batteries module pulls them all in
<flux>
that's the theory, but iirc cma's don't work that way?
<mfp>
they don't
<flux>
but cmo's do, which the stuff is packed into?
_zack has joined #ocaml
<mfp>
the problem is that batteries uses a package
* thelema
just read about a group working to build the whole software stack (os -> gui) in 20KLOC
<mfp>
and everything is under the Batteries module (for namespace reasons)
<flux>
so indeed with .cma's there can be unexpected missing side effects. but that's just something you need to deal with..
<flux>
the thing is ocaml doesn't really have a namespace mechanism, but rather a module system :)
<thelema>
flux: what would you want out of a namespace mechanism that modules don't provide?
<Yoric[DT]>
We're working on an alternate solution.
<mfp>
since Batteries-provided modules under Batteries (which are loaded unconditionally) are always linked against, all the 3rd party lib modules Batteries depends on are also loaded
<Yoric[DT]>
(using dynamic linking)
<thelema>
Yoric[DT]: the dynlink thing?
<flux>
thelema, openess
<Yoric[DT]>
Yep.
<mfp>
Yoric[DT]: I've found dynamic linking to be quite dangerous
<flux>
similarly to, say, polymorphic variants
<Yoric[DT]>
And Xavier mentioned that he was considering a way of getting the OCaml compiler to do "the right thing".
<thelema>
with [include] and aliasing, we've worked around openness pretty well in ocaml's module system
<Yoric[DT]>
(i.e. only linking the interesting part, *even in presence of pack*)
<Yoric[DT]>
mfp: how so?
<flux>
yoric[dt], that would solve the problem without any effort from the batteries, right?
<Yoric[DT]>
flux: yes.
<mfp>
Yoric[DT]: e.g. a name collision easily leads to a segfault
<Yoric[DT]>
mfp: gasp
<Yoric[DT]>
flux: Assuming that gets done any time soon :)
<mfp>
such clashes would be detected at link time when linking against the .cmxa, but Dynlink doesn't complain
<flux>
yoric[dt], in any case, I think if you are writing a tool that can automatically convert modules into something to easily dynload, that kind of tool could be useful in other circumtances also
<flux>
for example you could distribute a binary that can optionally depend on certain system libraries
<flux>
for example a set of audio libraries
* thelema
has to go, despite the interesting conversation
<Yoric[DT]>
Don't expect too much from the tool.
<flux>
oh :)
<Yoric[DT]>
The OCaml dynlink system, as far as I understand it, is quite limited.
<flux>
how would the tool work?
<Yoric[DT]>
Make all executables plug-ins for a Batteries loader.
<mfp>
Yoric[DT]: and then modules linked twice leading to weird errors (such as the runtime trying to mmap > 190GB of mem)
<Yoric[DT]>
That loader is linked statically to Batteries and can load & run the "executables".
<Yoric[DT]>
mfp: :/
<Yoric[DT]>
Well, I guess we can hope that Xavier gets around to improving the OCaml linking model.
<mfp>
Yoric[DT], I have to read again the proposal you sent to the ML about separating modules and namespacing
<mfp>
atm. I'm feeling it'd be much safer than anything involving dynlink
<Yoric[DT]>
That's quite possible.
<Yoric[DT]>
The dynlink hack has the advantage of being relatively simple.
<flux>
which ml would that "the ml" be?
<Yoric[DT]>
ocaml-list
<mfp>
the other pb with dynlink is that it only works in a few platforms, and only with >= 3.11 --- the ones I use are supported so it's OK for me, }:-), but the segfaults are just scary
<Yoric[DT]>
Indeed.
<Yoric[DT]>
Have you submitted bug reports?
<mfp>
well, it was arguably my fault, for using a module with the same name as an existent one
<mfp>
I had a Global module, which clashed with extlib's
<mfp>
(the pb is that I only discovered that when I tried to link statically)
<mfp>
ah there's another issue with dynlink
<mfp>
exceptions are generative
<mfp>
if you load the same module twice, exceptions raised by old code aren't caught in the new one, I'm told
<flux>
I'm not sure how that differs from having a per-project file "modules.ml", which you include from all your files?
<mfp>
flux: it's just a bit less work because you don't have to maintain the file manually
<mfp>
anyway, even if this is not used in general, something in the same spirit could help batteries
<mfp>
instead of using a package and placing everything in Batteries.*, rename the modules to Batteries_xxx
<mfp>
then allow to import selectively with a new directive (import?)
ikaros has joined #ocaml
<mfp>
unfortunately, there's no obvious way to import implicitly without adding the Batteries__ prefix
<mfp>
in practice, all batteries-provided modules would have to be specified :-| import List Rope Enum from Batteries (needed to refer to List instead of Batteries__List)
Lockless has quit ["Leaving"]
<mfp>
a rather heavy way to make them implicit would be to detect all refs to Batteries (sub)modules and rewrite them w/ camlp4; seems fragile, though
bohanlon has joined #ocaml
<Yoric[DT]>
Yeah, very fragile.
<mfp>
imperfect as the above scheme is, I can't see any better solution, and no good way to import (sub)modules implicitly
<mfp>
don't know if/when xleroy will fix loading of pkgs