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
time.
Friendly,
Sven Luther
Reply to: