jlouis has quit [Read error: 110 (Connection timed out)]
sergez has joined #ocaml
thermoplyae has quit ["daddy's in space"]
brooksbp has joined #ocaml
sergez has quit [Read error: 60 (Operation timed out)]
sergez has joined #ocaml
brooksbp has quit []
rwmjones has joined #ocaml
sergez has quit [No route to host]
zmdkrbou has quit [Read error: 110 (Connection timed out)]
seafood_ has quit [Read error: 110 (Connection timed out)]
middayc has joined #ocaml
middayc has quit [Read error: 110 (Connection timed out)]
seafood_ has joined #ocaml
seafood_ has quit [Client Quit]
seafood_ has joined #ocaml
seafood_ has quit []
seafood_ has joined #ocaml
mwc has joined #ocaml
seafood_ has quit []
netx has quit ["Leaving"]
kmeyer has quit [Remote closed the connection]
kmeyer has joined #ocaml
buluca has quit [Read error: 113 (No route to host)]
blackdog has quit [Read error: 113 (No route to host)]
blackdog has joined #ocaml
blackdog has quit [Remote closed the connection]
wy has joined #ocaml
<wy>
hello!
<wy>
Is there a way to get some information from the toplevel?
<wy>
for example what methods are in a class etc...
blackdog has joined #ocaml
seafood_ has joined #ocaml
<Nutssh>
I don't think so.
<Nutssh>
But you can get some info if you compile a *.ml with the right options; it'll print out an interface spec.
<wy>
Thanks. I'm also wondering why class constructors are not functions, but when I apply it as in "let a = new point 1", I got a function, int->point. I can then apply a to another integer to get an object
<Nutssh>
I'm not sure.
maayhem has joined #ocaml
<maayhem>
hello
<maayhem>
question: whats the type of match x with [...] -> y ? (if x: t1 and y: t2, is it of type t1 -> t2 or of type t2 only ?)
<wy>
I think it's t2, because it's not a function
<wy>
I can't figure out why the keyword "new" should be necessary and the constructors are not functions.
maayhem has quit [Remote closed the connection]
<Nutssh>
Just accept that its the way it is for a good reason?
<flux>
maybe it was considered confusing to pollute value name space with a non-let?
jderque has joined #ocaml
wy has quit [Read error: 110 (Connection timed out)]
asmanur has joined #ocaml
buluca has joined #ocaml
netx has joined #ocaml
Snark has joined #ocaml
Associat0r has quit []
ygrek has joined #ocaml
ttamttam has joined #ocaml
musically_ut has joined #ocaml
zmdkrbou has joined #ocaml
jderque has quit [Read error: 113 (No route to host)]
ttamttam has quit [Remote closed the connection]
ttamttam has joined #ocaml
ttamttam has left #ocaml []
ttamttam has joined #ocaml
leo037 has joined #ocaml
Snark has quit ["Ex-Chat"]
marmottine has joined #ocaml
leo037 has quit [Read error: 110 (Connection timed out)]
jderque has joined #ocaml
leo037 has joined #ocaml
love-pingoo has joined #ocaml
bluestorm has joined #ocaml
Yoric[DT] has joined #ocaml
<Yoric[DT]>
hi
seafood_ has quit []
ygrek has quit [Remote closed the connection]
olleolleolle has joined #ocaml
ita has joined #ocaml
ygrek has joined #ocaml
olleolleolle has quit []
pango_ has quit [Remote closed the connection]
pango_ has joined #ocaml
zmdkrbou has quit [Read error: 110 (Connection timed out)]
seafood_ has joined #ocaml
seafood_ has quit []
cyrilRomain has joined #ocaml
asmanur has quit [Read error: 110 (Connection timed out)]
musically_ut has quit [Remote closed the connection]
musically_ut has joined #ocaml
pango__ has joined #ocaml
pango__ is now known as pango
pango_ has quit [Remote closed the connection]
buluca has quit [Read error: 113 (No route to host)]
filp has joined #ocaml
asmanur has joined #ocaml
wy has joined #ocaml
Snrrrub has joined #ocaml
Smerdyakov has quit [Remote closed the connection]
<Snrrrub>
Hi all, I'm having some serious trouble with the Graphics module's keyboard/mouse functions. Sample code (it's short!): http://pastebin.com/d37dc2262 - for some reason, keyboard events get buffered until a mouse event. So I could type "hello world" and there would be no console output until I press a mouse button on the window.
Smerdyakov has joined #ocaml
<Snrrrub>
As soon as I click within the window, all the keystrokes are handled
mwc has quit [Read error: 104 (Connection reset by peer)]
jderque has quit [Read error: 113 (No route to host)]
<pango>
Snrrrub: works for me. Btw, using printf you can force a flush with the %! pattern
smimram has quit ["bli"]
<Snrrrub>
pango, what version of OCaml are you using? I'm using 3.09.2-9 on etch stable
<pango>
and Printf.printf "Mouse at %d,%d\n" (fst (Graphics.mouse_pos ())) (snd (Graphics.mouse_pos ())) is slightly incorrect; Since Graphics.mouse_pos is an unpure function, it can print coordinates the mouse never went to
<pango>
$ ocamlc -version
<pango>
3.10.0
<pango>
(Using Lenny here)
<Snrrrub>
pango, thanks for the hint on the printf flush pattern. That'll save on a fair bit of typing! About the mouse position printing - this is just to see if others face the same issue on keyboard input but I'll keep that in mind. It's an important point!
<pango>
let x, y = Graphics.mouse_pos () in Printf.printf "Mouse at %d,%d\n%!" x y; would be better
<pango>
(strangely now the window will immediately close and the program terminate with exitcode = 0... ?!?)
ygrek has quit [Remote closed the connection]
ygrek has joined #ocaml
<Snrrrub>
Hmmm, perhaps upgrading to 3.10 will fix my issue.
<pango>
aha, stupid me, it works again
<pango>
seems to work fine with 3.09-2 too, on another box thru my lan
jderque has joined #ocaml
<Snrrrub>
Uh oh. That's not cool.
Morphous has joined #ocaml
<Snrrrub>
Maybe it's my X server...
<pango>
what happens exactly? you press keys, click on the window, and only then all the keys you pressed are reported to stdout?
<Snrrrub>
yup
<pango>
or only the keys pressed after you clicked?
<Snrrrub>
No, all keys pressed get buffered until the next mouse click.
<Snrrrub>
so "hello world" *click* "abcd" *click* will result in the sequence: mouse, hello world, mouse, abcd
Morphous_ has joined #ocaml
<pango>
now that's getting interesting, it seems I'm observing this problem when compiling to native code only
<Snrrrub>
Ooh, interesting indeed!
<Snrrrub>
Yes, I can confirm that it works via the bytecode interpreter.
Amorphous has quit [Nick collision from services.]
Morphous_ has quit ["shutdown"]
Amorphous has joined #ocaml
Morphous has quit [Read error: 110 (Connection timed out)]
<flux>
just looking at thr last rows from a mobile terminal, but you're sure it's not a buffering problem?
<flux>
I guess the ijplementation is allowed to flush whenever it wants (thus leading to different behavior with different compilers?), so it would sort of be consistent
<pango>
flux: so, in some implementations you have to use the mouse to flush keyboard events? That doesn't look like an acceptable behavior
<pango>
the style of that event loop is not the best (busy loop checking for each event type... mmmh), but still
<flux>
pango, oh, I was thinking olny the reporting of the problems was the problem.. but really, I didn't look up the context :)
<flux>
(for example if the recognition of events is witnessed by unflushed output to stdout..)
<asmanur>
hum, i'm trying to do "circular programming" in OCaml, which uses lazy evaluation,
<pango>
each display is followed by a flush stdout... Also, if it was only an output buffering problem, shouldn't the mouse event be reported after the keyboard events?
<asmanur>
but i can't figure out how to create a function in ocaml such as the trace function defined in haskell as :
<asmanur>
trace f input = let (output, feedback) = f (input, feedback)
<asmanur>
in output
<asmanur>
is it possible ?
<Snrrrub>
Just out of curiosity: would graphics.cma and graphics.cmxa be generated from the same source calling into the same native code?
<bluestorm>
Snrrrub: what do you mean ?
<bluestorm>
"calling into the same native code" ?
<bluestorm>
of course they both comes from graphics.ml
<Snrrrub>
Okay, so there isn't anything special about the OCaml standard library. That answers my question.
<bluestorm>
iirc, when declaring external functions (ie. from C code), you can specify different functions for bytecode or native compilation
<bluestorm>
but graphics.ml doesn't use that
<Snrrrub>
Okay. Well I'm too new to OCaml to see what would cause this difference in behaviour.
<pango>
weird stuff indeed. Didn't find anything relevant in the bug tracker either
<flux>
ltracing both programs might be helpful
Ben` has joined #ocaml
<pango>
mmmh if I press keys in the native compiled version while it's being ltraced, it's killed by a SIGILL
<pango>
and bytecode version gets killed with a SIGSEGV
<Snrrrub>
I'm attempting an ltrace but ltracing ocamlrun startup is ... intense.
<Snrrrub>
a lot of strcmps
<pango>
it seems Graphics is heavily signal driven, and all sorts of weird things happen with ltrace
<flux>
strace can be useful too, but less so..
<Snrrrub>
Native: looks like the SIGIO on keyboard input isn't handled because the signal is interrupting an outstanding XQueryPointer which gets resumed immediately after the SIGIO is delivered
leo037 has quit ["Leaving"]
love-pingoo has quit ["Connection reset by pear"]
<pango>
if the same code is being used in bytecode and native programs, I guess it must be some kind of race...
Smerdyakov has quit [Remote closed the connection]
Smerdyakov has joined #ocaml
<bluestorm>
hey
<bluestorm>
did you know that Wikimedia (hence Wikipedia) uses OCaml mode when rendering tex ?
<pango>
yep
<mbishop>
hmm?
buluca has joined #ocaml
Associat0r has joined #ocaml
middayc has joined #ocaml
ita has quit [Read error: 110 (Connection timed out)]
smimou has joined #ocaml
<Snrrrub>
Hmmm, I think I've found some hints to the issue between native/bytecode difference. According to point #4: http://www-h.eng.cam.ac.uk/help/tpl/graphics/X/signals.html but in OCaml sources: otherlibs/graph/open.c:351 there's a call to Xlib from the signal handler.
<Snrrrub>
Interestingly, there's also a comment in open.c:336 that states: The caml_gr_sigio_handler is called via the signal machinery in the bytecode interpreter. The signal system ensures that this function will be called either between two bytecode instructions, or during a blocking primitive. In either case, not in the middle of an Xlib call.
<Snrrrub>
I can't see any equivalent code for native code that ensures that no Xlib call is in progress when a signal is received. In fact, given the tight polling loop in the test case, one would expect the control to be in caml_gr_wait_event_poll (events.c:150) and probably in the XQueryPointer call within that.