ski has quit [Read error: 110 (Connection timed out)]
ski has joined #ocaml
dark_light is now known as meu_novo_nick
Skal has joined #ocaml
sidewinder has quit [Read error: 113 (No route to host)]
love-pingoo has joined #ocaml
sieni_ has joined #ocaml
sieni has quit [Read error: 104 (Connection reset by peer)]
pango is now known as pangoafk
love-pingoo has quit ["Connection reset by by pear"]
sieni_ is now known as sieni
andreas__ has joined #ocaml
shawn_ has joined #ocaml
<andreas__>
morning all
_shawn has quit [Read error: 145 (Connection timed out)]
love-pingoo has joined #ocaml
_shawn has joined #ocaml
shawn_ has quit [Read error: 145 (Connection timed out)]
cratuki has joined #ocaml
revision17_ has joined #ocaml
<cratuki>
Hello. I have to outline some background - I have a theory that most software domains are best served by either a webapp (applications) or high-performance desktop programs (tools) and that there isn't much good justification for low performance desktop apps - you should have made a webapp.
<cratuki>
I've been looking for an excuse to write something in ocaml for a while.
<cratuki>
And as I see the world ocaml is one of the languages potentially good for desktop apps (others being C and C++) because of the performance issue.
<cratuki>
Today I've found an excuse to write an ocaml app and am looking towards building up tools
<cratuki>
There doesn't seem to be much in the way of toolkits like qt, wx, etc.
<cratuki>
Is there anyone who's had some experience designing user-facing programs in ocaml
<cratuki>
And would they be able to give me an indication of what the better libraries are atm
<cratuki>
or point me to a document discussing it?
* cratuki
EOF
<ketty>
cratuki: hello ^^
<ketty>
i would suggest lablgtk2
<cratuki>
OK - thanks! That'll be multiplatform so that has extra convenience.
<ketty>
the usual complaint people have against lablgtk2 is that it is poorly documented... but if you just look a bit at the *.mli files, you will find most things you need to know..
<cratuki>
OK good. One of the problems I had with tk on python in the past was that it got a bit black magicy. Being able to find what you need if you need it is handy.
<ketty>
and all methods are named after the corresponding functions in gtk, so it is easy to apply the official GTK-documentation to ocaml :)
Revision17 has quit [Read error: 110 (Connection timed out)]
<cratuki>
Thanks. I'm reading thrhough the tute now.
<ketty>
okey, good luck! :)
<cratuki>
thanks for your help
<cratuki>
Even has packages in my distribution.
<ketty>
great ^^
<ketty>
which distribution do you use?
<cratuki>
Gentoo at work (where I am), freebsd at home (although justswitched from ubuntu after having hardware trouble)
<ketty>
ok
<cratuki>
and you?
<ketty>
debian ^^
<cratuki>
heh. yeah. I like the apt approach. My servers run that.
<ketty>
allthou i use GODI for my ocaml-needs
<cratuki>
But I find it too outdated for my desktop needs. Ubuntu was good until it started freezing when I tried to do straightforward things with mount. Couldn't get my (dodgy software) raid to work there iether. Will check out GODI.
<ketty>
GODI is a source based ocaml-distribution by the way..
<cratuki>
Do you work with ocaml or is it just for a hobby?
<ketty>
ehh..
<cratuki>
no work huh :)
<ketty>
i have no work :)
<ketty>
i study computer science at the university...
<cratuki>
That sucks. Economy is booming where I am - programmers are in short supply. (Australia) what country are you at?
<ketty>
but there we don't use ocaml..
<cratuki>
So why did you get into it?
<ketty>
hmm..
<ketty>
don't remember :)
<cratuki>
heh
<cratuki>
I first saw it when people kept winning programming contests with it.
<ketty>
heh..
<ketty>
yeah.. maybe that was how i found it too..
<cratuki>
And then later I was trying to work out a potential replacement for C/C++ for writing desktop apps. ocaml was the only thing I saw that seemed to fit the bill.
<ketty>
yes..
<ketty>
but it is addicting :)
<cratuki>
lisp, java, perl, python all need vms.
<cratuki>
That's encouraging.
<cratuki>
It's years since I ran the tutorial. Will have forgotten it all.
<cratuki>
Is godi command-line based or gui-based?
<ketty>
console-gui :)
<sieni>
vms?
<cratuki>
Right. Um - so is it a RELP?
<ketty>
relp?
<cratuki>
Virtual Machines. JVM, python or perl runtimes (and you have to have the libraries installed and that's a pain, etc)
<sieni>
since when does lisp need a virtual machine?
<cratuki>
In lisp people tend to develop using a 'REPL' loop which is where you type in a function and it goes into the engine.
<ketty>
ohh..
<cratuki>
sieni: Um - you're manipulating the command stack. Macros wouldn't be possible unless it was in a vm.
<ketty>
no, godi is curses or something like that
<sieni>
wtf?
<sieni>
sbcl always compiles everything into native code and executes that. ergo: no virtual machine
<cratuki>
sieni: I may be misusing terminology, but there is a valid point at the bottom of it.
<cratuki>
sienei: I think of perl, python engines as VMs as well.
<ketty>
i don't know about lisp, but scheme don't need a vm..
<cratuki>
Hmm.
<cratuki>
OK
<cratuki>
But then I don't understand what happens if you have a macro that calls something that wasn't mentioned at compile time.
<sieni>
I really don't understand what you are talking about.
<cratuki>
How does that functionality get into a binary?
<ketty>
i don't understand you either :)
<sieni>
cratuki: the macros are expanded during the compile time, but they have access to whole lisp (during compilation)
<cratuki>
sieni: If I step through this again will you stick around for the conversation to set it right?
<sieni>
depends how long it takes, I'm getting hungry :-)
<cratuki>
Ok
<cratuki>
let me approach from the other direction
<cratuki>
My goal is to create a shippable desktop app.
<cratuki>
I'm concerned about having to send in extra libraries. Eg: the libraries you distribute with delphi
<cratuki>
Er. So if you compile a lisp program and send it to a user - is it possible to do this without sending them any ancilary files?
<ketty>
if it is staticaly linked, i would say yes..
<cratuki>
OK.
<cratuki>
sieni: didn't take as long as I expected.
* ketty
is off to the shower ^^
<sieni>
anyway, I guess that in both cmucl and sbcl you need to do something like dump a lisp image to disk in order to get a standalone application. Commercial implementations probably do this better.
<cratuki>
sieni: how is the bundling functionality in ocaml? Is it easy to produce a user-ready release?
<sieni>
I think you can link ocaml applications statically
<sieni>
Also MLton (a standard ml compiler) certainly allows that
<cratuki>
This would seem to be not the field for which you use ocaml - what's your application?
finelemon has joined #ocaml
<ketty>
cratuki: ocaml for sure produces stand-alone applications :)
<mellum>
Not by default, they link against libc
<cratuki>
It's great that gtk stuff is covered in the ocaml tutorial. I don't know of another platform that gets into the GUI action so quickly and tries to make it easy.
<ketty>
:)
<ketty>
you read ocaml-tutorial.org ?
<cratuki>
Yup.
<cratuki>
My environment is acting up though. open Gmain works, but open GWindow doesn't.
<cratuki>
And if I leave open GWindow out I get problems with the sample program I'm running.
<multani>
if i am correct, the instance of window parametric class has no specified type ?
<ketty>
they do have a type...
<ketty>
but not a class...
<multani>
hmm
<multani>
subtle ...
<multani>
ah
<multani>
i remember
<ketty>
hmm.. *reading*
<multani>
the "parameter" (don't know how to call it) of the parametric class, is bound the first type used
<multani>
or something like that ?
<ketty>
mm... i guess ^^
<multani>
*bound _to_ the first type used
<ketty>
i am still reading it...
<ketty>
ok..
<ketty>
if you want to cast an item from the observers list, that is not possible.. ^^
<ketty>
but i am not sure you need to do that...
<ketty>
what was your problem again? ^^
<ketty>
or, might have answered to fast..
<multani>
hhmm
<multani>
i want to subtype or cast an object
<ketty>
the basic rule about casting is that you can cast a specific obejct to a more general one, but not the reverse...
<multani>
hum yes
<multani>
i understand that, no problem
<ketty>
so in this case which apply?
<multani>
arg, it's hard to explain ^^
<ketty>
(feels like it is time for a remark about OOP being unnecesary complex ^^)
<ketty>
(but i am not good at that sort of things ^^)
<multani>
do you remember my problem from yesterday ? ^^
<ketty>
yes, sort of ^^
<multani>
which involves point, polygon, point_dumpable and polygon_dumpable
<ketty>
yes.. :)
<multani>
(don"t have the pastebin file anymore :( )
<multani>
good :)
<multani>
my goal in life, is to have a way to cast the point to a point_dumpable, in order to use its dump method
<ketty>
oh.. so you had an object of type point_dumpable, that was casted into a point, and you want to cast it back?
<multani>
yes, because there is two problems :
<multani>
- it seems I can't make the polygon_dumapble with point_dumpable, since the polygon object is waiting for _point _objects
<multani>
(and remember, poly_dumapble inherits from poly)
<ketty>
yes
<ketty>
which i told you it shouldn't :)
<multani>
(yes, but it's part of the game :) )
<multani>
- and if i cast the point_dumpable to point, in order build my poly, i can't use the dump method on the poly points
<ketty>
yes
<multani>
so, i try to cast everything to anything else, but with no luck :(
<multani>
ah
<ketty>
the only workaround i can think of right now is for poly_dumpable to keep track of the point_dumpables...
<ketty>
so when you add points, you allso save the point_dumpables for later use...
<ketty>
messy?
<multani>
can't i try to subtype my point to the _dumpable interface ?
<multani>
it's a bit ugly, but well ^^
<ketty>
hmm... i thought you said you could not touch point?
<multani>
hum, i wanted to do thaht in the poly_dumpable class :D
<ketty>
.... well, point is a more general type than point_dumpable, right?
<multani>
yes
<ketty>
so there is no way to cast objects from point to point_dumpable
<ketty>
since points does not have to be dumpable
<multani>
it seems logical
<multani>
so, i have to build the poly_dumpable with point_dumpable :)
<ketty>
yes :)
<multani>
but, why can't i do that ?
<ketty>
yes, why cant you do that? :)
<multani>
since point is a more general type than point_dumapble ?
sieni has joined #ocaml
<ketty>
hmm..
<ketty>
not sure i understand you
<multani>
wel, in fact I can ^^
<ketty>
you mean you want poly_dumpable to inherit from poly and by some magic make poly use point_dumpables instead of points?
<multani>
yes :D
<ketty>
good luck :)
<ketty>
the problem now is that you can't touch poly...
<multani>
but, i don't see the problem, since point_dumpable are point, after all
<ketty>
and that poly is not polymorphic...
<ketty>
there is no problem in storing point_dumpables in a poly
<ketty>
(since they are points)
<multani>
yes
<ketty>
but there is a problem with trying to get point_dumpables out of a poly
<ketty>
since poly deals just with points
<multani>
yes, i understand
<ketty>
and all it methods have the explict type poly attached to them...
<ketty>
so it will return plain polys...
<ketty>
ehhh.. plain points :)
<multani>
(you mean point i guess ^
<multani>
;)
<ketty>
yes.. those words are to similar! :)
<multani>
we can speak of segment and point if you prefer ;)
<ketty>
so, given the wikkedness of the problem i don't think you can find a good looking solution...
<ketty>
ok :)
<ketty>
would it be posible to construct a dump function that took a plain point as argument?
__DL__ has quit ["Bye Bye"]
<dylan>
multani: where's the code in question now?
<multani>
dylan, lost in pastebin space :)
<dylan>
well, can you find it and let me see again?
<multani>
hum, i don't have it here :/
<multani>
but if you are really motivated, i can make it again :)
<multani>
ketty, i thougth of that
<multani>
making a dumpable module
<multani>
which various functions
<ketty>
and would it work?
<multani>
but in reality, the point_dumapble ineherits from point, dumapble and another class which i want to take out its attributes :(
<multani>
(in the dump method)
<ketty>
hmm?
<multani>
er
<ketty>
ok
<dylan>
what does dumpable do?
<multani>
i don't _only_ the attributes from point, but from the other class too
<ketty>
i understand...
<ketty>
so in reallity point_dumpable is not just a dumpable point...
<multani>
dylan, it transforms the object in something else (in reality, in transforms the object into an xmlrpc structure)
<ketty>
but other stuff to...
<multani>
ketty, yes, but i think it's enough complicated with just one class, so I don't specified it :)
<multani>
*two classes
<ketty>
then there is just more reasons not to inherit from point =)
<multani>
hmm, yes .... but no :)
kral has quit ["Live fast, die young."]
<ketty>
well, it is your pain we are talking abount :)
<multani>
i know :'(
<multani>
i think I will go with the dumpable module stuff
<multani>
i will find a way to add attributes from the other class (or not)
<ketty>
mmm.. we will see :)
<multani>
it's the cleanest solution i thought :/
<ketty>
ok
<multani>
what do you think of it ?
<ketty>
i still think inheriting from invariant stuff like that is stupid...
<ketty>
but i don't know the real code..
<ketty>
my reasoning is that since you don't have controll over them you should not base your entire design on them..
<ketty>
in stead you should treat them like abstract types as much as posible...
<multani>
in fact, the idea is to have a "generic" part, which handles figures, point, segment, poly, etc., and then, to implement an app using mvc and things like that, which reuses the first part
<multani>
*the idea was
<ketty>
are you implementing the generic part too?
<multani>
i don't know if we achieved it or not :/ (seems not ^^)
<ketty>
(it should be implemented in a more polymorphic way ^^)
<multani>
yes, not me, but somes guys i work with
<ketty>
so.. is this work?
<multani>
as you can see, it works like a charm :)
<multani>
very reusable, etc. :)
<ketty>
mmm :)
<ketty>
you could tell them that you don't like it and want them to redo it :)
<multani>
it's a bit late i think :D
<ketty>
maybe it is time to just go for whatever solution that works, and not worry about how ugly you think it looks...
<ketty>
and you can blame all uglyness on those other guys anyway :)
shawn_ has joined #ocaml
<ketty>
and just because you have one solution that works doesn't mean it has to be final...
_shawn has quit [kornbluth.freenode.net irc.freenode.net]
mlh has quit [kornbluth.freenode.net irc.freenode.net]
<ketty>
so when implementing something ugly but working, you might get ideas that helps you do it better...
_shawn has joined #ocaml
mlh has joined #ocaml
<multani>
yes, we are currently something which is a bit ugly (yes, uglier than that :p ), so I tought to reuses the dump method between each classes
<ketty>
hmm...
<multani>
but i thought it would have been simpler
<ketty>
is the dump method of the different classes really that similar?
<ketty>
except for the type of the method...
<ketty>
does they share implementation?
<multani>
no
<multani>
they just transform the object into a structure
<multani>
(which can be send throught xmlrpc)
<ketty>
so, then all this does not give us really much... right?
<ketty>
since you still have to write all the different implementations...
<multani>
yes, but ...
<multani>
for ex.
<multani>
currently, i transform the point into {x, y}
<ketty>
yes..
<multani>
and the segment into {x1, y1, x2, y2}
<multani>
whereas i wanted to have {p1: {x, y}, p2: {x, y}}
<ketty>
mmm...
<multani>
(the same goes for poly, etc.)
romildo has joined #ocaml
<romildo>
Hi.
<ketty>
it is hard for me to say what (i think) is best to do since i don't know the full setting...
<ketty>
hello romildo
<multani>
ketty, both are good imo
<multani>
however, the second one (try to) reuse much code
<ketty>
i was thinking about what we previously talked about..
<multani>
ah, ok, sorry
<ketty>
how much code is it really?
<ketty>
:)
<ketty>
is there methods to get the x and y from a point?
<multani>
not much, i agree ^^
<multani>
ketty, yes
<ketty>
than it is really not much code :)
<ketty>
but we are not just talking about segements and points, right?
<multani>
right
mlh has quit [kornbluth.freenode.net irc.freenode.net]
_shawn has quit [kornbluth.freenode.net irc.freenode.net]
_shawn has joined #ocaml
mlh has joined #ocaml
<multani>
we have bezier curves, polygons, rectangles, etc.
<ketty>
... and a consistent way to dump them would be nice... ^^
<multani>
and relationship between each figures
<multani>
yes, you're absolutely right ;)
<ketty>
you know what i think? i think using normal labeled types would be much better than using objects...
* multani
is looking what is labeled types ^^
<romildo>
I have a queston regarding console output.
<ketty>
romildo: yes?
<multani>
ketty, you mean : type point = int * int ; ?
<romildo>
I want to indicate the progress of my applicaton by printing a counter to standard output, at a fixed position. Any clue?
<ketty>
multani: it is called variant types in ocaml, sorry :)
_shawn has quit [Connection timed out]
<ketty>
(we have sml in school, and they call them labeled types)
<ketty>
romildo: you can output the special backspace character code...
<ketty>
i don't remember what it is thou :)
<multani>
ketty, i got the variant type
<multani>
it look pretty :)
<ketty>
it is :)
<multani>
well, it's time for me to go to sleep
<multani>
thanks a lot ketty for this discussion :)
<ketty>
ok, goodnight then ^^
Schmurtz has joined #ocaml
multani has quit ["Parti"]
<romildo>
ketty: '\b' works. thanks.
Schmurtz has quit ["Plouf !"]
<romildo>
I have another question, regarding methods as values.
<romildo>
Can a method be manipulated as a value?
<dylan>
can be treated as any other function.
<romildo>
That is, can a method be passed as argument to functions, or put on data structures, etc?
<dylan>
yes.
<dylan>
it can be treated like any other function.
<dylan>
can be curried, etc. :)
_JusSx_ has quit ["leaving"]
lde has joined #ocaml
<romildo>
Suppose a class C has the method f declared as "method f = (* something action *)". Let x be an instance o C. Then with "let k = x.f", kill names the method f or the result of the method f ?
<romildo>
I mean, "let k = x#f"
<romildo>
s/kill/k/
<dylan>
in that case, the result.
<ketty>
hmm.. methods can have zero arguments..
<ketty>
but functions can not..
<romildo>
In that case, how would bind the method in a let declaration?
<ketty>
let k = fun () -> x#f
<ketty>
?
<dylan>
or let k () = x#f
<ketty>
yes :)
<sieni>
ketty: of course a method can have zero arguments: it's just a constant
<ketty>
sieni: hmm?
<ketty>
there is a different between constants and zero argumented methods..
<romildo>
a method with zero arguments would be a constant if there were no side effects in the language...
<sieni>
ketty: in a procedural language, yes
<romildo>
"let k () = x#f" does not bind k to the method, but to a function that, when applied to (), evaluates the method.
<ketty>
romildo: and the difference is?
<romildo>
It seems that it is not possible to bind a name to a zero argument method in OCaml. Is that a flow design?
<romildo>
ketty: a concept difference
<ketty>
assume the method was declared as method f () = ...
<ketty>
and you do: let k = x#f
<ketty>
how is that different from the previous example)
<ketty>
s/)/?
<romildo>
ketty: the assumption that the method is declared as "method f () = ..."
<romildo>
Now the method is not a zero argument method anymore.
<ketty>
i somewhat agree with you..
<sieni>
I don't understand the problem
<ketty>
there is no problem :)
<ketty>
it is just a matter of estetics :)
<sieni>
_every_ function in ocaml takes exatly one argument
<romildo>
The design of the language was made somewaht inconsistent when it allowed zero argument methods, since functions cannot have zero arguments.
<sieni>
and if your function doesn't take any arguments, then it is "emulated" by taking an argument of type "unit"
<romildo>
it is not only estetics, but language "consistency"
<sieni>
which just is a mathematical expression of the fact that the empty product is just a set with one element
<ketty>
the inconsistency is between non-functional values and functional values..
<ketty>
zero argumented methods and argumented methods are consistent with: let a = ... vs. let a () = ...
<romildo>
But with "let a = ...", the expressions that gives the value for a is evaluated only once, at the time the declaration is elaborated.
<ketty>
that is true...
<romildo>
With "let a () = ...", the expression that gives the value for "a ()" is evaluated every time the expression "a ()" is evaluated.
<sieni>
ketty: read e.g. the nice book "types and programming languages"
<romildo>
So it is not the same thing.
<ketty>
:) ... so.. maybe the root of the problem is the existence of "mutable" ?
<romildo>
yes. the language is not purely functional. "mutable" and i/o makes it impure.
<ketty>
since otherwise method a = ... would be exactly consistent with let a = ...
<romildo>
My conclusion: there should not be methods with zero arguments, as a method as a kind of function. All methods should have one argument. With a zero argument method is wanted, use an instance variable when no side effect is present, or use the argument () when side effects are produced. Just like ordinary variables and functions.
<sieni>
romildo: there's always haskell
<sieni>
ml doesn't even claim to be purely functional
<romildo>
That is why I say that there were an error in the language design.
<sieni>
romildo: umm...
<romildo>
I am not seing the language should be purely functional. Just that all methods should have exactly one argument, just like functions.
<sidewinder>
romildo: then hack the code and do whatever you want with it
<sidewinder>
romildo: call it romildocaml
<sieni>
romildo: all functions and methods in ml or haskell or any implicitly currying language have exactly one argument
<romildo>
except in ocaml, where methods may have zero arguments.
<sieni>
romildo: wtf?
CosmicRay has joined #ocaml
<romildo>
OCaml is a very good language and I will continue to use it. I was just writing some code where I want to dynamically choose which method to use in an algorithm and noticed that I couldn't pass methods with zero arguments, as an argument to functions. Then commented it here. The solution is easy: I will define them with the argument () and everythin will work as expected.
<romildo>
Excuse me if I have been pedantic. That was not the intention.
romildo has quit ["leaving"]
laurence_ has left #ocaml []
pauldia has quit [Read error: 110 (Connection timed out)]
CosmicRay has quit [Read error: 113 (No route to host)]