On Wed, May 13, 2009 at 9:43 AM, David Cantrell <[email protected]> wrote: > For binary search, you need to start either: > seeking to approximate middle of range; > rewind or fast-forward to an actual record boundary; > read, wash, rinse, repeat > or have fixed-width fields. But the gods like to punish people who > arbitrarily restrict their data thus.
MJD suggests Search::Dict, which is core. > Perhaps it makes sense to use a binary format like GDBM_File. People > who need plain-text data for their shell scripts can trivially dump that > back out, and GDBM_File has always been in core. None of the *DBM_File modules are guaranteed to be built and available in any given perl, despite being "core". > GDBM_File doesn't, of course, let you store an array of GUIDs, but a > space-seperated list would probably do the job just fine. If you really > need structured data, DBM::Deep is the way to go, at the expense of I would just space-separate them since 99% of the time, it's just going to be a single GUID. (Until we define the semantics for "duplicate report" to also mean "same prereq/environment" and not just "same grade") DBM::Deep also has issues on some platforms (e.g. Windows, of course) last I checked. Otherwise, I think it's awesome. >> Since getting smoker speedups depends on not retesting distributions >> with a known result > > You still need to test (to find conflicts with other recently installed > modules) and install common dependencies every time if you test against > a reasonably clean perl install. The only thing you can reliably skip > is generating and sending the report. That's a testing style decision, in my opinion. Assuming that previous test results are valid when providing prerequisites out of a build dir is really no different than having prerequisites already installed in @INC. Pure clean perl testing with everything from scratch is valuable, but it's not the "everyday" experience of end-users, so I think it's useful for there to be a range of styles for CPAN Testers. > That has the disadvantage of really hammering a network if the logs are > kept on NFS (mine are on some of the machines I use, and until I moved > the perl I was testing with etc into /tmp the sysadmins got rather > annoyed at me; I can't really move the logs into /tmp (and back to $HOME > at the end of a session) as that way they're not shared between > instances running on different machines but sharing the same $HOME). I'll think about what could be done. There could be a sorted file and a "recent" unsorted file that gets merged in every X hundred reports. -- David
