dsheets has quit [Read error: Connection reset by peer]
dsheets has joined #ocaml
buriedhead has quit [Ping timeout: 240 seconds]
pilki has joined #ocaml
<Drakken>
hi thelema
philtor has joined #ocaml
<Drakken>
thelema just so we're on the same page, I'm waiting to get that data format from you before I start working on the plotting code. I've been a little burned out today from the coding yesterday, so there's no hurry.
Drup has quit [Quit: Leaving.]
EmmanuelOga has joined #ocaml
<thelema>
I'm planning on giing 3 values for each function at each x value
<thelema>
or maybe I should start with 1, and then work up to 3.
<thelema>
*giving
<thelema>
points 1 2 3 4 5
<thelema>
f1_low l1 l2 l3 l4 l5
<thelema>
f1 e1 e2 e3 e4 e5
<thelema>
f1_hi h1 h2 h3 h4 h5
<thelema>
first row is x coordinates (might need logarithmic scale if last / first > 10
<thelema>
err, >100
<thelema>
l1...l5 are lower bounds on time, h1..h5 are upper bounds , e1..e5 are point estimates (all floats)
<thelema>
there'll be three rows, "foo", "foo_lo", "foo_hi" for each test function "foo"
pilki has quit [Quit: Leaving]
saberman_1 has joined #ocaml
saberman_1 has quit [Remote host closed the connection]
Axioplas1_ has quit [Quit: (brb)]
Axioplase_ has joined #ocaml
saberman_1 has joined #ocaml
saberman_1 has quit [Remote host closed the connection]
<edwin>
especially if you got an OS thats not Linux ;)
ttamttam has joined #ocaml
<ocp>
my only concern with your patch is that you are adding a new predefined identifier
<ocp>
I would prefer limit those ones, and just raise Failure "BusError"
<ocp>
edwin: you should not submit a patch with the bytecode of ocamlc, it makes the patch harder to read
<edwin>
I submitted another one without the bytecode
<edwin>
ocp: should I submit another patch variant that just raises Failure?
<ocp>
no, not yet, you should wait for official replies on Mantis before doing anything new
<edwin>
ok, will keep in mind the predefined id. stuff for the future
<ocp>
well, it is not a rule, it is just a preference
<ocp>
the least you touch the compiler, the better it is for the patch to be added ;-)
<flux>
I think it's not all bad to use a new exception for this, because at least prior to this patch, the code would have just died
<edwin>
if Sys.set_signal would've worked with SIGBUS then this whole patch wouldn't be necessary, but I think SIGBUS is just a too low level error for that to work (handle SIGBUS in pure OCaml)
<edwin>
haven't investigated why it enters an infinite loop, maybe because the OCaml signal handler returns
<edwin>
before calling the one I installed
<flux>
btw, is the code thread-safe? (I didn't look)
<ocp>
yes, probably
<ocp>
(I replied to the infinite loop reason)
<edwin>
it looks just like the Stack_overflow handling code, so hmm
<edwin>
threads and signals don't mix well in general
<ocp>
do you check that you are actually running OCaml code ?
<edwin>
in asmrun yes
<edwin>
in byterun I can't, because its the interpreter that dies
<edwin>
well, only one thread can run OCaml code at a time, and since I only raise the exc. when it occurs in OCaml code it should be thread safe
fantasticsid has quit [Quit: ERC Version 5.3 (IRC client for Emacs)]
<ocp>
I think the patch is ok, and avoiding a brutal exit is always good for a high level language like OCaml
<edwin>
for byterun I could try checking that the faulting instruction is in bigarray_stubs, but there is no portable way to check that. I can get the start address of a symbol, but not its size :(
<edwin>
yeah, that was the reason I wrote the patch (preventing brutal exit)
<edwin>
OCamlNet also mmaps, I should remember to send a patch (or at least a notice) to the author how to make it handle SIGBUS
<edwin>
does Gerd Stolpmann hang out in this channel?
<adrien>
if he does, I've never seen him
<ocp>
your patch could also be done only in bigarray
<ocp>
i.e. the sig handler would be put in place only when somebody maps a file with bigarray
<edwin>
but exception needs to be raised differently for byte and native code, is there a way to know which one I am called for?
<ocp>
I think you can use the same code for raising an exception in bytecode and native code
Kakadu has joined #ocaml
<edwin>
if I raise Failure then yeah
<ocp>
you can also register the exception during the initialisatoin of Bigarray (exception BusError) from Ocaml to C
<ocp>
and then raise the exception from the handler
<edwin>
or that, yeah
<edwin>
I'll see what the INRIA team prefers
<ocp>
that way, no predef, almost no code in the runtime
<ocp>
except the In_Mapped_Area
<edwin>
thats a tiny change ;)
<edwin>
do you want to add your suggestion to mantis?
<edwin>
or you're part of the inria team?
<Kakadu>
Qrntzz: hi!
<Kakadu>
Qrntzz: do u have any ideas what build system to use for qml+ocaml projects?
probst has joined #ocaml
<ocp>
edwin: I am on caml-devel, so I can discuss directly with the coreteam
NaCl has joined #ocaml
NaCl has quit [Changing host]
NaCl has joined #ocaml
<edwin>
ah ok
<ocp>
I am going to send a mail there to get their opinions
<ocp>
on the patch, with or without such changes
<edwin>
thanks, no hurry though
pilki has quit [Quit: This computer has gone to sleep]
sgnb` has joined #ocaml
ztfw` has joined #ocaml
lamawithonel_ has joined #ocaml
kmc has quit [Ping timeout: 240 seconds]
lopex has quit [Excess Flood]
joewilliams has quit [Ping timeout: 240 seconds]
Kakadu has quit [Read error: Connection reset by peer]
mal`` has quit [Ping timeout: 240 seconds]
ztfw has quit [Ping timeout: 240 seconds]
kmc has joined #ocaml
joewilliams has joined #ocaml
Kakadu has joined #ocaml
sgnb has quit [Ping timeout: 240 seconds]
foocraft has quit [Ping timeout: 240 seconds]
foocraft has joined #ocaml
lamawithonel has quit [Ping timeout: 240 seconds]
<Qrntzz>
Kakadu: hello
<Qrntzz>
Kakadu: not much, but noting we will need to compile both ocaml and cpp... omake? don't know if there's something more appropriate
<Kakadu>
Qrntzz: omake is dead.
<Qrntzz>
really? I'm slow a bit then
<Kakadu>
Qrntzz: cmake maybe?
<Qrntzz>
cmake? would it be suitable for ocaml sources?
<Qrntzz>
I wouldn't mind cmake, though
mal`` has joined #ocaml
<Kakadu>
Qrntzz: btw, can we develop non- .pro project in qtcreator?
<Qrntzz>
afaik, just .pro and .pri
<Kakadu>
afair I was imported Makefile-based projects to qtcreator but now I cant find how to do it
<Qrntzz>
Kakadu: just for the record, you don't need semicolons to terminate lines in qml
avsm has quit [Quit: Leaving.]
raichoo has quit [Quit: leaving]
ocp has quit [Ping timeout: 252 seconds]
<Kakadu>
Qrntzz: fixed.
<Kakadu>
build is fixed
<Qrntzz>
oh, ok
ztfw` is now known as ztfw
ztfw has quit [Read error: Connection reset by peer]
ztfw has joined #ocaml
ztfw has quit [Ping timeout: 240 seconds]
<Qrntzz>
Kakadu: doesn't notice changes to files, though. rebuilding manually using commands from the makefile
<Kakadu>
Qrntzz: чего?
<Qrntzz>
Kakadu: make не замечает моих изменений в файлах, поэтому отказывается перекомпилировать, ссылаясь на то что типа "all не требует выполнения команд", компилирую вручную командами из мейкфайла.
<Kakadu>
Qrntzz: On my PC its OK
<Kakadu>
короче у меня всё работает. Потом разберемся
<Qrntzz>
гг, ладно.
wagle has quit [Read error: Connection reset by peer]
<Kakadu>
Qrntzz: Now I have new problem with linking. You can pull to see it
<Kakadu>
I've added forgotten files just now
<Qrntzz>
Kakadu: missing kamlo.h, git pull says I'm up to date
wagle has joined #ocaml
<Kakadu>
Qrntzz: Try again plz
wagle has quit [Read error: Connection reset by peer]
cago has left #ocaml []
ocp has joined #ocaml
<Qrntzz>
Kakadu: make's being weird, only compiled the moc target until I recompiled main manually and re-ran make
<Qrntzz>
anyway, I see the problem now
wagle has joined #ocaml
<Kakadu>
Qrntzz: It seem you have very strange make. Or me :)
wagle has quit [Read error: Connection reset by peer]
<Kakadu>
> The shared libraries produced by ocamlc -output-obj or by ocamlopt -output-obj already contains the OCaml runtime library as well as all the needed C libraries.
<Kakadu>
hmmmm
<Qrntzz>
Kakadu: yes, I get that too
wagle has joined #ocaml
ulfdoz_ has joined #ocaml
<Qrntzz>
Kakadu: the errors come from the C++ name mangling
<Qrntzz>
Kakadu: enclose in `extern "C"'?
thomasga has quit [Quit: Leaving.]
<Kakadu>
Qrntzz: good idea
<Kakadu>
can u try to fix it?
<Qrntzz>
sure
ulfdoz has quit [Ping timeout: 255 seconds]
ulfdoz_ is now known as ulfdoz
ttamttam has quit [Quit: ttamttam]
<Qrntzz>
Kakadu: commited/pushed
Kakadu has left #ocaml []
Kakadu has joined #ocaml
<Kakadu>
wtf, segfault
<Qrntzz>
hmm
<Qrntzz>
yes, seems so
<Qrntzz>
at least that fixed the reference error
<Kakadu>
yep
<Kakadu>
Oh!
<Qrntzz>
?
<Kakadu>
I know the problem
ankit9 has joined #ocaml
<Kakadu>
Qrntzz: now I have the same problem with makefile. TT
<Kakadu>
sorry, I don't know how to fix it.
<Kakadu>
but I have localized the problem
<Kakadu>
Qrntzz: commited/pushed
oriba has joined #ocaml
<Qrntzz>
Kakadu: ok
<Qrntzz>
Kakadu: nnngh, it still doesn't execute target `main'
<Qrntzz>
anyway, `ASSERT: "closure_f!=NULL" in file gamemap.cpp, line 15'
<Kakadu>
yes
<Kakadu>
by some reason callback was not registered
<Qrntzz>
Kakadu: you didn't call caml_main() (and you should've been)
<Qrntzz>
as it triggers callback setting and other initialization code in the ocaml runtime
<Qrntzz>
putting it into main(), where it should be, doesn't work though, so I'm forced to put it into GameMap::sizex() with an empty argv as a hack
<Qrntzz>
but the assertion is now true and the app launches
avsm has joined #ocaml
<Kakadu>
Qrntzz: thanks, fixed.
thomasga has joined #ocaml
thomasga has quit [Client Quit]
<Kakadu>
Minimal app works
<Kakadu>
Qrntzz: what the next step?
<Qrntzz>
oops, forgot to commit
<Qrntzz>
I think you fixed it already anyways
<Qrntzz>
hm, so callbacks now work, can't we already write some kind of a generator for that
<Kakadu>
Yes, I think so
<Kakadu>
Qrntzz: mybe we can reuse code from lablqt/moc
raichoo has joined #ocaml
<Qrntzz>
Kakadu: mhm
<Qrntzz>
caml_main() called from main() didn't work for me, btw and now it does
<Kakadu>
Qrntzz: maybe it is makefile problem?
<Qrntzz>
I guess, since you modified it everything compiles fine
<Qrntzz>
anyway
<Qrntzz>
could you explain in 2 words how exactly were automatic bindings generated? not sure I understood all of this
<Kakadu>
It reads input file
<Kakadu>
stop
<Kakadu>
how code in moc works?
<Kakadu>
or at all how code for QtGui is generated in /xml?
noj has quit [Remote host closed the connection]
probst has quit [Quit: probst]
<Qrntzz>
well, pretty much all I know about moc is that it generates c++ boilerplate source from header files according to qt macros, etc
<Qrntzz>
need to examine xmltool a bit
<Qrntzz>
I haven't touched that part of code, tbh
probst has joined #ocaml
<Kakadu>
my moc reads ./input file and generates ocaml code and C++ class for calling this OCaml code. It was used for adding user-defined signals and slots to lablqt examples.
raichoo has quit [Ping timeout: 260 seconds]
<Qrntzz>
ah
<Qrntzz>
btw, is it the only part of lablqt code that uses jscore?
<Kakadu>
xml/ does
<Kakadu>
Qrntzz: IIrc you have fixed warning about `Expression "(function $text() { return gameMap.title })" depends on non-NOTIFYable properties`. Can you push it?
<Qrntzz>
sure
<Qrntzz>
Kakadu: done
<Qrntzz>
your generator code is quite large
<Qrntzz>
from what I can tell, the actual class definitions it outputs into a c++ file are hardcoded in
<Kakadu>
yep, classname is hardcoded
<Qrntzz>
(and will need to be changed for qml)
<Kakadu>
the idea was to create an object for all user signals and methods which will be used in Ocaml program.
<Qrntzz>
yes, I understood that
<Qrntzz>
the files that need to be changed the most are the cppGenerator and ocamlGenerator ones, correct?
<Qrntzz>
I hope that generating bindings for qml will be less complex than doing it for qt, because the code is quite cryptic to me now (must be unknown sexplib/js-core syntax though)
pangoafk is now known as pango
<Kakadu>
mmmm
<Kakadu>
Qrntzz: files in moc directory doesn't use files in xml directory
<Qrntzz>
Kakadu: I removed that line because I added `extern "C"' in kamlo.h so it's proper in any file it's #included in
<Qrntzz>
Kakadu: but forgot to commit, silly me
<Drakken>
Why does ocamlbuild have a .ml tags entry?
<Qrntzz>
Kakadu: fixed now
<Drakken>
the built-in _tags file
<Drakken>
<**/*.ml> or <**/*.mli> or <**/*.mlpack> or <**/*.ml.depends>: ocaml
<Drakken>
How do you build a source file?
<Drakken>
(with ocamlbuild)
vivanov has quit [Quit: Lost terminal]
Anarchos has joined #ocaml
<Drakken>
$ cat _tags
<Drakken>
<*.ml> or "prog.byte": package(num), package(str)
<Drakken>
Why do the library tags apply to both the source and the executable?
<Drakken>
The relationships can't possibly be the same.
<hcarty>
Drakken: Tags can have different meanings when compiling vs linking
<adrien>
source cause you refer to the functions and you need their prototypes
<adrien>
executable, for linking
<adrien>
s/cause/because/
<Kakadu>
Qrntzz: I've fixed problem with Makefile
<Qrntzz>
Kakadu: nice, thanks
<Kakadu>
so what about moc-like generator?
<Kakadu>
Qrntzz: we can discuss it tomorrow if u want
<Drakken>
sloppy semantics. very perlish.
<hcarty>
Drakken: Sloppy how?
<hcarty>
Drakken: You're welcome to use hand-written Makefiles as well, or oasis to hide the details of ocamlbuild.
<Qrntzz>
Kakadu: I need to examine the code first anyway and try it out myself, so I won't mind talking about that tomorrow
<Drakken>
hcarty when do tags apply to a target? when it's beign built, or when it's being used to build something else?
<Drakken>
obviously the same rule can't apply to both .ml and .byte
<hcarty>
Drakken: A tag applies to whatever is specified in the _tags file
<hcarty>
Drakken: No, of course not. There are rules for linking vs compilation as both adrien and I said.
<hcarty>
You could, if you wanted, define tags which only have affect one or the other
<hcarty>
have AN effect
<hcarty>
or s/ have// ...
<Kakadu>
Qrntzz: k
<Qrntzz>
aargh
<Qrntzz>
Kakadu: just a second after I sent that line to you, my building gets powercycled
<Kakadu>
powercycled?
<hcarty>
Drakken: If you look at most myocamlbuild.ml files there are sections which tie a tag to a specific set of conditions
<Qrntzz>
Kakadu: мне свет вырубило буквально через полсекунды
<hcarty>
Drakken: For example, OCaml byte-code compilation and OCaml native-code compilation may each do different things with the same tag
<Kakadu>
Qrntzz: бедный компьютер...
<Qrntzz>
yep.
<Drakken>
hcarty what does "apply" mean? for .byte it means "use tags when building target", but ocamlbuild doesn't build source files.
<Drakken>
hcarty but in each case the tags apply when *building* the target, not when *using* it.
<Drakken>
You can't say that about a source file.
<tomprince>
Drakken: I think the idea may be that tags describe what, not how.
<hcarty>
Drakken: What do you mean by using the target?
<Drakken>
hcarty I mean when the target is already built and the compiler uses it to build something else.
<Drakken>
for instance using a source file to build object code.
<hcarty>
Drakken: I do not think that a tag on a.ml will carry over to b.ml automatically (assuming b.ml uses a.ml)
<tomprince>
hcarty: I think Drakken is asking about how tags work in the case you a.ml is a generated file.
<hcarty>
tomprince, Drakken: If that's the case, then tags don't work any differently for generated code than they do for hand-written code.
<hcarty>
If you're talking about a custom tool that is built, then that tool is used to process something else - that most likely requires custom rules.
<tomprince>
hcarty: I think the Drakken wants to have some tags on the .ml be about generating the file, and some about building the generated file, and how they interact.
<hcarty>
_tags only apply to the file being processed
<Drakken>
tomprince I assume the .ml entries are about *using* the files to compile object files. I don't really care (right now) about generating source code.
<Drakken>
My point is that the semantics of a .ml _tags entry is different from that of other entries.
<hcarty>
Drakken: <*.ml>: package(foo) -- This tell ocamlbuild that any compilation of a .ml file requires the findlib package foo
<hcarty>
Drakken: How so?
<Drakken>
hcarty you're still confusing the target with the source. When you say "compilation of a .ml file", you don't mean the compiler is *producing* source file, you mean it's *using* the source file to *produce* an object file.
<hcarty>
Drakken: That distinction comes down to ocamlbuild's rules
<Drakken>
hcarty which are what I commented on: the rules are perlish.
<hcarty>
Drakken: Which means nothing...
<hcarty>
The rules are riddled with sigils
<Drakken>
the rules are surprisingly compicated. Now I wonder when when they apply to .cm* files: during complilation or linking?
<Drakken>
complicated.
<hcarty>
Drakken: Both
<hcarty>
The details of the rules can be complicated, but using them is not.
<hcarty>
If you would like to see the details, ocamlbuild's source is likely to be the best resource.
<Drakken>
hcarty is that really necessary? Doesn't some of the library code get build into the object once it's compiled?
<hcarty>
Depends on the compilation process. A .cmo or .cmx often still relies on other modules.
_andre has quit [Quit: leaving]
ttamttam has joined #ocaml
<thelema>
Drakken: actually, ocamlbuild can build source files - for example .mll -> .ml
dsheets has quit [Ping timeout: 248 seconds]
sepp2k has joined #ocaml
dsheets has joined #ocaml
<Drakken>
thelema I'm sure that's true, but I doubt that process has the same dependencies as compilation. So where would you put any tags related to building source code? In *.mll or *.ml?
<Drakken>
And if you put them in *.ml, does ocamlbuild try to use them during compilation?
<Drakken>
Does it try to library packages associated with <*.ml> in the .mll->.ml process?
dsheets has quit [Ping timeout: 244 seconds]
<hcarty>
Drakken: No - that's what was said earlier. Entries in _tags only apply to files indicated by that entry.
<hcarty>
<*.mll> tags will apply to .mll->.ml
<hcarty>
Or rather, <*.mll> tags will apply to .mll->*
ocp has quit [Read error: Operation timed out]
<hcarty>
<*.ml> tags will apply to .ml->*
<Drakken>
hcarty and <*.byte> tags apply to .byte->* ?
<hcarty>
Drakken: That is a fair point. In that case I think it applies to *->.byte
<Drakken>
hcarty of course it does. .ml is usually the starting point, and .byte or .native is usually the end result. But that means there's some kind of perlish semantic magic going on behind the scenes, and I didn't see anything about it in the user's manual.
<thelema>
when compiling to .byte, the tag 'byte' is added
<thelema>
similarly for 'native'
<tomprince>
dwim-mery
<hcarty>
I still don't understand what you mean by perlish.
<thelema>
hcarty: perl-like
<hcarty>
thelema: I get that. But not how.
dsheets has joined #ocaml
ankit9 has quit [Ping timeout: 240 seconds]
<hcarty>
It's not more DWIMery than any other abstraction.
<Drakken>
hcarty perl is notorious for two things: overcomplicated syntax and overcomplicated semantics.
<Drakken>
I'm referring to the semantics.
<tomprince>
That tags <*.ml> apply to building from ml but <*.byte> apply to building to byte.
<Drakken>
exactly.
<tomprince>
When both could potentially be both a source and a target of a build.
Kakadu has quit [Quit: Konversation terminated!]
<ttamttam>
I agree: I often have to have a look at the logs to adjust the left part of tags files
<Drakken>
Well, I'm not sure how executables are used as sources, but that's basically my point.
ttamttam has left #ocaml []
dsheets has quit [Ping timeout: 240 seconds]
<thelema>
I'm no expert at the tag system, I usually apply tags to all files in my project, and use rules to ignore tags that don't apply.
<thelema>
that said, I usually have pretty homogenous projects - not much special handling of certain files
<thelema>
when a file needa special handling, it gets a tag as <foo.*>:bar and then rules get added for `bar compile byte`, `bar compile native`, `bar link`
<thelema>
*needs
ankit9 has joined #ocaml
dsheets has joined #ocaml
iago has joined #ocaml
noj has joined #ocaml
Submarine has quit [Remote host closed the connection]
dsheets has quit [Ping timeout: 240 seconds]
dsheets has joined #ocaml
ocp has joined #ocaml
everyonemines has joined #ocaml
Anarchos has quit [Quit: Vision[0.9.7-H-090423]: i've been blurred!]
Snark has quit [Quit: Quitte]
ikaros has quit [Quit: Ex-Chat]
sepp2k has quit [Remote host closed the connection]
mcclurmc has quit [Excess Flood]
mcclurmc has joined #ocaml
ulfdoz has quit [Ping timeout: 240 seconds]
ocp has quit [Quit: Leaving.]
ocp1 has joined #ocaml
redfire has quit [Quit: Changing server]
edwin has quit [Remote host closed the connection]
everyonemines has quit [Quit: Leaving.]
ocp1 has quit [Read error: Operation timed out]
Cyanure has quit [Read error: Operation timed out]