| 00:07:31 | *** | Saving seen data "./dancer.seen" |
| 01:00 |
| 01:35:50 | | Quit j-r (Ping timeout: 252 seconds) |
| 01:36:57 | | Join j-r [0] (~j-r@p20030006215aee45404207fffefd0a65.dip0.t-ipconnect.de) |
| 02:00 |
| 02:07:35 | *** | Saving seen data "./dancer.seen" |
| 03:00 |
| 03:39:59 | | Join ZincAlloy [0] (~Adium@ip5f5abcae.dynamic.kabel-deutschland.de) |
| 04:00 |
| 04:04:34 | | Nick mendel_munkis is now known as munkis (~mendel_mu@ool-ae2cb218.dyn.optonline.net) |
| 04:04:58 | | Quit tomato (Ping timeout: 272 seconds) |
| 04:07:36 | *** | Saving seen data "./dancer.seen" |
| 05:00 |
| 05:49:43 | | Join tomato [0] (~tomato@user/tomato) |
| 06:00 |
| 06:03:29 | | Join pablocastellanos [0] (~pidgin@user/pablocastellanos) |
| 06:07:39 | *** | No seen item changed, no save performed. |
| 06:14:49 | bluebrother^ | ok, so I tried to build the manual. Fails because 332433eb3d9 changed \ifpdfoutput to \Ifpdfoutput −− what is that package? Couldn't find anything about \Ifpdfoutput, only \ifpdfoutput |
| 06:41:33 | bluebrother^ | ok, found some info on it. It's been changed in KOMAscript. Debian buster ships 3.25, while this was changed in 3.28. |
| 06:57:34 | speachy | yeah, newer pdflatex needs the latter, older needs the former. |
| 06:58:03 | speachy | IIRC I committed that change when the server's version got updated to one that needed the latter syntax. |
| 07:00 |
| 07:00:21 | bluebrother^ | too bad the commit message isn't really clear about that ... |
| 07:00:52 | speachy | it was discussed in IRC but yeah, I should have asked for a more verbose commit message. |
| 07:00:52 | bluebrother^ | anyway, came across another issue: in the credits list at least one name is missing (the same I had issues with when looking into Sphinx) |
| 07:01:06 | speachy | character encoding issue? |
| 07:01:10 | bluebrother^ | yes. |
| 07:01:41 | bluebrother^ | with Sphinx I get lots of warnings from LaTeX about encoding, with our current setup I don't see any warnings. But looking into the pdf the name simply doesn't exist |
| 07:02:57 | bluebrother^ | oh. Seems our credits.pl strips that, so no issue with LaTeX. |
| 07:05:39 | bluebrother^ | yep, that's it. The first character isn't ASCII, so the regex doesn't match it. Turns out to also apply to some more names. |
| 07:22:14 | rb-bluebot | Build Server message: New build round started. Revision 4fb5aeb096, 303 builds, 8 clients. |
| 07:38:06 | rb-bluebot | Build Server message: Build round completed after 952 seconds. |
| 07:38:07 | rb-bluebot | Build Server message: Revision 4fb5aeb096 result: 4 errors 0 warnings |
| 07:39:25 | _bilgus_ | :/ |
| 07:40:36 | _bilgus_ | uh oh /home/rbbuild/x-tools/rockbox/lib/gcc/m68k-elf/4.9.4/../../../../m68k-elf/bin/ld: /home/rbbuild/rockbox/build-iaudiom5/rockbox.elf section `.stack' will not fit in region `IRAM' |
| 07:41:12 | braewoods | _bilgus_: what'd you chnage? |
| 07:41:58 | | Join advcomp2019_ [0] (~advcomp20@user/advcomp2019) |
| 07:42:49 | braewoods | hm. |
| 07:43:56 | _bilgus_ | its tight apparently |
| 07:44:32 | braewoods | _bilgus_: why'd you cast the void*? that's usually unneeded. |
| 07:45:16 | braewoods | hm. |
| 07:45:33 | braewoods | so what changed? code size? stack size? both? |
| 07:46:01 | braewoods | i'm leaning towards code size since the compiler is probably using registers |
| 07:46:31 | _bilgus_ | yep its the same size but not.. |
| 07:47:01 | _bilgus_ | I've been checking asm and this is as close as I got |
| 07:47:03 | | Join yang-idl1 [0] (~yang@199.189.205.50) |
| 07:47:19 | _bilgus_ | I'll try messing with the m5 direct |
| 07:47:50 | | Join dys [0] (~dys@user/dys) |
| 07:47:55 | speachy | yeah, the m5 has given us plenty of grief before |
| 07:48:05 | braewoods | _bilgus_: did you consider trying something a bit different? |
| 07:48:21 | | Join emacsoma1 [0] (~emacsoman@136.60.128.68) |
| 07:48:24 | braewoods | hm |
| 07:48:31 | braewoods | nevermind, probably wouldn't help |
| 07:48:51 | _bilgus_ | a bit different ranged from 10-30 more instructions |
| 07:49:11 | braewoods | i wonder what would happen if you tried changing the optimization level |
| 07:49:17 | _bilgus_ | open to suggestions |
| 07:49:22 | braewoods | i've sometimes found -O2 actually beats -Os in some cases |
| 07:49:36 | speachy | _bilgus_: IIRC the last time this happened we "fixed" it by shrinking the stack slightly. |
| 07:49:36 | braewoods | but that's probably a big hack on its own |
| 07:49:45 | _bilgus_ | I can probably find 16 bytes |
| 07:50:08 | _bilgus_ | if not they will start sharing code |
| 07:50:18 | _bilgus_ | which maybe I should do |
| 07:50:24 | _bilgus_ | anyway.. |
| 07:50:41 | braewoods | speachy: sounds like most coldfire is a royal PITA. |
| 07:50:56 | braewoods | speachy: and only the iriver ones are common these days to find availablbe |
| 07:51:18 | speachy | braewoods: due to crappy caches we have to put critical code into IRAM if it has a hope of being performant |
| 07:51:32 | braewoods | so IRAM is basically coldfire's fast ram |
| 07:51:35 | speachy | and the X5 has a bit more than most, due to its features |
| 07:51:54 | | Quit emacsomancer (*.net *.split) |
| 07:51:55 | | Quit benjaoming (*.net *.split) |
| 07:51:55 | | Quit markun_ (*.net *.split) |
| 07:51:55 | | Quit advcomp2019__ (*.net *.split) |
| 07:51:56 | | Quit tomato (*.net *.split) |
| 07:51:56 | | Quit Piece_Maker (*.net *.split) |
| 07:51:57 | | Quit ufdm (*.net *.split) |
| 07:51:57 | | Quit blbro[m] (*.net *.split) |
| 07:51:57 | | Quit danwellby (*.net *.split) |
| 07:51:57 | | Quit hook54321 (*.net *.split) |
| 07:52:00 | | Quit gevaerts (*.net *.split) |
| 07:52:00 | | Quit michaelni (*.net *.split) |
| 07:52:00 | | Quit yang-idle (*.net *.split) |
| 07:52:00 | | Quit spork (*.net *.split) |
| 07:52:00 | | Quit TorC (*.net *.split) |
| 07:52:00 | | Quit pixelma (*.net *.split) |
| 07:52:00 | | Quit ats (*.net *.split) |
| 07:52:00 | | Quit Xeha (*.net *.split) |
| 07:52:00 | | Quit vup (*.net *.split) |
| 07:52:02 | | Quit rudi_s (*.net *.split) |
| 07:52:03 | | Quit kirvesAxe (*.net *.split) |
| 07:52:03 | | Quit jschwart (*.net *.split) |
| 07:52:03 | | Quit reductum (*.net *.split) |
| 07:52:03 | | Quit Arsen (*.net *.split) |
| 07:52:04 | speachy | IRAM is usually memory that's capable of running at full processor speed; ie no wait states |
| 07:52:06 | speachy | vs external RAM that's a lot slower |
| 07:52:06 | braewoods | ugh. net split. |
| 07:52:22 | speachy | caches hide that latency a lot |
| 07:52:45 | braewoods | is that the main reason linked lists have turned into performance dogs today? |
| 07:52:51 | braewoods | they're not very cache friendly. |
| 07:53:14 | | Join benjaoming [0] (~benjaomin@37.139.19.237) |
| 07:53:14 | | Join markun_ [0] (~markun@178-84-100-63.dynamic.upc.nl) |
| 07:53:18 | braewoods | at least on systems where cache misses are a serious issue |
| 07:53:28 | speachy | they don't scale up well, but all data structures are exercises in tradeoffs |
| 07:53:42 | braewoods | indeed, i usually use arrays today where i can. |
| 07:53:56 | _bilgus_ | woot |
| 07:53:57 | speachy | you can't slice and dice elements into/out of arrays though |
| 07:54:05 | braewoods | i know. it's a tradeoff. |
| 07:54:16 | braewoods | speachy: well, you can in sparse arrays. but yea. |
| 07:54:28 | speachy | sparse arrays aren't exactly cache friendly either. :D |
| 07:54:49 | braewoods | i know, mostly just convience of having a global lookup table of sorts you can access quickly |
| 07:55:24 | braewoods | arrays of pointers are also problematic but they are good for quick rearrangement of data |
| 07:55:38 | braewoods | cost of copying is greatly reduced |
| 07:56:08 | | Quit kadoban (Ping timeout: 272 seconds) |
| 07:56:11 | speachy | when it comes to sorting... heh, entire academic careers have been based on optimizing that |
| 07:57:00 | braewoods | i've sometimes concatenated a bunch of strings all into a contiguous memory region. used an array of pointers to manage access. this is only practical for read-only strings though. |
| 07:57:09 | | Join Arsen [0] (~arsen@managarm/dev/Arsen) |
| 07:57:38 | | Join dconrad [0] (~dconrad@208.38.228.17) |
| 07:57:49 | | Join tomato [0] (~tomato@user/tomato) |
| 07:57:49 | | Join Piece_Maker [0] (~Piece_Mak@cpc95746-bolt17-2-0-cust360.10-3.cable.virginm.net) |
| 07:57:49 | | Join ufdm [0] (~ufdm@c-73-164-63-214.hsd1.mn.comcast.net) |
| 07:57:49 | | Join blbro[m] [0] (~blbrostra@2001:470:69fc:105::8f7) |
| 07:57:49 | | Join danwellby [0] (~danwellby@88.97.8.245) |
| 07:57:49 | | Join hook54321 [0] (sid149355@user/hook54321) |
| 07:57:53 | | Join rudi_s [0] (~simon@user/rudi-s/x-7673890) |
| 07:57:53 | | Join kirvesAxe [0] (~kirvesaxe@user/kirvesaxe) |
| 07:57:53 | | Join jschwart [0] (~quassel@2001:985:2c6e:0:b00b:32ff:fe28:5567) |
| 07:57:53 | | Join reductum [0] (~reductum@2603-8000-b400-8764-dea6-32ff-fe16-a622.res6.spectrum.com) |
| 07:58:00 | | Join gevaerts [0] (~fg@user/gevaerts) |
| 07:58:00 | | Join michaelni [0] (~michael@213-47-68-29.cable.dynamic.surfer.at) |
| 07:58:00 | | Join spork [0] (topic@31-151-2-135.dynamic.upc.nl) |
| 07:58:00 | | Join TorC [0] (~Tor@fsf/member/TorC) |
| 07:58:00 | | Join pixelma [0] (marianne@p200300ea874bea00305e95fffec66ff3.dip0.t-ipconnect.de) |
| 07:58:00 | | Join ats [0] (~ats@cartman.offog.org) |
| 07:58:00 | | Join Xeha [0] (~Xeha@dynamic-82-220-88-142.ftth.solnet.ch) |
| 07:58:00 | | Join vup [0] (~~~~@46.101.193.235) |
| 07:58:03 | braewoods | speachy: correct me if i'm wrong but is the main reason memcpy is undefined for overlapping memory regions due to the fact that the copy mechanic is not defined? |
| 07:58:10 | speachy | correct. |
| 07:58:12 | braewoods | optimization reasons basically. |
| 07:58:22 | rb-bluebot | Build Server message: New build round started. Revision ee6b737b65, 303 builds, 8 clients. |
| 07:59:21 | _bilgus_ | funny thing is I had done this with one of the patchsets but it didn't change the emitted code size so I figured the compiler out smarted me |
| 08:00 |
| 08:00:58 | braewoods | i was considering using branchless versions of some operations in inflate but it occurs to me most of our targets don't have cpus sophisticated enough to benefit from branch elimination |
| 08:01:02 | | Quit blbro[m] (Ping timeout: 256 seconds) |
| 08:01:28 | _bilgus_ | when it gets like that I do stuff to view the asm |
| 08:01:48 | braewoods | iirc, that would only benefit desktop builds. |
| 08:02:06 | braewoods | does the ingenic x1000e even have a branch predictor? |
| 08:02:12 | braewoods | our newest target to date |
| 08:02:17 | braewoods | that isn't a desktop system |
| 08:02:20 | _bilgus_ | compiler explorer makes it more fun but just need to /home/bilgus/Desktop/RockboxDev/PLUGINFLAGS += -g -Wa,-adhln.txt |
| 08:02:27 | _bilgus_ | compiler explorer makes it more fun but just need to /home/bilgus/Desktop/RockboxDev/PLUGINFLAGS += -g -Wa,-adhln |
| 08:02:27 | speachy | code compactness matters most; the more that fits in the instruction cache the better |
| 08:02:46 | _bilgus_ | sorry its a file apparently |
| 08:02:54 | _bilgus_ | lol |
| 08:03:17 | _bilgus_ | I usually do arm bc i'm most familar with the instructions |
| 08:03:31 | speachy | braewoods: it's an 8-stage pipeline, so missed branches definitely hurt |
| 08:03:56 | braewoods | speachy: we could replace some macros with branchless alternatives. e.g., min/max |
| 08:04:16 | _bilgus_ | dio it with ifdefs please |
| 08:04:19 | braewoods | but i don't know how helpful it'd be |
| 08:04:30 | speachy | it has a branch predictor |
| 08:04:44 | braewoods | so eliminating branches we don't really need could help |
| 08:04:57 | speachy | I'm sure it could help, but how much vs the effort? |
| 08:05:12 | braewoods | no idea. as it stands MIN/MAX branchless isn't that complex. |
| 08:05:17 | speachy | and if it makes the code larger, it might hurt more than it helps on less cache-heavy targets |
| 08:05:30 | braewoods | i'll look into it later. |
| 08:05:55 | braewoods | i suspect only targets with branch predictors benefit |
| 08:06:48 | braewoods | it's a project for another time |
| 08:07:03 | braewoods | but some of the newer ports might benefit from this; i'd put these behind a branchless macro |
| 08:07:13 | braewoods | something we can enable for CPUs known to benefit |
| 08:07:40 | *** | Saving seen data "./dancer.seen" |
| 08:08:55 | braewoods | When did ARM gain branch prediction? |
| 08:09:38 | speachy | I think the ARM9xx series of processors |
| 08:09:58 | braewoods | i suspect PP and ColdFire wouldn't benefit from this. |
| 08:11:03 | rb-bluebot | Build Server message: Build round completed after 761 seconds. |
| 08:11:05 | rb-bluebot | Build Server message: Revision ee6b737b65 result: All green |
| 08:11:23 | speachy | ARM11 definitely had it, ARM9 maybe, but I don't think so now. ARM7 nope. |
| 08:11:45 | speachy | coldfire actually does have some branch rpediction |
| 08:11:48 | braewoods | So where do these fit in the armv4, etc, labels? |
| 08:12:00 | speachy | armv4/v5/etc are the instruction sets |
| 08:12:22 | braewoods | Oh. Nothing to do with the actual ARM core. |
| 08:12:37 | speachy | whereas ARM7/9/11/etc are the implementations in silicon |
| 08:13:03 | speachy | ARM7 implements armv4, ARM9 implements armv5, ARM11 implements armv6 |
| 08:13:35 | speachy | cortex-a* implements armv7 (newer ones are armv8 and now armv9) |
| 08:14:34 | dconrad | who on earth thought that was a good naming convention?? |
| 08:14:39 | speachy | cortex-m0/m0+ is armv6m (truly cut down!) but most cortex-ms are v7m. newest ones (just becoming generally available) are v8m. |
| 08:14:52 | speachy | "it seemed like a good idea at the time" :D |
| 08:15:19 | speachy | What's fun is that you could get the ARM ARM ARM |
| 08:15:48 | speachy | ARM (the company) ARM (architecture) ARM ("architecture reference manual") |
| 08:16:10 | speachy | I think someone else managed to tack a fourth ARM on to that right around the time I left |
| 08:16:17 | dconrad | at that point they're clearly just being jokers |
| 08:16:58 | dconrad | they need something thats the LEG, and maybe FOOT |
| 08:17:16 | speachy | dconrad: but in all seriousness, that confusion is a big part of why they started calling using the "cortex-A/M/R" designation for the actual cores |
| 08:17:27 | braewoods | when AMD was toying with their dual architecture boards, i used to joke they could change their name to AAA now. |
| 08:17:31 | braewoods | AMD, ATI, ARM |
| 08:17:33 | braewoods | :D |
| 08:17:40 | speachy | dconrad: oh, it's been done (internally) |
| 08:17:47 | dconrad | lol |
| 08:18:05 | speachy | one of the few external examples of that is the "thumb" instruction set. |
| 08:18:26 | braewoods | what was the point of those? reducing the size of instructions? |
| 08:18:38 | speachy | yeah, 16-bit vs 32-bit instruction size |
| 08:18:43 | speachy | makes your code a _lot_ more compact |
| 08:18:57 | braewoods | are those still used on modern designs? |
| 08:19:01 | speachy | you lose some performance (because you can't access as many general purpose registers) |
| 08:19:15 | speachy | but when you're memory/cache-constrained it can make a big difference |
| 08:19:36 | _bilgus_ | only reason the clip+ fit.. |
| 08:19:44 | speachy | outside of the embedded (ARMxTDMI and Cortex-M) processors that require it, it's not used much. |
| 08:19:46 | _bilgus_ | thumb |
| 08:20:30 | braewoods | is it my imagination or does x86 have fewer GP registers than other architectures of its time did? |
| 08:20:35 | speachy | IIRC armv8 (ie 64-bit) did away with it, re-working the entire instruction set encoding |
| 08:20:48 | speachy | x86 was infamously register-constrained. |
| 08:21:01 | braewoods | does 64 bit do enough to address that? |
| 08:21:31 | braewoods | x86 was pretty late to the 64 bit party but arm was even later assuming my timelines are right |
| 08:21:34 | speachy | x86_64's main performance benefit was the expansion of the register file |
| 08:21:43 | braewoods | mips64 existed (on paper) much earlier |
| 08:22:05 | speachy | mips existed in silicon at least a decade before x86_64 |
| 08:22:11 | speachy | mips64, I mean |
| 08:22:23 | braewoods | seems most of the mips implementors stick to 32 bit though |
| 08:22:49 | bertrik | I remember there being a lot of talks on arm64 at fosdem when that was a new thing |
| 08:22:56 | braewoods | you know what would be funny to see? |
| 08:22:57 | speachy | the R4000 PCU (MIPS III instruction set) was announced in 1991. |
| 08:23:00 | braewoods | the bogomips of a mips processor :D |
| 08:23:42 | speachy | due to larger integer and pointer sizes, unless your code needed to work with 64-bit stuff natively it was faster to stick with 32-bit code |
| 08:24:01 | speachy | (solely due to the larger memory footprint of 64-bit stuff) |
| 08:24:16 | speachy | the MIPS instruction set had 32 GPRs |
| 08:24:21 | braewoods | only performance powerhouses probably need 64 bits in general |
| 08:24:49 | braewoods | there's a few cases where 64 bits is helpful for supporting large files or so though. |
| 08:25:14 | speachy | what typically happened is that the kernel was 64-bit, but most userspace was 32-bit |
| 08:25:16 | braewoods | speachy: isn't that part of why x32 was a thing? |
| 08:25:22 | speachy | same with sparc actually |
| 08:25:46 | braewoods | it was a special amd64 ABI. |
| 08:25:56 | speachy | braewoods: yep, that's the idea behind x32. but it wasn't better enough than "normal" x86 to overcome the penalty of losing binary compatibility. |
| 08:26:35 | braewoods | i actually had to correct people that dropping x32 didn't mean losing 32 bit x86 support. |
| 08:26:38 | * | braewoods facepalms. |
| 08:27:09 | speachy | x32 used 32-bit pointers but gained access to all of the other x86_64 improvments like the expanded register set and instructions |
| 08:27:41 | braewoods | it also meant you couldn't memory map larger stuff |
| 08:27:47 | braewoods | or similar |
| 08:28:35 | braewoods | for rockbox though there's little point to 64 bit since most of our main stuff wouldn't benefit |
| 08:28:39 | speachy | yeah, the larger address space was the real benefit, even in the 90s |
| 08:29:19 | speachy | made for far, far, far simpler code. |
| 08:29:23 | braewoods | we can't handle files larger than 2GB anyway (assuming my code analysis is correct) |
| 08:29:28 | braewoods | since our file offsets are signed |
| 08:29:52 | braewoods | is that correct? |
| 08:30:03 | speachy | there's no reason we couldn't go to 64-bit file offset pointers tomorrow |
| 08:30:21 | speachy | we don't have to maintain binary compatibiltiy with anything else |
| 08:30:29 | braewoods | the only point would be supporting 4GB files on FAT32 |
| 08:30:45 | speachy | yeah, but who's going to use a >2GB audio file? :) |
| 08:30:55 | braewoods | when i work on MTP, i plan to factor the size into my code. |
| 08:30:57 | speachy | (if we handled video that would be another matter...) |
| 08:31:08 | braewoods | if they try to pass a value larger than our off_t can store, it'll be rejected. |
| 08:31:34 | braewoods | technically MTP only supports up to 32 bit unsigned stuff |
| 08:31:37 | speachy | use size_t and offset_t in your code and it's trivially changed with a recompile later. (except of course the over-the-wire stuff, which is fixed) |
| 08:31:41 | braewoods | no point in supporting the 64bit etensions |
| 08:32:01 | braewoods | since our underlying FS can't handle it anyway |
| 08:32:10 | | Join massiveH [0] (~massiveH@ool-18e4e82f.dyn.optonline.net) |
| 08:32:30 | speachy | what would benefit us the most isn't 64-bit instruction sets, but rather SIMD/DSP stuff. |
| 08:32:54 | braewoods | just stating it does have some limits but it's a very short list. |
| 08:32:55 | speachy | enabling our codecs and other computtionally-heavy stuff to go much faster. |
| 08:33:01 | braewoods | mainly time and file sizes. |
| 08:33:06 | braewoods | for our stuff. |
| 08:33:08 | speachy | but utilizng that effectively is a _lot_ of work |
| 08:34:01 | braewoods | speachy: a lot of port specific code. |
| 08:34:02 | speachy | heh, the ingenic parts we're using have a pretty rich SIMD engine that's arguably more powerful than the main mips core |
| 08:34:55 | speachy | well, not "port specific" so much as "processor architecture specific" |
| 08:35:07 | braewoods | the x1000e has a lot of potential for architecture specific optimizations |
| 08:35:13 | braewoods | such as branchless |
| 08:35:32 | braewoods | whether they amount to anything is another question |
| 08:35:33 | speachy | hoestly that level of optimization will be a rounding error |
| 08:35:58 | braewoods | at least my new workstation is nearly done |
| 08:36:15 | braewoods | i was long overdue for an upgrade |
| 08:36:18 | speachy | which is good if you're at the point where even rounding errors matter (eg a lot of what went into the PP code) |
| 08:36:40 | braewoods | 64GB of ECC RAM, an 8 core APU |
| 08:37:32 | speachy | the single largest bang-for-buck optimization on our MIPS code would be to implement nested/preemptible interrupts. |
| 08:38:41 | speachy | I have some half-started code on that front but I think it would take a rework of our core threading/os code to actually be viable |
| 08:39:07 | | Join blbro[m] [0] (~blbrostra@2001:470:69fc:105::8f7) |
| 08:39:24 | speachy | though It did occur to me that we might benefit now from ditching our custom OS in favor of (eg) FreeRTOS. |
| 08:39:48 | braewoods | so we'd become an application? |
| 08:40:26 | speachy | well, we already are an application, albeit bolted to our own OS instead of someone else's. |
| 08:41:12 | speachy | but our OS interface is pretty much the same as every other RTOS; ie threads, mutexes, semaphores |
| 08:42:12 | braewoods | speachy: do you have any advice for IP cameras? seems like they're all stuck with proprietary firmware doing who knows what. |
| 08:43:41 | speachy | they're all more or less the same junk. so unless you want to roll your own (which will also be junk, just differently so) you're best off sticking to things that don't require cloud integration and have the physical features you need. |
| 08:44:40 | braewoods | i thought so. i was hoping to find one that already had an openwrt port but no such luck. |
| 08:44:46 | speachy | there are several pure-FOSS surveillance systems out there that will work with any camera that supplies an RSTP feed |
| 08:45:04 | braewoods | i know, but what i'm currently looking at is the actual cameras. |
| 08:45:13 | braewoods | the management system is a different story |
| 08:45:40 | speachy | you could always just use an RPi with its native camera or with a USB-attached webcam or something |
| 08:45:57 | braewoods | can you weather-proof that? |
| 08:46:05 | braewoods | or custom case required? |
| 08:46:07 | speachy | sure, but not cost-effectively vs just buying one already put together |
| 08:46:29 | speachy | especially if you want things like PoE, IR LEDs, rotation control, etc etc |
| 08:48:22 | braewoods | well to me what matters most is retaining software control |
| 08:48:39 | braewoods | i don't trust proprietary stuff not to betray me so to speak |
| 08:48:53 | braewoods | especially since most of them require a network connection to do anything |
| 08:49:27 | speachy | even if you take an untrusted camera, you can always firewall the crap out of it so it can only send data to your designated system(s). |
| 08:53:24 | braewoods | speachy: i see that. i'm just weighing my options for now. |
| 08:56:56 | | Quit dconrad (Remote host closed the connection) |
| 09:00 |
| 09:09:19 | | Join dconrad [0] (~dconrad@208.38.228.17) |
| 09:13:59 | | Quit dconrad (Ping timeout: 252 seconds) |
| 09:21:08 | | Join kadoban [0] (~kadoban@user/kadoban) |
| 10:00 |
| 10:07:41 | *** | Saving seen data "./dancer.seen" |
| 10:16:21 | | Quit _bilgus_ (Remote host closed the connection) |
| 10:20:19 | | Quit skipwich (Quit: DISCONNECT) |
| 10:20:31 | | Join skipwich [0] (~skipwich@user/skipwich) |
| 10:21:11 | | Quit massiveH (Quit: Leaving) |
| 10:37:17 | | Quit yang-idl1 (Changing host) |
| 10:37:17 | | Join yang-idl1 [0] (~yang@fsf/member/yang) |
| 10:37:42 | | Nick yang-idl1 is now known as yang-idle (~yang@fsf/member/yang) |
| 10:40:05 | | Join Moriar [0] (~moriar@107-200-193-159.lightspeed.stlsmo.sbcglobal.net) |
| 10:43:18 | blbro[m] | Tried to make the manual build with old and new versions of KOMAscript: g#3689 |
| 10:43:20 | rb-bluebot | Gerrit review #3689 at https://gerrit.rockbox.org/r/c/rockbox/+/3689 : manual: Add workaround for older KOMAscript versions. by Dominik Riebeling |
| 10:44:08 | speachy | seems sane |
| 10:44:42 | blbro[m] | cannot try with a newer installation right now, would be nice if someone could confirm this isn't breaking things :) |
| 10:46:56 | speachy | just the regular 'make manual' ? |
| 10:47:11 | speachy | oof, big boom. |
| 10:48:09 | speachy | yeah, it's badly broken |
| 10:49:30 | blbro[m] | :/ |
| 10:49:43 | blbro[m] | was half expecting that. It does work for me ... |
| 10:50:00 | blbro[m] | guess I need to give it another look later |
| 10:50:26 | | Join bigman60y [0] (~bigman60y@136.144.33.92) |
| 10:52:21 | bigman60y | Hello. Trying to use SonyNWDest Tool on a NW-A45 on a Windows10 PC and getting error: Cannot open device. |
| 10:54:51 | blbro[m] | speachy: is there anything hinting to why it goes boom? Wondering if that \ifdefined doesn't like the if clause to be empty. |
| 10:55:34 | speachy | re-running capturing the full output |
| 10:56:38 | speachy | blbro[m]: www.shaftnet.org/~pizza/boom.txt |
| 10:58:52 | blbro[m] | in preamble.tex, if you add \typeout(blah) before the \else, does that make a difference? |
| 11:00 |
| 11:22:00 | speachy | blbro[m]: nopw |
| 11:35:20 | | Quit bigman60y (Quit: Connection closed) |
| 11:43:56 | | Join bigman60y [0] (~bigman60y@136.144.33.92) |
| 11:52:48 | | Quit bigman60y (Quit: Connection closed) |
| 12:00 |
| 12:00:18 | | Quit Moriar (Ping timeout: 268 seconds) |
| 12:05:05 | | Join bigman60y [0] (~bigman60y@136.144.33.92) |
| 12:05:11 | | Quit bigman60y (Client Quit) |
| 12:07:45 | *** | Saving seen data "./dancer.seen" |
| 13:00 |
| 13:02:05 | | Join lebellium [0] (~lebellium@2a01:cb10:2e:2000:8d5f:ebab:9329:1ae8) |
| 14:00 |
| 14:07:46 | *** | No seen item changed, no save performed. |
| 14:39:45 | | Join _bilgus [0] (~bilgus@162.154.213.134) |
| 15:00 |
| 15:04:53 | rb-bluebot | Build Server message: New build round started. Revision 614b189f7a, 303 builds, 9 clients. |
| 15:16:34 | rb-bluebot | Build Server message: Build round completed after 702 seconds. |
| 15:16:36 | rb-bluebot | Build Server message: Revision 614b189f7a result: All green |
| 15:23:18 | | Join Moriar [0] (~moriar@107-200-193-159.lightspeed.stlsmo.sbcglobal.net) |
| 15:36:26 | braewoods | dmesg |
| 15:36:27 | braewoods | err |
| 16:00 |
| 16:07:49 | *** | No seen item changed, no save performed. |
| 16:37:20 | | Quit edhelas (Read error: Connection reset by peer) |
| 17:00 |
| 17:07:55 | | Quit lebellium (Quit: Leaving) |
| 17:44:53 | | Join amachronic [0] (~amachroni@user/amachronic) |
| 17:47:06 | rb-bluebot | Build Server message: New build round started. Revision a8063054f9, 303 builds, 9 clients. |
| 17:58:35 | rb-bluebot | Build Server message: Build round completed after 689 seconds. |
| 17:58:37 | rb-bluebot | Build Server message: Revision a8063054f9 result: All green |
| 17:59:39 | rb-bluebot | Build Server message: New build round started. Revision 69420e796c, 303 builds, 9 clients. |
| 18:00 |
| 18:07:53 | *** | Saving seen data "./dancer.seen" |
| 18:13:11 | rb-bluebot | Build Server message: Build round completed after 812 seconds. |
| 18:13:13 | rb-bluebot | Build Server message: Revision 69420e796c result: All green |
| 18:13:58 | rb-bluebot | Build Server message: New build round started. Revision b103b07503, 303 builds, 9 clients. |
| 18:27:22 | rb-bluebot | Build Server message: Build round completed after 804 seconds. |
| 18:27:23 | rb-bluebot | Build Server message: Revision b103b07503 result: All green |
| 18:38:11 | rb-bluebot | Build Server message: New build round started. Revision cdd1f90131, 303 builds, 9 clients. |
| 18:51:10 | rb-bluebot | Build Server message: Build round completed after 780 seconds. |
| 18:51:12 | rb-bluebot | Build Server message: Revision cdd1f90131 result: All green |
| 19:00 |
| 19:03:28 | | Quit Natch (Remote host closed the connection) |
| 19:18:57 | | Quit amachronic (Quit: amachronic) |
| 19:19:06 | | Join dconrad [0] (~dconrad@208.38.228.17) |
| 19:28:17 | dconrad | g#3696 if anybody wants to take a look |
| 19:28:19 | rb-bluebot | Gerrit review #3696 at https://gerrit.rockbox.org/r/c/rockbox/+/3696 : Eros Q Native: Make Mute logic channel-independent by Dana Conrad |
| 19:28:36 | dconrad | a pretty simple patch for pretty basic oversight on my part haha |
| 19:45:21 | rb-bluebot | Build Server message: New build round started. Revision 77a98ada12, 303 builds, 8 clients. |
| 19:47:43 | | Quit ZincAlloy (Quit: Leaving.) |
| 20:00 |
| 20:04:25 | rb-bluebot | Build Server message: Build round completed after 1143 seconds. |
| 20:04:26 | rb-bluebot | Build Server message: Revision 77a98ada12 result: All green |
| 20:07:54 | *** | Saving seen data "./dancer.seen" |
| 20:15:10 | | Join F3l1x_10m_ [0] (~Al3x_10m@user/f3l1x-10m/x-3393542) |
| 20:18:58 | | Quit F3l1x_10m (Ping timeout: 240 seconds) |
| 20:32:51 | | Join F3l1x_10m__ [0] (~Al3x_10m@user/f3l1x-10m/x-3393542) |
| 20:36:06 | | Quit F3l1x_10m_ (Ping timeout: 258 seconds) |
| 20:41:49 | | Join F3l1x_10m_ [0] (~Al3x_10m@user/f3l1x-10m/x-3393542) |
| 20:44:55 | | Quit F3l1x_10m__ (Ping timeout: 258 seconds) |
| 20:53:26 | | Quit tchan (Read error: No route to host) |
| 21:00 |
| 21:08:34 | | Join tchan [0] (~tchan@c-98-206-141-238.hsd1.il.comcast.net) |
| 21:22:30 | | Quit dconrad (Remote host closed the connection) |
| 21:23:37 | | Join dconrad [0] (~dconrad@208.38.228.17) |
| 21:36:33 | rb-bluebot | Build Server message: New build round started. Revision c9e9558044, 303 builds, 8 clients. |
| 21:42:37 | speachy | nice, load average of 39. :D |
| 21:51:37 | rb-bluebot | Build Server message: Build round completed after 903 seconds. |
| 21:51:38 | rb-bluebot | Build Server message: Revision c9e9558044 result: All green |
| 21:51:59 | _bilgus | what was the previous average? |
| 21:54:34 | speachy | that's was builder here |
| 21:54:38 | speachy | my builder here, I mean |
| 21:54:56 | speachy | it was already pushing 30 on an unrelated job prior to this build round |
| 21:56:21 | _bilgus | coverity doesn't do stdin processing apparently |
| 21:56:25 | _bilgus | Error: compilation via stdin '-' unsupported. All other compilations will proceed as normal |
| 22:00 |
| 22:01:58 | _bilgus | all these safety bytes keep adding up |
| 22:02:31 | _bilgus | been trying to keep code increase minimal... |
| 22:04:52 | speachy | of course. |
| 22:05:44 | speachy | don't see any real alternative though; bad data can lead to all sorts of odd behavior |
| 22:06:40 | speachy | (I'm not too worried about outright crashes, and it's not like there can be any security implications, but let's not risk trashing random memory/stack...) |
| 22:07:57 | *** | Saving seen data "./dancer.seen" |
| 22:09:11 | _bilgus | oh the number of real bugs found outweighs all the strife |
| 22:10:33 | speachy | if we have to we can drop-kick the 2MB targets. :) |
| 22:10:41 | _bilgus | now we just need to wait and see what else we broke |
| 22:11:01 | _bilgus | all those assumptions |
| 22:11:40 | _bilgus | there has to be even fewer |
| 22:11:47 | _bilgus | of the 2mb targets |
| 22:15:54 | speachy | only the clipv1, m200v4, and c200v2 |
| 22:26:05 | speachy | cant' be too many of those left in working order |
| 22:27:05 | speachy | have to say the server's definitely snappier with respect to post-round activities |
| 22:34:41 | | Quit Moriar (Ping timeout: 248 seconds) |
| 23:00 |
| 23:11:58 | | Quit dconrad (Remote host closed the connection) |
| 23:19:25 | | Join dconrad [0] (~dconrad@208.38.228.17) |
| 23:19:47 | _bilgus | and for less power I presume |
| 23:23:45 | | Quit dconrad (Ping timeout: 248 seconds) |
icon identifies that the person is a core developer (has commit access).