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).

Notice: Only Gecko based browsers prior to FF4 support the multipart/mixed "server push" method used by this log reader to auto-update. Since you do not appear to use such a browser, this page will simply show the current log, and not automatically update.

#rockbox log for 2021-07-24

00:02:37 Quit Natch (Ping timeout: 245 seconds)
00:05:33__builtinspeachy: the latter can be somewhat automated
00:05:37__builtinfor plugins at least
01:00
01:20:43***Saving seen data "./dancer.seen"
02:00
02:16:00 Join lebellium [0] (~lebellium@2a01:cb10:2e:2000:70ba:d034:95fc:d46b)
03:00
03:20:46***No seen item changed, no save performed.
04:00
04:10:33 Quit massiveH (Quit: Leaving)
05:00
05:09:02 Join ZincAlloy [0] (~Adium@ip5f5abcae.dynamic.kabel-deutschland.de)
05:20:50***Saving seen data "./dancer.seen"
06:00
06:22:33 Join Natch [0] (~natch@c-e070e255.014-297-73746f25.bbcust.telenor.se)
07:00
07:19:25speachyyep
07:19:41speachyjust takes... time and effort.
07:20:53***No seen item changed, no save performed.
07:29:59 Quit Natch (Ping timeout: 268 seconds)
07:32:29 Join Natch [0] (~natch@c-e070e255.014-297-73746f25.bbcust.telenor.se)
08:00
08:00:50 Join amachronic [0] (~amachroni@user/amachronic)
08:55:29 Join advcomp2019__ [0] (~advcomp20@user/advcomp2019)
08:56:51 Quit _bilgus (Remote host closed the connection)
08:58:58 Quit advcomp2019_ (Ping timeout: 240 seconds)
08:59:06 Join _bilgus [0] (~bilgus@162.154.213.134)
09:00
09:00:50amachronicspeachy, i've got the manuals for the m3k/q1 to build and added installation instructions. the rest of it might not be 100% accurate, but can we start building them so we can link to the instructions?
09:08:38_bilgusbraewoods IIRC you end up adding strlcpy to core?
09:20:54***Saving seen data "./dancer.seen"
09:44:36rb-bluebotBuild Server message: New build round started. Revision 42ba117952, 303 builds, 9 clients.
09:44:50_bilgusguess we shall see
09:48:19braewoods_bilgus: eh? strlcpy was already present. i was just using it.
09:48:58_bilgusoh? I thought it literally wasn't in at all
09:49:15braewoods_bilgus: no, just differences in string.h
09:49:30braewoodsit's not present in linux glibc but it is in ours
09:49:36_bilgusok cool this should be all good then
09:50:32braewoodsi prefer strlcpy for simple string construction due to the performance advantages over printf
09:50:49braewoodsit's significant
09:50:55braewoodswhen you do a lot anyway
09:52:13braewoodsunfortunately snprintf is the only portable option for safe string stuff
09:52:25braewoodsunless you wrap memccpy :D
09:53:04braewoodsi'm surprised posix never adopted strlcpy or strlcat; they have compelling use cases
09:53:24braewoodsstrncpy / strncat are kinda crappy options
09:53:32braewoodsi never understood why they exist
09:54:11braewoodsthere's situations where they fail to null terminate and they fully write to the unused space
09:54:17braewoodsboth of which don't make any sense
09:55:20braewoodsi kinda figured they were leftovers like gets that weren't well thought out
09:55:41braewoodsstrcpy/strcat actully do make sense in some cases if you can trust the input
09:57:17rb-bluebotBuild Server message: Build round completed after 759 seconds.
09:57:19rb-bluebotBuild Server message: Revision 42ba117952 result: All green
09:58:32speachyamachronic: IIRC the only way manuals get built is if the target is marked as "stable"
10:00
10:01:33speachybut I'll hack something in
10:03:34amachronicok thanks. just wondering, is missing rockbox utility the only reason to not mark it stable?
10:03:50speachymanual+rbutil, yeah
10:04:48amachronicthen i'll have to stop procrastinating on rbutil :)
10:05:32speachyI don't see manual stuffs for the q1 or m3k committed..?
10:06:11amachronicit's still in gerrit. should I commit it now?
10:06:28speachyjust a sec.
10:06:44speachyactually go ahead
10:06:53speachymanuals won't get built until tonight anyway
10:07:10rb-bluebotBuild Server message: New build round started. Revision fde6eaa8e1, 303 builds, 9 clients.
10:08:20speachyI think you'll need to generate screenshots for the q1 −− nothing else shares its screensize so there's no piggybacking on another target's screenshots
10:08:45amachronicyeah I know, it's just annoying.
10:08:53speachyah, I see that in the commit message. :D
10:09:13speachyI never did finish generating screenshots for the X3.
10:09:43speachybut it's high time I finished the manual bits for the X3ii/X20 and ErosQ (hosted) ports too, as they're otherwise stable.
10:09:46speachy"stable"
10:10:48speachyand the agptekrocker too..
10:14:01amachronica lot of the screenshots in the manual must be outdated... some of the menus have changed
10:14:22speachyit's safe to say that the screenshots have only rarely been updated
10:14:31speachythere's no way to automate 'em, alas
10:17:27rb-bluebotBuild Server message: Build round completed after 616 seconds.
10:17:29rb-bluebotBuild Server message: Revision fde6eaa8e1 result: All green
10:22:15_bilgusbraewoods, TBH I knew of the clunky way ncpy worked but the filling buffer with nulls thing eh thats an important caveat IMO
10:22:44_bilgusI wasn't aware of that IOW
10:37:06braewoods_bilgus: i thought everybody who has used C awhile would have known that. it's well specified in the manpage iirc.
10:37:47braewoodseh
10:38:10braewoodsi guess it makes sense if you want to null terminate the unused portion
10:38:33_bilgusit would also tend to hide bugs
10:39:04braewoodsi usually don't write to a buffer memory region until i'm ready to use it
10:39:20braewoodssince well written code isn't supposed to use it beyond the known good parts
10:39:39braewoodsperformance reasons and all since buffers are usually big
10:46:53 Quit ZincAlloy (Quit: Leaving.)
10:51:05 Join JanC_ [0] (~janc@user/janc)
10:51:18_bilgusamachronic, there are quite a few intentional fall throughs are you planning on doing a group of them?
10:53:03 Quit JanC (Ping timeout: 252 seconds)
10:58:26amachronici can do them in bulk if you want, right now i'm just going through coverity and classifying stuff / fixing minor things
10:59:26_bilgushttps://scan3.coverity.com/reports.htm#v55211/p14259/mergedDefectId=352819 https://github.com/Rockbox/rockbox/commit/9f4bd8712fc122f61ec162c544d613a95c3ca66e#diff-f192f1ab608d8b7fc62f5ae325b7579a41356aeecc3c465450aab2ba23f9ef15R146
11:00
11:00:31_bilgusthat one is a good example of 'stuff' that shouldn't gotten through
11:01:31amachronicyeah, that whole function is not even remotely structured to handle errors.
11:02:07amachronicnor can I tell what kind of dummy data should be put in the event of parse failure
11:03:57_bilgusit looks like its so fragile in that area it makes me think −− maybe thats the point?
11:11:03_bilgusSo I get 60*1000 and 1000 but whats 13?
11:11:56_bilgusM:S:??
11:12:03amachronicwikipedia says it's hh:mm:ff −− last field is frames
11:12:05amachronichttps://en.wikipedia.org/wiki/Cue_sheet_(computing)
11:12:06 Join ZincAlloy [0] (~Adium@ip5f5abcae.dynamic.kabel-deutschland.de)
11:12:53amachronicbut why 13? it's not clear to me
11:13:08speachyI recall there being a _lot_ of cuesheet variations out there.
11:13:30_bilgusthat is a relief at least there is something of document that it is based on
11:17:39rb-bluebotBuild Server message: New build round started. Revision a0948ddfa1, 303 builds, 9 clients.
11:18:22 Quit ZincAlloy (Quit: Leaving.)
11:18:41speachyamachronic: ^^ has the bits needed to generate the manuals for the m3k & q1 in the nightly runs
11:20:58***Saving seen data "./dancer.seen"
11:22:25_bilgusInstead we can just skip the source forward by 8 chars
11:23:12_bilgusthat would remove INDEX 01 since it already matches
11:23:15speachy_bilgus: it's 13 because there are 75 frames per second, and *=13 gives you a close approximation in milliseconds.
11:23:42speachy75*13 = 975, which is ~~1000
11:23:45_bilgusyeah the wiki made it apparent
11:26:53_bilguswonder what atoi does with null input
11:27:17 Quit skipwich_ (Quit: DISCONNECT)
11:27:59_bilgus no conversion is performed and zero is returned
11:28:00speachy_bilgus: ours will dereference it
11:28:25_bilgusOh?
11:28:34speachyfirmware/libc/atoi.c L30
11:29:21rb-bluebotBuild Server message: Build round completed after 702 seconds.
11:29:28rb-bluebotBuild Server message: Revision a0948ddfa1 result: All green
11:29:37rb-bluebotBuild Server message: New build round started. Revision f8bbe3352c, 303 builds, 9 clients.
11:29:45_bilgusdamn straight
11:30:08_bilguswow
11:30:17speachywe can't necessarily go based on the POSIX libc spec, as we've reimlpemented a lot of it.
11:30:25speachyI'll go and add a null check in there
11:32:24speachy g#3615
11:32:26rb-bluebotGerrit review #3615 at https://gerrit.rockbox.org/r/c/rockbox/+/3615 : libc: atoi() is supposed to return 0 if handed a NULL pointer by Solomon Peachy
11:33:01speachyheh, this sort of thing is why we have to build with -fno-delete-null-pointer-checks
11:35:15 Join skipwich [0] (~skipwich@user/skipwich)
11:36:30speachyour str*() routines also don't do null checks.
11:37:13speachyditto memcmp/memcpy (though the latter is often overridden with per-arch asm)
11:38:22amachronicbut those don't really need to have null checks?
11:38:50amachroniclike, memcpy into null is probably a bug no matter what
11:38:58amachronicunless of course the length is 0
11:40:02speachyon native targets a read null dereference is usually harmless, but on hosted it'll crash
11:40:22speachyof course writing to a null dereference.. that's _nearly_ always bad.
11:40:54rb-bluebotBuild Server message: Build round completed after 678 seconds.
11:40:56rb-bluebotBuild Server message: Revision f8bbe3352c result: All green
11:41:02amachronicthe point being, it's a sign of a more serious programming error (either read OR write) and it's better to crash hard.
11:41:08speachyyeah
11:41:56speachybut only if there's a way to translate that hard crash into a stack trace or some sort of other diagnostic
11:42:54speachyI mean, in the bowels of the skin parsing code, there's a lot of places where we're not properly checking to see if malloc() succeeds
11:44:20speachyrealistically if we ever fail to malloc() we're probably toast.
11:45:19amachronicwe do have backtraces on panics for hosted and ARM native, but MIPS native is missing
11:46:25speachyI started to write one but put it aside when the voices started yelling at each other
11:47:26speachydue to how the ingenic parts have their mmu set up bad pointers tend to reliably HACF, thankfully.
11:50:39speachyok. time to put all of this imaginary software down for a while and take apart the dryer..
11:58:35 Nick JanC_ is now known as JanC (~janc@user/janc)
12:00
12:06:58 Quit amachronic (Ping timeout: 256 seconds)
12:27:58rb-bluebotBuild Server message: New build round started. Revision d0536b8b6b, 303 builds, 9 clients.
12:38:00rb-bluebotBuild Server message: Build round completed after 601 seconds.
12:38:01rb-bluebotBuild Server message: Revision d0536b8b6b result: All green
12:49:17 Join amachronic [0] (~amachroni@user/amachronic)
12:54:46 Quit amachronic (Ping timeout: 272 seconds)
13:00
13:03:33 Join ZincAlloy [0] (~Adium@ip5f5abcae.dynamic.kabel-deutschland.de)
13:21:01***Saving seen data "./dancer.seen"
14:00
14:21:51_bilgusamachronic looking at the cue sheet code I think a specialized scanf like parser would probably be enough to clean it up
14:22:54_bilgusIf you want to tackle it, it will probably turn out higher quality ;P but I'll look at it this evening
14:46:42 Join amachronic [0] (~amachroni@user/amachronic)
14:47:25amachronic_bilgus knock yourself out, I don't use cuesheets myself so it's not a big deal for me
14:50:38 Quit amachronic (Client Quit)
15:00
15:21:04***Saving seen data "./dancer.seen"
15:35:02bluebrotherspeachy: depends on what you consider "nice and simple" :)
15:36:14bluebrotherI'm in the middle of playing around with it, and there are obviously a bunch of rough edges. But with some small Sphinx extensions the input could be more readable. At least IMHO.
15:36:31bluebrotherguess I should bring it into a state where I can show it :)
15:46:43speachyyeah..
15:47:25speachyit's just that I worry that by the time everything we need has been rejiggered and extended and whatnot, the result will be just as incomprehensible to $random_people as the current LaTeX mess.
17:00
17:21:06***No seen item changed, no save performed.
17:41:10 Quit lebellium (Quit: Leaving)
19:00
19:21:08***Saving seen data "./dancer.seen"
19:30:43braewoods_bilgus: there's also a few lesser known libc features. strtol, etc, have a special feature if the base is 0. it tries to deduce the base based on the rules of C integer literals.
19:32:06braewoodsit's also common for people to improperly use strtol. since all values are valid return values, you have to set errno to 0 first and then check it after to know if strtol actually failed or not.
19:32:26braewoodsit's why i usually wrap strtol
19:33:12braewoodswhy i usually prefer to return output values via pointers and use the RV for an error indicator
19:33:34braewoodsthe output values mainly make sense when no errors are possible
19:33:55braewoodsor when pointers are in use...
19:34:16braewoodsintegers though, generally have no special value for errros
19:49:58 Quit ZincAlloy (Quit: Leaving.)
20:00
20:54:08 Join massiveH [0] (~massiveH@ool-18e4e82f.dyn.optonline.net)
21:00
21:21:10***Saving seen data "./dancer.seen"
21:56:51 Quit speachy (Quit: WeeChat 3.0.1)
22:00
22:51:26 Join dconrad [0] (~dconrad@208.38.228.17)
23:00
23:09:47 Quit skipwich (Ping timeout: 268 seconds)
23:13:25 Join rando25892 [0] (~sthk@user/rando25892)
23:21:12***Saving seen data "./dancer.seen"

Previous day | Next day