rwmjones changed the topic of #ocaml to: Discussions about the OCaml programming language | http://caml.inria.fr/ | Grab Ocaml 3.10.1 from http://caml.inria.fr/ocaml/release.html (featuring new camlp4 and more!)
Mr_Awesome has quit ["aunt jemima is the devil!"]
ita has quit ["Hasta luego!"]
ulfdoz_ has joined #ocaml
ulfdoz has quit [Read error: 104 (Connection reset by peer)]
hkBst has quit ["Konversation terminated!"]
middayc has quit []
thermoplyae has quit ["daddy's in space"]
dbueno has joined #ocaml
dbueno has quit [Remote closed the connection]
postalchris has quit [Read error: 110 (Connection timed out)]
middayc has joined #ocaml
middayc has quit []
postalchris has joined #ocaml
postalchris has quit [Client Quit]
ben has joined #ocaml
adema has joined #ocaml
bluestorm has joined #ocaml
ramenboy has joined #ocaml
adema has quit [Read error: 110 (Connection timed out)]
middayc has joined #ocaml
Tetsuo has joined #ocaml
<tsuyoshi> huh.. in that "novice's notes" I see only two types of complaints: 1) problems solved by external libraries and 2) treating ocaml like an interpreted language rather than a compiled language
<tsuyoshi> it is interesting how people coming from a python/perl/etc. background can have different expectations
<bluestorm> tsuyoshi:
<bluestorm> i think saying "it's solved by external libraries" is only a part of the solution
<bluestorm> to be a real one, it has to be easy to use
<flux> to be any easier, toplevel would need to automatically load modules when you refer them
<bluestorm> currently, i don't think an outsider can see a clear statement about wich "external libraries" he should use, and how
<bluestorm> (i mean in a simple, multi-platform way)
<bluestorm> so tsuyoshi there still is a problem
<tsuyoshi> well, all I use is debian
<bluestorm> of course "including that all in the stdlib" is a quite radical solution
<tsuyoshi> installing extra libraries is basically a solved problem here...
<bluestorm> tsuyoshi: packaged extra libraries ?
<tsuyoshi> the only thing I know of that's useful that isn't packaged is pgocaml
<bluestorm> i agree unix systems are now quite comfortable with ocaml-related packaging
<bluestorm> (i've found godi and ocamlfind to be pretty neat)
<bluestorm> hm
<tsuyoshi> there's actually a lot of ocaml stuff packaged for debian that I think is a waste of time
<bluestorm> :p
<flux> such as?
<flux> cool, nowadays libcurses is packaged
<tsuyoshi> hmm.. I don't remember offhand
<tsuyoshi> I just remember installing every ocaml library in debian and only finding maybe a third of them to be of any use
<flux> I suppose you need to have a specific need to use some libraries
<tsuyoshi> but that's ok.. I mean, nobody uses everything
<bluestorm> the problem with that distro-centric point of view is that it doesn't really scale
<bluestorm> i mean, debian admitedly has done a great work on ocaml packaging
<tsuyoshi> windows and osx people seem to be pretty dissatisfied with ocaml though
<bluestorm> but you can't expect any gnu-linux/bsd/windows distribution to do the same
<tsuyoshi> the problem I think is that it will take someone who actually develops on windows and osx to fix these things
<bluestorm> :p
<tsuyoshi> but inria seems to be a linux-based place
middayc has quit [Read error: 110 (Connection timed out)]
Tetsuo has quit [Read error: 110 (Connection timed out)]
Tetsuo has joined #ocaml
bluestorm has quit ["Konversation terminated!"]
asmanur has joined #ocaml
ttamttam has joined #ocaml
ygrek has joined #ocaml
Yoric[DT] has joined #ocaml
<Yoric[DT]> Hi from the DevDay.
<Yoric[DT]> Is anyone transcribing already ?
<Yoric[DT]> Xavier Leroy (XL) is currently describing OCaml 3.10.
<Yoric[DT]> XL: (stuff from the release notes)
<Yoric[DT]> XL: a second bugfix release scheduled soon.
<Yoric[DT]> XL: Work on Ocaml 3.11 (scheduled Q3 2008)
<Yoric[DT]> XL: dynamic loading of native code, performance improvements on thread synch.
<Yoric[DT]> XL: discussed: small extension of coercions, private type abbreviations.
<Yoric[DT]> XL: possible port to iPhone.
* Yoric[DT] hopes somebody is reading or saving logs.
<Yoric[DT]> XL: iPhone hacks have started.
<Yoric[DT]> XL: status of the Caml Consortium.
<Yoric[DT]> XL: in 2007, from 4 to 7 members.
<asmanur> i am :p
<Yoric[DT]> XL: the consortium sells permissive licensing conditions on the OCaml code base, enables lightweight corporate sponsoring + good place to discuss industrial needs.
<Yoric[DT]> XL: the consortium *does not* bring enough funds to pay fr a full-time developer, or anything else.
<Yoric[DT]> asmanur: :)
<Yoric[DT]> XL: Challenge 1 = Manpower.
<Yoric[DT]> XL: Currently, there's about 0.5 person working full-time.
<Yoric[DT]> XL: Everybody has full-time cutting-edge research projects.
<Yoric[DT]> XL: What can the community do about it ?
<Yoric[DT]> XL: Firstly, avoir unreasonable demands.
<Yoric[DT]> XL: Plus testing, contribute to the Windows port, take over construction and distribution of binary releases for Windows and MacOS.
<Yoric[DT]> XL: Plus bug reports.
<Yoric[DT]> XL: Plus organize initiatives.
<Yoric[DT]> XL: Plus apply as Ingénieur de Recherche in INRIA.
<Yoric[DT]> XL: 2 permanent positions.
<Yoric[DT]> XL: Challenge 2 = Core vs. the rest.
<Yoric[DT]> XL: The .tar.gz from Inria does not include everything.
<Yoric[DT]> XL: Everything they include must be copyright INRIA, ends up being maintained by INRIA forever and slows down the release cycles.
<Yoric[DT]> XL: Actually, the INRIA distribution should be even smaller.
<Yoric[DT]> XL: What can the community do about it ?
<Yoric[DT]> XL: Draw some inspiration from Linux, CPAN, etc. : organize distributions.
<Yoric[DT]> XL: Things such as GODI, Debian OCaml package.
<Yoric[DT]> XL: Try and converge towards a single distribution effort in the style of CPAN, even if it ends up less sophisticated than the above.
<Yoric[DT]> XL: Challenge 3 = Backward compatibility.
<Yoric[DT]> XL: Incompatible changes don't go down well with users.
<Yoric[DT]> XL: Unfortunately, it prevents incremental fixing of past design errors.
<Yoric[DT]> XL: Not much the community can do about that.
<Yoric[DT]> XL: Now, on to technical challenges.
<Yoric[DT]> XL: Challenge 4 = More type system features.
<Yoric[DT]> XL: Many things could be added to the type system.
<Yoric[DT]> XL: For instance, GADT (Generalized Algebraic Data Types).
<Yoric[DT]> type 'a ty =
<Yoric[DT]> | Int constraint 'a = int
<Yoric[DT]> | Pair of 'b ty * 'c ty constraint 'a = 'b * 'c
<Yoric[DT]> let rec print : forall 'a. 'a ty -> 'a -> unit =
<Yoric[DT]> fun t x -> match t with
<Yoric[DT]> | Int -> print_int x
<Yoric[DT]> | Pair(t1, t2) -> print t1 (fst x); print t2 (snd x)
<Yoric[DT]> XL: Essentially, you know that if t is an Int, 'a is int and if t is Pair, 'a is '*b * 'c .
<Yoric[DT]> XL: The theory is mostly done, including inference.
<Yoric[DT]> XL: But is it worth the trouble ?
<cygnus_> where is he chatting
<Yoric[DT]> XL: The current type inference engine is reaching its limits (design limitations, too many incremental extensions piled on top of one another, plus its implementation is excessively imperative)
<Yoric[DT]> cygnus_: École Nationale Supérieure des Télécommunications, Paris.
<cygnus_> oh he's talkin in real life ?
<cygnus_> and you are typing it
<Yoric[DT]> XL: Essentially, this means that the inference engine will need to be reimplemented from scratch based on more modern, constraint-based systems.
<Yoric[DT]> cygnus_: indeed.
l_a_m has joined #ocaml
<Yoric[DT]> XL: Challenge 5 = Parallelism.
<Yoric[DT]> XL: we (the CS community) 're moving towards more cores, distributed memory, plus clusters.
<Yoric[DT]> XL: What's a good programming model for parallelism ?
<Yoric[DT]> XL: Worst -> best
<Yoric[DT]> XL: 1) Shared memory, locks, condition variables (e.g. Java, current OCaml). Pretty awful.
<Yoric[DT]> XL: 2) Same thing with static type-checking of locking (no implementation, based on e.g. Abadi & Flanagan). Safer but still awful.
<Yoric[DT]> XL: 3) STM (à la Haskell) : database-like transactions behaving atomically, except the compiler is doing the actual work. Much more agreeable for programmers but quite imperative.
<Yoric[DT]> XL: 4) Message passing (à la Erlang or JoCaml).
<Yoric[DT]> XL: No obvious winner.
<Yoric[DT]> XL: Now, what should be done about the run-time system for all this ?
<Yoric[DT]> XL: Simplest -> Most complex.
<Yoric[DT]> XL: 1) No shared heap, IPC (done in Zheng Li's coThreads, no change to the run-time).
<Yoric[DT]> XL: 2) No shared heap, IPC when necessary, local communications when needed (about 1/3 of the run-time must be rewritten to remove global-state stuff).
<Yoric[DT]> XL: 3) Shared heap with concurrent GC (about 2/3 of the run-time must be rewritten, very hard algorithmic issues with weakly consistent memory models, no solution yet).
<Yoric[DT]> XL: What about encapsulation of effects ?
<Yoric[DT]> XL: For clean semantics for parallel computations, one needs to statically control or eliminate entirely shared mutable data structures.
<Yoric[DT]> XL: Two threads can race for access to a reference.
<Yoric[DT]> XL: In any approach, encapsulation is needed.
<Yoric[DT]> XL: That's quite different from today's OCaml.
<Yoric[DT]> XL: Answering questions wrt licensing issues.
<tsuyoshi> so are they actively working on a new type inferer?
<Yoric[DT]> XL: If you have problems with our licenses, the best solution is probably to become a member of the consortium.
<Yoric[DT]> XL: Answering question wrt concurrency.
<Yoric[DT]> XL: "I personally prefer message passing."
<Yoric[DT]> tsuyoshi: I'll ask.
<tsuyoshi> thanks
<Yoric[DT]> XL: No.
<Yoric[DT]> XL: At some point it'll be needed, but it's not started.
<tsuyoshi> ah
<Yoric[DT]> XL: Not even preliminary work on this specific subject.
<Yoric[DT]> sidenote: although he does seem to know who would work on that if necessary.
<Yoric[DT]> Question: How many parallel APIs can coexist in a system ? There's already Camlp3l, MPI, JoCaml...
<Yoric[DT]> XL: Er... I'm not sure.
<tsuyoshi> I have been struggling to add support for relational algebra to the compiler.. if the type system was more flexible it would be easier
<Yoric[DT]> XL: If you have any kind of message passing, you can probably implement Camlp3l easily on top of it.
<Yoric[DT]> XL: Join Patterns on top of simple message passing would be hard.
<tsuyoshi> so it's good to hear that they're think,nthinking about it, at least
<Yoric[DT]> tsuyoshi: do you want me to say that ?
<tsuyoshi> yoric: if you think he'd be interested in that
<Yoric[DT]> Well, I repeated what you say and there was no real answer.
<Yoric[DT]> Question: what about type-safe message passing ?
<Yoric[DT]> XL: As long as it's one program, that's easy.
<Yoric[DT]> XL: What is more subtle is if you have separately compiled programs.
<Yoric[DT]> XL: There have been several proposals, in GCaml, another one very closed [I didn't get the name], yet another one [mumbled name].
<Yoric[DT]> XL: I think it is possible, we could already have this.
<Yoric[DT]> XL: I'm kind of waiting for one specific approach to emerge.
<Yoric[DT]> XL: The community could help with agreeing on one specific approach out of these three.
<Yoric[DT]> (end of talk)
<Yoric[DT]> Vincent Balat (VB) is now talking about the Ocsigen.
<flux> yoric[dt], thanks for the effort, btw
<Yoric[DT]> VB: Ocsigen = OCaml [web] Site Generator, research project of PPS (Guy Cousnieau, Pierre-Louis Curien, Jérôme Vouillon, Roerto Di Cosmo...)
<Yoric[DT]> VB: You may not know them because they're not in the OCaml mailing-list, but some of them are the original authors of Caml.
<Yoric[DT]> VB: The lab is working on relations between proofs and programs.
<cygnus_> why are they not on the ml then
<Yoric[DT]> VB: A number of web programming projects in OCaml.
<Yoric[DT]> VB: OCamlnet, mod_caml (apache module for writing website with OCaml => Cocanwiki), WDialog, ASXCaml (?)...
<Yoric[DT]> VB: What's the difference between Ocsigen and these projects ?
<Yoric[DT]> VB: It's not another web programming tool in OCaml, it's a research project, we're attempting to find new programming techniques for the web.
<Yoric[DT]> VB: Two projects Ocsigen (OCaml-specific) and WebSiCoLa (mostly language independent).
<Yoric[DT]> VB: The main idea is continuation-based web programming.
<Yoric[DT]> VB: Other related projects (Seaside, Links, Hop, Wash, PLT Scheme) and that's about it.
<Yoric[DT]> VB: Quite few wrt other web programming tools.
<Yoric[DT]> VB: Trying to build an open-source community around the project.
Mr_Awesome has joined #ocaml
<Yoric[DT]> VB: [Demo of Nurpawiki written with the currently released Ocsigen tools]
<Yoric[DT]> VB: [Demo of the Lambdium-light CMS written with the currently released Ocsigen tools]
<Yoric[DT]> VB: Ocsigen 1.0 (scheduled within a few weeks) = full-featured, extensible web-server, a module called Elium (continuation-based web programming), libraries (Ocsimore).
<Yoric[DT]> VB: The server implements http, extension mechanism, static pages, access control, data compression, CGI just in case, reverse proxy and of course Elium.
<Yoric[DT]> VB: It's built on cooperative multi-threading (itself written with LWT, threads in monadic style) + some preemptive threads for non-cooperative libraries.
<Yoric[DT]> VB: Cooperative MT = only one thread of execution, never use blocking functions, go back to another continuation instead.
<Yoric[DT]> let r = request() in parse_answer r ====> requesr () >>= fun r -> parse_answer r
<Yoric[DT]> VB: We will release LWT for people who want to use it -- we actually encourage people to use it, it's quite functional-programming friendly.
<Yoric[DT]> VB: You're all actual OCaml developers, I can show you some code.
<Yoric[DT]> VB: Let's try and develop a forum.
<Yoric[DT]> VB: Static checking of HTML.
<Yoric[DT]> VB: Module Text => untyped pages.
<Yoric[DT]> VB: Module Xhtml => Type checking with polymorphic variants.
<Yoric[DT]> VB: Module OcamlDuce => Type checking with OCamlDuce (XHTML, XML).
<Yoric[DT]> [Currently on display some source code]
<Yoric[DT]> [First example uses a syntax extension to write nearly inline HTML. The type checker uses polymorphic variants to find errors.]
<Yoric[DT]> VB: Other output modules.
<asmanur> Yoric[DT]: can't you ask for the code or something ? it would be interesting
<Yoric[DT]> asmanur: I'll try.
<asmanur> thanks
<Yoric[DT]> [Second example uses usual OCaml syntax]
<Yoric[DT]> VB: For general XML, use OcamlDuce.
<Yoric[DT]> VB: The paradigm is that clicking on a link or sending stuff with a form is calling a function.
<Yoric[DT]> VB: We're calling these functions "services".
<Yoric[DT]> let mainpage = new_service ~path:["stuff"] ~get_params:unit ()
<Yoric[DT]> let () = register mainpage (fun sp () () ->
<Yoric[DT]> Mylib.create_page sp "Messages" [Mylib.display_messages .......... (gasp)
<Yoric[DT]> create_page was one of the earlier examples.
<Yoric[DT]> VB: There's some XML dialect used to describe the set of services.
<Yoric[DT]> VB: Second example, more complex, with parameters.
* Yoric[DT] doesn't quite catch how that can typecheck.
<Yoric[DT]> [Okay, I misunderstood something, it was not a XML dialect to describe the set of services, the XML dialect was used to generate a web page by calling some OCaml functions]
<Yoric[DT]> VB: There are no broken links, because that would be an unbound identifier, caught by the compiler.
<Yoric[DT]> asmanur: code seems similar to http://www.ocsigen.org/tutorial0.99.5-1#p1baseprinciples .
<asmanur> ok thanks
<Yoric[DT]> VB: When you load twice the same webpage, if you are doing two different things on the same page at once (e.g. placing two orders on the same website), you have a difficulty.
<Yoric[DT]> VB: It's the "back button problem".
<Yoric[DT]> VB: It's trivial with functional programming, because that's just continuations.
* Yoric[DT] is wondering about garbage-collection.
<Yoric[DT]> VB: The problem has been described by Christian something (didn't catch last name).
<Yoric[DT]> VB: In Elium, new services may be created dynamically to implement these continuations (we're calling them "coservices").
<Yoric[DT]> [And from the source code, it's actually registering continuations]
<Yoric[DT]> VB: My example is not very clean, I should have factorized code better.
<Yoric[DT]> VB: On a forum, when you click on a link after writing down your message, you don't want to display a page, you just want your message to be taken into account, then you want your current webpage to be redisplayed.
<Yoric[DT]> VB: We call this an "action".
<Yoric[DT]> [Some example I don't quite get, seemingly related to logging]
<Yoric[DT]> VB: Some services are attached to URLs, some [like logging on a BBForum, if I understand], are not.
<Yoric[DT]> VB: Some services registered dynamically are available only for one user.
<Yoric[DT]> VB: It's really easy to write sophisticated behavior with few lines of code.
<Yoric[DT]> VB: The whole example [a small forum] is 146 loc.
* flux is browsing ocsigen pages, again
<Yoric[DT]> VB: Summary of features: static checking of pages, full set of service kinds (strong use of continuation-based web programming, very precise control of URLs, highly related to concrete needs of web developers...), automatic session management.
<Yoric[DT]> VB: 1.0 is almost ready.
<Yoric[DT]> VB: For the future, higher-level features, more dynamic website.
<pango> (ajax ?)
<Yoric[DT]> VB: For the future, use only OCaml to write code that will be partly executed on the client.
<Yoric[DT]> VB: Maybe generating JS or maybe using some plug-in.
<Yoric[DT]> Answering stuff wrt garbage-collection.
<Yoric[DT]> VB: You can limit co-services to n uses or you can add some time-out.
<Yoric[DT]> VB: A closure is not bigger than the data you want to keep in memory.
<Yoric[DT]> VB: You need to implement some mechanism to limit resource consumption.
<Yoric[DT]> VB: We're not using call/cc, we're actually building closures, which does not need to save the whole stack.
<Yoric[DT]> Question by Martin Jambon (MJ).
<Yoric[DT]> MJ: What happens if you upgrade the server ? What happens to the users currently connected ?
<Yoric[DT]> VB: We have a mechanism to reload the modules without shutting down the server.
<Yoric[DT]> VB: You will lose the sessions.
<Yoric[DT]> VB: But you can persist services.
<Yoric[DT]> VB: Not co-services, though, as they're expected to be short-lived.
<Yoric[DT]> (end of talk)
<Yoric[DT]> VB: The slides and examples are on the Cocan Wiki.
<Yoric[DT]> Next talk by Gerhardt Stolpmann.
<Yoric[DT]> (GS)
<Yoric[DT]> GS: I'd like to show you GODI.
<Yoric[DT]> GS: OCaml user since version 1.0.3 or so.
<Yoric[DT]> GS: In his previous job, he had one day per week working on personal projects.
<Yoric[DT]> GS: Now consultant.
<Yoric[DT]> GS: Now lives of OCaml.
<Yoric[DT]> GS: GODI started as a personal project.
<Yoric[DT]> GS: History: 1996 OCaml, 1997 GS's first OCaml program, 1999 Findlib, around 2002 GS's written code becomes impossible to mange, 2003 GODI, 2008 about 110 packages in GODI.
<flux> hm, I suppose a tool to convert godi-packages to debian-packages could be useful; all packages could be targeted for godi then
<Yoric[DT]> GS: Goals = Make it easy to rebuild everything, support for multiple platforms.
<Yoric[DT]> GS: Community effect = packages add more software, users help debugging, QA improved.
<Yoric[DT]> GS: + business reasons = good reason to start talking and offer services as a consultant :)
<Yoric[DT]> [Looks like a demo of GODI installation is starting]
<Yoric[DT]> [Okay, I'm not going to describe the demo, it works essentially like any package management system]
<Yoric[DT]> [From source]
<flux> I have a live demo of that running here, too..
<Yoric[DT]> [Demo on compiling against libraries that are not installed system-wide]
<Yoric[DT]> [Demo on upgrading]
<flux> seems to work fine.. now, dare I try it on a solaris machine..
* Yoric[DT] is planning to try it on Cygwin some day.
* Yoric[DT] is a bit too scared for that, though.
<Yoric[DT]> [Explanation of dependencies]
<flux> if it worked on native windows, now that'd be cool
<Yoric[DT]> Yep.
<Yoric[DT]> As it is, I'll need to install linux on my student's laptops :(
<Yoric[DT]> GS: Anatomy of a package.
<Yoric[DT]> GS: distfile = original tarball, as distributed by the author downloaded from the original http/ftp server.
<flux> I wonder if godi works for cross-compiling.. (I guess it is extremely likely it will not)
<Yoric[DT]> GS: buildfile = wrapper around distfile = additional tarball from GODI with driving scripts and metadata, downloaded from GODI server, although custom locations are possible, too.
<Yoric[DT]> flux: do you want me to ask ?
<Yoric[DT]> GS: The format originates in BSD "ports".
<Yoric[DT]> GS: (actually heavily customized NetBSD port system)
<flux> yoric[dt], I suppose you could, although the answer is most likely "no"; even ocaml Makefiles need to be patched to make that happen
<Yoric[DT]> GS: godi_console written in OCaml.
<Yoric[DT]> flux: well, then I guess you have your answer :)
<Yoric[DT]> GS: godi_make not so nice, based on BSD make, written in C with scripts written in Shell.
<flux> (also, ocaml needs too big runtime environment to be useful for the target I've tried..)
<Yoric[DT]> Embedded targets ?
<flux> yeah
<Yoric[DT]> Have you looked at Desert Spring Time ?
<flux> well, not the runtime environment itself, but couple that with the produced binary size - and the fact that there are no shared ocaml libraries..
<Yoric[DT]> GS: New implementation of godi_make written in OCaml.
<flux> hmm, I distinctly remember the name, but I can't recall what it is -> checking
<flux> right, that
<Yoric[DT]> GS: replacing Shell is an open issue. Shell is powerful stuff.
<flux> apparently the site is gone
<Yoric[DT]> :/
<Yoric[DT]> It was interesting.
<Yoric[DT]> GS: Makefile uses BSD-make syntax.
<Yoric[DT]> GS: framework, metadata (name, download...), dependencies, build options, post-install stuff.
kelaouch1 has quit ["leaving"]
<Yoric[DT]> GS: not-so-nice part: the plist = the list of files that are part of the package.
kelaouchi has joined #ocaml
<Yoric[DT]> GS: currently, needs to be written manually.
<Yoric[DT]> GS: When all that is written, test the package locally (does it build successfully, can it be removed successfully ?)
<Yoric[DT]> GS: There's an online release tool for submitting stuff & updates to GODI.
<Yoric[DT]> * GS: There's an alternate approch called GODIVA.
<Yoric[DT]> * Makefile and PLIST are generated.
<Yoric[DT]> GS: Requires adhering to a make interface outlined in the "GODIVA policy".
<Yoric[DT]> GS: Perhaps this could serve as a standard distribution policy for OCaml packages.
<Yoric[DT]> GS: Now, you can also run your own GODI server.
<Yoric[DT]> GS: Packages provided by additional servers are merged with the packages from the official site.
<Yoric[DT]> GS: Note that GODI can package non-OCaml software.
<Yoric[DT]> GS: Most packages can be built on all system types : bytecode-only/native-code, with/without pthreads, shared/static libraries.
<Yoric[DT]> GS: + doc.
<Yoric[DT]> GS: The future...
<Yoric[DT]> GS: New bootstrap architecture (prototype available).
<Yoric[DT]> GS: Reduced dependency on software written in C.
<Yoric[DT]> GS: GUI for godi_console would be nice.
<Yoric[DT]> GS: Native Windows support would be nice, too. Probably only as a commercial project, because that's lots of work, plus Windows users just don't have build environment, so binary packages would be needed.
ygrek_ has joined #ocaml
<Yoric[DT]> GS: Currently about 30 package maintainers.
<Yoric[DT]> GS: 2/3 of the packages are not maintained by GS.
<Yoric[DT]> GS: New packages are always welcome, but it does take some skills in Shell, etc.
<Yoric[DT]> GS: I focus on the core packages and GODI itself, not much time for anything more.
<Yoric[DT]> (end of talk)
ygrek has quit [Remote closed the connection]
<Yoric[DT]> Question about sharing work between Debian packages and GODI packages. Common infrastructure would be noce.
<Yoric[DT]> GS: Would be possible. That's something like the GODIVA approach.
<Yoric[DT]> Sylvain Le Gall (I think) = SLG
<Yoric[DT]> SLG: I have tried to backport GODI patches to Debian.
<Yoric[DT]> SLG: We could share some metafiles.
<Yoric[DT]> SLG: The GODIVA policy is nice but it just won't work with OMake, OCamlMakefile, ocamlbuild, etc. it's too much C inspired.
<Yoric[DT]> SLG: There are technical issues regarding where and when to build stuff, because in Debian you build first and distribute later (as under Windows).
<Yoric[DT]> GS: The discussion will continnue.
<Yoric[DT]> s/continnue/continue/
<Yoric[DT]> Question: GODI supports a lots of architectures, but not as many as ocamlbuild, what would be the alternatives to BSD make and stuff ?
<Yoric[DT]> GS: Well, starting with software that already worked let me concentrate on OCaml-specific problems.
<Yoric[DT]> GS: Plus it's easy to modify.
<Yoric[DT]> GS: So yeah, that was probably the right choice.
<Yoric[DT]> GS: This big shell scripting stuff is hard to maintain, though.
<Yoric[DT]> Question about cross-compilation
<Yoric[DT]> GS: I haven't even thought about it.
<Yoric[DT]> (end of talk, start of lunch)
<pango> thanks
elus has joined #ocaml
<Yoric[DT]> [Transcription will resume around 13h30]
<asmanur> :D
<asmanur> thanks for the transcription :p
<Yoric[DT]> (French time, of course :))
<Yoric[DT]> My pleasure.
<flux> I wonder if godi support SMP (for compiling stuff) - this bootstrapping takes ages..
<flux> even if packages didn't support it, packages themselves could be compiled in parallel
middayc has joined #ocaml
asmanur has quit [Read error: 110 (Connection timed out)]
* Yoric[DT] is back.
<Yoric[DT]> [Discussion in progress regarding the possibility of organizing a CPAN for OCaml]
<Yoric[DT]> [Dropping ocamlbrowser and labltk from a "standard distribution" -- not provided by INRIA itself]
<Yoric[DT]> [People involved in the discussion are rwjones, slegall, mjambon and our local bluestorm]
<Yoric[DT]> [Although bluestorm is lurking]
<Yoric[DT]> [Non-religious discussions between Fedora and Debian]
<Yoric[DT]> [Back to CPAN]
<Yoric[DT]> [Site should be mostly static]
<Yoric[DT]> [Could be the official source for GODI packages]
pango has quit [Remote closed the connection]
ygrek_ has quit [Remote closed the connection]
<Yoric[DT]> [Talk by Nicolas Pouillard = NP about OCamlBuild]
pango has joined #ocaml
<Yoric[DT]> [Before the talk, we have a photo session]
<Yoric[DT]> [Back to NP]
<middayc> will there be any videos available?
<Yoric[DT]> Yep.
<middayc> great :)
<Yoric[DT]> NP: OCamlbuild is a compilation manager for OCaml projects.
<Yoric[DT]> NP: Standard in 3.10.
<Yoric[DT]> NP: Makefiles are annoying and bug-prone.
<Yoric[DT]> NP: The objective of OCamlBuild is a tool that just works (tm).
<Yoric[DT]> NP: There are basically 3 kinds of projects : Regular (automatically handled by OCamlBuild, one command is sufficient), Regular with exceptions (require a _tag file), Everything else (need a plug-in).
<Yoric[DT]> NP: OCamlBuild provides automated whole-project compilation, minimal recompilation, lots of useful targets, support for multiple build directories, automatic and safe cleaning.
* Yoric[DT] needs to ask about caching preprocessing.
<Yoric[DT]> NP: Plus it's portable and it's shipped with OCaml.
Snark has joined #ocaml
<Yoric[DT]> NP: Regular project = compilation units, parsers and lexers, packages, libraries and toplevels, external libraries, one main OCaml unit from which these units are reachable.
<middayc> (thanks for letting us know what is going on)
<Yoric[DT]> NP: OCaml has subtle compilation rules, in particular suffixes are different for native and bytecode object files, interfaces may be absent, but sometimes buildable from yacc source files, native packages are difficult to do, linkage order matters, include directories order matters, ocamldep only gives partial information, etc.
<Yoric[DT]> How does OCamlBuild manage all that ?
<Yoric[DT]> NP: How does OCamlBuild manage all that ?
<Yoric[DT]> NP: Lots of hand-crafted OCaml-specific compilation logic.
<Yoric[DT]> NP: (i.e. the standard library)
<Yoric[DT]> NP: Dynamic exploration approach: start from the given targets, attempt to discover dependencies using ocamldep, sometimes ocamldep cannot be trusted, so backtrack if necessary, then launch compilations and discover new dependencies.
<Yoric[DT]> NP: Now, sometimes, you need to deal with exceptions.
<Yoric[DT]> NP: around 10% of projects have exceptions.
<Yoric[DT]> NP: Custom warnings, debugging, profiling, recursive types, linkall, threads, custom pervasives, units that need external C libraries, binaries that need external OCaml libraries, etc.
<Yoric[DT]> [Examples of _tags]
<Yoric[DT]> [I'm not going to copy these examples, that's basically the same ones as in the manual]
<Yoric[DT]> [Well, not exactly]
<Yoric[DT]> NP: Each line is made of a pattern and a list of signed tags.
<Yoric[DT]> NP: A line adds or removes tags from matching files.
* Yoric[DT] needs to ask about quoting, too.
marmottine has joined #ocaml
<Yoric[DT]> NP: dynamic dependencies may be added from plugins.
<Yoric[DT]> NP:Let's see how to write a plug-in.
<Yoric[DT]> NP: They're written in plain OCaml.
<Yoric[DT]> NP: Plug-ins are compiled on the fly.
<Yoric[DT]> NP: They provide dynamic configuration if necessary.
<Yoric[DT]> NP: Plug-ins can extend/create/override rules, add flags based on tags, tag files, change options, define the precise directory structure, help ocamldep, specify external libraries.
<Yoric[DT]> ...
<Yoric[DT]> NP: Parallel execution is possible, where applicable.
<Yoric[DT]> NP: Rules know how to ask for // targets, the system manages synchronization.
<Yoric[DT]> NP: It's not an optimal scheduling, because the graph may be dynamic.
<Yoric[DT]> NP: By the way, there's support for non-standard tools such as menhir (replacement for ocamlyacc).
<Yoric[DT]> NP: + ocamldoc
<Yoric[DT]> NP: + camlp4
<Yoric[DT]> NP: +nice output
<Yoric[DT]> NP: OCaml will save you lots of time and let you concentrate on your code.
<Yoric[DT]> [Plenty of questions wrt Camlp4 + OCamlBuild]
<Yoric[DT]> [The manual should answer the questions, someone needs to write it down]
<Yoric[DT]> [Reasons why OCamlBuild is part of the distribution]
<Yoric[DT]> SLG: But that makes the core of OCaml bigger.
<Yoric[DT]> XL: Well, yeah, but we need it for Camlp4, and Camlp4 is part of the distribution and we couldn't put it anywhere else.
<Yoric[DT]> XL: Now, OCamlBuild is used to build OCaml anyway.
<Yoric[DT]> SLG: So we're back to this morning's question about internal data structures and of how difficult it is to develop OCaml tools without accessing the source code of OCaml.
<Yoric[DT]> [End of talk]
<Yoric[DT]> [Sylvain Le Gall will talk again]
* Yoric[DT] 's fingers are burning.
<Yoric[DT]> SLG: Do we want to do this again next year ?
<Yoric[DT]> SLG: There will be a section on the Wiki regarding comments and suggestions on this meeting.
<Yoric[DT]> SLG: That and volunteers :)
<Yoric[DT]> SLG: It's easy to send e-mails on the mailing-list, but some things can only happen face-to-face.
<Yoric[DT]> [Now, on to the real talk]
<Yoric[DT]> SLG: OCaml in Debian.
<Yoric[DT]> SLG: This will be shorter and less technical than other talks.
<Yoric[DT]> SLG: Because I didn't have time to prepare anything complex anyway.
<Yoric[DT]> SLG: Let's see the issues related to distributing OCaml in Debian -- and later about other distributions.
<Yoric[DT]> SLG: Debian is a binary distribution created in 1993 and based around a very good package management system.
<Yoric[DT]> SLG: It's also recognized for its very strict policies.
<Yoric[DT]> SLG: In particular, Debian has been annoying INRIA for some time about OCaml licensing issues.
<Yoric[DT]> SLG: And that's going to continue :)
<Yoric[DT]> SLG: Oh, yeah, and big flamewars are just part of the fun.
<middayc> :)
<Yoric[DT]> SLG: Recruitement of Debian Developers is based on sharing a common vision of what Debian is all about.
<Yoric[DT]> SLG: There's a central repository, which is quite important as it allows us to make a number of tests on packages, among other things related to the possibility of rebuilding packages.
<Yoric[DT]> SLG: We have tools to try and determine what files are left if a package is installed and deinstalled, etc.
<Yoric[DT]> SLG: There's also a bug category Failed To Build From Source, the highest level bug.
<Yoric[DT]> SLG: To make a Debian package, take a pristine upstream source ( = direct from the author ).
<Yoric[DT]> SLG: Every Debian package contains this unmodified tarball.
<Yoric[DT]> SLG: The only exception is when some files don't comply with the Debian licence and can't be included directly.
<Yoric[DT]> SLG: For instance, in MLDonkey, some files had to be removed, because they really looked reverse-engineered from Windows source.
<Yoric[DT]> SLG: So, please, if there are things we can't distribute, put it in a plug-in.
asmanur has joined #ocaml
<Yoric[DT]> SLG: To this source code, we add a debian/ directory, containing rules (a Makefile), control (description of dependencies and binary dependencies when they can't be guessed), ChangeLog, copyright, etc.
<Yoric[DT]> SLG: Without that copyright, we wouldn't be allowed to distribute the software, mind you.
<Yoric[DT]> SLG: Let's talk about OCaml.
<Yoric[DT]> SLG: The first ChangeLog entry of OCaml package dates back to 1.02, and was done by Christophe Le Bars.
<Yoric[DT]> SLG: That was in 1996 and OCaml wasn't in the official archive because OCaml was considered non-free.
<Yoric[DT]> SLG: The official OCaml for Debian is Sven Luther in 2000.
<Yoric[DT]> SLG: Now it's maintained by the community, not by a specific packager.
<Yoric[DT]> SLG: It's sometimes a problem, because in case of bug report, nobody really knows who should handle it.
<Yoric[DT]> SLG: There's a mailing list DOM (Debian OCaml Maintainer) since 2000, a policy since 2002 and an alioth project since 2003.
<Yoric[DT]> SLG: Since 1999, the number of packages has climbed from around 4 to around 125. Not all these packages are actually released to the repository.
<Yoric[DT]> SLG: The number of active maintainers has climbed from 1 to around 15.
<Yoric[DT]> [around = because I'm reading from a graph]
<Yoric[DT]> SLG: We are working by step.
<Yoric[DT]> SLG: At the moment, we're including LiquidSOAP, an application for PodCast (or is that WebCast ?), and all the dependencies.
<Yoric[DT]> ppsmimou: you're being quoted
<Yoric[DT]> SLG: There's a small group of 5-6 people doing most of the work.
<Yoric[DT]> SLG: Most of the other people have a short lifespan.
<Yoric[DT]> SLG: Now, closed issues.
<Yoric[DT]> SLG: We use OCamlfind.
<Yoric[DT]> SLG: The problem of naming schemes is not completely closed yet, because .cmo are not native, so they may not end up in the same package as .cmx .
<Yoric[DT]> SLG: The ABI issues are not fully closed yet, there's a solution, not a great one, but it should work : OCaml won't enter testing unless it can compile all OCaml packages.
Mr_Awesome has quit ["aunt jemima is the devil!"]
<Yoric[DT]> SLG: Team maintainance works.
<Yoric[DT]> SLG: Some issues are really open, thoug.
<Yoric[DT]> SLG: Dependencies between libraries are not solved.
<Yoric[DT]> SLG: If OCamlNet needs to be rebuilt, so does everything that depends on OCamlNet.
<Yoric[DT]> SLG: Bytecode stripping is another problem. It turns out that .cmo files contain executable debugging information, nobody knows why.
<Yoric[DT]> XL: It's an obsolete feature, none of your packages should have that.
<Yoric[DT]> XL: Probably a command-line error when invoking the compiler.
<Yoric[DT]> XL: We're willing to help.
<Yoric[DT]> XL: It's due to a compiler option only useful for platforms without dlopen, which is definitely not the case of Linux.
<Yoric[DT]> SLG: Another problem is that 3 architectures are currently broken.
<Yoric[DT]> SLG: We found out when compiling Felix and Camomile.
<Yoric[DT]> SLG: That's IA64, ARM [and a third one I didn't catch].
<Yoric[DT]> SLG: That's waiting for bugfixes from INRIA.
<Yoric[DT]> XL: ARM now works with Debian stable.
<Yoric[DT]> XL: We have a problem with ARM since they have many different ABIs.
<Yoric[DT]> XL: The situation is complicated.
<Yoric[DT]> XL: For the other ABIs, floating point is very different -- and broken.
<Yoric[DT]> XL: QUestion, btw, who is still using OCaml in IA64 and Alpha ?
<Yoric[DT]> XL: We don't really have time to maintain this, plus we don't have the hardware.
<Yoric[DT]> RWJ: Red Hat is shipping a commercial product based on OCaml in IA64.
<Yoric[DT]> XL: Oops.
<Yoric[DT]> SLG: Now, on to Debian vs. Red Hat vs. GODI.
<Yoric[DT]> SLG: Debian has more OCaml packages because we have started early.
<Yoric[DT]> SLG: The build system/package management system doesn't work well with OCaml.
<Yoric[DT]> SLG: We are still trying to find solutions to make apt work with OCaml.
<Yoric[DT]> SLG: Frankly, we don't know how to get dependency analysis between libraries.
<Yoric[DT]> SLG: But GODI is very nice.
<Yoric[DT]> SLG: I hope we will be able to cooperate.
<Yoric[DT]> RWJ: We have a few interesting scripts using ocamlopt and parsing the output.
<Yoric[DT]> SLG: So do we.
<Yoric[DT]> RJW: It kind of works with the necessary adjustments.
<Yoric[DT]> SLG: Yeah...
<Yoric[DT]> SLG: Anyway, OCaml is great, but packaging it is hard.
<Yoric[DT]> SLG: It's the same kind of problems for Python, mind you.
<Yoric[DT]> SLG: We are looking for solutions.
<Yoric[DT]> SLG: If you have ideas (or just fresh blood), please manifest yourself.
<Yoric[DT]> SLG: Questions ?
<Yoric[DT]> Alain Frisch: What's the point of having Debian packages for developers ?
<Yoric[DT]> SLG: Well, it's important for applications.
<Yoric[DT]> SLG: For developers, not so much.
<Yoric[DT]> SLG: It can be a time-saver.
<Yoric[DT]> SLG: But a user of LiquidSOAP will probably prefer installing the binaries rather than recompiling everything.
<Yoric[DT]> AF: Yeah, but you need to decide between stable, testing, unstable.
<Yoric[DT]> SLG: Yeah, developers using stable should use GODI.
<Yoric[DT]> AF: Why does MLDonkey have dependencies to other packages ?
<Yoric[DT]> SLG: For build dependencies, not run-time dependencies.
<Yoric[DT]> ?: Would it be possible to replace debian packages by GODI ?
<Yoric[DT]> SLG: Yeah, but haaard.
<Yoric[DT]> SLG: Not enough manpower.
<Yoric[DT]> Same ? [I'll call him
<Yoric[DT]> Same ? [I'll call him 'a] : Any technical problems ?
<Yoric[DT]> SLG: You need to keep track of what has been installed from GODI, what has been installed from apt, plus to manage upgrades...
<Yoric[DT]> 'b: Maybe source installation is interesting but there's a reason why Coq wasn't chosen for the GODI demo. It wouldn't have been installed in 15 seconds.
<Yoric[DT]> SLG: In addition, when people start a development, they tend to prefer if the environment remains the same.
<Yoric[DT]> SLG: Debian is good far stability.
<Yoric[DT]> 'b = Pierre Letouzey : [ ? ]
<Yoric[DT]> PL : What is the difficulty of specifying dependencies for .cmi / .cmo ?
<Yoric[DT]> SLG: Because the Debian system is designed for C.
<Yoric[DT]> SLG: OCaml uses MD5 sums, which don't appear in C-style .so .
<Yoric[DT]> PL: Is your point the fact that OCaml changes appear in each release ?
<Yoric[DT]> SLG: Basically, if you change one thing in the whole chain of dependencies, you have to rebuild everything and things can't be discovered automatically.
<Yoric[DT]> SLG: If you just add a function, you're going to break the MD5, hence the ABI.
<Yoric[DT]> RWJ: Whereas in C, that's a compatible change.
<Yoric[DT]> Jaap Bender: Couldn't GODI generate Debian packages ?
<Yoric[DT]> SLG: That would be nice.
<Yoric[DT]> SLG: We'd like to integrate everything as much as possible but we need time to do it, plus good ideas.
<Yoric[DT]> 'c : There's another contribution upstream developers could do : put packages in a sane state. That's something that doesn't often happen. It's the same problem with GODI. In this kind of circumstances, the maintainer needs to patch the source.
<Yoric[DT]> 'c : That's something which could be shared between GODI and Debian.
<Yoric[DT]> GS: Sometimes, we don't know who maintains the software.
<Yoric[DT]> SLG: There's a difference between C and OCaml libraries.
<Yoric[DT]> SLG: it's hard to measure responsiveness of OCaml maintainers, because usually, there's no bug, so no bug reports, bugfixes, etc. So people start to believe that nobody uses the package.
<Yoric[DT]> SLG: Well, another problem is that upstream authors are often unresponsive.
<Yoric[DT]> 'd : Would there be a way for GODI to ask for Debian dependencies ?
<Yoric[DT]> SLG: I suppose, you should ask GS. Perhaps from findlib.
<Yoric[DT]> SLG: You could test if the package is there and install it if isn't.
<Yoric[DT]> SG: No, the problem would be the [?] files.
<Yoric[DT]> SG: No, the problem would be the C files.
<Yoric[DT]> SG: For instance, the pcre OCaml library requires the pcre C library.
<Yoric[DT]> SG: GODI doesn't handle that.
<Yoric[DT]> SG: Thank you.
<Yoric[DT]> [End of talk]
<Yoric[DT]> Xavier Clerc (XC): Running OCaml on a JVM.
<Yoric[DT]> XC: Not endorsed by the Inria.
<Yoric[DT]> XC: Let's compare OCaml and Java.
<Yoric[DT]> XC: OCaml is expressive, Java is verbose.
<Yoric[DT]> XC: OCaml community is small, Java is huge.
<Yoric[DT]> XC: OCaml Libraries are few, Java many
<Yoric[DT]> XC: OCaml code quality of libraries is high, Java's is ... not as bad as C.
<Yoric[DT]> XC: The idea is to get the best of both worlds.
<Yoric[DT]> XC: There's already JavaCaml by GS, an interpreter of OCaml bytecode in Java (a port of OCamlRun), looks dead.
<Yoric[DT]> XC: Plus CamlJava, an OCaml <-> Java interface through JNI. Portable but quite low-level and requires compilation on each architecture.
<Yoric[DT]> XC: O'Jacare, an interface generator for OCamlJava, by Henry.
<Yoric[DT]> (same limitations as CamlJava)
<Yoric[DT]> (plus unmaintained)
<Yoric[DT]> XC: Our objective is to use 100% pure Java, without JNI, run programs both interpreted and compiled, easy access to Java classes and no special runtime for the bytecode. Plus compatibility with the original implementation. Another nice property would be to have several OCaml programs running in the same JVM.
<Yoric[DT]> XC: Current version is 1.0 alpha (available at ocamljava.x9c.fr), beta version in February, for OCaml 3.10.1. Targets Java 1.5, implements the whole standard library (including lexing, parsing, marshalling, bigarray, dbm, dynlink, graph, num, str, unix, threads).
<Yoric[DT]> XC: The only missing library is Tk.
<Yoric[DT]> XC: Already able to run toplevel and build a working ocamlc.jar.
<Yoric[DT]> XC: Subprojects Barista (bytecode gen), Cadmium (interpreter & runtime support), Cafesterol (OCaml-to-Java compiler), Nickel (bindings generator) and OCamlScripting (scripting engine for Java, based on the rest).
<Yoric[DT]> XC: Let's start with Barista : Library for class file manipulation, asm/unasm, implements the whole Java 1.5, depends on Camlzip and Camomile, released under GPL 3.
<Yoric[DT]> [Example of the OCaml data structure representing the Hello World class]
<Yoric[DT]> XC: Cadimum = Java port of ocamlrun + runtime support for Cafesterol-compiled programs.
<Yoric[DT]> XC: When used as an interpreter, implements the whole bytecode instruction set except Tk.
<Yoric[DT]> XC: No dependencies, released under LGPL 3.
<Yoric[DT]> [Source: implementation of caml_string_get, looks more readable than the C version]
<Yoric[DT]> XC: Cafesterol, provides ocamljava, counterpart of ocamlc/ocamlopt. implements all language constructs, supports two compilation modes.
<Yoric[DT]> XC: Standalone mode or library sharing mode.
<Yoric[DT]> XC: Dependencies on Camlzip, Barista, sources for OCaml.
<Yoric[DT]> XC: Released under QPL v1.
<Yoric[DT]> XC: Let's compare ocamlc, ocamlopt, ocalmjava.
<Yoric[DT]> For interfaces, they produce .cmi/.cmi/.cmi .
<Yoric[DT]> For implementations, they produce .cmo/.cmx/.cmj .
<Yoric[DT]> For binaries, - / .o / .jo .
<Yoric[DT]> For libraries, .cma / .cmxa / .cmja .
<Yoric[DT]> For library binaries - / .a,.so / .jar
<Yoric[DT]> Default is dynamic linking (Java style), but standalone linking is available (OCaml) as well as linking as Applet or as Servlet.
<Yoric[DT]> XC: Nickel generates OCaml bindings for Java classes, uses OCaml object system and supports callbacks, for instance to implement event handlers. Java interfaces may be implemented in OCaml. No dependencies, GPL 3.
<Yoric[DT]> [Slide: the kind of file read by Nickel, a XML dialect that seems to describe Java type signatures]
<Yoric[DT]> XC: Constructing an instance is done by feeding a polymorphic variant. That's how we replace the several constructors.
<Yoric[DT]> XC: For an ActionListener, you just need to write the actionPerformed method and this will be used by the generated wrapper to create a class fit for use as an ActionListener.
<Yoric[DT]> XC: OCamlScripting provides a scripting engine for Java.
<Yoric[DT]> [Code: using the scripting engine to run dynamically compiled OCaml code inside Java]
<Yoric[DT]> XC: Compatibility issues : the implementation is big-endian.
<Yoric[DT]> XC: Unsafe features may behave differently, possibly fail badly.
<Yoric[DT]> XC: Some Unix primitives are emulated.
<Yoric[DT]> XC: Fonts are different for the graphics module.
<Yoric[DT]> XC: http://cadmium.x9c.fr/distrib/cadmium-compatibility.pdf -- list of all primitives and their difference with the original implementation.
<Yoric[DT]> XC: Compatibility of Cafesterol : Evaluation order is not the same as ocamlopt. This should not be a problem.
Demitar has quit [Read error: 110 (Connection timed out)]
<Yoric[DT]> XC: Object cache not implemented. This should not be a problem either, because it doesn't affect the semantics.
<Yoric[DT]> XC: Pending signals are checked at given points, which probably means less reactivity to Unix signals.
<Yoric[DT]> XC: Stack overflow / memory shortage are handled by Java, not by OCaml.
<Yoric[DT]> XC: There's rudimentary support for backtrace.
<Yoric[DT]> XC: Tail calls are optimized only for direct recursion.
<Yoric[DT]> XC: Are they optimized for mutual recursion in ocamlopt ?
<Yoric[DT]> XL: Yes.
<Yoric[DT]> XC: Well, in Java, it's contrary to semantics.
<Yoric[DT]> XC: So there's no easy optimization for this.
<Yoric[DT]> XC: Some very big functions may fail to compile due to a built-in limit for Java methods.
<Yoric[DT]> XC: In this case, turn off inlining or split your function.
<Yoric[DT]> XC: Roadmap: 1.0 alpha September 2007, beta scheduled for February, featuring some JDBC bindings plus bugfixes, 1.0 final scheduled for April.
<Yoric[DT]> XC: Later, compatibility, features and move to 1.6, as soon as it's available under MacOS X.
<Yoric[DT]> XC: 2.x, performance issues.
<Yoric[DT]> XC: 3.x, converge to OCaml version number.
<Yoric[DT]> [Demo]
<Yoric[DT]> [In Safari]
<Yoric[DT]> XC: Cadmium relies on Java reflection, you need to trust the applet.
<Yoric[DT]> XC: It's slow but the computer is 5 year-old.
<Yoric[DT]> [Fully-featured toplevel]
<Yoric[DT]> [Not that slow]
<Yoric[DT]> [Demonstrating factorial and #trace ]
<Yoric[DT]> [Display looks slow, but that's usual with Java]
<Yoric[DT]> [Demo 2]
<flux> hmm. idea: patch to toplevel to produce graphviz output with #trace
<Yoric[DT]> [Pseudo-drawing software, not very interesting as far as features are concerned]
<Yoric[DT]> [Source: open Cadmium open Graphics and about 60 lines of OCaml. The only difference with an usual application is that there are a few lines of registration at the end.]
<Yoric[DT]> [Demo of a UI written in Swing, with the implementation written in OCaml]
<Yoric[DT]> [Questions ?]
<Yoric[DT]> RWJ: Problems with 64 bits ?
<Yoric[DT]> XC: Currently 32 bits, because of an early decision. Need to check some semantics of Java.
<Yoric[DT]> (array lenghts)
<Yoric[DT]> XC: If you try to write the same implementation for 32bits and 64bits, you won't be able to create a large block.
<Yoric[DT]> RWJ: String length is it as in OCaml or Java ?
<Yoric[DT]> DT: Same set of command-line switches ?
<Yoric[DT]> XC: Plus additional switches, but yes.
<Yoric[DT]> DT: Do you believe I will be able to write an Eclipse plug-in in OCaml ?
<Yoric[DT]> XC: I hope so. At least, ocamlc and ocamlopt can be compiled and work.
<Yoric[DT]> Somebody Wang: What about performances ?
<Yoric[DT]> XC: Of course it's a major problem.
<Yoric[DT]> XC: According to my limited tests, Cafesterol-compiled programs are faster than Python or Ruby programs.
<Yoric[DT]> XC: So Cafesterol should be sufficient if you only need Python- or Ruby-speed.
<Yoric[DT]> XC: As marshalling is fully implemented, you can have Cafesterol-compiled source communicating with ocamlopt-compiled source.
<Yoric[DT]> XC: So for performance-intensive code, you can use that.
<Yoric[DT]> XC: But the more closures you use, the slower the program.
<Yoric[DT]> SW: Do you have ideas on how to improve performances ?
<Yoric[DT]> XC: I do.
<Yoric[DT]> XC: For instance, values are represented in Java in a very memory-consuming manner, so it puts lots of pressure on the GC and this has a large impact on performaces.
<Yoric[DT]> XC: I have a clear idea of what I have to do to improve performance.
<Yoric[DT]> XC: But features and compatibility first, I'll work on performance later.
<Yoric[DT]> XC: With a better encoding, we should have huge performance gains.
<Yoric[DT]> XC: At the moment, just tweaking the GC will help a lot. Performance of Cafesterol-compiled programs is very dependent on GC.
<Yoric[DT]> [Questions on how to remember which subproject does what]
<Yoric[DT]> 'd: A non-technical remark. I heard of your project before but I didn't look at it carefully. Just looking at the presentation, I believe it's an exciting project. It deserves improving, testing, etc. In my experience, based on Ocsigen, we started to find a lot of bugs and we started to improved Ocsigen a lot when people started using it.
<Yoric[DT]> 'd : 20 people was enough.
<Yoric[DT]> 'd : So put screenshots, examples, applets, etc. Attract people. I felt kind of lost on that website.
<Yoric[DT]> 'd : Tutorial, examples...
<Yoric[DT]> XC: I totally agree. I need more time. That's one of the two things I want to do for the beta : better website, simple examples and a binary distribution.
<Yoric[DT]> bluestorm: Did you run into problems with the binding of objects because of different models, in particular wrt inheritance ?
<Yoric[DT]> XC: Not really. The main problem is that OCaml only has one constructor per object.
<Yoric[DT]> XC: Oh, yeah, a naming problem, when several methods have the same parameters. We add apostrophes or we could rename them using the XML file.
<Yoric[DT]> DT: What is that XML file ?
<Yoric[DT]> XC: One XML file contains the information about all the Java classes you want to use. Then you pass this file to Nickel and it generates a .ml with type definitions and externals, a .java file containing the glue, and .c file defining all the externals needed by the ml file so that you can use ocamlc to compile your program.
<Yoric[DT]> XC: The .c file is just a stub to trick the linker.
<Yoric[DT]> XC: Oh, and you need to write the XML file yourself.
<Yoric[DT]> [Questions wrt name mangling]
<Yoric[DT]> AF: Looks like a huge project, especially for a hobby.
<Yoric[DT]> AF: Do you have any plans for it ?
<Yoric[DT]> XC: It started as a way to understand OCaml.
<Yoric[DT]> XC: So, just for fun.
<Yoric[DT]> XC: Well, that and F#.
<Yoric[DT]> XC: I prefer OCaml.
<Yoric[DT]> XC: But no precise project.
<Yoric[DT]> XC: This program can't be used on multicore architectures.
<Yoric[DT]> XC: It should have the same limitations as OCaml.
<Yoric[DT]> XL: You're bug-for-bug compatible :)
<Yoric[DT]> [ Coffee break ]
<pango> good idea ;)
ita has joined #ocaml
pango_ has joined #ocaml
<Yoric[DT]> [ General discussion ]
<Yoric[DT]> SLG: First subject : Unicode.
<Yoric[DT]> SLG: Necessary for instance for Unison, for international file names.
<Yoric[DT]> 'e: We need a mechanism to produce recommandation for libraries.
<Yoric[DT]> SLG: Something like JSR, yes.
<Yoric[DT]> SLG: Not just for Unicode.
<Yoric[DT]> SLG: There was something like this for ExtLib and IO classes.
<Yoric[DT]> GS: We have a document somewhere. We don't have nominal typings like Java, we can get around some things by using structural typings.
<Yoric[DT]> SLG: That's another point in the list, if we have nothing special to say about Unicode, we're going to pursue.
<Yoric[DT]> Philippe Wang: What about identifiers with accents ?
<Yoric[DT]> XL: We did that for Caml-Light.
<Yoric[DT]> XL: Should the syntax of OCaml accept Unicode in identifiers ? Presumably with a UTF-8 encoding, just like Java.
<Yoric[DT]> XL: I have considered that. Why not, at least for identifiers, there's no real problem, we can use the same kind of specifications of Java.
<Yoric[DT]> XL: The only difficulty is deciding for infix operators, so far we have only a few characters, with Unicode, the sky's the limit. Do you want to use Klingon ?
<Yoric[DT]> XL: That would not make the lexer much more complex.
<Yoric[DT]> PW: My point is that teaching that accents don't work is not the job of the teacher.
<Yoric[DT]> SLG: You say we should decide which operators are infix. Why don't we use Java's specifications ?
<Yoric[DT]> XL: Well, they don't have infix operators.
<Yoric[DT]> Martin Jambon: Oh, there's also the problem of uppercase vs. lowercase.
<Yoric[DT]> XL: There's a Java specification regarding that is uppercase and what is lowercase.
pango has quit [Remote closed the connection]
<Yoric[DT]> 'e: Why not say that everything >= 128 is lowercase ?
<Yoric[DT]> XL: Because you won't be able to have a constructor called gamma :)
<Yoric[DT]> RWJ: What about letting users decide precedence ?
<Yoric[DT]> XL: Because it won't work with the current OCaml parser.
<Yoric[DT]> DT: Where do we have that debate ?
<Yoric[DT]> XL: Let's start on the mailing-list and find people who are really interested. I'm open to suggestions.
<Yoric[DT]> SLG: Let's use the Cocan Wiki for that, too.
<Yoric[DT]> SLG: Let's create a section "OSR".
<Yoric[DT]> [Practical questions regarding Camlp4]
<Yoric[DT]> [Extending OCamlBuild to use findlib]
sergez__ has joined #ocaml
sergez__ has quit [Read error: 104 (Connection reset by peer)]
sergez__ has joined #ocaml
<Yoric[DT]> XL: Status of JoCaml is advanced prototype.
<ita> accents in identifier is one of the best obfuscation schemes
<Yoric[DT]> SLG: What about menhir ?
<Yoric[DT]> XL: It exists and it works well.
<Yoric[DT]> SLG: Will this replace ocamlyacc ?
<Yoric[DT]> XL: Possibly. I haven't discussed that with the author yet.
sergez__ has quit [Remote closed the connection]
<Yoric[DT]> bluestorm: What is the status of overloading of operators ?
<Yoric[DT]> XL: I'm not a big fan. It doesn't work very well with with type inference.
<Yoric[DT]> XL: It's all I can say at this point.
<Yoric[DT]> PW: Will there be formal specifications of OCaml ?
<Yoric[DT]> XL: Well, some people in Cambridge are working on formal specifications of Caml-light.
<Yoric[DT]> XL: It's good to have specifications, it's even better to be able to use them. I haven't checked that yet.
<Yoric[DT]> XL: It's a huge undertaking, so you need to balance the benefits vs. the effort.
<Yoric[DT]> PW: Maybe some people would want to write another OCaml.
<Yoric[DT]> XL: Not having specifications never prevented anyone from writing another compiler, so that's not really needed.
<Yoric[DT]> XL: Basically think how you could justify that to your boss.
<Yoric[DT]> PW: What about removing the parts that are not specified ?
<Yoric[DT]> XL: oO Well, that would require removing lots of things, starting with == .
<Yoric[DT]> XL: It's an old debate but in formal methods, you often leave things unspecified.
<Yoric[DT]> PW: What about evaluation order ? Obj ?
<Yoric[DT]> XL: Well, Obj isn't specified and will remain so.
<Yoric[DT]> RWJ: [Sorry, didnt' catch it]
<Yoric[DT]> 'f : Unrelated question. Sometimes, I find it interesting to have a repository of questions and answers to these difficult questions. Sometimes, questions are asked on the mailing-list and the answer essentially gets lost.
<Yoric[DT]> 'f : Sometimes the question is asked again but nobody remembers the answer. In particular wrt difficult typing issues.
<Yoric[DT]> XL: A FAQ wiki, why not ?
<Yoric[DT]> PW: What about renaming some functions in the standard library ? What about make vs. create ?
<Yoric[DT]> XL: Well, that won't change, for compatibility.
<Yoric[DT]> XL: Don't hesitate to work on ExtLib or something related.
<Yoric[DT]> XL: Oh, and pay attention to the name of your functions :)
<Yoric[DT]> RWJ: Can I get rid of every single definition including list and option ?
<Yoric[DT]> XL: oO Probably not everything, no.
<Yoric[DT]> 'g : What about the ability to create infix constructors ? I mean, Camlp4 lets you do that, but without Camlp4 ?
<Yoric[DT]> [Subject : Should we organize OCaml Summer of Codes ? What kind of code would we need ?]
<Yoric[DT]> SLG: Did anyone take part in Google Summer of Code ?
<Yoric[DT]> 'h : I have. It's quite agreeable. Everything is organized by you and your supervisor.
<Yoric[DT]> 'h : At the end you're evaluated as Passed or Fail, there's lots of freedom to decide almost everything.
<Yoric[DT]> 'h : They don't really care about the project, they just give the money.
<Yoric[DT]> XL: Jane Street Capital is probably going to organize that again this summer.
<Yoric[DT]> XL: Good place to work on OCaml or get your students to do so.
<Yoric[DT]> SLG: My problem is that there's no actual OCaml organization.
<Yoric[DT]> XL: You can use some other organization as a sponsor. Is there anything in France ?
<Yoric[DT]> SLG: Maybe INRIA or PPS ?
<Yoric[DT]> SLG: Maybe they could apply to Google SoC and get some money.
<Yoric[DT]> XL: Good idea, we should check.
<Yoric[DT]> 'i : Problem is you have to provide a mentor. Someone connected to the project.
<Yoric[DT]> 'j : I don't know, in GNU, we have the EFF, but the organization is very loose, mentoring is at most an exchange of 2-3 messages per week. So mentors might not be hard to find.
<Yoric[DT]> PL: Problem is usually not money but mentors.
<Yoric[DT]> PL: Universities have money, INRIA has money, what's lacking is mentors.
<Yoric[DT]> SLG: Any idea about subject ?
<Yoric[DT]> DT: What about an IDE ?
<Yoric[DT]> SLG: Well, ODT is good.
<Yoric[DT]> SLG: Or Cameleon.
<Yoric[DT]> DT: I personally can't even run it in Debian...
<Yoric[DT]> SLG: Well, it breaks every time.
<Yoric[DT]> SLG: We often can't compile it at all.
ita has quit ["Hasta luego!"]
dbueno has joined #ocaml
<Yoric[DT]> SLG: We weren't even informed that repositories had moved or that there was a Cameleon 2.
<Yoric[DT]> SLG: So Cameleon is probably not the perfect idea.
<Yoric[DT]> SLG: But Eclipse is good, you don't need to redo everything.
dbueno has left #ocaml []
thermoplyae has joined #ocaml
<Yoric[DT]> SLG: If you want to submit Summer of Code subjects, put it on COCAN.
<Yoric[DT]> SLG: Now, let's organize the next meeting.
<Yoric[DT]> SLG: In 6 months, if you find that this meeting was useful, let's start and organize it. I might not be able to handle it.
<Yoric[DT]> [Goodbye, applause]
<Yoric[DT]> Ok, I'll put the minutes on my blog.
Morphous has joined #ocaml
<Yoric[DT]> Bye everyone.
Yoric[DT] has quit ["Ex-Chat"]
Amorphous has quit [Connection timed out]
opening has quit [Connection timed out]
Morphous is now known as Amorphous
marmottine has quit [Read error: 113 (No route to host)]
ben has quit []
marmottine has joined #ocaml
Ogedei has joined #ocaml
bluestorm has joined #ocaml
Tetsuo has quit [Remote closed the connection]
elus has quit [Connection timed out]
asmanur has quit [Connection timed out]
Snark has quit ["Ex-Chat"]
asmanur has joined #ocaml
girafe has joined #ocaml
asmanur has quit [Remote closed the connection]
ygrek has joined #ocaml
darinm has joined #ocaml
<middayc> bye (I was reading - and have some more reading to do, thanks)
darinm_ has joined #ocaml
darinm has quit [Connection timed out]
darinm_ is now known as darinm
ttamttam has left #ocaml []
darinm has quit []
darinm has joined #ocaml
girafe has quit ["Quitte"]
darinm has quit []
marmottine has quit [Remote closed the connection]
ygrek has quit [Remote closed the connection]
Demitar has joined #ocaml
ramenboy has quit [Remote closed the connection]
szell has joined #ocaml
middayc has quit []
cybercobra has joined #ocaml
<cybercobra> besides .net compatibility, are there any major differences between F# and ocaml?
<cygnus_> so it's like a suckier version of ocaml?
<bluestorm> cybercobra: yes there are
<bluestorm> F# doesn't implement some cool features of OCaml
<pango_> it probably have features OCaml doesn't have, I think this page only lists the OCaml's features not supported by F#
<cygnus_> i have a question
<bluestorm> adds some cool features, and some useless ones
<cygnus_> can ocaml compete with haskell i nthe long term?
<cygnus_> it seems ahskell has more community support
<bluestorm> cygnus_: on what front ?
<cybercobra> hm. in that case, what's the best Ocaml book?
<bluestorm> cybercobra: on the net, or in library ?
<cybercobra> bluestorm: dead-tree
<bluestorm> hm
<bluestorm> actually i don't know about good english books
<cybercobra> I only found a few on Amazon, and most have bad reviews
<cygnus_> is the ocaml reference manual so hard to read cause it was transltead from french?
<cybercobra> which is why I was asking about Ocaml-F# similarity as a good book on F# recently came out
<bluestorm> cygnus_: i don't think it was translated from french
<bluestorm> cygnus_: how dyou know it's good ?
<bluestorm> if you can find "Developing Applications With Objective Caml", it's quite good
<cygnus_> what's good
<bluestorm> but i'm not sure this translated version got printed
<pango_> bluestorm: from what I've heard, it didn't
<bluestorm> cygnus_: Haskell is not OCaml, so there are places where they can't compete
<cygnus_> where is that?
<bluestorm> basically, Haskell won't replace OCaml as a good eager impure functional language
<bluestorm> because it isn't
<cybercobra> also, "string_of_int"? wtf is with the weird naming?
<mbishop> that's weird?
<cygnus_> when does this matter ?
<bluestorm> and OCaml is not likely to replace Haskell as an good pure lazy functional language
<bluestorm> hm
<mbishop> better than stringOfInt
* mbishop shudders
<bluestorm> cygnus_: string_of_int, int_of_string ?
<cybercobra> string_to_int seems more normal
<bluestorm> doesn't sounds that bad
<bluestorm> hm
<bluestorm> cygnus_:
<bluestorm> lazy evaluation has performances and memory issues
<bluestorm> and i'd say "clarity" issue too
<cygnus_> why does haskell have more support than ocaml?
<bluestorm> on the other hands, it sometimes is a big win
<cybercobra> cygnus_: trendier
<mbishop> cygnus_: does it?
<bluestorm> (of course you can have lazy evaluation with Ocaml, but explicit)
<bluestorm> cygnus_: the community is more noisy
<bluestorm> wich is good
<bluestorm> (for Haskell, i mean)
<bluestorm> why that, i don't precisely know
<cybercobra> cygnus_: Pugs gave it a fairly recent visibility boost
<bluestorm> but i suspect it it's language-related
<bluestorm> hm
<bluestorm> it's *not* lanugage-related
<bluestorm> :D
<cygnus_> i use ocaml at work but yeah i just wonder
<cygnus_> i don't really know much about ocaml and haskell
<cygnus_> but i like to understand how things are
<bluestorm> cygnus_: for example that may have something to do with the fact that Ocaml is more a french thing, and Haskell an english/USA one
<cygnus_> ye i think so
<bluestorm> but hm
<cygnus_> i think you're right
<bluestorm> i think Haskellers just were good with community handling and so on
<cygnus_> i find ocaml to look a bit ugly also
<bluestorm> wich ocamlers have not always been, i guess
<bluestorm> hm
<bluestorm> cygnus_: this is an habit question
<bluestorm> write ocaml code for a few weeks and you'll get used to it
<cygnus_> i think if the manual was better it would have more support too
<bluestorm> (i don't say ocaml doesn't have syntaxic issues, but all languages do, and of course Haskell too)
<bluestorm> hm
<bluestorm> the manual is quite good to my eyes
<hcarty> The development of OCaml is (from what I understand) more closed than Haskell - at least GHC
<bluestorm> synthetic and precise
<bluestorm> what would you want ?
<cygnus_> chapter 3 doesn't flow a logical order of introducing things
<bluestorm> (it's a "reference manual", not the preferred ocaml course)
<mbishop> ocaml can be a bit ugly, but it's more pratical than it's prettier sister SML
<bluestorm> did you begin Haskell by reading the 98 report ?
<cygnus_> no
<cygnus_> but i would have thought that since i knew some ocaml i could understand the ref manual
<cygnus_> but all of the type stuff is not expalined still
<bluestorm> hm
<cybercobra> i'd say the lack of a good english dead-tree book might be a factor. Haskell has several.
<cygnus_> cybercobra, that's what my boss sead
<mbishop> I think Harper is planning on releasing a book
<mbishop> there is a new draft out
<cybercobra> mbishop: power to them
<cygnus_> mbishop: got a link?
<bluestorm> mbishop: i'd be interested in a link too
<bluestorm> hm
<mbishop> there was an older draft out before
<mbishop> but he recently updated it
<bluestorm> is that the new Jason Hickey stuff ?
<bluestorm> hm, it is :p
<mbishop> oh, yes, did I say Harper? my bad :P
<cygnus_> thanks
<mbishop> but according to the warning on the title page, it may possibly be published
<cygnus_> good it doesn't ahve crazy watermarks or something
<cygnus_> i asked a few phd guys is lisp the best langauge? cause i heard it is from some people and the ysaid haskell and ocaml are replacing it , is this true?
<bluestorm> depends on what you want
<cygnus_> when is lisp the best
<bluestorm> (i think most lispers these days are turning to Scheme)
<bluestorm> cygnus_: moreover, there are languages wich are interesting to learn even if you actually don't *program* with them
<bluestorm> Haskell is one of those
<bluestorm> i haven't learned Lisp yet, but i guess it may be
<cygnus_> ok
<bluestorm> cygnus_: one interesting thing about lisp/scheme is that they can be seen as "the ancesters" of nowadays ML-based languages
<cybercobra> lisp is only neat for the macros and pervasive use of lists
<bluestorm> you've got the idea of functional programming, minus the typing and the ADT/patterns
<bluestorm> (and on the other hand you've got macros)
<bluestorm> but this "simplicity" of lisp/scheme might be interesting
<bluestorm> i guess this is why some people use it for teaching
bluestorm has quit ["Konversation terminated!"]
Snrrrub has joined #ocaml
l_a_m has quit [Remote closed the connection]
<hcarty> mbishop: Thanks for the pointer to the updated book
middayc has joined #ocaml
cybercobra has left #ocaml []
AxleLonghorn has joined #ocaml
AxleLonghorn has left #ocaml []