Re: Linux-libre git repository

2020-08-13 Thread Jason Self
On Thu, 13 Aug 2020 09:47:21 -0700 Vagrant Cascadian wrote: > It is also possible to retrieve tarballs directly from linux-libre git > tags, though I know at least projects hosted on github this does > occasionally result in non-identical tarballs. Not sure what factors > might trigger this, othe

Re: Linux-libre git repository

2020-08-13 Thread Vagrant Cascadian
On 2020-08-12, Mark H Weaver wrote: > Mark H Weaver wrote: >>> the linux-libre project periodically deletes most of its older >>> tarballs, even if there are no accidents. > > Jason Self responded: >> Just FYI that git://linux-libre.fsfla.org/releases.git was created >> mainly to solve that probl

Re: File search progress: database review and question on triggers

2020-08-13 Thread Pierre Neidhardt
I've pushed my experiment to the `wip-filesearch' branch. As of this writing it is not automatically triggered by "guix build". To test it: - Load the module from a REPL. - Run --8<---cut here---start->8--- (test-index-git) --8<---cut here--

Re: merge wip-haskell?

2020-08-13 Thread Ricardo Wurmus
Timothy Sample writes: > I just pushed “wip-haskell-updates-2” which integrates my work from > . I left the original branch intact > to make it easy to compare. I rebased this on top of “master” and pushed it as “wip-haskell”. I updated my changes to pandoc

Re: File search progress: database review and question on triggers

2020-08-13 Thread Pierre Neidhardt
Arun Isaac writes: > But filenames usually don't have diacritics. So, I'm not sure if > diacritic insensitivity is useful. Probably not, but if there ever is this odd file name with an accent, then we won't have to worry about it, it will be handled. Better too much than too little! > This is

Re: File search progress: database review and question on triggers

2020-08-13 Thread Arun Isaac
> Yes, but full text search brings us a few niceties here: These are nice features, but I don't know if all of them are useful for file search. Normally, with Arch's pkgfile, I seach for some missing header file, shared library, etc. Usually, I know the exact filename I am looking for, or I know

Re: File search progress: database review and question on triggers

2020-08-13 Thread Pierre Neidhardt
Ricardo Wurmus writes: > Pierre Neidhardt writes: > >> - Or do you think SQLite patterns (using "%") would do for now? As >> Mathieu pointed out, it's an unfortunate inconsistency with the rest of >> Guix. But maybe regexp support can be added in a second stage. > > These patterns could be

Re: File search progress: database review and question on triggers

2020-08-13 Thread Arun Isaac
>> sqlite insert statements can be very fast. sqlite.org claims 5 >> or... > > I tried it, and got it down to... 30s! That's great! :-) > - Or do you think SQLite patterns (using "%") would do for now? As > Mathieu pointed out, it's an unfortunate inconsistency with the rest of > Guix.

Re: File search progress: database review and question on triggers

2020-08-13 Thread Ricardo Wurmus
Pierre Neidhardt writes: > - Or do you think SQLite patterns (using "%") would do for now? As > Mathieu pointed out, it's an unfortunate inconsistency with the rest of > Guix. But maybe regexp support can be added in a second stage. These patterns could be generated from user input that

Re: Fwd: Installer: Language and Location should be (optionally) independent of each other

2020-08-13 Thread dcn
I think it was just me being a bit .. slow at that very moment. I somehow interpreted "Choose a territory for this language" as the actual location which would be used for the timezone and such, not as the 'variant' of the language. It might help if the language code is listed along the territo

Re: File search progress: database review and question on triggers

2020-08-13 Thread Ricardo Wurmus
Pierre Neidhardt writes: > Julien Lepiller writes: > >> Why wouldn't it help? Can't you make it a trie from basename -> >> complete name? If I'm looking for "libcord.so" (which is a key in the >> trie), I don't think I need to look for every path. I only need to >> follow the trie until I find