hey Marvin, On Fri, Nov 5, 2010 at 12:30 AM, Marvin Humphrey <[email protected]> wrote: > Greets, > > Most of Lucy's documentation has been written so that it will work with > multiple host languages. To the extent possible, class descriptions, method > descriptions and so on are host-language neutral -- only code samples need be > customized. > > Our multi-chapter Tutorial is still Perl-specific, however. It would be great > if we could adapt it for use across multiple host languages -- but right now, > it has dependencies which will not be available for every language/platform > combination. That would be absolutely awesome I am not really into perl (shame on me I know) and something like that would definitly help me a lot. I find myself in the situation where I am gonna need it sooner or later :) > > Currently, the tutorial builds sample applications designed to be used in a > web context using an HTML presentation of the United States Constitution as a > corpus. For HTML parsing, CGI processing, and paging through results, we use > dedicated Perl modules, some of which belong to the Perl core and some of > which must be obtained from CPAN. > > To eliminate these dependencies, I think the Tutorial should be simplified to > build a command-line app, and the corpus should be changed to plain text. > Every potential host language has basic file and directory manipulation > capabilities; it should be possible to generalize the tutorial prose so that > it can work with all of them without modification. +1 > > Additionally, by eliminating those CPAN prerequisites entirely, we skirt the > issue of dependency licensing. awesome again! > > The only downside is that easily-customizable sample applications are > compelling (see Ruby on Rails), and we'll be taking our "instant web search" > kit and making it less handy.
I know it would be an overhead but could we maintain that aside of the getting started example? simon > > We face a similar challenge with the CustomQueryParser Cookbook entry > -- which uses Parse::RecDescent -- but that will be harder to resolve. I'm > not sure what to do about that one, except possibly remove it from the > distribution and publish it elsewhere as an independent article. > > Marvin Humphrey > >
