| 00:40:05 | *** | Saving seen data "./dancer.seen" |
| 02:00 |
| 02:20:34 | | Quit F3l1x_10m (Ping timeout: 240 seconds) |
| 02:40:09 | *** | Saving seen data "./dancer.seen" |
| 03:00 |
| 03:13:04 | | Join ideasman42 [0] (~ideasman4@2402:b801:2844:2100::1) |
| 03:15:01 | | Quit ideasman42 (Client Quit) |
| 04:00 |
| 04:14:49 | | Join ZincAlloy [0] (~Adium@ip5f5abcae.dynamic.kabel-deutschland.de) |
| 04:19:17 | | Quit ZincAlloy (Ping timeout: 245 seconds) |
| 04:27:34 | | Join ZincAlloy [0] (~Adium@2a02:8108:943f:d824:f49f:88f4:4840:d1fb) |
| 04:32:28 | | Quit ZincAlloy (Ping timeout: 272 seconds) |
| 04:40:12 | *** | Saving seen data "./dancer.seen" |
| 04:50:01 | | Join ZincAlloy [0] (~Adium@2a02:8108:943f:d824:c53:bc06:23e3:720a) |
| 04:50:17 | | Join Moriar [0] (~moriar@107-200-193-159.lightspeed.stlsmo.sbcglobal.net) |
| 05:00 |
| 05:19:10 | | Join johnb2 [0] (~johnb2@p5b3af7a3.dip0.t-ipconnect.de) |
| 05:21:15 | | Join F3l1x_10m [0] (~Al3x_10m@user/f3l1x-10m/x-3393542) |
| 06:00 |
| 06:05:47 | | Quit Moriar (Ping timeout: 258 seconds) |
| 06:26:53 | rb-bluebot | Build Server message: New build round started. Revision 03a6eb63f1, 303 builds, 9 clients. |
| 06:40:16 | *** | Saving seen data "./dancer.seen" |
| 06:44:00 | | Quit F3l1x_10m (Ping timeout: 276 seconds) |
| 06:44:19 | _bilgus | uh oh |
| 06:44:34 | _bilgus | might be stuck |
| 06:45:31 | rb-bluebot | Build Server message: Build round completed after 1118 seconds. |
| 06:45:34 | rb-bluebot | Build Server message: Revision 03a6eb63f1 result: All green |
| 06:45:43 | rb-bluebot | Build Server message: New build round started. Revision 848633f921, 303 builds, 9 clients. |
| 06:46:19 | _bilgus | spoke too soon |
| 06:50:20 | | Join F3l1x_10m [0] (~Al3x_10m@user/f3l1x-10m/x-3393542) |
| 06:51:48 | | Quit johnb2 (Quit: Nettalk6 - www.ntalk.de) |
| 07:00 |
| 07:01:04 | rb-bluebot | Build Server message: Build round completed after 921 seconds. |
| 07:01:05 | rb-bluebot | Build Server message: Revision 848633f921 result: All green |
| 07:01:07 | rb-bluebot | Build Server message: New build round started. Revision d57900ae12, 303 builds, 9 clients. |
| 07:14:59 | rb-bluebot | Build Server message: Build round completed after 831 seconds. |
| 07:15:01 | rb-bluebot | Build Server message: Revision d57900ae12 result: All green |
| 07:15:04 | rb-bluebot | Build Server message: New build round started. Revision cb6b0d2c0e, 303 builds, 9 clients. |
| 07:27:36 | rb-bluebot | Build Server message: Build round completed after 752 seconds. |
| 07:27:38 | rb-bluebot | Build Server message: Revision cb6b0d2c0e result: All green |
| 08:00 |
| 08:07:57 | | Nick yang-idl1 is now known as yang-idle (~yang@199.189.205.50) |
| 08:08:18 | | Quit yang-idle (Changing host) |
| 08:08:18 | | Join yang-idle [0] (~yang@fsf/member/yang) |
| 08:22:56 | | Join cereal_eater [0] (~cereal_ea@91-115-230-103.adsl.highway.telekom.at) |
| 08:23:35 | | Join dconrad [0] (~dconrad@208.38.228.17) |
| 08:23:41 | | Quit dconrad (Client Quit) |
| 08:23:57 | cereal_eater | Any comments on the issue with the colour selector and the anti alieased fonts? https://forums.rockbox.org/index.php/topic,53937.msg249012.html#msg249012 |
| 08:29:09 | _bilgus | braewoods iriver.c iriver_encode/decode https://github.com/Rockbox/rockbox/blob/master/tools/iriver.c#L163 |
| 08:29:38 | _bilgus | any clue why no free is called? |
| 08:30:32 | _bilgus | I was thinking if you were in a rolo like situ it wouldn't matter but this file runs on the host side |
| 08:32:04 | _bilgus | cereal_eater, those are macros |
| 08:32:10 | _bilgus | gve me a moment |
| 08:36:56 | cereal_eater | ok |
| 08:38:26 | | Join massiveH [0] (~massiveH@ool-18e4e82f.dyn.optonline.net) |
| 08:40:17 | *** | Saving seen data "./dancer.seen" |
| 08:41:46 | _bilgus | cereal https://github.com/Rockbox/rockbox/blob/master/firmware/export/lcd.h#L308 |
| 08:42:10 | _bilgus | it appears the device shines through in that color picker |
| 08:45:10 | cereal_eater | thanks for the information, unfortunately this is way above my head and I don't understand the range from 0 to 31 instead of 0 to 255. |
| 08:45:20 | _bilgus | might be a bug that 31 i thingk it should be R & 0x3F |
| 08:46:52 | cereal_eater | for green it is 0 to 63 |
| 08:46:58 | _bilgus | its 565 |
| 08:47:05 | _bilgus | or reverse 565 |
| 08:47:39 | _bilgus | what is the rgb color you want |
| 08:47:46 | _bilgus | I'll do the math for you |
| 08:49:00 | cereal_eater | please show me the math as in teach me to fisch :-) |
| 08:50:59 | _bilgus | obv |
| 08:51:30 | cereal_eater | the RGB is 48, 79, 254 |
| 08:55:53 | speachy | _bilgus: the pile of scanner emails is.. confusing. it's acting almost like they are radically different projects being built under the same umbrella. |
| 08:56:07 | _bilgus | yeah |
| 08:56:25 | _bilgus | I think that might make it a do one device get it clean switch to another |
| 08:56:45 | speachy | _bilgus: btw, I didn't intend to push coverity stuff via the buildfarm; instead have it batch one or two "representative" builds on a nightly basis. eg one hosted, one native |
| 08:56:46 | _bilgus | but at least it does have the bugs in the snapshots |
| 08:57:47 | _bilgus | I assumed you would have one builder that did that in the pool but I think it being so slow itd probably be wise to not do that |
| 08:57:59 | cereal_eater | _bilgus: is it like 31 is 255 and all numbers in between correspond linearly? |
| 08:58:20 | _bilgus | everything gets anded with 3f |
| 09:00 |
| 09:01:57 | braewoods | _bilgus: if i had to guess, it's lazy C programming. i've seen this crap in short lived utilities. they let the kernel clean up their mess. |
| 09:02:57 | speachy | "we're terminating anyway, who cares about cleaning up first?" |
| 09:03:24 | speachy | one bit of code I'm responsible for only leaks because libusb does. |
| 09:03:26 | braewoods | _bilgus: why ping me about it though? i don't recall touching that code. |
| 09:06:52 | braewoods | hm. interesting. i wonder if any program uses the extra fields of gzip containers. |
| 09:06:56 | braewoods | gzip itself only uses filename |
| 09:07:27 | _bilgus | maybe not that function in particular? but the file so you've seen more of it than I :) |
| 09:07:48 | braewoods | let me look at it |
| 09:07:52 | _bilgus | cereal_eater, give me a few i'll do a write up |
| 09:10:01 | braewoods | _bilgus: looks like you could free pChecksums. it retains the original pointer and doesn't appear to be modified. |
| 09:10:11 | braewoods | it'd need to be added to each exit point |
| 09:10:15 | braewoods | shall I prepare a patch? |
| 09:11:09 | braewoods | right now i've been testing my gzip container code |
| 09:13:38 | speachy | oh, one request −− if you mark a coverity issue as "ignore" please add a comment why. |
| 09:13:46 | _bilgus | braewoods, sure if you want |
| 09:13:57 | speachy | (and classification as "intentional" or whatever else is appropriate) |
| 09:14:38 | _bilgus | sure hopefully the modeling file makes that less frequent |
| 09:15:18 | speachy | I've been focusing on "control flow" issues; a lot of them are due to #ifdef chains from SIMULATOR builds or something like that |
| 09:15:44 | speachy | so it's not a "false positive" per se; the analysis is correct but we don't care. |
| 09:16:11 | speachy | (eg peak meters in sim builds don't work, because we don't have working recording in the simulator) |
| 09:23:11 | braewoods | g#3655 |
| 09:23:14 | rb-bluebot | Gerrit review #3655 at https://gerrit.rockbox.org/r/c/rockbox/+/3655 : tools/iriver: fix resource management in encode/decode functions by James Buren |
| 09:23:16 | braewoods | what you asked for |
| 09:23:30 | braewoods | i ended up redoing the resource management to handle all the exit paths easier |
| 09:24:13 | braewoods | aka, add a single exit point that is jumped to via goto |
| 09:38:42 | | Quit cereal_eater (Ping timeout: 252 seconds) |
| 09:42:47 | | Join cereal_eater [0] (~cereal_ea@91-115-230-103.adsl.highway.telekom.at) |
| 09:44:59 | rb-bluebot | Build Server message: New build round started. Revision 9f0f2c6658, 303 builds, 9 clients. |
| 09:46:33 | _bilgus | cereal_eater, https://forums.rockbox.org/index.php/topic,53937.msg249025.html#msg249025 |
| 09:46:42 | _bilgus | hopefully that makes it clear enough |
| 09:47:14 | _bilgus | basically each field gets converted t 0-31 or 0-63(GREEN) then you shift them into place |
| 09:47:52 | _bilgus | braewoods, thank you! |
| 09:48:34 | braewoods | i'm close to being ready to push inflate code to gerrit |
| 09:49:08 | cereal_eater | wow, cool thanks for the explanation. I'm gonna wrap my head around this and customize some themes. |
| 09:49:56 | _bilgus | be aware that the range is smaller |
| 09:50:13 | _bilgus | like they get muddy |
| 09:50:28 | cereal_eater | OK, I see. |
| 09:50:31 | _bilgus | so sometimes its best to tweak it by eye |
| 09:51:09 | _bilgus | I'm not familar enough with it enough to tell you the math for that but by eye works for me :) |
| 09:58:19 | rb-bluebot | Build Server message: Build round completed after 800 seconds. |
| 09:58:24 | rb-bluebot | Build Server message: Revision 9f0f2c6658 result: All green |
| 10:00 |
| 10:03:43 | speachy | so far both high/memory corruption issues in the mp4 metadata parser are false positives. |
| 10:04:51 | cereal_eater | by the way, is there interest in the anti aliased fonts? Could I upload a pack to the wiki? |
| 10:07:53 | speachy | oh, _bilgus −− When I get this server upgrade dealt with I'd like to pick up your coverity build/submission scripts so this stuff can all proceed automagically. |
| 10:22:09 | | Quit massiveH (Quit: Leaving) |
| 10:23:00 | rb-bluebot | Build Server message: New build round started. Revision a20755e9ef, 303 builds, 9 clients. |
| 10:35:16 | rb-bluebot | Build Server message: Build round completed after 736 seconds. |
| 10:35:18 | rb-bluebot | Build Server message: Revision a20755e9ef result: All green |
| 10:37:56 | | Quit cereal_eater (Quit: Connection closed) |
| 10:40:18 | *** | Saving seen data "./dancer.seen" |
| 10:40:22 | speachy | So, straw poll −− how does Monday morning (US eastern time) sound for taking things down for the upgrade? |
| 10:54:33 | braewoods | ok... fixed a few bugs I found in my gzip container code (mostly due it not being tested before) |
| 10:55:22 | braewoods | i think that's as far as i can get just using my desktop to test... |
| 10:55:55 | braewoods | now i need to write some code to test it on an actual target so i can see if there's any obvious issues |
| 11:00 |
| 11:29:42 | | Quit akaWolf (Ping timeout: 258 seconds) |
| 11:32:02 | | Join akaWolf [0] (~akaWolf@akawolf.org) |
| 11:36:42 | braewoods | unsurprisingly it works |
| 11:36:56 | braewoods | now for the next testing phase; how much does cpu boosting help? |
| 11:37:11 | braewoods | it took like 68s for a 16MB file |
| 11:37:14 | braewoods | w/o i t |
| 11:41:02 | braewoods | huh. much faster but still slow. |
| 11:41:13 | braewoods | time to see how much is due to IO writes |
| 11:43:30 | braewoods | of course IO is going to suffer some due to the limited RAM |
| 11:45:46 | braewoods | huh. not much difference. it really is that slow |
| 11:46:17 | braewoods | takes 27s for my iriver h120 to decompress 16MB |
| 11:46:23 | braewoods | it does work though |
| 11:46:42 | braewoods | but i can't see this being practical for large payloads |
| 11:56:00 | | Quit tomato (Ping timeout: 268 seconds) |
| 11:58:41 | braewoods | g#3660 |
| 11:58:43 | rb-bluebot | Gerrit review #3660 at https://gerrit.rockbox.org/r/c/rockbox/+/3660 : inflate: import initial module for deflate decompression by James Buren |
| 11:58:47 | braewoods | whoever wants to review it |
| 11:59:11 | _bilgus | speachy sounds great |
| 11:59:38 | _bilgus | braewoods I can't sit with it rn but will tonight or tomorrow if no one else does |
| 11:59:51 | _bilgus | speachy there isn't much going on there |
| 11:59:53 | braewoods | ok. |
| 12:00 |
| 12:00:06 | speachy | I'd love to do it tomorrow but it conflicts with the meet&greet for the kiddo's school |
| 12:00:27 | _bilgus | I meant with the coverity builds |
| 12:00:40 | _bilgus | curl command is the worst of em |
| 12:00:44 | braewoods | _bilgus: we can still go with your ZIP idea but i suspect the slow decompression will mean we'd want to still use STORE method (uncompressed) |
| 12:01:20 | braewoods | it's fast on my desktop probably mainly due to more RAM and clock speed |
| 12:02:09 | braewoods | does work but it is slow. i'll work on a ZIP UI extractor later on. |
| 12:02:31 | _bilgus | braewoods, I don't know that we will do them on the fly it would be nice from a read-only FS standpoint |
| 12:03:06 | _bilgus | but even uncompressed its not like these are substantial space hogs |
| 12:03:08 | braewoods | i ended up adapting the plan9 inflate algorithm |
| 12:03:43 | _bilgus | was that the single byte at a time one? |
| 12:03:54 | braewoods | yes but i modified it with new IO routines |
| 12:04:04 | braewoods | it still is but it reads from an IO buffer now |
| 12:04:17 | braewoods | so it doesn't have as much callback overhead |
| 12:04:24 | braewoods | it should be faster on our beefier ports |
| 12:05:04 | braewoods | i'm using the minimum buffers i could get away with |
| 12:05:07 | braewoods | like 32K each |
| 12:05:15 | braewoods | around 70K of non-stack memory is needed |
| 12:05:25 | braewoods | i moved most of the heavy stuff off the stack |
| 12:05:37 | braewoods | leaving only the small state variables |
| 12:06:30 | braewoods | i wouldn't be surprised if the main reason it's slow on coldfire is the small amount of "fast ram" it has |
| 12:07:38 | speachy | IIRC the coldfire also lacks a data cache too |
| 12:08:24 | braewoods | yea. |
| 12:08:56 | braewoods | it may not be worthwhile to add that firmware extracting feature if it's THIS slow |
| 12:09:04 | braewoods | i'll test it out on more targets |
| 12:09:56 | _bilgus | speachy https://pastebin.com/U14qsSxY |
| 12:09:57 | braewoods | but it was kinda sad seeing data rates of like 500 kilobytes a second |
| 12:09:58 | braewoods | :| |
| 12:10:00 | _bilgus | thats the rocker |
| 12:10:49 | _bilgus | ive done the 3 I had cross compilers for on this laptop I think arm mips and m68k? |
| 12:11:07 | _bilgus | arm was the only one that I removed the cache on |
| 12:12:12 | _bilgus | oh sorry wrong convo on the cache |
| 12:40:22 | *** | Saving seen data "./dancer.seen" |
| 12:46:57 | | Part edhelas |
| 12:47:31 | | Join edhelas [0] (9d94237298@v2202101139504140605.quicksrv.de) |
| 13:00 |
| 13:29:24 | | Quit rogeliodh (Quit: The Lounge - https://thelounge.chat) |
| 13:30:47 | | Join rogeliodh [0] (~rogeliodh@rogeliodh.dev) |
| 14:00 |
| 14:40:24 | *** | Saving seen data "./dancer.seen" |
| 14:50:02 | | Part edhelas |
| 14:50:41 | | Join edhelas [0] (9d94237298@2a03:4000:51:f44:4e1:2ff:fe00:4257) |
| 16:00 |
| 16:40:28 | *** | Saving seen data "./dancer.seen" |
| 17:00 |
| 17:52:19 | | Join Moriar [0] (~moriar@107-200-193-159.lightspeed.stlsmo.sbcglobal.net) |
| 18:00 |
| 18:40:31 | *** | No seen item changed, no save performed. |
| 18:45:46 | | Quit ZincAlloy (Quit: Leaving.) |
| 18:47:34 | | Quit _bilgus (Quit: Leaving) |
| 20:00 |
| 20:34:52 | speachy | _bilgus: so we should ideally submit one per toolchain then? Including hosted and SDL/sim...) |
| 20:35:25 | speachy | we're in the only 2 per day bucket though |
| 20:37:15 | speachy | only a handful of issues have been under firmware/target, and even firmware/ has been pretty sparse. plugins and codecs are where it's all at.. |
| 20:39:48 | braewoods | speachy: wasn't coverity mainly intended for hosted programs? |
| 20:39:54 | braewoods | not sure how useful it is for freestanding |
| 20:40:10 | speachy | sure, but C is C.. |
| 20:40:26 | speachy | it's not the different toolchains we care about per se, but the coverage from the different targets they represent |
| 20:40:32 | *** | Saving seen data "./dancer.seen" |
| 21:00 |
| 21:08:09 | | Quit Moriar (Quit: Leaving.) |
| 21:53:19 | | Join advcomp2019_ [0] (~advcomp20@user/advcomp2019) |
| 21:56:58 | | Quit advcomp2019__ (Ping timeout: 240 seconds) |
| 22:00 |
| 22:06:24 | | Quit edhelas (Remote host closed the connection) |
| 22:20:06 | | Join _bilgus [0] (~bilgus@2600:1702:3810:17f0:18b6:b7d6:6d21:7004) |
| 22:40:36 | *** | Saving seen data "./dancer.seen" |
| 23:00 |
| 23:08:13 | rb-bluebot | Build Server message: New build round started. Revision da45b37fac, 303 builds, 9 clients. |
| 23:19:20 | rb-bluebot | Build Server message: Build round completed after 668 seconds. |
| 23:19:23 | rb-bluebot | Build Server message: Revision da45b37fac result: All green |
icon identifies that the person is a core developer (has commit access).