Re: NUCULAR fielded text searchable indexing
On Oct 17, 7:20 am, Steve Holden [EMAIL PROTECTED] wrote: I still remember Gadfly fondly. What a great piece of software Gadfly is ... congrats on that Aaron. For me it was one of the first Python packages that truly stood out and made me want to learn Python. i. -- http://mail.python.org/mailman/listinfo/python-list
Re: NUCULAR fielded text searchable indexing
On Oct 17, 7:20 am, Steve Holden [EMAIL PROTECTED] wrote: [EMAIL PROTECTED] wrote: (see the graphic at the bottom of http://nucular.sourceforge.net) It's a shame the name obscures rather than enlightens. Your stuff is usually pretty good - I still remember Gadfly fondly. Sorry you feel that way about the name, Steve :(. I thought it was funny and eye catching. I'm glad you remember Gadfly (http://gadfly.sourceforge.net). Still distributed with many packages (including Zope, I think). Still getting 5-20 downloads a day on sourceforge. Not bad for a package released back in '94, eh? -- Aaron Watters === The method employed I would gladly explain, While I have it so clear in my head, If I had but the time and you had but the brain-- But much yet remains to be said. -- http://www.xfeedme.com/nucular/gut.py/go?FREETEXT=snark -- http://mail.python.org/mailman/listinfo/python-list
Re: NUCULAR fielded text searchable indexing
[EMAIL PROTECTED] wrote: On Oct 8, 7:00 pm, Delaney, Timothy (Tim) [EMAIL PROTECTED] wrote: [EMAIL PROTECTED] wrote: ANNOUNCE: NUCULAR fielded text searchable indexing Does NUCULAR stand for anything? The (apparent) misspelling of nuclear has already turned me off wanting to find out more about it. Tim Delaney No, it doesn't stand for anything. I guess it's not for you :(. Sorry about that. (see the graphic at the bottom of http://nucular.sourceforge.net) It's a shame the name obscures rather than enlightens. Your stuff is usually pretty good - I still remember Gadfly fondly. regards Steve -- Steve Holden+1 571 484 6266 +1 800 494 3119 Holden Web LLC/Ltd http://www.holdenweb.com Skype: holdenweb http://del.icio.us/steve.holden Sorry, the dog ate my .sigline so I couldn't cat it -- http://mail.python.org/mailman/listinfo/python-list
Re: Fwd: NUCULAR fielded text searchable indexing
On Oct 12, 2:01 am, Paul Rubin http://[EMAIL PROTECTED] wrote: [EMAIL PROTECTED] writes: That's reasonable speed, but is that just to do the set intersections and return the size of the result set, or does it retrieve the actual result set? It only showed 20 results on a page. I notice that each book in the result list has an ID number. Say those are stored fields in Nucular: how long does it take to add up all the ID numbers for the results of that query? I.e. the requirement is to actually access every single record in order to compute the sum. This is similar to what happens with faceting. Adding up the id numbers would be fast (since you have them after you've evaluated the query), but finding the median title would be slower, which is what I think you had in mind. Yes, pulling in the the complete description for every document in the result set would probably be much slower with a disk based index (because you would have to seek all over the index files). Of course if you are using the flash drive you mentioned it might not be that slow either... and it looks like this is the direction things are going... Heh, check out the benchmark graphs: http://www.tomshardware.com/2006/09/20/conventional_hard_drive_obsole... My point exactly :)... Thanks again -- Aaron Watters give me chocolate and no one gets hurt. (from a tee shirt) -- http://mail.python.org/mailman/listinfo/python-list
Re: Fwd: NUCULAR fielded text searchable indexing
| | http://www.tomshardware.com/2006/09/20/conventional_hard_drive_obsole... Unclipped link is http://www.tomshardware.com/2006/09/20/conventional_hard_drive_obsoletism/ -- http://mail.python.org/mailman/listinfo/python-list
Re: Fwd: NUCULAR fielded text searchable indexing
[EMAIL PROTECTED] writes: http://www.xfeedme.com/nucular/gut.py/go?FREETEXT=w (w for web) we get 6294 entries which takes about 500ms on a cold index and about 150ms on a warm index. This is on a very active shared hosting machine. That's reasonable speed, but is that just to do the set intersections and return the size of the result set, or does it retrieve the actual result set? It only showed 20 results on a page. I notice that each book in the result list has an ID number. Say those are stored fields in Nucular: how long does it take to add up all the ID numbers for the results of that query? I.e. the requirement is to actually access every single record in order to compute the sum. This is similar to what happens with faceting. You are right that you might want to use more in-process memory for a really smart, multi-faceted relevance ordering or whatever, but you have to be willing to pay for it in terms of system resources, config/development time, etcetera. If you want cheap and easy, nucular might be good enough, afaik. I used a cave-man approach with solr, which is I have an external process keeping the indexes warm by simply reading something from each page a few times an hour. That is enough to pull 10k or so results a second from a query. Without the warming, getting that many results takes over a minute. I do think much better approaches are possible and solr/lucene is by no means the be-all and end-all. I don't know if solr is using mmap or actual seek system calls underneath. Regarding the 30 million number -- I bet google does estimations and culling of some kind (not really looking at all 10M). Probably. I'm not interested in really addressing the google size of data set at the moment. Right, me neither, but a few 10's of GB of indexes is not all that large these days. http://www.newegg.com/Product/Product.aspx?Item=N82E16820147021 holy rusty metal batman! way-cool! Heh, check out the benchmark graphs: http://www.tomshardware.com/2006/09/20/conventional_hard_drive_obsoletism/page7.html -- http://mail.python.org/mailman/listinfo/python-list
Re: Fwd: NUCULAR fielded text searchable indexing
On Oct 11, 3:30 am, Paul Rubin http://[EMAIL PROTECTED] wrote: Delaney, Timothy (Tim) [EMAIL PROTECTED] writes: As for [ http://nucular.sourceforge.net ] itself, I've only had a chance to glance at the site... Thanks for taking a look. I hope you don't mind if I disagree with a number of your comments below. ...but it looks a little more akin to Solr than to Lucene. Solr is a Java application that wraps Lucene to present a more convenient interface I'm not sure but I think nucular has aspects of both since it implements both the search engine itself and also provides XML and HTTP interfaces, like http://www.xfeedme.com/nucular/gut.py/go ...although it does this using XML over an HTTP socket. One thing about Solr and probably anything else like this: if you want to handle a high query load with big result sets, you absolutely must have enough ram to cache your entire index. ... Of course it would be nice to have everything in RAM, but it is not absolutely necessary. In fact you can get very good performance with disk based indices, especially when the index is warm and the most heavily hit disk buffers have been cached in RAM by the file system. As a test I built an index with 10's of millions of entries using nucular and most queries through CGI processes clocked in in 100's of milliseconds or better -- which is quite acceptable, for many purposes. ...Since ram is expensive and most of it will be sitting there doing nothing during the execution of any query, it follows that you want multiple CPU's sharing the ram. So we're back to the perennial topic of parallelism in Python... ...Which is not such a big problem if you rely on disk caching to provide the RAM access and use multiple processes to access the indices. The global interpreter lock (GIL) can be kinda nice sometimes too. When I built the big indices mentioned above it took a long time. If I had used a multithreaded build my workstation would have been worthless during this time. As it was I was using Python in a single process, so the other CPU was happy to work with me during the build, and I hardly noticed any performance degradation. In one java shop I worked in the web interface worked ok (not great) provided it was only hit by one access at a time, because the system was engineered so that one access consumed all computational resources on the box. Of course if you hit it continually with 4 concurrent accesses the system went to its knees and got tangled up in livelocks and other messes. In the case of web apps it can be very nice to have one access handled by one process in one thread leaving the other cpu's available to handle other accesses or do other things. imho, fwiw, ymmv, rsn, afaik. -- Aaron Watters === even in a perfect world where everyone is equal i'd still own the film rights and be working on the sequel -- Elvis Costello Every day I write the book -- http://mail.python.org/mailman/listinfo/python-list
Re: Fwd: NUCULAR fielded text searchable indexing
[EMAIL PROTECTED] writes: ...but it looks a little more akin to Solr than to Lucene. ... I'm not sure but I think nucular has aspects of both since it implements both the search engine itself and also provides XML and HTTP interfaces That sounds reasonable. As a test I built an index with 10's of millions of entries using nucular and most queries through CGI processes clocked in in 100's of milliseconds or better -- which is quite acceptable, for many purposes. How many items did each query return? When I refer to large result sets, I mean you often get queries that return 10k items or more (a pretty small number: typing python into google gets almost 30 million hits) and you need to actually examine each item, as opposed to displaying ten at a time or something like that (e.g. you want to present faceted results). So we're back to the perennial topic of parallelism in Python... ...Which is not such a big problem if you rely on disk caching to provide the RAM access and use multiple processes to access the indices. Right, another helpful strategy might be to use a solid state disk: http://www.newegg.com/Product/Product.aspx?Item=N82E16820147021 -- http://mail.python.org/mailman/listinfo/python-list
Re: Fwd: NUCULAR fielded text searchable indexing
regarding http://nucular.sourceforge.net On Oct 11, 12:32 pm, Paul Rubin http://[EMAIL PROTECTED] wrote: How many items did each query return? When I refer to large result sets, I mean you often get queries that return 10k items or more (a pretty small number: typing python into google gets almost 30 million hits) and you need to actually examine each item, as opposed to displaying ten at a time or something like that (e.g. you want to present faceted results). I can't give a detailed report. I think 10k result sets were not unusual or noticably slower. Of the online demos, looking at http://www.xfeedme.com/nucular/gut.py/go?FREETEXT=w (w for web) we get 6294 entries which takes about 500ms on a cold index and about 150ms on a warm index. This is on a very active shared hosting machine. You are right that you might want to use more in-process memory for a really smart, multi-faceted relevance ordering or whatever, but you have to be willing to pay for it in terms of system resources, config/development time, etcetera. If you want cheap and easy, nucular might be good enough, afaik. Regarding the 30 million number -- I bet google does estimations and culling of some kind (not really looking at all 10M). I'm pretty sure of this because in some cases I've looked at all results available and it turned out to be a lot smaller than the estimate on the first page. I'm not interested in really addressing the google size of data set at the moment. http://www.newegg.com/Product/Product.aspx?Item=N82E16820147021 holy rusty metal batman! way-cool! thanks, -- Aaron Watters === less is more -- http://mail.python.org/mailman/listinfo/python-list
Re: Fwd: NUCULAR fielded text searchable indexing
Delaney, Timothy (Tim) [EMAIL PROTECTED] writes: In the case of nucular, it's a mispronunciation that has been widely ridiculed all over the world. There are people (including myself) who so associate it as an object of ridicule that it's an immediate turn-off. It gave me a chuckle, since it's an obvious play on the mispronunciation. As for the program itself, I've only had a chance to glance at the site, but it looks a little more akin to Solr than to Lucene. Solr is a Java application that wraps Lucene to present a more convenient interface, although it does this using XML over an HTTP socket. One thing about Solr and probably anything else like this: if you want to handle a high query load with big result sets, you absolutely must have enough ram to cache your entire index. Since ram is expensive and most of it will be sitting there doing nothing during the execution of any query, it follows that you want multiple CPU's sharing the ram. So we're back to the perennial topic of parallelism in Python... -- http://mail.python.org/mailman/listinfo/python-list
Re: NUCULAR fielded text searchable indexing
On 9 Okt, 22:32, [EMAIL PROTECTED] wrote: Well I'd like people to use the software because they think it's good. If the name is a problem it's probably only the first of many reasons they won't want to use it or will not like it because it doesn't match their preconceptions. Please ignore the fuss about the name - I guess you didn't spend the required three months pre-hyping the project on a blog, thus not getting buy in from the impatient masses - and tell us how the software compares to stuff like Lucene or Xapian. Paul -- http://mail.python.org/mailman/listinfo/python-list
Re: NUCULAR fielded text searchable indexing
[Paul] tell us how the software compares to stuff like Lucene or Xapian. +1 -- Richie -- http://mail.python.org/mailman/listinfo/python-list
Re: NUCULAR fielded text searchable indexing
On Oct 10, 6:05 am, Paul Boddie [EMAIL PROTECTED] wrote: On 9 Okt, 22:32, [EMAIL PROTECTED] wrote: ...tell us how the [ http://nucular.sourceforge.net ] software compares to stuff like Lucene or Xapian... I wish I could, honestly. I've looked briefly into trying to put together some sort of comparisons, but I find the documentation for both the systems mentioned quite forbidding. I certainly don't want to spend as much time developing comparisons with other projects as I did developing nucular :). For the moment I will make the completely unbiased suggestion that nucular indices may be a lot easier to set up and use than either Lucene or Xapian, particularly from a Python programming perspective. It's also not immediately clear to me whether Xapian and Lucene support completely unrestricted numbers and combinations of fields, but I'm not sure. I'll see if I can come up with something better than that... As a side note, if you do benchmarks, please don't use the Lucene benchmark query taken from http://lucene.apache.org/java/docs/benchmarks.html namely, Query: +Domain:sos +(+((Name:goo*^2.0 Name:plan*^2.0) (Teaser:goo* Tea ser:plan*) (Details:goo* Details:plan*)) -Cancel:y) +DisplayStartDate: [mkwsw2jk0 -mq3dj1uq0] +EndDate:[mq3dj1uq0-ntlxuggw0] Because I expect nucular will perform very poorly on this query (since it can't even implement it). I put a set of query features that I thought was suitable for most purposes into nucular. Others may appear in later releases, but the one's that are there cover the most common needs, I think. I would prefer benchmarks that compared simple common examples, not obscure complicated ones. -- Aaron Watters === if you want a friend, get a dog. -- Truman -- http://mail.python.org/mailman/listinfo/python-list
Re: Fwd: NUCULAR fielded text searchable indexing
On 2007-10-09, Bill Hamilton [EMAIL PROTECTED] wrote: On 10/9/07, Grant Edwards [EMAIL PROTECTED] wrote: On 2007-10-09, Robin Becker [EMAIL PROTECTED] wrote: [EMAIL PROTECTED] wrote: On Oct 9, 8:46 am, Istvan Albert [EMAIL PROTECTED] wrote: ps. there is a python project named The Devil Framework, I cringe every time I hear about it.Nucularis not as bad, but it is close. Aw shucks. I thought it was funny. Can't I make fun of politicians in my open source projects? Besides there is a great tradition of tounge-in-cheek package names, like Cold fusion, for example. ... I think it's an excellent name :) And Bush would probably pronounce it Nuke-lee-ur. I dislike Bush as much as the next guy, but could we please keep politics off the group? I say, it's a joke, son! And there's nothing political about it. The joke is predicated on the incongruity between the superficial logic of the statement and reality. The superficial part is the assumption that somebody who swaps two syllables when pronouncing a word will swap them back when the word is _spelled_ with them swapped. The reality is that's not they way language processing works the human brain. There's also some incongruity in the assumption that George Bush would be discussing an obscure Python library. OK, it wasn't _that_ funny, but there wasn't anything even remotely political about it. I just needed somebody who is widely know to mis-pronounce nuclear as nuke-you-lar. Jimmy Carter would have worked just as well -- a little better, actually, since he graduated from the Nuclear Engineering program at the US Naval Acadamy, and the mere fact that he mispronounces nuclear is sort of incongruous. But, there probably aren't that many people who remember how Jimmy Carter pronounced the work nuclear, or that he had a degree in nuclear engineering. Anyway, I apologize for my attempt at humor, since it appears to have somehow offended. -- Grant Edwards grante Yow! The Osmonds! You are at all Osmonds!! Throwing up visi.comon a freeway at dawn!!! -- http://mail.python.org/mailman/listinfo/python-list
RE: Fwd: NUCULAR fielded text searchable indexing
From: Grant Edwards Anyway, I apologize for my attempt at humor, since it appears to have somehow offended. Why apologize? If someone doesn't like the name given to a piece of software by its author(s), screw them. If I find the software useful, I'll use it. Even if its called 'bouncingBetty'. Actually, I might try it, just because of the name, but you get my point. The information contained in this message and any attachment may be proprietary, confidential, and privileged or subject to the work product doctrine and thus protected from disclosure. If the reader of this message is not the intended recipient, or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please notify me immediately by replying to this message and deleting it and all copies and backups thereof. Thank you. -- http://mail.python.org/mailman/listinfo/python-list
Re: Fwd: NUCULAR fielded text searchable indexing
On Oct 10, 11:08 am, [EMAIL PROTECTED] wrote: Why apologize? If someone doesn't like the name given to a piece of software by its author(s), screw them. If I find the software useful, I'll use it. Even if its called 'bouncingBetty'. Or 'BeautifulSoup' for that matter ;-) George -- http://mail.python.org/mailman/listinfo/python-list
RE: Fwd: NUCULAR fielded text searchable indexing
[EMAIL PROTECTED] wrote: From: Grant Edwards Anyway, I apologize for my attempt at humor, since it appears to have somehow offended. Why apologize? If someone doesn't like the name given to a piece of software by its author(s), screw them. If I find the software useful, I'll use it. Even if its called 'bouncingBetty'. Actually, I might try it, just because of the name, but you get my point. I agree entirely (being the person who started this). There is a difference between using a word though that has existing connotations for a lot of people, and one that doesn't. In the case of nucular, it's a mispronunciation that has been widely ridiculed all over the world. There are people (including myself) who so associate it as an object of ridicule that it's an immediate turn-off. If you want to keep using the name, so be it - no skin off my nose. But I couldn't mention NUCULAR here at work (Australia) for oh so many reasons ... Tim Delaney -- http://mail.python.org/mailman/listinfo/python-list
RE: NUCULAR fielded text searchable indexing
[EMAIL PROTECTED] wrote: ANNOUNCE: NUCULAR fielded text searchable indexing Does NUCULAR stand for anything? The (apparent) misspelling of nuclear has already turned me off wanting to find out more about it. Tim Delaney -- http://mail.python.org/mailman/listinfo/python-list
Re: NUCULAR fielded text searchable indexing
On Oct 8, 7:00 pm, Delaney, Timothy (Tim) [EMAIL PROTECTED] wrote: [EMAIL PROTECTED] wrote: ANNOUNCE: NUCULAR fielded text searchable indexing Does NUCULAR stand for anything? The (apparent) misspelling of nuclear has already turned me off wanting to find out more about it. Tim Delaney No, it doesn't stand for anything. I guess it's not for you :(. Sorry about that. (see the graphic at the bottom of http://nucular.sourceforge.net) -- Aaron Watters === An apple every 8 hours will keep 3 doctors away. (kliban) -- http://mail.python.org/mailman/listinfo/python-list
Re: NUCULAR fielded text searchable indexing
On Oct 9, 7:26 am, [EMAIL PROTECTED] wrote: No, it doesn't stand for anything. It also reminds me of someone we all know, and I wish it didn't. As the latin proverb says Nomen est omen. Calling your package docindexer would draw a lot more people. It is hard to justify to a third party that a project named nucular actually does something useful. It looks like a great piece of work otherwise. Congrats. ps. there is a python project named The Devil Framework, I cringe every time I hear about it. Nucular is not as bad, but it is close. -- http://mail.python.org/mailman/listinfo/python-list
Re: NUCULAR fielded text searchable indexing
On Oct 9, 8:46 am, Istvan Albert [EMAIL PROTECTED] wrote: ps. there is a python project named The Devil Framework, I cringe every time I hear about it.Nucularis not as bad, but it is close. Aw shucks. I thought it was funny. Can't I make fun of politicians in my open source projects? Besides there is a great tradition of tounge-in-cheek package names, like Cold fusion, for example. Actually one reason I chose it, is I own nucularOption.com and also http://nucular.sourceforge.net was available. too late now. sorry again, -- Aaron Watters === It's humbling to think that when Mozart was my age he'd been dead for 10 years. -- Tom Lehrer -- http://mail.python.org/mailman/listinfo/python-list
Re: NUCULAR fielded text searchable indexing
On Tue, 09 Oct 2007 12:46:34 +, Istvan Albert wrote: On Oct 9, 7:26 am, [EMAIL PROTECTED] wrote: No, it doesn't stand for anything. It also reminds me of someone we all know, and I wish it didn't. As the latin proverb says Nomen est omen. Calling your package docindexer would draw a lot more people. It is hard to justify to a third party that a project named nucular actually does something useful. Yeah, like those crappy products Linux, Lisp, Apache, Windows, Java, Google, Yahoo and especially Python. Can you imagine trying to tell your boss that you want to use something called Python for your programming project? *wink* -- Steven. -- http://mail.python.org/mailman/listinfo/python-list
Re: NUCULAR fielded text searchable indexing
[EMAIL PROTECTED] wrote: On Oct 9, 8:46 am, Istvan Albert [EMAIL PROTECTED] wrote: ps. there is a python project named The Devil Framework, I cringe every time I hear about it.Nucularis not as bad, but it is close. Aw shucks. I thought it was funny. Can't I make fun of politicians in my open source projects? Besides there is a great tradition of tounge-in-cheek package names, like Cold fusion, for example. ... I think it's an excellent name :) -- Robin Becker -- http://mail.python.org/mailman/listinfo/python-list
Re: NUCULAR fielded text searchable indexing
On 2007-10-09, Robin Becker [EMAIL PROTECTED] wrote: [EMAIL PROTECTED] wrote: On Oct 9, 8:46 am, Istvan Albert [EMAIL PROTECTED] wrote: ps. there is a python project named The Devil Framework, I cringe every time I hear about it.Nucularis not as bad, but it is close. Aw shucks. I thought it was funny. Can't I make fun of politicians in my open source projects? Besides there is a great tradition of tounge-in-cheek package names, like Cold fusion, for example. ... I think it's an excellent name :) And Bush would probably pronounce it Nuke-lee-ur. -- Grant Edwards grante Yow! I like your SNOOPY at POSTER!! visi.com -- http://mail.python.org/mailman/listinfo/python-list
Fwd: NUCULAR fielded text searchable indexing
On 10/9/07, Grant Edwards [EMAIL PROTECTED] wrote: On 2007-10-09, Robin Becker [EMAIL PROTECTED] wrote: [EMAIL PROTECTED] wrote: On Oct 9, 8:46 am, Istvan Albert [EMAIL PROTECTED] wrote: ps. there is a python project named The Devil Framework, I cringe every time I hear about it.Nucularis not as bad, but it is close. Aw shucks. I thought it was funny. Can't I make fun of politicians in my open source projects? Besides there is a great tradition of tounge-in-cheek package names, like Cold fusion, for example. ... I think it's an excellent name :) And Bush would probably pronounce it Nuke-lee-ur. I dislike Bush as much as the next guy, but could we please keep politics off the group? -- -Bill Hamilton -- http://mail.python.org/mailman/listinfo/python-list
Re: NUCULAR fielded text searchable indexing
On Oct 9, 9:14 am, [EMAIL PROTECTED] wrote: a great tradition of tounge-in-cheek package names, like Cold fusion, for example. Cold Fusion is a super cool name. Nobody will every think of it as representing something odd or silly. too late now. sorry again, why would it be late? is the future of you own work not worth the time it takes to rename it? Compared to all the other work it took ... it is just a mere inconvenience. All I can say please do yourself a favor rename it. Imagine yourself in the position of someone who has no idea what the project is about and try to imagine what kind of thoughts and feelings the name will conjure. It matters a lot. It is a shame to put yourself at disadvantage. Anyway that's all I can say. FWIW the Devil Framework guys are sticking to their name, I think this is something that feels too personal, people who invent a name will have a hard time accepting that it is bad. i. -- http://mail.python.org/mailman/listinfo/python-list
Re: NUCULAR fielded text searchable indexing
On Oct 9, 3:35 pm, Istvan Albert [EMAIL PROTECTED] wrote: why would it be late? is the future of you own work not worth the time it takes to rename it? Compared to all the other work it took ... it is just a mere inconvenience. From a sourceforge perspective I think it's more than in inconvenience -- in fact I'm not sure it can be done -- unless I get on the phone with the guys over there and beg for some special exception or something. [btw, I like using sourceforge: lot's of neat packaged services; no real complaints.] The approved http://nucular.sourceforge.net and I don't think they'll approve another project with the same description. people who invent a name will have a hard time accepting that it is bad. Well I'd like people to use the software because they think it's good. If the name is a problem it's probably only the first of many reasons they won't want to use it or will not like it because it doesn't match their preconceptions. But if there's some way to change the name easily in the next week or so, I'll consider it anyway. hints? -- Aaron Watters === Why do you hang out with that sadist? Beats me! -- Kliban -- http://mail.python.org/mailman/listinfo/python-list
ANN: NUCULAR fielded text searchable indexing
ANNOUNCE: NUCULAR fielded text searchable indexing Nucular is a system for creating disk based full text indices for fielded data. It can be accessed via a Python API or via a suite of command line interfaces. Nucular is intended to help store and retrieve searchable information in a manner somewhat similar to the way that www.hotjobs.com stores and retrieves job descriptions, for example. Nucular archives fielded documents and retrieves them based on field value, field prefix, field word prefix, or full text word prefix, or combinations of these. Features: -- Nucular is very light weight. Updates and accesses do not require any server process or other system support such as shared memory locking. -- Nucular supports concurrency. Arbitrary concurrent updates and accesses by multiple processes or threads are supported, with no possible locking issues. -- Nucular indexes and retrieves large collections quickly. Read more and download at: http://nucular.sourceforge.net Online demos: http://www.xfeedme.com/nucular/gut.py/go http://www.xfeedme.com/nucular/mondial.py/go I hope you like! -- Aaron Watters === I don't know ka-RAH-tee But I know ka-RAY-zee -- James Browne -- http://mail.python.org/mailman/listinfo/python-list
