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
