On Tue, 28 Apr 2020 14:52:04 GMT, mark wrote:
On my Ubuntu 18.04 LTS 64-bit it takes 1.5sec to read the Packages files and a further 4.1sec to index them (and create a ~20MB cache in /tmp).
The packages are read from /var/lib/apt/lists/Packages (the dir and glob are in model.d). That dir has ~300MB of Packages files on my machine. Maybe you have a lot more?
|> ll /var/lib/apt/lists/*Packages*
-rw-r--r-- 1 root root 870491 Mar 21 23:05 /var/lib/apt/lists/dimen.winder.org.uk:9999_d-apt_dists_d-apt_main_binary-amd64_Packages
-rw-r--r-- 1 root root 256863 Apr 26 21:06 /var/lib/apt/lists/dimen.winder.org.uk:9999_debian_dists_unstable_contrib_binary-amd64_Packages
-rw-r--r-- 1 root root 27796 Apr 26 21:06 /var/lib/apt/lists/dimen.winder.org.uk:9999_debian_dists_unstable_contrib_binary-amd64_Packages.diff_Index
-rw-r--r-- 1 root root 46166225 Apr 28 21:11 /var/lib/apt/lists/dimen.winder.org.uk:9999_debian_dists_unstable_main_binary-amd64_Packages
-rw-r--r-- 1 root root 27910 Apr 28 21:11 /var/lib/apt/lists/dimen.winder.org.uk:9999_debian_dists_unstable_main_binary-amd64_Packages.diff_Index
-rw-r--r-- 1 root root 529594 Apr 28 09:06 /var/lib/apt/lists/dimen.winder.org.uk:9999_debian_dists_unstable_non-free_binary-amd64_Packages
-rw-r--r-- 1 root root 27796 Apr 28 09:06 /var/lib/apt/lists/dimen.winder.org.uk:9999_debian_dists_unstable_non-free_binary-amd64_Packages.diff_Index
-rw-r--r-- 1 root root 2208 Sep 10 2019 /var/lib/apt/lists/dimen.winder.org.uk:9999_rlw_._Packages
-rw-r--r-- 1 root root 5146 Apr 24 14:21 /var/lib/apt/lists/dimen.winder.org.uk:9999_vivaldi_dists_stable_main_binary-amd64_Packages
-rw-r--r-- 1 root root 1199029 Apr 29 07:12 /var/lib/apt/lists/dimen.winder.org.uk:9999_vscode_dists_stable_main_binary-amd64_Packages
I am using Debian Sid. But I use approx (which runs on port 9999) as I have four machines to update and do not really want to download everything four times – approx acts as a cache.
If you try deleting /tmp/debfind-2020-04-28.cache and then run 'dub test' you should just see the cache being recreated and the CLI tests running. Then if that works and you try running 'dub' it should run the DebFind GUI which should detect the cache and be ready straight away.
|> dub test
Generating test runner configuration 'debfind-test-application' for 'application' (executable).
Excluding main source file src/app.d from test.
Performing "unittest" build using /usr/bin/ldc2 for x86_64.
aaset 0.2.5: building configuration "library"...
gtk-d:gtkd 3.9.0: target for configuration "library" is up to date.
debfind ~master: building configuration "debfind-test-application"...
Linking...
To force a rebuild of up-to-date targets, run again with --force.
Running ./debfind-test-application
stemmer.d unittests: checked 23,531 stems
Reading package files…
/usr/lib/ldc/x86_64-linux-gnu/include/d/std/conv.d(2312): [unittest] Unexpected 'N' when converting from type string to type ulong
std.conv.ConvException@/usr/lib/ldc/x86_64-linux-gnu/include/d/std/conv.d(2312): Unexpected 'N' when converting from type string to type ulong
----------------
conv.d:2312 [0x55d90cefbf41]
conv.d:1905 [0x55d90cefbc6c]
conv.d:222 [0x55d90ce7431c]
modelutil.d:115 [0x55d90ce7421b]
modelutil.d:80 [0x55d90ce73a56]
modelutil.d:44 [0x55d90ce7348b]
parallelism.d:1811 [0x55d90ceea1e2]
??:? void std.parallelism.TaskPool.doJob(std.parallelism.AbstractTask*) [0x7f7fdd29f8b0]
??:? void std.parallelism.TaskPool.startWorkLoop() [0x7f7fdd29fa5a]
??:? thread_entryPoint [0x7f7fdcf648cb]
??:? [0x7f7fdce9cf26]
??:? clone [0x7f7fdcc6d2ee]
1/4 unittests FAILED
Program exited with code 1
I can't help thinking that I'd have been better off writing this in wxPython...
I really like D, but don't like Gtk at all.
I am a fan of GTK+ compared to Qt, so Rust/gtk-rs and D/GtkD are my friends!