At the bottom it displays 450 packages. Yet upon bunzip mydslinfo.bz2 and performing
grep "^Title:" mydslinfo | wc -l
I get far more than 450. There are more than 450 packages in the repository.
[EDIT] After checking my local copy vs remote (ibiblio) vs grep vs find -name "*.info" the correct total "info" files as of this posting is 893
I had a feeling it wasn't working as I'd hoped. I got 901 lines using bunzip2 -c mydslinfo.bz2 |grep "^Title:" | wc -l
Not sure how to approach the problem at this time, but I'll look into it soon.Yeah it was 901. I had a mismatch from the recently deleted extensions. If you update database you should get 893. Both local and remote directories are in complete sync.893 now, yes. 446 listed in the gui...definitely something weird, must be either still cramming infos together or just dropping some of it. I haven't found anything close to an answer yet. I think I'm going to do a test with parsing the file line by line instead of reading the whole thing in. It might actually be faster, and probably easier to debug.
The "load local" mentioned in the RC thread might be a *little* less than easy, considering the application automatically tries to connect when it starts. If local was just plugged in, a user with a system not connected would have to wait several seconds every time the application is started, or manually close the terminal window every time.
I was thinking of a few possibilities:
1) Start the interface with a fl_choice -- local or web -- and load the main window only if you choose the internet. 2) Commandline/env option to prevent the initial update from running 3) Update automatically, but ask before doing it. This would be the easiest to implement of these 3 options.446 is half of 893-1 (-1 being the last search for Location:) I know where the problem is, but I'm not sure how to fix it at the moment...it will require a different search string for gmatch.
Code Sample
for s in string.gmatch(data,"\n(Location:.-)\nLocation:") do
I thought the capture would be the only part of the actual match, but I think I was wrong. It seems that the gmatch function iterates over the input looking for "\n(Location:.-)\nLocation:" and just returns the capture, but that whole string is used as the match. So what it's doing is capturing every other info.
So far I haven't come up with a reliable search string.Next Page...
original here.