[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: ocaml and lindows.com

On Wed, Nov 05, 2003 at 04:59:51PM -0800, David FOx wrote:
> Stefano Zacchiroli wrote:
> >David Fox said:
> > 
> >
> >>Sure, why not?  I don't think it will be all that much work, I tried it
> >>out on Pcre and it was pretty quick.  Heck, I'll pay for it myself as
> >>long as there are no unions involved!  Where should I send the check?
> >>:-)
> >>   
> >>
> >
> >I will mail my bank account number to lindows CEO then :-)))
> >
> >Seriously, we already discussed the split of bytecode/native code for
> >libraries a long ago (check the archive, but it wont be east due to the
> >bad habit of this list of not changing subject when needed). We reached
> >the conclusion that is not wort the effort because it will almost double
> >the number of ocaml debian packages and actually dpkg database has serious
> >scaling problem wrt the number of available packages.
> >Last time we discussed it we decided this disavantage overrules the
> >benefits. If you think pcre deserves a special treatment we can discuss
> >it, but it will be hard for you to convince me that it's actually the case
> >:)
> >BTW I think that the subscribers of this list are interested in knowing in
> >more details what you, as lindows, are doing with debian and especially
> >with the packages we maintain. It's nice to know our work is useful for a
> >company, we can think at it as a "success story" ...Maybe you can sent 
> >here a brief description of your work (possibly in a
> >separate thread ;-)?
> >TIA,
> >Cheers.
> > 
> >
> We have done several projects here using ocaml, because me and two other 
> senior engineers here have a long history with functional programming 
> languages.  I wrote the back end of the Click-n-Run software warehouse 
> in ocaml.  This takes the Debian repository and reprocesses all the 
> packages to generate the database information used by the front end (the 
> catalogue) and modifies the packages so that they fit into our 
> distribution, modifying and generating KDE menu entries and so forth.  
> This turns out to be a little more complicated than it first sounds, 
> because you have to modify the version numbers on the packages, and then 
> you have to modify all the equals dependencies, and so on and so forth.

Well, i have begun work on a little source snapshot tool (it takes a
given list of binary packages and version, transform them to source
version, and should go download the corresponding sources at
snapshot.debian.org, but i didn't finish it). Goswin also has some ocaml
tools for making debian mirrors, or something such. There is also ara in
the archive, altough i don't remember who wrote it.

Maybe it is time for writing a common ocaml library for interaction with
ocaml packages list and such, should not be all that difficult, but
would beat having everyone implement their own version of it.

I have also been thinking about a full dpkg/apt ocaml reimplementation
in ocaml, but never had the time for it. A full coq proven and generated
implementation would be sweet too, but a lot of work.

> The other major use is in our new hardware detection system.  I 
> basically did a literal translation of a lot of perl code we inherited, 
> which is my excuse why it is still pretty ugly.  But it had to be 
> drop-in compatible.  This version isn't available for download yet, but 
> it will be late in the year.  There are ocaml components that manage the 
> boot loader, the PCI device mapping, and the X configuration.

Woaw, you do hardware detection in ocaml, nice.

Here too a low level hardware access library would be a good common
thing. I have been wanting to do graphic chip programming since some


Sven Luther

Reply to: