Banana has quit [Read error: 110 (Connection timed out)]
khaladan has quit [Read error: 104 (Connection reset by peer)]
<Lob-Sogular>
Don't suppose anyone here has experience with CamlGI? specifically, references to: new cgi r (where r is of Request.t), but no references how to obtain said Request.t value--so how do I do that?
<Lob-Sogular>
ah. nevermind. found the examples directory in the cvs repository
Demitar has quit ["Ex-Chat"]
cyyoung has joined #ocaml
Razor-X has quit [Read error: 110 (Connection timed out)]
TaXules has joined #ocaml
bohanlon has quit [""Time to upgrade the OS""]
mikeX has quit ["zz"]
cyyoung has quit ["Leaving"]
hikozaemon has joined #ocaml
chessguy has joined #ocaml
dark_light has quit [Read error: 113 (No route to host)]
jcreigh has joined #ocaml
pango has quit [Read error: 60 (Operation timed out)]
Smerdyakov has quit ["Leaving"]
pango has joined #ocaml
jcreigh has quit ["Do androids dream of electric sheep?"]
<multani>
the problem is : i wanted to use the *_dumpable objects, with the dump method
<pango>
(tip: pastebin.be has ocaml syntax highlighting ;) )
<multani>
but since my polygon class use non-dumpable point object, it seems I can't use someting like the point_dumpable's dump method
<multani>
pango, shame on me, I thought it doesn't have it :(
<pango>
oh .com does too... ocaml is becoming famous or something ? ;)
<dylan>
multani: you don't need inheritence in this case.
<love-pingoo>
multani: why don't you require point_list points to be dumpable points in the definition of polygon ?
<multani>
well I can't touch the first two classes (point and polygon)
<dylan>
multani: I mean, there's no need for the dumpable class.
<love-pingoo>
multani: I was about to propose you to parametrize the polygon class by the point type, to make it easy to get dumpable and non-dumpable polygons
<love-pingoo>
but if you can't touch it :(
<multani>
dylan, I came there a few weeks ago, with another problem of the same kind, and someone there help me, and finally, we've got this dumpable class
<multani>
(if I am correct, it was ketty )
<dylan>
humm. you're not even inheriting from dumpable.
<multani>
anyway, with or without this inheritance, i got the same problem
<dylan>
I think it's because the polygon's point list is of type point, not point_dumpable.
<dylan>
you'd need an up cast, which isn't possible...
<dylan>
it's because of:
<dylan>
val mutable point_list : point list = []
<dylan>
and you said you can't change that?
<multani>
dylan, not really
<love-pingoo>
you can either redefine polygon from scratch (at least by making it parametric) or not call point#dump on non-dumpable points (dump them by yourself from the polygon's #dump)
<multani>
love-pingoo, currently i do the second solution, but it's not very pretty
<dylan>
a functor over polygon would be cool.
sieni_ is now known as sieni
* multani
is looking for functor in the ocaml documentation ...
<ketty>
multani: it would be easy if polygon_dumpable could only store point_dumpable... would that be acceptable?
<multani>
ketty, as far as I know, it would be OK
<ketty>
then you can rewrite "class polygon =" to "class 'a polygon ="
<ketty>
and do some other changes :)
<multani>
yes, but I can't touch the polygon class :'(
<pango>
well, ocaml has no such function in its standard library, contrary to sml
<pango>
it's not that hard to write, howevr
<romildo>
yes. I can write it. Just wanted to know if it is already on the library. Thanks.
<pango>
I don't like it much. The benefit of handling option types explicitly is that you cannot forget about the two cases ;)
<pango>
if your functions really assume the value is Some _, deconstruct that value earlier and pass the deconstructed value around...
_JusSx_ has joined #ocaml
<romildo>
In the algorithm I am implementing I need to find the index of an element in an array. So I wrote an auxiliary function (array_find : 'a array -> int option). But it is known that the element is on the array for sure. So I want to directly get the index i returned as the option (Some i). If there were a function the code could be cleaner (I think).
<romildo>
I have written my code as follows:
<romildo>
let pos_a = Array.map (fun i -> let Some j = array_find a b.(i) in j) pos_b in
<pango>
you'll still probably need some None -> assert false case to avoid compiler warning
<romildo>
With such a function is used, the code would be something arguably more readable like:
<romildo>
let pos_a = Array.map (fun i -> maybe (array_find a b.(i))) pos_b in
<romildo>
If I am not wrong, such function is called maybe in Haskell.