00:03
lus|wasz has joined #ocaml
00:07
vezenchio has quit [Read error: 110 (Connection timed out)]
00:08
lus|wasz is now known as vezenchio
00:10
lus|wasz has joined #ocaml
00:15
TylerE has joined #ocaml
00:15
<
TylerE >
I'm having trouble with the Graphics library under Windows (MinGW)
00:16
<
TylerE >
I typed in a simple program from the merjis.com tutorials
00:16
<
TylerE >
used ocamake to build it
00:16
<
TylerE >
$ ocamake.exe graphics1.ml -o graphics.exe
00:16
<
TylerE >
graphics1.ml
00:16
<
TylerE >
Linking...
00:17
<
TylerE >
Error while linking craphics1.cmo: Reference to undefined global 'Graphics'
00:17
<
TylerE >
Linking failed
00:17
<
TylerE >
any ideas?
00:17
<
TylerE >
the release notes make me think this
*should* work
00:18
<
Smerdyakov >
No, since you aren't including the Graphics library....
00:18
<
Smerdyakov >
Though I know nothing about 'ocamake'.
00:19
<
Smerdyakov >
You need to specify libraries explicitly with the real compiler program.
00:25
cjohnson has quit [Read error: 54 (Connection reset by peer)]
00:26
wegzze has quit [Read error: 110 (Connection timed out)]
00:26
cjohnson has joined #ocaml
00:27
vezenchio has quit [Read error: 110 (Connection timed out)]
00:28
lus|wasz has quit ["I thought what I'd do was, I'd pretend to be one of those deaf-mutes"]
00:36
TylerE has quit [Read error: 110 (Connection timed out)]
00:37
barzhaz has joined #ocaml
00:41
barzhaz has left #ocaml []
01:12
gim has quit ["pouf"]
02:11
mpc has joined #ocaml
02:16
cjohnson has quit ["Leaving"]
02:55
lmbdwr has left #ocaml []
02:58
pango has quit [Nick collision from services.]
02:58
pango_ has joined #ocaml
03:01
mrsolo has joined #ocaml
03:10
mpc has joined #ocaml
03:10
mpc has quit [Client Quit]
03:23
zigong__ has quit [Remote closed the connection]
04:23
pnou has quit ["brb"]
04:33
mlh has quit [Client Quit]
05:16
mrsolo has quit [Read error: 104 (Connection reset by peer)]
05:16
mrsolo_ has joined #ocaml
05:56
CoolPops has joined #ocaml
05:58
<
CoolPops >
Is it possible for the Str module to match lazily? i.e. I had a ''very'' hard day today ''at'' work. ... a regexp: "''\\(.*\\)''" would return everything from very ... at but I would like to match very as 1 match, and at as another.
06:06
<
mflux >
str may not be able to (I don't remember w/o referring to the documentation), but pcre is much better regular expression matcher anyway
06:06
<
mflux >
and it would support notation .*?
06:06
<
CoolPops >
mflux: is that an addon?
06:06
<
CoolPops >
mflux: ok. I'll look into it.
06:07
<
CoolPops >
mflux: thanks for the pointer.
06:11
<
mflux >
glad to be of assistance
06:34
Herrchen has joined #ocaml
07:10
pango_ has quit ["Client exiting"]
07:12
alex-i_ has joined #ocaml
07:14
alex-i has quit [Read error: 113 (No route to host)]
07:27
pango has joined #ocaml
07:37
alex-i_ has quit [Read error: 60 (Operation timed out)]
07:40
CoolPops has quit [Read error: 110 (Connection timed out)]
08:41
shawn_ has joined #ocaml
08:42
eternite has joined #ocaml
08:47
_shawn has quit [Read error: 104 (Connection reset by peer)]
08:48
mrsolo_ has quit [Read error: 104 (Connection reset by peer)]
08:48
mrsolo_ has joined #ocaml
08:50
mrsolo_ has quit [Read error: 104 (Connection reset by peer)]
08:50
mrsolo_ has joined #ocaml
08:55
mrsolo_ has quit [Read error: 104 (Connection reset by peer)]
08:55
mrsolo_ has joined #ocaml
09:15
gpciceri has joined #ocaml
09:15
moonfish has quit [Read error: 54 (Connection reset by peer)]
09:30
bk_ has joined #ocaml
09:46
ita has joined #ocaml
09:48
<
ita >
type seg = {mutable x:int; mutable next: seg; mutable prev:seg} && let newseg a = let rec ct = {x=a; pprev=ct; nnext=ct} in ct;; is all i needed for a doubly linked list
09:55
<
karryall >
ita: except you have nothing to represent an empty list
10:04
ita has quit [Remote closed the connection]
10:20
ita has joined #ocaml
10:23
gpciceri has quit ["Leaving"]
10:32
karryall has quit ["tcho"]
10:33
ita has quit ["Konversation terminated!"]
11:00
buggs|afk has joined #ocaml
11:06
buggs has quit [Nick collision from services.]
11:06
buggs|afk is now known as buggs
11:33
eternite has quit ["Ocaml:http://caml.inria.fr/"]
11:41
Iter has joined #ocaml
13:09
zigong has joined #ocaml
13:44
Iter has quit [leguin.freenode.net irc.freenode.net]
13:45
Iter has joined #ocaml
14:15
vezenchio has joined #ocaml
14:51
mflux has quit [Remote closed the connection]
14:51
mflux has joined #ocaml
15:14
Robert has quit ["brb"]
15:17
mpc has joined #ocaml
15:20
gpciceri has joined #ocaml
15:21
_fab has joined #ocaml
15:27
<
pango >
-rw-rw-r-- 1 root mldonkey 62 2004-09-19 12:38 .htaccess
15:28
<
pango >
oups wrong chan :)
15:31
gpciceri has quit ["Leaving"]
15:32
Robert has joined #ocaml
15:42
Robert has quit ["brb (grrr...)"]
15:44
<
Smerdyakov >
Only COMMUNITS say "oups"!
15:46
<
pango >
Smerdyakov: only dyslexics say communits
15:49
mpc has joined #ocaml
15:50
<
z|away >
Bastard children of 'ol Karamazov are known to have many problems...
15:51
<
Smerdyakov >
Like buggering apes
15:56
Robert has joined #ocaml
15:57
<
mflux >
"dyslexics of the world, UNTIE!"
16:49
monochrom has joined #ocaml
16:50
vezenchio has quit [Read error: 110 (Connection timed out)]
16:53
mpc has joined #ocaml
17:00
pango has quit [Nick collision from services.]
17:00
pango_ has joined #ocaml
17:03
pango_ is now known as pango
17:07
mrsolo_ has quit ["Leaving"]
17:07
mrsolo_ has joined #ocaml
17:45
cjohnson has joined #ocaml
19:05
lodewijk has joined #ocaml
19:05
Herrchen has quit ["leaving"]
19:12
<
lodewijk >
does anyone know how to get the integer value from the abstract Unix.file_descr (which is an integer) ?
19:12
<
Robert >
What do you need it for?
19:13
<
lodewijk >
I'm juggling some of them and it would help print_string debugging.
19:14
<
Robert >
Sorry, I have no idea.
19:17
bk_ has quit ["Leaving IRC - dircproxy 1.1.0"]
19:17
<
lodewijk >
hmm. I guess I'll write a small C stub to do it then. thanks anyway :)
19:17
lodewijk has quit ["bye"]
19:50
<
mflux >
yeah, I've wanted that sometimes too
19:50
<
mflux >
useful if you want to strace a program and get some useful information out of it
19:53
<
Smerdyakov >
In SML/NJ, there is an Unsafe.cast : 'a -> 'b function you could use.
19:53
<
Smerdyakov >
Maybe OCaml has something similar.
19:53
<
mflux >
hmm, there are some black magic functions, but I haven't given them a look
20:10
vegai has joined #ocaml
20:28
<
Smerdyakov >
Well, loooook who's here!
20:31
<
monochrom >
Ocaml has oo.magic or something.
20:31
<
Riastradh >
Obj.magic
20:44
gpciceri has joined #ocaml
20:49
pango has quit [Remote closed the connection]
20:54
pango has joined #ocaml
21:02
mpc has joined #ocaml
21:23
gpciceri has quit ["Leaving"]
21:38
cjohnson has quit [Read error: 54 (Connection reset by peer)]
21:39
cjohnson has joined #ocaml
21:44
Iter has quit [Read error: 110 (Connection timed out)]
22:06
tnks has joined #ocaml
22:07
<
tnks >
I was curious -- Does anybody here find Haskell inadequate compared to OCaml?
22:07
<
tnks >
(not in which ways).
22:07
<
tnks >
sorry. . . I meant "(in which ways)"
22:09
<
Smerdyakov >
The module system is horrible.
22:09
<
Smerdyakov >
And there aren't any good compilers for producing efficient object code.
22:10
<
monochrom >
OCaml has objects, classes, subtyping.
22:11
<
monochrom >
Now, I say this because I find subtyping and extensible records useful.
22:11
<
monochrom >
For example "the type of all records that has the field x:int, all other fields unconstrained and I don't care".
22:12
<
monochrom >
You can at least mimic that with object/class :)
22:13
<
monochrom >
Alright, you can also mimic some of that with Haskell's type class...
22:14
<
monochrom >
OCaml is eager. Some people find that comforting.
22:40
<
dan2 >
is there any way to make mutable types in OCaml
22:43
<
Smerdyakov >
The mutable keyword....
22:46
<
Smerdyakov >
Anyone want to help me test my SML-based PHP replacement?
22:50
<
dan2 >
Smerdyakov: when using mutable, how do I update variables
22:51
<
Smerdyakov >
dan2, read the tutorial in the manual.
22:52
* Smerdyakov
leaves.
22:52
<
Smerdyakov >
Anyone who wants to try the web thing, see
http://smlweb.sf.net/ . You need to check it out from CVS currently to install it.
22:54
<
monochrom >
let x = ref 0;;
22:54
<
monochrom >
x := !x + 1;;
22:54
<
dan2 >
monochrom: thanks
23:03
_fab has quit [Read error: 113 (No route to host)]
23:14
<
dan2 >
let k = ref 1 and a = ref (of_int 1) and b = ref (of_int 0) and c = ref (of_int 0) in
23:15
<
dan2 >
while k < n do
23:15
<
dan2 >
k := (incr !k);
23:15
<
dan2 >
a := add !b !c;
23:15
<
dan2 >
can someone tell me whats wrong
23:15
<
Riastradh >
Just about everything is wrong with that function.
23:16
<
dan2 >
Riastradh: how should I fix it
23:16
<
Riastradh >
Rewrite it entirely. Remove all references. Use a recursive loop.
23:16
<
dan2 >
Riastradh: no
23:16
<
dan2 >
Riastradh: recursive loop is bad
23:17
<
dan2 >
Riastradh: its the leading reason why I am not getting as good performance C
23:17
<
mattam >
i doubt x is ever different from fib x
23:17
<
Riastradh >
No, dan2.
23:17
<
mattam >
it doesn't type-check anyway
23:17
<
dan2 >
Riastradh: being able to reuse variables would make it so it doesn't have to constantly allocate memory for every variable
23:17
<
Riastradh >
There are almost innumerable other factors to consider.
23:18
<
dan2 >
Riastradh: I don't want a recursive function, how do I make
*THIS* work
23:18
<
Riastradh >
Yet you don't seem to mind allocating superfluous references on the heap and performing a ton of heap loads & stores.
23:19
<
dan2 >
Riastradh: I don't care, let me complete this
23:19
<
Riastradh >
dan2, do you know the saying 'a good Fortran programmer can write Fortran in any language?'
23:20
<
dan2 >
Riastradh: yes... just wtf should I do to fix this
23:20
<
dan2 >
I DON'T WANT A RECURSIVE FUNCTION
23:20
<
Riastradh >
Writing Fortran in OCaml won't help you fix anything.
23:20
<
mattam >
dan2: make it type-check first
23:20
<
dan2 >
mattam: uhh?
23:20
<
Riastradh >
Why not? Trust me: recursion is
_NOT_ the reason that the compiled OCaml code runs more slowly than the compiled C code.
23:20
<
dan2 >
Riastradh: its the garbage collector
23:20
<
mattam >
k is used as an int and an int ref as well for example
23:20
<
dan2 >
Riastradh: and not having to continuously allocate memory is a good thing
23:21
<
Riastradh >
dan2, can you demonstrate that the garbage collector is invoked at all during a call to a recursive fib?
23:21
<
dan2 >
Riastradh: yes, its eating 92% of the time during a run of fibonacci up to 200000
23:21
<
Riastradh >
I don't see any reason why it should be; there is no heap allocation, assuming you use the same algorithm as you use in that Fortran code.
23:21
<
dan2 >
Riastradh: I profiled the code
23:22
<
Riastradh >
Were you using regular ints or one of the bignum libraries when you performed this profiling?
23:22
<
pango >
dan2: using the same iterative algorithm you just described ?
23:22
<
dan2 >
Riastradh: the same GMP that Numerix uses
23:22
<
dan2 >
pango: no, a recursive
23:23
<
monochrom >
Hrm, what are those of_int things?
23:23
<
dan2 >
monochrom: for translation to GMP integers
23:23
<
Riastradh >
There's your reason, then.
_Bignums_ require heap allocation. It is entirely unrelated to any imagined overhead of recursion.
23:23
<
dan2 >
Riastradh: ironically, in C, I preallocated all the memory using some logic, and it BURNS the ocaml
23:23
<
dan2 >
Riastradh: .6 seconds for 200000
23:24
<
Riastradh >
Your Fortran code will have the same problem, only it'll also incur extra overhead for the heap-allocated references.
23:24
<
Riastradh >
Did you pre-allocate the
_bignum_ memory or what was used for the _variables_?
23:24
<
dan2 >
Riastradh: the memory for bignum
23:24
<
monochrom >
Preallocation is neat. But don't be unfair.
23:24
<
Riastradh >
Exactly. Even your Fortran-in-OCaml code still doesn't do that.
23:25
<
dan2 >
* fib(n) is exponential, number of bits is logarithmic
23:25
<
dan2 >
* thus, number of bits is a linear function and seems
23:25
<
dan2 >
* to converge near n/1.44
23:25
<
dan2 >
unsigned long size = (double)n / 1.44;
23:25
<
Riastradh >
Just so show that you're wrong, since you apparently don't trust me, I shall help you fix your Fortran code: what's the type of k?
23:26
<
Riastradh >
s/so show/to show/1
23:26
<
dan2 >
Riastradh: k is an integer
23:26
<
Riastradh >
An int?
23:26
<
dan2 >
well, int ref
23:27
<
Riastradh >
What is the type of (>)?
23:27
<
Riastradh >
...oh, bother.
23:27
<
Riastradh >
Never mind; ignore that.
23:27
<
dan2 >
oh, now I understand :)
23:27
<
Riastradh >
What's the type of n?
23:27
<
monochrom >
Hrm, is int in ocaml boxed?
23:27
<
dan2 >
n is integer
23:27
<
Riastradh >
dan2, are you sure k is an
_int_ ref?
23:27
<
dan2 >
(non ref, it should be immutable)
23:27
<
monochrom >
Are, boxed.
23:27
<
dan2 >
Riastradh: why wouldn't it?
23:27
<
mattam >
monochrom: not int's, no
23:28
<
Riastradh >
...oh, sorry, never mind.
23:28
<
monochrom >
So for example I can use the full 32 bits?
23:28
<
Riastradh >
dan2, so you see what's wrong with your code?
23:28
<
dan2 >
not entirely
23:28
<
Riastradh >
No, monochrom. There still need to be type tags.
23:28
<
dan2 >
just the !k > n part
23:28
det has quit [Read error: 110 (Connection timed out)]
23:28
<
mattam >
monochrom: 31 bits
23:28
<
monochrom >
Alright, you're right.
23:28
<
Riastradh >
What's the type of incr, dan2?
23:29
<
mattam >
and 63 on 64 bits arches IIRC
23:29
<
dan2 >
Riastradh: the compiler is only complaining about that last bit, !k;;
23:29
<
dan2 >
Riastradh: let incr = function x -> x+1
23:29
<
Riastradh >
You defined incr yourself?
23:30
<
mattam >
that's definitely funny
23:30
<
Riastradh >
Oh, OK. There's a system incr function that destructively increments the contents of its argument.
23:30
<
Riastradh >
...(its argument is of type int ref)
23:30
<
dan2 >
Riastradh: I didn't know
23:30
<
dan2 >
Riastradh: is there something wrong with my function?
23:30
<
Riastradh >
No, not at all.
23:31
<
dan2 >
Riastradh: so what is wrong with the last part of the function, the !k;;
23:33
<
monochrom >
!k is n at the end.
23:33
<
dan2 >
monochrom: ?
23:33
<
Riastradh >
Excuse me a moment.
23:33
chris has joined #ocaml
23:33
<
dan2 >
monochrom: good call :)
23:33
<
dan2 >
monochrom: didn't see that for a moment
23:34
<
dan2 >
monochrom: should be a
23:35
<
monochrom >
Hrm, why didn't ocaml perform dead-code removal so that the code ran fast when you had !k? :)
23:36
<
dan2 >
monochrom: its complaining about syntax on that !a;;
23:36
<
mattam >
because then compile times would be higher i suppose :)
23:36
<
monochrom >
Ah, ocaml didn't know that "add" is pure.
23:36
<
Riastradh >
dan2, try putting a semicolon after the 'done'.
23:37
<
dan2 >
monochrom: why do I have to dereference in this
23:37
<
dan2 >
I just want the reference anyhow\
23:37
pango has quit [Nick collision from services.]
23:37
pango_ has joined #ocaml
23:37
<
dan2 >
lets not spend time dereferencing then referencing again
23:37
<
Riastradh >
No, you don't want the reference. First of all, what you're doing there isn't variable assignment: it's
_reference_contents_ assignment.
23:38
<
monochrom >
Because references are not pointers.
23:38
<
monochrom >
Well, references are pointers under the hood, but on the surface there is a syntactic distinction.
23:39
<
monochrom >
I'd wager that c:=!b is translated to mere pointer copying.
23:40
shammah has joined #ocaml
23:40
<
Riastradh >
Note, however, that compilers for functional languages tend not to spend much effort in optimizing mutable references.
23:43
<
Riastradh >
He wants to be proven wrong about the speed benefits of Fortran code in OCaml, pango_.
23:44
<
pango_ >
Riastradh: yes, so it should compare his program against this one, not against one doing f(n) = f(n-1) + f(n-2)
23:45
<
Riastradh >
Oh, I see.
23:47
<
pango_ >
dan2: btw, replace the last line with ignore (fib n), or you'll also measure the time converting the result to a string...
23:47
<
dan2 >
pango_: already have one of those
23:48
<
pango_ >
dan2: I guess you checked the time spent in gc ?
23:48
<
dan2 >
hmm, is there anyway to get the profiler to spit out total time
23:48
<
dan2 >
pango_: yes, majority of time was spent in gc, but less than that of the recursive
23:48
<
dan2 >
pango_: like 7% less
23:48
<
dan2 >
pango_: seemed faster than recursive
23:49
<
dan2 >
how do I get gprof to spew out total time
23:53
<
pango_ >
here almost 92% of the time is spent adding bigints...
23:58
<
dan2 >
pango_: your version is significantly slower than mine
23:58
<
dan2 >
and gmp is much faster than big_int
23:58
<
pango_ >
dan2: so what
23:58
<
dan2 >
pango_: most of my time is being spent in GC as I said
23:59
<
pango_ >
dan2: then find why
23:59
<
dan2 >
pango_: what number did you test it on
23:59
<
Riastradh >
It's obvious why. He's allocating a lot of memory to store bignums.