Previous day | Jump to hour: 01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19 20 21 22 23 | Next day

Seconds: Show Hide | Joins: Show Hide | View raw
Font: Serif Sans-Serif Monospace | Size: Small Medium Large

Click in the nick column to highlight everything a person has said.
The Logo icon identifies that the person is a core developer (has commit access).

#rockbox log for 2022-02-25

00:48:38***No seen item changed, no save performed.
01:02:37braewoodswhy would a sid emulator need floating point? the commodore 64 didn't even have one.
01:02:48braewoodsHW wise
02:40:15 Quit nihilazo (Ping timeout: 256 seconds)
02:40:30 Join nihilazo [0] (
02:48:40***Saving seen data "./dancer.seen"
04:29:06 Join megamaced [0] (
04:48:41***No seen item changed, no save performed.
05:03:14q3kbraewoods: maybe because the SID is an analog synthesis chip? :)
06:48:42***No seen item changed, no save performed.
07:52:30 Join massiveH [0] (
07:55:38 Quit koniu (Ping timeout: 252 seconds)
08:09:55 Join koniu [0] (
08:48:43***Saving seen data "./dancer.seen"
08:53:47 Quit massiveH (Quit: Leaving)
10:47:11 Join ac_laptop [0] (~ac_laptop@2001:910:107e:1:56ee:75ff:fe00:97ac)
10:48:46***Saving seen data "./dancer.seen"
10:59:42bluebrotherwhy would one not want to tag their music but use the database? If you don't use tags simply don't use the database. There's still the file browser ...
11:29:05 Quit ac_laptop (Quit: WeeChat 3.4)
11:57:43 Join bilgus_ph [0] (~bilgus_ph@
11:59:12bilgus_phBluebrother, trying it out its v. Annoying to have UNTAGGED in the tracks list and try to browse through
12:01:48bilgus_phG#4247 should help in all the <inbuilt file list> menus <ALL TRACKS> <RANDOM>
12:04:42bilgus_phYour namesake must be missing
12:06:58 Join ZincAlloy [0] (~Adium@2a02:8108:943f:d824:9427:c7d8:fb6f:7258)
12:09:02 Quit bilgus_ph (Quit: Connection closed)
12:11:17 Quit ZincAlloy (Ping timeout: 240 seconds)
12:42:33 Join ZincAlloy [0] (
12:48:47***Saving seen data "./dancer.seen"
13:04:45 Quit megamaced (Quit: megamaced)
13:12:25 Join lebellium [0] (
13:32:25 Quit ufdm (Remote host closed the connection)
13:32:57 Join ufdm [0] (
13:35:12 Quit ufdm (Read error: Connection reset by peer)
13:38:54 Join ufdm [0] (
14:07:01 Quit speachy (Read error: Connection reset by peer)
14:12:40 Join speachy [0] (~speachy@
14:12:40 Quit speachy (Changing host)
14:12:40 Join speachy [0] (~speachy@rockbox/developer/speachy)
14:12:40Mode"#rockbox +v speachy" by ChanServ (
14:48:51***Saving seen data "./dancer.seen"
15:51:51 Quit Bobathan_ (Quit: ZNC 1.8.2+deb2+b1 -
15:53:59 Join Bobathan [0] (
16:00:02 Quit speachy (Quit: WeeChat 3.4)
16:48:52***Saving seen data "./dancer.seen"
17:21:17 Quit rogeliodh (Quit: The Lounge -
17:21:41 Join rogeliodh [0] (
17:31:18 Quit lebellium (Quit: Leaving)
18:09:34 Quit ZincAlloy (Quit: Leaving.)
18:17:28_bilgusI dont't see how this ever worked
18:18:49_bilgusok so the clause is dependent on the same tag so we use the already defined filter?
18:19:25_bilgusbut how does that get our match? well clearly it doesn't BUT..
18:48:53***Saving seen data "./dancer.seen"
19:18:05 Join massiveH [0] (
20:35:10_bilgusso far I have, clauses are added by saving a tag, clause type, navifileoffset
20:36:37_bilgusthose are (atleast for non numeric tags) later turned into a filter which is indexed to a databasefile (0-10)
20:37:32_bilgusso filters are a tag and the file descriptor of the databasefile
20:48:54***No seen item changed, no save performed.
21:29:42_bilgusSO It appears that the logical OR is not carried over to filters and it then gets applied to whatever the next valid clause
21:31:45_bilgusthen you get the filtered items (which works) but the OR gets applied to the next clause and it causes weird things
21:32:31_bilgusProblem is I'm not sure how to decide to eliminate that OR (maybe if the clause prior is a filter and after is a filter? but then I need to keep state
21:33:07_bilgusI think maybe the better idea is to just keep all clauses in the case of an OR
21:33:23_bilgusit'll be slower but at least it'll be correct
22:05:00_bilgus Tagcache Don't create filters when parsing a logical OR
22:34:41_bilgusI guess that should be Don't reuse filters since they still get made into filters
22:48:56***No seen item changed, no save performed.
23:06:04 Quit massiveH (Quit: Leaving)

Previous day | Next day