<palomer_>
however, ocaml will actually refine the 'a to 'b by itself (methinks)
<palomer_>
and catRights will only work with elements of (a,a) either list
<thelema>
that's what I get out of the toplevel:
<thelema>
val catRights : ('a, 'a) either list -> 'a list = <fun>
<palomer_>
if you insist that something is 'a, and it is more specific, I expect a type error.
<palomer_>
err
<palomer_>
<thelema> if you insist that something is 'a, and it is more specific, I expect a type error. <--but 'a is more specific! (namely, it is actually 'b)
<palomer_>
btw, is there cleaner syntax than object method a = foo method b = bar end ?
<thelema>
maybe there's a bug in the type checker around this.
<thelema>
to define a new object - no, that's as good as it gets. you could camlp4 something for yourself if you like.
<palomer_>
# let a : 'a = 4;;
<palomer_>
val a : int = 4
<thelema>
I guess it happily ignores the 'a part of any type declarations you give it
* qwr
thinks, that it unifies it with the inferred type
<qwr>
... and 'a always becomes an alias to the type it will be unified
<palomer_>
what if I don't want a universal variable to be further refinable?
<palomer_>
(just a question to put out there)
<qwr>
what you mean by that?
<qwr>
universal variable?
<thelema>
palomer_: then you need to rewrite your code - type annotations are just suggestions. The type checker determines the real types.
<palomer_>
qwr, err, I meant 'a variables
<qwr>
but 'a isn't a type
<qwr>
it's type variable
<qwr>
you can have have 'a in polymorphic function, if nothing determines it's type in the function
<qwr>
but it will become a concrete type, when you use that function
<palomer_>
righto!
<palomer_>
but the annotations can be further refined
<thelema>
you can't stop ocaml from specializing 'a.
<qwr>
(yes it may be different on different uses - but it will be one concrete type on one use)
<palomer_>
okay
* palomer_
doesn't mind that much, was just comparing with haskell
<palomer_>
different haskell implementations handle these cases differently
<qwr>
imho haskell type system works basically in same way - they just have type classes and more clever stuff there
<qwr>
what the (runtime) implementation does doesn't really matter here
<palomer_>
the way annotations are dealt with varies
<palomer_>
ghc has a forall keyword which decides if a variable is refinable
<palomer_>
other implementations do their own thing
* palomer_
did his masters thesis on this kind of thing
<qwr>
ok
<palomer_>
heck, my ex-prof wrote an 80 page report on this stuff
<palomer_>
(probably boring as heck)
* qwr
hasn't really digged into haskell type system ;)
* qwr
has just used it trying to not get on it's way...
<palomer_>
it's way?
<palomer_>
haskell's way?
<qwr>
haskell's type systems way ;)
<palomer_>
haskell's type system can get a little hairy sometimes
<palomer_>
especially when you start stacking monads on top of each other
<palomer_>
stacking stuff on top of ST is the worst
<palomer_>
(stacking is when you combine monads together, ST is the monad with references)
<palomer_>
trying to understand the errors is impossible!
<palomer_>
erm, but I shouldn't criticize haskell
* palomer_
apologizes
* qwr
thinks he's seen some of those non-refinable type variable errors by ghc
<palomer_>
yeah, since ghc 6.something they call'em rigid types
<qwr>
and i was quite puzzled at start. now i don't remember what a fuck i was doing
<qwr>
they even made somehow sense when i thinked long enough about them ;)
<qwr>
thought
<palomer_>
simon peyton jones rewrote the paper explaining rigid types like 3 times
<palomer_>
I still didn't get it!
<qwr>
anyway, ocaml shouldn't have those ;)
^authentic has joined #ocaml
authentic has quit [Read error: 113 (No route to host)]
^authentic is now known as authentic
jprieur has quit [Read error: 110 (Connection timed out)]
Axioplase has quit ["((lambda(k) (k 'sleep)) eval)"]
Torment has joined #ocaml
hsuh has quit ["bye"]
Jedai has quit [Read error: 110 (Connection timed out)]
pec1 has joined #ocaml
pec1 has left #ocaml []
wy has joined #ocaml
adu has joined #ocaml
<adu>
OCaml rocks!
slowriot has quit [Read error: 104 (Connection reset by peer)]
<palomer_>
is there a way to access self from an instance variable?
* mbishop
is frightened by palomer_'s excessive use of OO
<palomer_>
a hack mayhaps?
* palomer_
thinks he doesn't understand the concept behind instance variables
<palomer_>
mbishop, if you saw my code, you'd scream!
<palomer_>
but it's working!
* palomer_
giggls with glee
<palomer_>
thelema, got any insight on how to set the background colour of a label?
* palomer_
switches objects to records and does not notice a difference
<palomer_>
back to objects!
dibblego has quit [Remote closed the connection]
adu has quit []
wy has quit ["Leaving"]
alexyk has joined #ocaml
<thelema>
palomer_: gtklabels are transparent - no way to set their background, but if you put them in something with a BG, ...
<thelema>
palomer_: as to self - class foo = object (self) method get_self = self end
mwc has quit ["Leaving"]
wy has joined #ocaml
szell has quit [SendQ exceeded]
<alexyk>
still wondering from yesterday why GODI ocaml doesn't find pkg-lib/extlib in any easy way except for ocamlfind; -I +extlib doesnt work as -I is std-lib -- is there a short non-ocamlfind way to specify its extlib etc pkg-lib packages on the command line to ocamlc?
schme has joined #ocaml
<alexyk>
interestingly, GODI toplevel easily finds extlib via #load "extlib.cma";;
<alexyk>
it is command-line ocamlc which doesn't find it
<palomer_>
thelema, but you can't call methods from instance variables!
<palomer_>
is there a reason why instance variables can't access self?
<thelema>
palomer_: ah, because self isn't defined yet. does this pattern help:
<thelema>
class foo = let v = calculate_something in object self val v = v; end
<sanxiyn>
ocaml --help told me about -dinstr which dumps OCaml bytecode.
<bluestorm>
sanxiyn: why would you want break/continue ?
<sanxiyn>
Looking at bytecode generated for for loops, it seems as easy as inserting branchif at place of break.
<bluestorm>
if you want to break control flow, you can use exceptions
<sanxiyn>
bluestorm: It's cumbersome to include try/with whenever you want to use break/continue.
<bluestorm>
do you often want to use them ?
<sanxiyn>
bluestorm: It's most unnatural. And I believe less efficient.
<sanxiyn>
bluestorm: Yes.
<bluestorm>
i'd say something is wrong on your side :-'
<bluestorm>
you should have a look at the camlp4 extension listed above
<sanxiyn>
Well I just want to make OCaml better, really.
<bluestorm>
before trying compiler voodoo
<sanxiyn>
bluestorm: I've looked at it by the way.
<sanxiyn>
bluestorm: That's what gave me the idea, actually.
<sanxiyn>
ocaml-break-continue is implemented as transformatin to exception handling, but there's no reason to do that way. OCaml bytecode has goto instruction just fine.
<thelema>
sanxiyn: break maps nicely to an exception, and continue maps pretty well to an if expression.
<bluestorm>
sanxiyn: the problem with bytecode modification is that it won't work for native code too, will it ?
<Smerdyakov>
sanxiyn, can you give us a concrete example of what you're implementing, such that you think you want a loop with break/continue?
<thelema>
bluestorm: native code has goto.
<palomer_>
if functional style was taught in school, loops would probably dissapear!
<sanxiyn>
bluestorm: Well, I'm just testing whether it's feasible. It seems to. I could worry about native codegen later once bytecodegen is working...
<bluestorm>
palomer_: i'm not sure
<thelema>
palomer_: loops are easier to teach than recursion, I expect.
<bluestorm>
loop are could for a certain kind of things
<sanxiyn>
bytecomp/bytegen.ml:649
<palomer_>
yeah, recursion is a toughy
<bluestorm>
and bare recursion is not always better
<Smerdyakov>
sanxiyn, are you not going to answer my question?
<bluestorm>
was a one-liner in a toplevel initially, so maybe the best code ever :p
<bluestorm>
maybe *not*
<sanxiyn>
bluestorm: cool
<thelema>
bluestorm: ick, non-tail recursion
<Smerdyakov>
sanxiyn, you need to justify the usefulness of break/continue because they make programs hard to reason about.
<bluestorm>
thelema: hm
<bluestorm>
can the compiler still generate tail-calls for the frequent tail-recursive calls ?
<bluestorm>
(in that case call stack would grow logarithmically, wich is not a problem in most cases)
<sanxiyn>
Smerdyakov: Good modularization, interface, and encapsulation make program easy to reason about, not certain syntactic feature.
<thelema>
hmm, I think the compiler would do that. n/m, not quite as bad as I first thought.
<Smerdyakov>
sanxiyn, while those also help, "break" and "continue" definitely hurt.
<bluestorm>
sanxiyn: i'd assume he's talking about formal verification
<Smerdyakov>
bluestorm, me? No.
<sanxiyn>
ok, thank you guys, back to code.
<Smerdyakov>
sanxiyn, OK, so now you are definitely refusing to answer my question.
<Smerdyakov>
sanxiyn, I wanted some concrete code.
ttt-- has quit [Read error: 110 (Connection timed out)]
<sanxiyn>
Smerdyakov: Well, I won't bother. I'd rather spend my time on hacking the compiler :)
<Smerdyakov>
sanxiyn, OK, though I would suggest that it's generally worth hearing people out when you ask a question about a subject that they know more about than you do. You'll never escape unrealized bad habits if you maintain this affronted response to suggestions like mine.
<sanxiyn>
Smerdyakov: I'm not sure I understand. If you recommend never using loop etc. in OCaml, why are loop in OCaml at all? Why doesn't Caml devel team remove them already?
<Smerdyakov>
sanxiyn, backward compatibility
<sanxiyn>
ok.
<Smerdyakov>
sanxiyn, and an attempt to please different classes of people, where the classes who want loops are deluding themselves. :-)
<sanxiyn>
heh.
<thelema>
Smerdyakov: loops are useful for the moderately-washed masses who don't have your facility with recursion.
<Smerdyakov>
thelema, OCaml is not for the moderately-washed masses.
<thelema>
ocaml isn't for the unwashed masses. There's some moderately washed people that can handle ocaml because of imperative features like loops
<Smerdyakov>
I don't care about them.
<mbishop>
It would be neat for a language to have imperative/functional modules, so that you could load up either one, and it would include FOR loops and the like in imperative (also optimize the semantics for speed with mutation, etc)
<Smerdyakov>
mbishop, what does it mean to "optimize a semantics for speed"?
<mbishop>
I mean, if you were to load up the imperative module, it would change the semantics of the language to be imperative, and since it knows you're going to be imperative, use mutation and other optimizations for speed/space saving
<sanxiyn>
Smerdyakov: Like, not forcing people to use exception when goto is sufficient.
<Smerdyakov>
mbishop, I don't see what speed or space saving has to do with semantics.
<Smerdyakov>
mbishop, I'm guessing you're really thinking about code generation.
<mbishop>
probably
<Smerdyakov>
sanxiyn, what was that in response to?
<Smerdyakov>
sanxiyn, if you think I'm advocating using exceptions, you've misunderstood me; I try to avoid exceptions as much as I can.
<sanxiyn>
Smerdyakov: "optimize for speed"?
<Smerdyakov>
If you want to maximize runtime efficiency, you shouldn't be using OCaml, anyway.
<sanxiyn>
ocamlc says:
<sanxiyn>
Warning P: this pattern-matching is not exhaustive. Here is an example of a value that is not matched: Pexp_break
<Smerdyakov>
SML has a much better optimizing compiler.
<thelema>
mbishop: I think the "imperative" optimizations are valid even on the pure language.
<sanxiyn>
Looks good so far...
johnnowak has quit []
alexyk has joined #ocaml
alexyk__ has joined #ocaml
alexyk_ has quit [Read error: 110 (Connection timed out)]
jprieur has quit [Read error: 104 (Connection reset by peer)]
alexyk has quit [Read error: 110 (Connection timed out)]
jprieur has joined #ocaml
ofaurax has joined #ocaml
evn_ has quit []
Axioplase has joined #ocaml
<hcarty>
SML also seems to, unfortunately, lack an C FFI generator like camlidl. And sugar like printf.
<sanxiyn>
Yay!
<sanxiyn>
I got my first testcase using break working!
<sanxiyn>
thelema: Hm, description says "Fork of OCaml compiler". Can you tell me more about this?
jlouis has joined #ocaml
Morphous has joined #ocaml
<thelema>
sanxiyn: there's a bunch of low-hanging fruit in ocaml. The developers are theory guys - if it's not a research project (or a bug), they don't have the time.
<thelema>
sanxiyn: so far I've been expanding the scope of the stdlib.
<thelema>
sanxiyn: I have some patches to the compiler proper as well, but worry about licensing for distributing those.
<sanxiyn>
LICENSE says that "The Compiler" is distributed under QPL.
<thelema>
it is, but github provides tarballs of the git tree for download, and QPL says that source distributions have to be original source + patches
<hcarty>
thelema: I think the core devs would probably answer your question on the mailing list if you ask there. And I am sure others would be interested in hearing about this as well.
<sanxiyn>
thelema: I guess one could maintain patch in version control and do patching in build time. But yes, that's unfortunate.
<thelema>
hcarty: what's the question?
<sanxiyn>
thelema: Whether it would be possible to relicense in order to make it easier to distribute modifications to compiler, etc.
<hcarty>
"Is it ok to add these patches, given that github does X?"
<thelema>
sanxiyn: that's part of why I'm happy using git.
jprieur has quit ["Connection reset by beer"]
<sanxiyn>
IIRC, OCaml underwent licensing change in the past, so relicensing doesn't seem to be in the realm of impossibility (unlike Linux kernel, etc.)
<thelema>
hcarty: it's clearly not, and I expect them to say "use a different git host" (I have a more complete repo on repo.or.cz with these patches)
<hcarty>
thelema: Ah, ok. I wondered about the relationship between the githib and repo.or.cz OCaml forks
<thelema>
sanxiyn: the developers get bothered about this every couple years, and their answer basically comes to "QPL works for us, if you want it under a different license, join the caml consortium.
kelaouchi has quit [Read error: 104 (Connection reset by peer)]
kelaouchi has joined #ocaml
<thelema>
hcarty: if there is a relationship, I'm not aware of one.
<thelema>
hcarty: I doubt the github people have anything to do with repo.or.cz, as the second uses very crude code and interface, and the first is extremely polished. I'd guess very different people.
<sanxiyn>
thelema: Is there a mailing list for these kinds of discussion? Or caml-list is re-used? Or there is no discussion at all?
<hcarty>
thelema: I mean that you established both repos, not the hosts
<hcarty>
sanxiyn: It generally takes place on caml-list
<sanxiyn>
ok
<thelema>
hcarty: ah. yes, I established both, with help from julien_moutinho in doing the git-cvs migration and needed fixes afterwards
wy has quit ["Leaving"]
<sanxiyn>
Is there a test suite for the compiler?
<thelema>
sanxiyn: There's some general discussion on the mailing list, but so far, this repo has been my creation.
<sanxiyn>
I can't find one.
<thelema>
sanxiyn: look in the test/ directory
kelaouchi has quit [Read error: 104 (Connection reset by peer)]
<sanxiyn>
Eh, my tarball doesn't contain test directory.
<thelema>
it's not a beautiful test suite, but there's enough automation to make it work.
<thelema>
sanxiyn: It's in the CVS checkout.
<sanxiyn>
ok
<thelema>
(also in git)
kelaouchi has joined #ocaml
Amorphous has quit [Connection timed out]
<ertai>
is github unaccessible without a login?
<thelema>
ertai: you should be able to check out any public repository. If you want to push into my repo, get an account and I'll add you.
<hcarty>
ertai: For the web interface, cloning, or writing to the repo?
<thelema>
there's a clone url and a public clone url -- public clone = git://github.com/thelema/coml.git
<ertai>
they seems to have closed the registration page, I'll be noticed when the would need more testers
<sanxiyn>
I made a typo (thelema -> thelma)
<thelema>
sanxiyn: that's one disadvantage of my nick.
<ertai>
right when having the link... but ok that works for me too
marmottine has quit [Remote closed the connection]
<ertai>
I think the kind of fork you're doing here is really border line regarding the license
<ertai>
thelema: was for you
<sanxiyn>
What do you think of F#?
<thelema>
ertai: because QPL requires patches and git works all through patches?
<sanxiyn>
thelema: Does git work through patches? (I thought it was darcs?)
<ertai>
sanxiyn: you're right
<sanxiyn>
IIRC git stores (well compressed and packed) complete copy of all revisions.
ygrek has quit [Remote closed the connection]
<ertai>
one can also say that SVN stores patches (well that's delta's)
<thelema>
I thought the "well-compressed" part reduced to diffs
<thelema>
and when I upload a pack of new changes to github, I can guarantee there's no whole tree that gets transferred
<ertai>
yes but I think what they mean by patches is you have the original + some files that will change the original
<ertai>
thelema: you're right they send some kind of patches
<thelema>
the intent of the QPL is to give people the easy ability to have just the original source, and git provides that quite well.
<sanxiyn>
"You may distribute your modifications, in a form that is separate from the Software, such as patches"
* sanxiyn
reads it again
<sanxiyn>
I'm still not sure what that means.
<thelema>
I'd call the modifications in the git tree "separate from the Software"
<ertai>
thelema: I think the QPL is here to clearly identify what's modified
<thelema>
yes, and in a git tree, the modifications are clearly separate.
<jlouis>
sanxiyn, yes. git stores the whole repository with all revisions by default
<sanxiyn>
ertai: Well, many free software licenses require that ("clearly identifying what's modified"), such as GPL.
<thelema>
jlouis: I think the question has to do with distribution, and (IANAL, but) I believe that distributing with GIT satisfies the separate modifications
<thelema>
otoh, the 'download tarball' part would violate that. I'll ask the github people again if they can disable it on my project.
<ertai>
thelema: would be good
evn_ has joined #ocaml
<ertai>
thelema: even better would a way to get the patch against the official tree
<thelema>
Okay, there's now a ticket in github's tracker - we'll see how quickly they move.
<gildor>
thelema: why do you call you (illegal) fork of ocaml, ocaml-community
<gildor>
... you the only one to commit since 1 month
<gildor>
(moreover you are redoing extlib)
<thelema>
gildor: the fork isn't illegal - the repo at github is.
<sanxiyn>
gildor: I guess the name represent the wish.
<gildor>
QPL on certain part of the compiler prevent fork
<thelema>
gildor: I'm not coding everything committed - lots of it comes directly from extlib and other 'extended ocaml stdlib' sources
<gildor>
you are also syncrhonising from the CVS branch
<thelema>
err, the fork at github would be if any QPL code were modified.
<thelema>
no modified QPL code exists at github.
<gildor>
this is really totally borderline
<sanxiyn>
gildor: I thought I may distribute my modifications in a form that is separate, etc.
<thelema>
gildor: as to only me committing, I've kept this private for a while (wanting to make a proper release before trying to get others to join this effort)
<gildor>
if INRIA were trolltech, you should be already on trial
<sanxiyn>
gildor: Well, my understanding is thelema's repository so far has only modifications to LGPL part.
<gildor>
why don't you enhance extlib rather than forking the whole ocaml distrib
<gildor>
even if is only modifying LGPL part
<gildor>
modification are not enough clearly distinct
<thelema>
gildor: because many/most people don't use extlib precisely because it's not standard.
<gildor>
exactly the same reason why people won't use an unofficial ocaml fork
<sanxiyn>
gildor: By the way, can you tell me why there isn't break/continue in OCaml?
ofaurax has quit ["Leaving"]
<sanxiyn>
It doesn't seem to be too difficult to add.
<gildor>
... or maybe you have some kind of superior argument which will explain to people that
<gildor>
"extlib was not standard but forking ocaml is far better"
<thelema>
but if the community can get behind a fork (which they may if it has enough advantages), then I may solve the problem of INRIA's maintainership being conservative.
<gildor>
sanxiyn: why not
<gildor>
sanxiyn: INRIA choice
<sanxiyn>
I see.
<gildor>
thelema: being conservative is an avantage for many things
<sanxiyn>
I guess I can use my patch myself and update when new release comes out.
<sanxiyn>
Thank you for telling me that it is not an oversight.
<thelema>
gildor: and being open source (even QPL) allows forks.
<gildor>
sanxiyn: or try to submit your patch to INRIA and defend it with good argument
<sanxiyn>
gildor: You didn't give any argument. Your argument was "why not".
<sanxiyn>
I interpreted that as that chance of acceptance is slim.
<gildor>
sanxiyn: why not-> this choice is not better than the other
<sanxiyn>
It's open source, so I am entitled to do private fork.
<gildor>
sanxiyn: private fork -> ok
<sanxiyn>
patch distribution -> also ok
<jlouis>
heh, FreeBSD ports still runs 3.09.3
bluestorm has quit ["Konversation terminated!"]
<gildor>
sanxiyn: publishing a git tree which can be download (using a soft. which is called git) = publication of a QPL fork
<Yoric[DT]>
'night everyone
Yoric[DT] has quit ["Ex-Chat"]
<sanxiyn>
gildor: ok, I'm not one who publishes git tree :)
<thelema>
gildor: and in that git tree the modifications are separate from the Software.
<gildor>
sanxiyn: i have nothing again a patch, even published against ocaml
<sanxiyn>
thelema: Well, that's rather ambigous to me.
<gildor>
many great things has come from this kind of patch
<gildor>
gildor: a tarball is a gzipped of file which are clearly separated in the tar
<gildor>
thelema: i mean
<sanxiyn>
Ok, I guess I should prepare some code samples that using break and continue improve code a lot, and mail to the list.
<gildor>
your argument is flawed
<thelema>
gildor: yes, but the modifications aren't separate from the Software.
netx has quit [Read error: 104 (Connection reset by peer)]
<sanxiyn>
I thought utility of break/continue was self-evident, but apparently not.
<thelema>
but in the git tree, they are.
<gildor>
sanxiyn: very good way of doing a great patch
<sanxiyn>
ok bye! thank you all!
sanxiyn has quit ["전 이만 갑니다."]
<thelema>
If you'd like, I'll ask the INRIAites about git+qpl on caml-list
<gildor>
thelema: if you only publish patch that you made, the answer is yes
evn_ has quit []
<jlouis>
I actually prefer a pretty conservative OCaml distribution
<gildor>
but you publish patch from Xleroy and Doligez
<thelema>
jlouis: and I encourage you to stick with INRIA's distribution. There's many who want a bigger stdlib (me among them), and I'm starting this project for us.
<jlouis>
I hate languages that keep on changing all the time. Changes should merit themselves.
<gildor>
jlouis: i agree, being conservative is a good thing... i do prefer it
<gildor>
thelema: extlib is a good place to extend stdlib
<jlouis>
and that includes the standard library. I am sure the Ocaml stdlib could be improved much
<thelema>
if INRIA insists on a name change, I even have a new name for it: sdrom (subjective dromedary)
<gildor>
thelema: BTW, if you only want to fork the stdlib, then only fork this part... not the rest of the compiler
<gildor>
this is not complicated to just fork stdlib (and fully legal)
<thelema>
gildor: I pretty much have to keep a complete tree to keep up to date with INRIA cvs.
<gildor>
thelema: keeping uptodate only patches from stdlib is not that complicated also...
<gildor>
the root of the CVS has just to be ocaml/stdlib, rather than ocaml
<thelema>
One part of my vision for community-ocaml includes standard camlp4
<thelema>
which would require integration around the compiler part too.
<gildor>
if you git tree is to only change stdlib, this is a little bit overkilling to publish ocaml in a whole
<thelema>
overkill, maybe. easy for me - yes.
<gildor>
thelema: untrue, take a look at camlp5
<gildor>
you can maintain a camlp4 outside ocaml
<thelema>
but why would I want to?
<thelema>
biab
evn_ has joined #ocaml
<gildor>
thelema: just saying that you can find way not to publish a fork of ocaml
<gildor>
thelema: trying to make your work outside of ocaml, give you a chance to make proposition to INRIA with better solution
<gildor>
thelema: forking = closing the door of your contribution to INRIA OCaml
<gildor>
thelema: if your contribution worth it, it is really a waste of time
jsk has quit [Connection timed out]
evn_ has left #ocaml []
<thelema>
gildor: INRIA has quite clearly for many years closed the door to their maintaining any community-contributed code. I'm trying to provide a place for (at least some of) that code to go.
<thelema>
gildor: If you want to bring this up on caml-list, go ahead, otherwise I will when I get back - gotta go now.
<thelema>
back in a few hours.
<gildor>
thelema: i won't bring anyting anywhere, i just hope that you will restrict your git repo to only what you intend to change / filtering what you cannot change
<gildor>
thelema: which will stop any misinterpretation of what you are doing -- and bring you the help of people that don't want to fork
unigue_ has left #ocaml []
mwc has quit ["Leaving"]
ita has quit [Read error: 104 (Connection reset by peer)]
ita has joined #ocaml
hkBst has quit ["Konversation terminated!"]
mwc has joined #ocaml
<palomer_>
thelema, do you know how to create a Gdk.color?