struktured has quit [Read error: 110 (Connection timed out)]
seafood has joined #ocaml
seafood has quit []
Mr_Awesome has quit [Read error: 110 (Connection timed out)]
jeddhaberstro has quit []
snhmib has quit ["Good riddance!"]
kilimanjaro has joined #ocaml
Olathe has joined #ocaml
Olathe has left #ocaml []
SamB_XP has joined #ocaml
SamB_XP has left #ocaml []
threeve has joined #ocaml
jessicah has left #ocaml []
struktured_ is now known as struktured
threeve has quit []
struktured has quit [Connection timed out]
struktured has joined #ocaml
johnnowak has joined #ocaml
Mr_Awesome has joined #ocaml
rby has joined #ocaml
Yoric[DT] has joined #ocaml
<Yoric[DT]>
hi
<kilimanjaro>
hello
Snark has joined #ocaml
mishok13 has joined #ocaml
filp has joined #ocaml
filp has quit [Client Quit]
<Yoric[DT]>
Does anyone have an example camlp4 extension which makes use of type-conv?
<tsuyoshi>
uhh.. don't bin-prot and sexp use it?
<Yoric[DT]>
Yes.
<Yoric[DT]>
I was looking for something smaller :)
<tsuyoshi>
oh
Palace_Chan has quit ["Palace goes to sleep"]
rby has quit ["This computer has gone to sleep"]
ozy` has joined #ocaml
<Yoric[DT]>
Well, time to make data structures sexplib-compliant...
mfp has quit [Read error: 104 (Connection reset by peer)]
Camarade_Tux has joined #ocaml
mfp has joined #ocaml
Snark has quit ["Ex-Chat"]
johnnowak has quit []
marmotine has joined #ocaml
Associat0r has joined #ocaml
rby has joined #ocaml
rby has quit [Remote closed the connection]
rby has joined #ocaml
<rwmjones_>
is there a good tutorial for gallina?
<rwmjones_>
or indeed a bad tutorial, any tutorial would be better than none
marmotine has quit [Read error: 113 (No route to host)]
marmotine has joined #ocaml
OChameau has joined #ocaml
<Yoric[DT]>
thelema: ping
<mattam>
rwmjones_: you mean Coq? There's the course notes by Chlipala and the ones by B. Pierce which are the most recent attempts at teaching Coq available on the web I think.
<rwmjones_>
hmmm 50 quid
yangsx has quit [Read error: 110 (Connection timed out)]
<Camarade_Tux>
hmm, if you were to use a C parser, what would it be ? I want to automate the creation of bindings for an interface that will evolve.
<flux>
camarade_tux, it could be elsa, or you could just use gcc-xml
<flux>
apparently rwmjones actually has some experience on the subject?
<rwmjones_>
Camarade_Tux, I've not found a good way to do this, so let me know ... we ended up automating a lot of the libvirt bindings, but basically its a giant custom perl script
<Yoric[DT]>
Nooooooooooooo
<Yoric[DT]>
Sorry.
<Camarade_Tux>
rwmjones_, I used some automating for binding webkit-gtk but it was a sed script (hopefully webkit-gtk has a nicely-formatted header file which seems to be made on purpose for this)
* Yoric[DT]
depends on Camomile 0.7.x for Batteries and just discovered that the version packaged in GODI is 0.6.x.
<flux>
camarade_tux, perhaps you can check out what the qt-binding-guys have done (osp)
<Camarade_Tux>
also, I checked flux's suggestion and elsa is not what I'm looking for, especially I'd have to reparse elsa's format which is even weirder than C
<Yoric[DT]>
Even Debian *stable* has 0.7.x.
<rwmjones_>
Camarade_Tux, there is definitely scope for a project that binds a large number of C interfaces automatically ... eg take all the C libraries in a Linux distro such as Debian or Fedora and try to automate high quality bindings to them (and not just for OCaml, but for a wide range of languages) ... a sort of competitor to .net
<Yoric[DT]>
Well, I guess I'm good to package Camomile myself...
<Camarade_Tux>
flux, yeah, I've read they were binding gcc-xml, definitely going to check
<flux>
camarade_tux, btw, there's also swig :)
<Camarade_Tux>
swig understood anything to swig...
<rwmjones_>
swig sucks too ... so does camlidl
<Camarade_Tux>
s/swig//
<flux>
rwmjones_, but what the interfaces actually tells you is very limited..
<rwmjones_>
flux, not so ... with an open source distro you can parse the source of thelibraries to determine semantics
* Yoric[DT]
will take a break.
* rwmjones_
didn't say it was easy
<Camarade_Tux>
Yoric[DT], we should definitely update the godi package, I've had the same problem
<flux>
rwmjones_, now that would be something :)
* Yoric[DT]
notices that even Feitsy has 0.7.x.
<Yoric[DT]>
Camarade_Tux: I'll try and do that this afternoon.
<flux>
rwmjones_, although, not necessarily impossible
<Yoric[DT]>
It will be a nice opportunity to test my GODI account.
<Camarade_Tux>
Yoric[DT], great :)
<flux>
rwmjones_, for example the interface builder could make "guesses" about the interface (is "a" a string?) and then statically attempt to prove them..
<rwmjones_>
flux, there is a clearly defined target (all C libraries in Debian), you have source, it's a numbers game ... probably 50% of the C calls would be in the 'easy' category
<rwmjones_>
& you go from there
<rwmjones_>
nice research project for some student ...
<rwmjones_>
easily measurable goals anyway :-)
* Camarade_Tux
is going to think about a maybe new C parser but he first needs to go an pay his rent
<Camarade_Tux>
(simple C parser, just for the interfaces of course)
<rwmjones_>
their end of year score is just the % of C calls they implement correctly
<flux>
camarade_tux, I know the itch, but perhaps you still should just go and build on someone else's work :)
<rwmjones_>
Camarade_Tux, parsing C is hard ... look at the stuff written about it by the author of CIL
<Camarade_Tux>
flux, of course I'll see but I can think about it while I'm trying to find a bank somewhere, I have to pay this month cash...
<flux>
camarade_tux, can't pay in code? bad contract..
<flux>
forgot about cil
<Camarade_Tux>
flux, yesterday I've been given my "htip/tcp" address, don't even think you could speak about code ;p
<flux>
rwmjones_, so how come you didn't end up using cil?
<Camarade_Tux>
rwmjones_, my sed script managed to get good results but it only parsed the header, I think it is really doable if you don't try to read the content of functions (and just crash on global variables you encounter, or maybe face-stab the C code author and then crash)
<flux>
sed/perl/scotchtape-approach is fine if you're trying to convert one project
<flux>
but I don't think it'll fly far if you want it to be generic :)
<rwmjones_>
flux, the libvirt bindings are narrowly defined single project ... would make sense to use CIL or Haskell's C parser if I was going to bind everything in Debian (or Fedora)
<Camarade_Tux>
yeah of course, for webkit-gtk, I relied on the header being indented in a certain way
<rwmjones_>
the perl generator doesn't attempt to parse anything though
<Camarade_Tux>
and even worse, (int a, int b) would be recognized but not (int a,int b) ;)
<Yoric[DT]>
Well, I guess I can try and find out how to upload it, now.
<Guest9596>
Yoric[DT]: You know batteries included?
<Yoric[DT]>
Er... yes.
<Guest9596>
So, you're not going to fork projects and diverge from their upstream, right?
<Yoric[DT]>
Why?
* Camarade_Tux
has troubles understanding...
<Yoric[DT]>
Guest9596: not if we can avoid it.
<Guest9596>
Yoric[DT]: But would you consider Batteries becoming the upstream for new projects?
<Yoric[DT]>
The only project we have forked for the moment is extlib, because they didn't have the time/manpower/willpower to review our patches.
<Guest9596>
Yoric[DT]: Fair enough.
<Yoric[DT]>
Sure.
<Yoric[DT]>
Can you detail, though?
<Guest9596>
Yoric[DT]: I am considering open sourcing all of the code to Smoke and Presenta.
<Yoric[DT]>
Oh, you're John Harrop under a new disguise, are you?
<Guest9596>
Yoric[DT]: Yeah. Sorry. :-)
<Guest9596>
Yoric[DT]: I know nothing of the IRC...
<Yoric[DT]>
/nick John
<Yoric[DT]>
(to take name "John")
<Guest9596>
Yoric[DT]: It says "Nick already taken"
<Guest9596>
brb
<Yoric[DT]>
Well, I guess you need to choose another, then:)
<Camarade_Tux>
should jdh30 be available ;)
<Camarade_Tux>
s/should/shouldn't
<Camarade_Tux>
ok, if Camarade_Tux__ connects in 13.2 seconds, SysRq+k will have worked ;p
<Camarade_Tux>
mooo, doesn't work :'( (on the other hand I've mistriously lost the ability to change the screen backlight last week so I'll see again with 2.6.27)
itewsh has joined #ocaml
<Yoric[DT]>
Gasp, upload doesn't seem to work :/
marmotine has quit [Read error: 113 (No route to host)]
<gildor>
Yoric[DT]: upload to forge.ocamlcore.org ?
<Yoric[DT]>
No, to GODI.
<Yoric[DT]>
It's frustrating.
Guest9596 is now known as JonDHarrop
<JonDHarrop>
hey, it worked.
<JonDHarrop>
Sorry for the distraction...
JonDHarrop is now known as jdh30
<jdh30>
Yoric[DT]: Anyway, I was just wondering if you would like to adopt open source projects as well as repackage them.
jdh30 is now known as Guest44162
<Yoric[DT]>
Frankly, it's tempting but I don't think I have the resources for that yet.
<Yoric[DT]>
After the first release of Batteries, I'll send a call for participants.
<Guest44162>
Yoric[DT]: Ok, NP>
<Guest44162>
.
<Yoric[DT]>
If enough people answer, it might be possible.
rby has joined #ocaml
<Yoric[DT]>
But I think I'd be stretching myself too thin if I accepted right now.
<Guest44162>
Yoric[DT]: Will batteries fill out the standard library and, if so, how will it replace it?
<Guest44162>
Yoric[DT]: That's fine.
<Guest44162>
Yoric[DT]: I can just put the code up on our site to start with.
<Yoric[DT]>
I think that would be a good start.
<Yoric[DT]>
Smoke looked quite good.
<Yoric[DT]>
(I haven't checked Presenta)
<Guest44162>
Yoric[DT]: I wrote an OCaml Journal article about a mini vector graphics engine that went down well with readers so I'd like to do more on that.
<Guest44162>
Yoric[DT]: Presenta was our first commercial software product written in OCaml and it was a failure because we were unable to get the binaries to run reliably on customers' machines.
<Guest44162>
Yoric[DT]: They just segfaulted.
<Yoric[DT]>
Yeah, I already had difficulties with your Smoke binaries.
<Yoric[DT]>
(unrelated question: does anyone around here have write access to the GODI svn?)
<Guest44162>
Yoric[DT]: Really!? Oh, do you mean the native code binariesa?
<Guest44162>
Yoric[DT]: Does bytecode work ok?
<Yoric[DT]>
I don't remember.
<Yoric[DT]>
I tried that when you first announced Smoke, that was some time ago already.
<Guest44162>
I think OCaml really needs a JIT compiler for its bytecode. That would solve all of these problems...
<Yoric[DT]>
Yeah, well, that's partly what I'm asking students to write.
<Yoric[DT]>
I have no idea about the level of these students, though.
<Camarade_Tux>
Yoric[DT], you should try the godi-list or mail Gerd directly
<Guest44162>
Yoric[DT]: Ok. Smoke is still one of our most accessed web pages, more popular than several of our products. But it never sold a single copy.
<Yoric[DT]>
Camarade_Tux: already tried, he's in vacation :)
<Yoric[DT]>
Guest44162: :?
<Yoric[DT]>
Guest44162: :/
<Yoric[DT]>
That's a shame.
<Guest44162>
Oh
Guest44162 is now known as JonDHarrop
<JonDHarrop>
How's that/
<Camarade_Tux>
Oktoberfest for sure ;p
<Yoric[DT]>
?
<Yoric[DT]>
:)
* Camarade_Tux
won't stand a 1s ping much longer...
<Yoric[DT]>
JonDHarrop: I suppose that's related to binary compatibility problems.
<Yoric[DT]>
I'm not sure OCaml bytecode is much more reliable, though.
<JonDHarrop>
Yoric[DT]: Yes and no. Some of the problems were probably due to poor quality OpenGL drivers (e.g. ATi's).
<Yoric[DT]>
As the model is "change one module, recompile the whole project".
<JonDHarrop>
Yoric[DT]: I found OCaml's bytecode to be vastly more reliable.
<Yoric[DT]>
ok
<JonDHarrop>
Yoric[DT]: When running the same binary across a range of different Linuxs.
<JonDHarrop>
Yoric[DT]: That model sucks.
<Camarade_Tux>
(* to be fair, nvidia is probably more annoying with opengl as its GL.so will only work with the "nvidia" module, not vesa or anything else *)
<JonDHarrop>
Yoric[DT]: Functorizing entire libraries over their dependencies sounds like a decent workaround but it will be seriously tedious, adversely impact usability and incur performance penalties that could be extremely severe.
<Yoric[DT]>
JonDHarrop: let's say that it's not very closed-source friendly :)
<Yoric[DT]>
I've seen other languages taking that direction, too.
<Yoric[DT]>
For some languages, it seems the only way of performing safety analysis.
<JonDHarrop>
Yoric[DT]: Well, it isn't very open source friendly either. Ask the Debian package maintainers how much time they waste recompiling libraries whenever anyone releases a minor update to any core library.
<Yoric[DT]>
Yeah, I remember a discussion on this subject.
<Yoric[DT]>
And yes, I concur it's annoying.
<JonDHarrop>
Yoric[DT]: I wish OCaml was more commerce friendly....
<Yoric[DT]>
I understand.
<JonDHarrop>
Yoric[DT]: I wonder if that might ever happen....
<Yoric[DT]>
Frankly, I doubt it.
<Camarade_Tux>
hopefully ocaml compiles quite quickly so you can recompile everything in a matter of hours (2-3 hours) but still it takes time of course
<JonDHarrop>
Yoric[DT]: Yeah, me too. :-(
<Yoric[DT]>
Weren't you interested in re-implementing OCaml, a few months ago?
<JonDHarrop>
Camarade_Tux: OCaml already has enough libraries that it takes them days to recompile.
<Yoric[DT]>
(that is, a OCaml -> LLVM or Mono)
<JonDHarrop>
Yoric[DT]: Yes, I am still very interested in that.
* Yoric[DT]
ponders the subject.
<JonDHarrop>
Yoric[DT]: Mono 2.0 did not get the real (accurate) GC as previously promised 3 years ago which basically rules it out.
<Yoric[DT]>
I won't be able to participate to a SoC next summer for personal reasons.
<JonDHarrop>
LLVM still kicks ass but you need to write your own run time.
<Camarade_Tux>
JonDHarrop, I don't compile everything but a nice set for my livecd thing and it's done quickly
<Yoric[DT]>
But I'm willing to try and participate to the start/end of the SoC and to the preparation.
<JonDHarrop>
Camarade_Tux: Sure, that would work.
<JonDHarrop>
Camarade_Tux: This only causes problems for distros and commerce.
<JonDHarrop>
Yoric[DT]: You mean you'll try to get some students to work on this kind of thing?
<Yoric[DT]>
Would you be interested in co-posting a subject for a Google SoC or a Jane Street Soc on this kind of thing?
<JonDHarrop>
Yoric[DT]: There are lots of potential benefits to it. Free polymorphism would be fantastic.
<JonDHarrop>
Yoric[DT]: What exactly would that entail beyond adding my name to a document? ;-)
<Yoric[DT]>
I'm not sure.
<Yoric[DT]>
Helping them, I guess :)
<JonDHarrop>
Yoric[DT]: Sounds great. ;-)
<Yoric[DT]>
(well, answering their questions)
<JonDHarrop>
Yoric[DT]: Well, I can try but I am a physicist and not a compiler writing comp-sci.
<JonDHarrop>
Yoric[DT]: The guise is wearing thin though... :-)
<Yoric[DT]>
:)
<JonDHarrop>
That's an excellent idea though.
<Yoric[DT]>
Well, we'll both need to do some reading by this summer, then :)
<JonDHarrop>
Let's brainstorm on what project goals might be.
<JonDHarrop>
When you say this summer, my window tells me you mean next summer (2009)? :-)
<JonDHarrop>
1. Ahead of time generation of type specialized code.
<JonDHarrop>
Actually, before doing this, what about implementing a new language from scratch. Could they just implement a mini-ML with first-class functions via LLVM?
<JonDHarrop>
I mean, is it really worth reusing any of the current OCaml implementation?
marmotine has joined #ocaml
<jlouis>
if you want more than mini-ml, it is probably faster to hammer on an existing implementation
<Yoric[DT]>
Yep.
<Yoric[DT]>
Well, to be frank, I'd say
<JonDHarrop>
jlouis: Sure but does that mean OCamls?
<Yoric[DT]>
1. A compiler that works.
<Yoric[DT]>
Language design is yet another problem.
<Yoric[DT]>
I don't think we can ask anyone to design *and implement* a new language over the summer.
<Yoric[DT]>
The point of reimplementing an existing language is that, well, most problems have already been solved.
<Yoric[DT]>
Plus they could reuse a number of tools for faster testing.
<Yoric[DT]>
(I'm thinking Camlp4, which already knows the AST of OCaml)
<Yoric[DT]>
No, that doesn't necessarily mean OCaml.
<JonDHarrop>
Yoric[DT]: Absolutely. I wasn't suggesting designing a new language but, rather, stripping down OCaml.
<JonDHarrop>
jlouis was working on MosML, IIRC.
<jlouis>
still is, though progress is slow. I have 8 reports to correct the next weeks
<Smerdyakov>
I imagine it's almost trivial to implement an ML language by compilation to an expressive enough backend. I don't know if LLVM is that backend.
<JonDHarrop>
Yoric[DT]: Let's say they start by stripping out the OCaml grammar from Camlp4 to include only core features (no functors, no objects, no types beyond ML's etc.) and then implement that.
<jlouis>
Smerdyakov, LLVMs IR is a typed assembler + a little
<JonDHarrop>
Smerdyakov: You need a run time.
<jlouis>
I don't know if you regard that as expressive
<Yoric[DT]>
JonDHarrop: that's a good start.
<JonDHarrop>
They would need to define a run-time representation of a closure.
<Smerdyakov>
JonDHarrop, LLVM doesn't provide one?
<jlouis>
LLVM provides ocamls GC
<Yoric[DT]>
Smerdyakov: I think HLVM, the companion stuff, provides closures.
<JonDHarrop>
Smerdyakov: Not really, no. They provide examples that don't work and a GC API that is essentially untested.
<JonDHarrop>
Yoric[DT]: But HLVM is dead, IIRC.
jeddhaberstro has joined #ocaml
<Yoric[DT]>
Oh, is it?
<JonDHarrop>
Yoric[DT]: Or "was never alive".
<Yoric[DT]>
ok
<Smerdyakov>
I think a lot of people hype up the difficulty of implementing a new programming language completely from scratch.
<Yoric[DT]>
Mmmmhhhhh......
<JonDHarrop>
Yoric[DT]: That's the impression I got. The nearest living relative is PyPy which is interesting but written by people who actually like Python.
<Smerdyakov>
Most any PhD student in programming languages can do a reasonable job with a month of full-time work.
<JonDHarrop>
Smerdyakov: Yes and no. We want multicore capability.
<Yoric[DT]>
Do we ? :)
<JonDHarrop>
I think this would make a great Masters project.
<JonDHarrop>
You can spin it as an ML aimed at technical computing. Only OCaml has come close to that before, with its awesome AMD64 code gen for numerical code, but it lacks lots of basic and valuable optimizations like bounds checks.
<Yoric[DT]>
I'm wondering what would be most important in a new implementation of a functional (or nearly-functional) language.
<Yoric[DT]>
Bounds checks are nice but they're a project by themselves (if you don't want to use annotations).
<jlouis>
Dependent types :P
<Yoric[DT]>
Now, annotations are a distinct possibility.
<Yoric[DT]>
jlouis: yeah, with inference :)
<jlouis>
Substructural types, hehe
<JonDHarrop>
This is a major strength of F# but I would also like to emphasize the importance of FFI by baking in C-compatible internal representations as much as possible. OCaml has serious FFI issues...
<Smerdyakov>
I think Coq/Ynot is the obvious winner for a "general purpose" language.
<jlouis>
Yoric[DT], with inference and \Omega of course ;)
<Smerdyakov>
Almost everything should be in DSLs, though.
<Yoric[DT]>
jlouis: of course :)
<Yoric[DT]>
Very fast DSLs would be a nice thing.
<Yoric[DT]>
Which leads us to staged compilation.
<Smerdyakov>
I got one. :)
<JonDHarrop>
Yoric[DT]: I think we can make a strong case for building an ML implementation with different emphasis to traditional implementations that make it ideally suited to technical computing, where many people are turning to ML.
Amorphous has quit [Read error: 104 (Connection reset by peer)]
<JonDHarrop>
Yoric[DT]: LLVM already does lots of nice optimizations for you. Bounds checks may well be one...
<Yoric[DT]>
I'm sure that has already been done, but what about a compiler with programmable optimizations?
<Camarade_Tux>
JonDHarrop, from the three or foud bindings I've made, I've not had much troubles with ocaml's FFI, could you give some examples ? (just curious)
<jlouis>
bounds checks? We'll just prove the crap inside bounds for code that needs to be fast.
<Smerdyakov>
Yoric[DT], GHC, to an extent
<Yoric[DT]>
Smerdyakov: does it?
<Smerdyakov>
Yoric[DT], yes. You can add arbitrary algebraic rewrite rules.
* Yoric[DT]
seems to remember seeing a SML compiler with this thing.
<jlouis>
Yoric[DT], yes. You can tell it about rewrites
<JonDHarrop>
Yoric[DT]: I'm really not sure that staged compilation => fast DSLs. At least, I tried and failed to write some decent compilers using MetaOCaml.
<Yoric[DT]>
Smerdyakov: oh, I thought these were just comments.
<Yoric[DT]>
Smerdyakov: (I *think* I've seen these things in code)
<Smerdyakov>
JonDHarrop, what makes you think MetaOCaml is the write way to write a good optimizing compiler?
<jlouis>
Yoric[DT], yes, but GHC can understand those comments
<Yoric[DT]>
Well, that's essentially what I was thinking about.
<Smerdyakov>
s/write/right
<JonDHarrop>
Camarade_Tux: Look at the state of Qt, FFTW and OpenGL bindings in OCaml.
<Yoric[DT]>
Smerdyakov: well, it's a nice place to start investigating, at last.
<Smerdyakov>
Yoric[DT], MetaOCaml? I strongly disagree.
<JonDHarrop>
Smerdyakov: I was referring to staged compilation for implementing fast DSLs.
<Yoric[DT]>
I have close-to-zero experience with MetaOCaml, so I won't argue.
<Yoric[DT]>
Smerdyakov: care to tell us why?
<Smerdyakov>
Ur/Web is just an expressive type theory with lots of inlining in the compiler. No concept of staging annotations.
<jlouis>
I'd rather throw more type theory at the problem than staging as well
* Yoric[DT]
knows that smells in his code.
<Camarade_Tux>
JonDHarrop, don't know about fftw but Qt and OpenGL are probably hard things to bind, for instance opengl seems to constantly use mutation which simply hurts when doing ocaml
* Yoric[DT]
feels it smells like cyclic dependencies.
<Smerdyakov>
Yoric[DT], what do you mean, in practical terms?
<JonDHarrop>
Camarade_Tux: Qt is inherently hard to bind because it is a customized C++ dialect but there is no excuse for bad FFTW and OpenGL bindings.
<JonDHarrop>
Camarade_Tux: They are just C code.
<Yoric[DT]>
Smerdyakov: sorry, I'm lost in the conversation.
<Yoric[DT]>
And the code I'm currently trying to compile surely has cyclic dependencies.
<JonDHarrop>
Camarade_Tux: LablGL reimplements low-level arrays in the form of Raw arrays when Bigarrays were later bred for that purpose but they are both completely unnecessary.
<JonDHarrop>
brb
<Camarade_Tux>
JonDHarrop, I've had troubles with installing lablgl so I've not really tried it
rwmjones_ has quit ["Closed connection"]
<Camarade_Tux>
JonDHarrop, for opengl... I wrote a small app yesterday with florent monnier's bindings and a code like glBegin WHATEVER;\n glVertex3 ...\n glVertex3 ...\nglEnd (); simply hurts or at least surprises, I've just talked to somebody using opengl from C, he told me it was the same in C
<Camarade_Tux>
it rather looks like you can't mix ocaml and opengl that easily and that you couldn't mix haskell and opengl easily either
<Camarade_Tux>
(haskell and opengl would probably be a sure way to commit suicide in fact)
itewsh has quit [Read error: 60 (Operation timed out)]
itewsh has joined #ocaml
<Yoric[DT]>
Yeah, cyclic dependency removed.
<JonDHarrop>
Camarade_Tux: OCaml+OpenGL is mediocre but only due to limitations of OCaml itself.
<JonDHarrop>
Camarade_Tux: If OCaml had C compatible types then it would be a lot easier to write decent bindings to OpenGL but OCaml doesn't even have float32 or int16...
<Yoric[DT]>
(and Batteries Included just gained support for Sexplib)
<JonDHarrop>
Camarade_Tux: Let alone C compatible int arrays and so forth.
<Camarade_Tux>
JonDHarrop, well, can't say more, I'm not really used to opengl, may it be from C or from ocaml
<JonDHarrop>
A new ML implementation with these features would greatly improve interoperability which, IMHO, has become a really serious problem for OCaml and is stifling its growth.
<Camarade_Tux>
JonDHarrop, however I agree some types for interoperability (no matter what the compiler does with them) would be good
<Yoric[DT]>
What if OCaml just defined modules Float32, Int16, CArray, etc.
<Yoric[DT]>
Would it be better?
<JonDHarrop>
Camarade_Tux: I've done a lot of OpenGL, both with C/C++ and with OCaml (and XNA/WPF with F#).
<Yoric[DT]>
(assuming that were possible)
* Smerdyakov
tells interoperability to go take a hike. :)
<Yoric[DT]>
Well, the truth is that .Net makes wonders for interoperability.
<Yoric[DT]>
And LLVM could probably do more or less as much.
<JonDHarrop>
Yoric[DT]: That can go some way to fixing the problem but you forego uniformity (i.e. the ability to factor your code), performance and simplicity.
<JonDHarrop>
For example, you could implement a Int32Array module that provides an unboxed array of 32-bit ints but accesses to it would probably go via Int32 which is very slow in OCaml.
Camarade_Tux has left #ocaml []
Camarade_Tux has joined #ocaml
<Yoric[DT]>
The other possibility would probably be to somehow have the compiler translate OCaml-friendly types to C-friendly types when crossing boundaries.
<JonDHarrop>
Incidentally, I thought it was interesting that someone brought up random number generators on the caml-list recently. This is one application where OCaml fares extremely badly.
<Yoric[DT]>
Doesn't look too hard.
<JonDHarrop>
Yoric[DT]: You're still left with poor performance. The idea of C-compatible internal representations in your new ML is that you evade having to do any marshalling/copying at all in the FFI.
<Yoric[DT]>
I agree that it's ideal.
<Yoric[DT]>
But now, how do you manage garbage-collection?
<JonDHarrop>
OCaml is about 3x slower than most other languages at both the MonteCarlo part of SciMark2 and Mersenne Twister.
<JonDHarrop>
Yoric[DT]: That's just it: The kinds of applications I want an ML for don't require a high-performance GC.
<JonDHarrop>
Yoric[DT]: You could even start with reference counting just to get the ball rolling ASAP. After all Mathematica is reference counted...
<JonDHarrop>
Yoric[DT]: A naive stop-the-world GC would be the next stop.
Amorphous has joined #ocaml
<JonDHarrop>
Yoric[DT]: A performant fully concurrent GC is beyond feasibility, IMHO.
<Yoric[DT]>
Then perhaps GC is the wrong option.
<Yoric[DT]>
Perhaps region-based memory (or even resources) management is the way to go.
<Yoric[DT]>
You can do quite nice things with regions.
<JonDHarrop>
Yoric[DT]: But the language implementation could still become extremely useful and, I think, could see rapid adoption.
<Smerdyakov>
JonDHarrop, I think it's easier if you develop your GC with dependent types/classical theorem proving at each stage.
<JonDHarrop>
Smerdyakov: Where are the success stories?
<JonDHarrop>
Smerdyakov: AFAIK, only Sun and MS have managed to do this.
<Yoric[DT]>
Plus, unless I'm mistaken, regions + effects can provide a rather uniform mechanism for garbage-collection, more generally resource management and exceptions.
<JonDHarrop>
Smerdyakov: IBM's JVM is further down the list with poor performance. GHC 6.8 is much further down still with awful performance. And OCaml isn't even on the list.
<Smerdyakov>
JonDHarrop, I'm sure we'll have something to suggest in the Ynot project. :)
<JonDHarrop>
Yoric[DT]: Does the programmer have to do anything?
<JonDHarrop>
Smerdyakov: :-)
<JonDHarrop>
Smerdyakov: I think the Mono team could follow your advice but it is too ambitious for this!
grigorij has joined #ocaml
<Yoric[DT]>
JonDHarrop: I'm trying to remember.
<Yoric[DT]>
If I recall correctly, you can have full inference.
<JonDHarrop>
Yoric[DT]: What are the limitations of regions? I thought MLKit was the only ML to have used them and they decided it was not a good idea...
<Yoric[DT]>
Ah no, you have to declare your regions.
<Yoric[DT]>
Did they decide so?
<JonDHarrop>
Yoric[DT]: Ah, that's no good.
<Yoric[DT]>
I remember that error messages are somewhat unreadable.
<JonDHarrop>
Yoric[DT]: I think that's what Torben said.
<Yoric[DT]>
There's a Haskell compiler with regions, now.
<JonDHarrop>
Yoric[DT]: Oh.
<Yoric[DT]>
Can't remember the name, though.
<JonDHarrop>
Yoric[DT]: That nobody uses. ;-)
<JonDHarrop>
GHC? ;-)
<Yoric[DT]>
:)
<JonDHarrop>
Ok.
<JonDHarrop>
Back to brainstorming and then I'm off.
<JonDHarrop>
They could strip down the Camlp4 grammar for OCaml and write the whole compiler in OCaml using LLVM for code generation.
<JonDHarrop>
Forget standalone compilation and just run everything through a JIT-compiled top-level.
<JonDHarrop>
Type specialized code is emitted as polymorphism is used, removing the need for a uniform representation and the performance cost of polymorphism in OCaml.
Snark has quit ["Ex-Chat"]
<JonDHarrop>
Run-time representation of most types is trivial. Closures are the only exception and they can be done as simply as possible.
<JonDHarrop>
Oh, and you can do that nice thing that Kaleidoscope does where C functions can be declared and called directly from the target language. No more C stubs...
<JonDHarrop>
I think that is feasible for a Masters project. What do you think?
<Yoric[DT]>
« Type specialized code is emitted as polymorphism is used »: do you mean compile-time or run-time?
<JonDHarrop>
I mean JIT-time.
<Yoric[DT]>
ok
<JonDHarrop>
Heh, sounds like something off the matrix. :-)
<Yoric[DT]>
:)
<Yoric[DT]>
Actually, come to think about it, I guess I need to read more about V8 and TraceMonkey.
<Yoric[DT]>
Perhaps something can come from that direction, too.
<Yoric[DT]>
Although this might be the job of LLVM rather than that of the compiler.
<Yoric[DT]>
(I meant the "adaptative JIT" or some similar name)
<JonDHarrop>
Yoric[DT]: I chatted on usenet about that and apparently V8 sucks. People have found lots of important cases where it is outperformed by existing JS implementations.
<Yoric[DT]>
Does it?
<Camarade_Tux>
sunspider is much much better
<Yoric[DT]>
Well, at the moment, TraceMonkey looks like the fastest implementation.
<Yoric[DT]>
Camarade_Tux: which one is that?
<JonDHarrop>
Apparently the primary application of JS is not, in fact, ray tracing. ;-)
<Yoric[DT]>
:)
<Camarade_Tux>
or rather SFX, aka Sunspider extreme, which is webkit's engine
<Camarade_Tux>
JonDHarrop, you'll be happy : one of the most involved dev in sunspider is making a javascript ray-tracer ;)
<JonDHarrop>
Perhaps a JS implementation is MetaOCaml is another project...
<JonDHarrop>
The V8 benchmark suite already has one.
<JonDHarrop>
Anyway, I'm off to write some kickass graphics algos in OCaml for the Journal. See y'all around!
<Camarade_Tux>
but what are you looking for exactly ?
Demitar has joined #ocaml
<nyingen>
I want to improve the DB4 binding for Ocaml, but I'm not sure where the C stubs, Ocaml source, etc are to be stored. Some files are being autogenerated, etc
<nyingen>
So I was wondering what the typical method is, though I guess the DB4 binding could be written atypically :)
<Camarade_Tux>
are there .idl files somewhere ?
<nyingen>
Camarade_Tux: aha, excellent link, just what I was looking for. My google search failed to turn that up
<Camarade_Tux>
googling for extension never works :p
<Camarade_Tux>
but how experienced with ocaml are you ?
<nyingen>
Camarade_Tux: No .idl files, just .ml, .src, .c, and some perl scripts that do something
<nyingen>
Camarade_Tux: I know Haskell, but I'm new to Ocaml
<Camarade_Tux>
the .src are unusual and perl too so the bindings could well be autogenerated with those too
<nyingen>
yeah
<Camarade_Tux>
however I don't know and I should *definitely* sleep
<nyingen>
Camarade_Tux: Okay, thanks for your tips so far!
<Camarade_Tux>
before I leave, what do you need to improve in the bindings ?
<nyingen>
*Many* functions are unimplemented
<nyingen>
The binding supports basic put, get, but I need things like fetching duplicate sets and using secondary DBs
<Camarade_Tux>
I see
<Camarade_Tux>
just to let you know, if you only need a db, not specifically db4, there are ocaml bindings to sqlite3 which are maybe more complete (well, I'm almost sure they are)
<Camarade_Tux>
now, sleep :)
Camarade_Tux has quit []
struktured_ is now known as struktured
Associ8or has quit []
<mbishop>
Does Mike Spivey frequent this channel?
struktured_ has joined #ocaml
struktured has quit [Connection timed out]
beigebox_ has quit [Read error: 110 (Connection timed out)]