Amorphous has quit [Read error: 60 (Operation timed out)]
Kerris7 has quit []
paul424 has joined #ocaml
Amorphous has joined #ocaml
Yoric[DT] has quit ["Ex-Chat"]
<paul424>
hey I have a type # type 'a t = {mutable my_array:'a option array ,array_size: int,mutable p: int, mutable q: int } ;; and then # let empty size = (my_array: (Array.make size None), array_size: size, p: 0 ,q: 0);; does not work
hkBst has quit [Read error: 104 (Connection reset by peer)]
<flux>
paul424, you should you separate fields with ;, not ,
<paul424>
yeap I noticed that already, thanks anyway ....
<paul424>
solved the probolem long ago ;)
<flux>
yeah, one should hope that kind of problem wouldn't last for too long :)
<paul424>
hehhe :)
<paul424>
flux: are u there ? could u have a look on something, cause I have problem with type system
<flux>
well, try me
<paul424>
I just used the 'a option to have greater flexiblity but when I want to use my_function(43, structure) I get : structure is of type 'a option not int option
<paul424>
in last line I get error: This expression has type int * 'a CyclicQueue.t but is here used with type int * int CyclicQueue.t
<flux>
your code compiles due to my not being defined
<flux>
if I "fix" it with let rec my I get a different error
<flux>
(I get File "bar.ml", line 38, characters 54-61:This expression has type int * ('a * 'b * 'c) but is here used with type int * int CyclicQueue.t)
<flux>
uh, I meant to say "your code doesn't compile due to my not being defined"
<paul424>
mh,,,,
<paul424>
hmm ...
<flux>
let my = CyclicQueue.empty 54,CyclicQueue.enqueue(43,my),CyclicQueue.enqueue(23,my) - as you can see, my isn't defined before that line, thus it isn't visible in the definition, thus it cannot be compiled
<paul424>
ohh I am so clumsy when it comes to program in ocaml ... how should I define it ?
<flux>
are you trying to define a recursive type?
<paul424>
NOOOO
<flux>
I mean, a value
munga has joined #ocaml
<paul424>
no
<paul424>
it is the implemnetation of cyclic list
<flux>
so is let rec my = .. what you're looking for?
<flux>
in any case that kind of construction doesn't make 'my' compatible with the definition of QUEUE_FUN..
<paul424>
I want to use the impereative style of ocaml
<flux>
oh
<flux>
perhaps then you want to do let my = CyclicQueue.empty;; CyclicQueue.enqueue(43,my);; etc
<paul424>
oh ok thanks ;)
<paul424>
what is the way to print something ... the print function or what ?
<alexyk>
I have a choice: to have a list of handles, or wrap handles in objects and have lists of objects; is there much overhead from having lists of objects? are they represented as pointers internally, or blocks which are copied?
<gildor>
flux: you keep calling me ;-)
<flux>
gildor, I wonder why, though.. I need to focus on what I press next time I respond to gionne, but irssi should pick gionned when I hit "gi<tab>" if gionne has talked last time
<flux>
;)
<alexyk>
hmm, noone uses objects around here, but they're sheer goodness, actually
<flux>
I use objects
<flux>
at times
<alexyk>
flux: cool! so how about lists of objects, are they expensive?
<flux>
alexyk, expensive in what sense?
<alexyk>
creating/destroying lists of objects vs list of ints
<alexyk>
passing around to functions
<flux>
well, surely they are more expensive
<flux>
passing an object is just as expensive as passing anything (even an int)
<alexyk>
flux: are the whole objects passed or are they pointers?
<flux>
I think a better comparison would be against a record of closures
<flux>
alexyk, they are behind a pointer ("boxed"), as is everything in ocaml, except primitive types
<alexyk>
basically I can use an int handle or wrap it in object, and weigh abstraction vs efficiency
<alexyk>
flux: so passing a tuple (string, int) is as expensive as passing an object pointer?
<flux>
yes
Yoric[DT] has joined #ocaml
Camarade_Tux has joined #ocaml
<Yoric[DT]>
hi
<flux>
alexyk, the other side of the coin is obviously that mutations to the object go everywhere where there is a reference to it
<alexyk>
flux: well. it's a good thing :)
<flux>
in any case, if you wanted const methods to an object, you could use phantom types to have those :)
<flux>
..it would make all methods polymorphic, though..
<flux>
(perhaps it'd be simpler to provide another version of the object, with the mutation methods removed)
<flux>
or cothreads - that might be more difficult
<mfp>
there should be some sort of standard template for release ANNs
<mfp>
+ mandatory blog entry or something
<mfp>
when something is released in Haskell-land, reddittors get to chose between (or see all of) the mailing list ANN, the hackage upload page, the project page & the blog entry
Yoric[DT] has quit ["Ex-Chat"]
bzzbzz has joined #ocaml
hcarty has joined #ocaml
<rwmjones>
gildor, ping ... I don't know if it was my imagination, but does ocamlcore have a place for "useful code snippets", ie. smaller than a module/package, but larger than a one-liner?
<rwmjones>
gildor, that is to say, I thought ocamlcore did but maybe I was imagining it :-)
<flux>
put them all into a library called RwmCore?-)
<rwmjones>
JonesCore, like JonesForth maybe ...
<rwmjones>
we actually had 'merjislib'
<rwmjones>
quite useful ...
<blue_prawn>
if it's your imagination, it would be a good idea to create it
<alexyk>
mfp: your solution to add Gc.finalise didn't work for me... runtime complaint! So if I have a method destroy, and in initializer say Gc.finalise destroy, destroy doesn't exit there yet; saying self#destroy instead, compiles and doesn't run
<mfp>
alexyk: did you see Alain Frisch's reply?
<mfp>
alexyk: Gc.finalise won't work for immediate values
<mfp>
such as ints
<alexyk>
mfp: ah...
<mfp>
a trivial workaround is to do for instance val h = (handle, handle) and use Gc.finalise on it
<mfp>
with (fun (x, _) -> destroy x)
<mfp>
you have to be careful when you define the finalizer
<alexyk>
mfp: the whole idea of objects suddenly dims -- I had either int ports or int handles, and really could have either, will probably go back to objectlessness
<mfp>
because the closure you give to Gc.finalise could hold a reference to the value, meaning it'd never be collected
<mfp>
using objects or not depends on how you intend to use those values later
<mfp>
if you want to use row polymorphism or not
<mfp>
or if you need late binding to be able to redefine some methods
<mfp>
it's largely orthogonal to the handle management thing
<alexyk>
mfp: true; in my app, it's just a convenience