sponge45 changed the topic of #ocaml to: Discussions about the OCaml programming language | http://caml.inria.fr/
bluestorm has quit ["Konversation terminated!"]
Submarine has joined #ocaml
Axioplas1 has quit ["leaving"]
ramky is now known as ramkrsna
johnnowak has joined #ocaml
johnnowak has quit []
johnnowak has joined #ocaml
<mbishop>
Hmm, I did 'open Unix;;' and it seemed to work, but I can't call any of the functions from the unix module, always says "can't "
<mbishop>
er, says "Reference to undefined global `Unix'"
ikaros has quit ["Leaving"]
<hcarty>
mbishop: Are you using "Unix.foo" to call functions, or just "foo"?
<hcarty>
Once you do "open Unix;;" you don't have to use the Unix. prefix any more.
<mbishop>
I tried both, neither work
<mbishop>
they both give that same error
<hcarty>
Then you may not have the library loaded - which I don't remember the syntax for at the moment
<hcarty>
If you have findlib, you can use 'use "topfind";; #require "unix";;'
<hcarty>
Sorry, that should be '#use "topfind";;'
<mbishop>
that worked, thranks
<hcarty>
mbishop: You're welcome
pants1 has quit ["Leaving."]
johnnowak has quit []
Smerdyakov has quit ["Leaving"]
diffbavis has quit [Read error: 104 (Connection reset by peer)]
johnnowak has joined #ocaml
Submarine has quit ["Leaving"]
diffbavis has joined #ocaml
Mr_Awesome has quit ["...and the Awesome level drops"]
oscarh has quit [zelazny.freenode.net irc.freenode.net]
Smergo has quit [zelazny.freenode.net irc.freenode.net]
stevan_ has quit [zelazny.freenode.net irc.freenode.net]
Hadaka has quit [zelazny.freenode.net irc.freenode.net]
ludwig- has quit [zelazny.freenode.net irc.freenode.net]
ulfdoz has quit [zelazny.freenode.net irc.freenode.net]
shawn has quit [zelazny.freenode.net irc.freenode.net]
slipstream has quit [zelazny.freenode.net irc.freenode.net]
hcarty has quit [zelazny.freenode.net irc.freenode.net]
johnnowak has quit [zelazny.freenode.net irc.freenode.net]
flux- has quit [zelazny.freenode.net irc.freenode.net]
gim has quit [zelazny.freenode.net irc.freenode.net]
haelix has quit [zelazny.freenode.net irc.freenode.net]
cmeme has quit [zelazny.freenode.net irc.freenode.net]
pattern has quit [zelazny.freenode.net irc.freenode.net]
DoctorMach has quit [zelazny.freenode.net irc.freenode.net]
gunark has quit [zelazny.freenode.net irc.freenode.net]
ramkrsna has quit [zelazny.freenode.net irc.freenode.net]
seafood has quit [zelazny.freenode.net irc.freenode.net]
TaXules has quit [zelazny.freenode.net irc.freenode.net]
dark_light has joined #ocaml
johnnowak has joined #ocaml
DoctorMach has joined #ocaml
shawn has joined #ocaml
slipstream has joined #ocaml
ulfdoz has joined #ocaml
oscarh has joined #ocaml
Smergo has joined #ocaml
hcarty has joined #ocaml
stevan_ has joined #ocaml
ramkrsna has joined #ocaml
ludwig- has joined #ocaml
Hadaka has joined #ocaml
flux- has joined #ocaml
gim has joined #ocaml
seafood has joined #ocaml
gunark has joined #ocaml
haelix has joined #ocaml
cmeme has joined #ocaml
pattern has joined #ocaml
TaXules has joined #ocaml
<dark_light>
if i have a function defined as let test ?(c=1) b = b+c and another as let test b = b+1, the code produced by the call test x will have differences between the two functions?
<dark_light>
or, "the code produced by a no provided optional label will treat the label exactly as a constant?"
<tsuyoshi>
for such a small function, it will probably be inlined
<dark_light>
actually my function is.. let send ?(c=false) plr str = let msg = if c then colorize str else str in really_send plr.socket msg; really_send plr.socket "\r\n"
<dark_light>
i shouldn't worry about this, but.. i really don't know what is the overhead to have that optional c when most use i will have will be like send plr "hello"
<tsuyoshi>
the overhead (if it isn't inlined) will be one test and a branch
<tsuyoshi>
maybe 100 cycles at the most
<dark_light>
but it will do the test even if the compiler knows in advance that let msg = if c then colorize str else str equals to let msg = str ?
<tsuyoshi>
on a 500mhz processor you get 500 million cycles per second.. so I don't think I would worry much
<tsuyoshi>
dark_light: I don't think it would do the test if it's inlined
<tsuyoshi>
if you interested in this then you could try compiling it and looking at the assembly
<dark_light>
the problem is, i don't know assembly :)
<tsuyoshi>
oh then you should learn
<tsuyoshi>
it's much easier to learn than ocaml
<dark_light>
sure? ahahahaha
<tsuyoshi>
oh yeah.. I think most decent coders can pick it up in a couple days
shawn has quit [Read error: 60 (Operation timed out)]
shawn has joined #ocaml
<ulfdoz>
Diplomandin verdammig. Jetzt fang ich auch schon damit an.
<ulfdoz>
ECHAN, sorry
love-pingoo has joined #ocaml
triple_ has joined #ocaml
bluestorm has joined #ocaml
bluestorm has quit [Remote closed the connection]
love-pingoo has quit ["Connection reset by pear"]
johnnowak has quit []
triple_ has quit ["leaving"]
descender has quit ["Elegance has the disadvantage that hard work is needed to achieve it and a good education to appreciate it. - E. W. Dijkstra"]
ppsmimou has quit ["Leaving"]
ppsmimou has joined #ocaml
love-pingoo has joined #ocaml
ikaros has joined #ocaml
ikaros has quit [Read error: 60 (Operation timed out)]
ikaros has joined #ocaml
bluestorm has joined #ocaml
diffbavis has quit [Read error: 104 (Connection reset by peer)]
_PenPen_ has joined #ocaml
malc_ has joined #ocaml
malc_ has quit ["leaving"]
dark_light has quit [Read error: 104 (Connection reset by peer)]
dark_light has joined #ocaml
zygomatik has joined #ocaml
<zygomatik>
hi! I'm a noob in ocaml and I'm looking for a way to save an image produced by the Graphics module. Any clue ?
<love-pingoo>
zygomatik: I think there is a module with the same signature as graphics but which outputs postscript instead
<love-pingoo>
does that help ?
<love-pingoo>
I don't think it does the interactive stuff, though.
<love-pingoo>
Otherwise you have to dump the color matrix yourself.. some formats (like ppm) are not complicated.
ramkrsna has quit [Remote closed the connection]
pmatos has joined #ocaml
<zygomatik>
love-pingoo, thanx a lot. i'll check that
<zygomatik>
love-pingoo, I see it's called graphps
ramkrsna has joined #ocaml
Smerdyakov has joined #ocaml
ramkrsna has quit ["Leaving"]
delamonpansie has joined #ocaml
delamon has quit [Read error: 110 (Connection timed out)]
velco has joined #ocaml
love-pingoo has quit ["Leaving"]
_PenPen__ has joined #ocaml
_PenPen_ has quit [Read error: 60 (Operation timed out)]
diffbavis has joined #ocaml
zagzig_ has joined #ocaml
bluestorm has quit [Remote closed the connection]
_PenPen_ has joined #ocaml
<hcarty>
Is there a way to get an OCaml array length from the C FFI? I haven't found anything in the manual, but I may be missing something.
<hcarty>
Regardless, it looks like it may just be simpler to use a bigarray and wrap the call to convert a given array in to a Bigarray
zygomatik has quit ["Leaving"]
_PenPen__ has quit [Read error: 60 (Operation timed out)]
zagzig has quit [Read error: 110 (Connection timed out)]
smimp has joined #ocaml
smimou has joined #ocaml
bluestorm has joined #ocaml
Submarine has joined #ocaml
gunark has quit [Read error: 104 (Connection reset by peer)]
pmatos has quit [Remote closed the connection]
<dark_light>
I am having a trouble with labels (i think) and type inference. Basically the thing isn't compiling due type errors and I don't know why :) If anyone has time to look at it, I would appreciate. http://pastebin.co.uk/10721
velco has quit ["<boris``> reduction ad absurdum is a fallacious method of proof"]
<dark_light>
(I tried to remove unnecessary code, but I think the example is really still very long..)
<dark_light>
maybe I am confusing myself with the labels+currying in send and sendl functions
<mbishop>
pango_: hmm, guess I'll just install the old fashioned way :)
Submarine has quit ["Leaving"]
<dark_light>
i still see the page at google cache, http://209.85.165.104/search?q=cache:HuKyTVg_W3wJ:sylvain.le-gall.net/ocaml-gettext.html+ocaml+gettext
<mbishop>
What should "/absolute/path/to/ocaml/compiled/sources" be? /usr/lib/ocaml/3.09/ ?
<mbishop>
apparently yes, that is the appropriate path :)
<mbishop>
Hmm
<mbishop>
The build is dying, saying that it can't find the module "Parsetree"
<pango_>
dark_light:
<pango_>
let who_like plr list begin_fun iter_fun end_fun =
<pango_>
let lines ~c l = sendl plr ~c l in
<pango_>
...
<pango_>
seems to work, too
<dark_light>
so i don't need to specify the type..? hmmmm..
<dark_light>
well, but i couldn't use lines without the ~c?
<pango_>
I'm not obsessed by curried function... while sometimes nice, in many cases it obscures the meaning of code
malc_ has joined #ocaml
<pango_>
mmh yes, removing ~c:true from calls doesn't work
<dark_light>
the more curryied the code, the more i like to work with it... well, there are exceptions
<pango_>
and the less I'd like to maintain your code...
<dark_light>
yeah, i had never such a experience to let someone else maintain my own code....
<dark_light>
actually i don't like to *maintain* my code at all, i just like to write :)
<pango_>
I can manage to understand your 50 lines, but certainly not feel confident that I/O will happen in the right order, after so much use of partial labelled functions called from HoFs...
<dark_light>
pango_, the problem i think is as described here: http://caml.inria.fr/pub/docs/manual-ocaml/manual006.html in section '4.1.2 Labels and type inference': type inference doesn't like optional arguments (too bad to happen that i like...)
benny_ has joined #ocaml
<pango_>
labeled boolean parameters are often mistakes
<dark_light>
hmmm.. why? i had two functions, one for "true" and another for "false".. and that was bad
<dark_light>
and, well, i really put things a bit weird with currying. but i often thinks curryied functions is concise and elegant...
<pango_>
but why make it optional ?
<dark_light>
pango_, because there are a default case, hmmm.. it just happens to don't happen in any use of the function
<pango_>
somehow, I don't think it's normal to spend 10 minutes trying to estimate if you understand 50 lines of code
<dark_light>
Hmmmm... :o
<pango_>
did you try rereading code you wrote, say, 3 months ago ?
<mbishop>
Any idea why I don't have the Parsetree module?
<dark_light>
all my projects has a shorten timeline (or almost all...), so, no, this code probably i would not like in 3 months...
* dark_light
is a very indecise person
<malc_>
LUKE: Is Perl better than Python?
<malc_>
YODA: No... no... no. Quicker, easier, more seductive.
<malc_>
LUKE: But how will I know why Python is better than Perl?
<malc_>
YODA: You will know. When your code you try to read six months from now.
<dark_light>
ahahahaahha :~
<dark_light>
pango_, i was with two functions: send for no colors, and sendc for with colors. but this just seemed.. bad
<dark_light>
so i continued to use send, and for color, send ~c:true ... and that seemed pretty good...
<dark_light>
i don't feel inclined to write a boolean every time i use send. maybe i should go back to send/sendc scheme? x_x
<pango_>
let send c plr str = ... let send, sendc = send false, send true
<dark_light>
mbishop, well, i think there are no Parsetree module in official distribution
<pango_>
that what you still get your amount of partially applied functions ;)
<mbishop>
dark_light: weird, wonder why camtop wants it then
<dark_light>
ahahahaahhaha
<dark_light>
mbishop, maybe because it's a third part module required to use it..
<dark_light>
ah, camtop? hmm.. toplevel? maybe it's in ~/.ocamlinit ..
<dark_light>
pango_, ah, i come to my initial though about it: sometimes i have to pass a function the send function to a certain player, but without knowing if the function would use a plain send or color send
<mbishop>
File "camtop/camtop_toplevel.ml", line 29, characters 0-14:
<mbishop>
Unbound module Parsetree
<mbishop>
that's the exact error...I did find a Parsetree module on google...but I have no idea what it's from heh
<pango_>
dark_light: better not shadow the initial "send" function then... so you can use the version with a boolean parameter if you don't know yet
<mbishop>
a toplevel for cameleon2
<dark_light>
pango_, so i end up with three functions.. with prompt functions (send a msg + a prompt) i would end up with 6 functions.. plus, the list send will give me 9 functions
<pango_>
dark_light: more like it's not the right answer, but it's not the right question either :)
<dark_light>
mbishop, i am thinking there are something missing in your install..
<mbishop>
Perhaps, that's weird though...using the debian package for ocaml
<tsuyoshi>
so what's wrong with 9 functions
er has joined #ocaml
benny has quit [Read error: 110 (Connection timed out)]
<er>
would anyone have suggestions on switching from ints->nativeints in a codebase
<pango_>
dark_light: if colorizing depends on, say, the setting of player's terminal, maybe you want to use those settings, not thread colorization boolean flag around
<er>
redefining operators helps,
<pango_>
er: functors
<pango_>
er: but you'll lose performance, without defunctorization
<er>
but you still get lots of type errors with array accesses etc.
<er>
pango_, i don't need the flexibility to be able to switch, and it would be nice to be able to use standard operators (+,-) etc.
<tsuyoshi>
you coould redefine the array access operators, can't you?
<mbishop>
dark_light: building cameleon2 without the toplevel stuff seems to work fine
* mbishop
shrugs
<er>
that is, i want to make a one-way move towards nativeints because it makes the program more easily portable
<pango_>
let ( + ) = Int32.add, etc.
<pango_>
sorry, nativeints, not Int32
<er>
pango_, how would that work for the array access operator for eg.
<dark_light>
pango_, ah, hmmm, yes i plan do this, but the msg+prompt is another thing (it marks the last message was the final message, and the user should type commands now..)
<er>
?
<pango_>
let ( + ) = Nativeint.add then
<malc_>
er: you will have to convert ints to nativeints left and right, array/strig indices, all the stdlib functions work only on ints
<malc_>
so it's pointless
<pango_>
er: arrays expect ints
<pango_>
for indices
<er>
pango_, right, but couldn't i redefine that to do nativeint.to_int for every access?
<malc_>
besides the performance hit (should you care about that) will be non negligible
<er>
basically, ints suck because they're 16bit
<malc_>
HUH?
<pango_>
they're 31 bits signed
<malc_>
ints are 31bit on 32bit arches and 63 on 64bit
<er>
hm.
<pango_>
on 32 bit archs, yes
<pango_>
and other integer types are boxed, so you'll lose performance bigtime if you switch