On Thursday, 02 August 2007 02:06:04 am Jeremy Huntwork wrote: > The libxml and libxslt stuff could be dropped if we were to make use of > a C or C++ based parser. I know George M. was working heavily on a > solution, but I don't know his current status. The one that is in the > alfs-POC works well enough (I'm sure there's bugs that need to be fixed, > but it was working last I checked.) > > -- > JH
With a bit of delay, a public reply to Mr. Jeremy Huntwork with the most noble of intents. First of all I would like to thank you for remembering my contributions despite inter(active)net eons have passed since last year, and we have not talked about it since. The approach I have been working on, single - handed, and in complete _ob_scurity since the advent of certain issues, is now totally completed in its design, extendibility and C++ based implementation. Parts of it have found their way into the alfs-POC SVN (and _not_ viceversa) in the past, as stated by you (Jeremy Huntwork) in various occasions. Believe it or not, I am able to build what I was set out to build with it; and yes, UTF-8 is not a problem at all, or any other encoding for that matter. Neither are many other things that will eventually emerge for you in here. And it also has _no_ external dependencies whatsoever. For the sake of completion, I will simply re - post a particular part of older code, as it was posted in the mailing list after a rather unfortunate series of events. I have talked to you about it Jeremy H., you do remember when, how, where, with what and for what, right? It was dubbed "xnzyme". I have given that name up since then. The interested reader can find many other POC (and not so POC..) within the alfs mailing list spanning both as bash - based(with their obvious pitfalls for when the project management was _convinced_ that bash was all that was necessary) and C++ std::string based ones (std::string was used for the commodity of implementation, for it is unsuitable for the task beforehand given its limitations) posted by yours truly. Therefore I consider the link below useful point of reflection regarding how some things may, and most importantly may not (to the trained eye) be done: http://linuxfromscratch.org/pipermail/alfs-discuss/2006-December/009077.html To date, that was my last reply ever to *lfs and *lfs related lists. Further details can be seen there and here. I wish to everybody good luck for _their_ particular *lfs automation framework implementation in their language of choice. It is possible that something better than Portage / Paludis - based Gentoo, Sourcemage, Archlinux, T2, Lunarlfs, etc can emerge from these lists and eventually enter the perennial circle of cross - pollination among GPL projects. Concerning my personal project, I will eventually release a _GPLv3_ (three) licensed version of the entire project I have been working on, when _circumstances_ will be mature for it. The project treats the problem of automation in general when building distributions from source, therefore it cannot be considered an *lfs/derivate contribution for it is to share very different goals with the automation infrastructure as it is to be built for *lfs/derivative by official lfs contributors. It will have its own little spot in the inter(active)net, its own Mercurial repositories etc. I would like to thank the many people who emailed me during this period (readers and non of these lists), requesting information for both bash - based and C++ - based concepts regarding the aforementioned attempts. Cursum Perficio. Age quod agis. George Makrydakis -- http://linuxfromscratch.org/mailman/listinfo/alfs-discuss FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
