Re: style change: explicitly permit braces for single statements
On Thu 16 Jul 2020 at 13:08:49 -0400, Ted Lemon wrote: > It sounds like we need a better tool. FWIW, when actually working on > code, I've found that 120 is a better width than 80 -- with 80, there are > just too many line breaks. But I don't mean to say that your > preference is wrong -- what sucks is that we have to compromise, instead > of having tools that present the text the way that we want to consume > it without changing anything in the underlying file. E.g. web browsers > just reflow the text when you change the window width. Why don't we > have this for code editors? I have seen an editor (I think it was google's Android development environment) that even went so far as to recognize some particular boilerplate Java code fragments, and abbreviated them. You could unfold them if you wanted though. I wasn't sure if I liked that or hated it. -Olaf. -- Olaf 'Rhialto' Seibert -- rhialto at falu dot nl ___ Anyone who is capable of getting themselves made President should on \X/ no account be allowed to do the job. --Douglas Adams, "THGTTG" signature.asc Description: PGP signature
Re: style change: explicitly permit braces for single statements
> E.g. web browsers just reflow the text when you change the window > width. Why don=E2=80=99t we have this for code editors? Short answer: try to build it and you'll see. Longer answer: Because the exact layout of `words' affects readability of code far more than it does running text. Consider Longer answer: Because the exact layout of `words' affects readability of code far more than it does running text. Longer answer: Because the exact layout of `words' affects readability of code far more than it does running text. Longer answer: Because the exact layout of `words' affects readability of code far more than it does running text. Longer answer: Because the exact layout of `words' affects readability of code far more than it does running text. To a first approximation, all are equally readable. Now consider for (i=0;i<32;i++) ring[i] = 0; j = 0; for (i=0;i<32;i++) j = map[j]; for (i=0;i<10;i++) { ring[j] = 1; j = map[j]; } for (i=0;i<32;i++) ring[i] = 0; j = 0; for (i=0;i<32;i++) j = map[j]; for (i=0;i<10;i++) { ring[j] = 1; j = map[j]; } for (i=0;i<32;i++) ring[i] = 0; j = 0; for (i=0;i<32;i++) j = map[j]; for (i=0;i<10;i++) { ring[j] = 1; j = map[j]; } for (i=0;i<32;i++) ring[i] = 0; j = 0; for (i=0;i<32;i++) j = map[j]; for (i=0;i<10;i++) { ring[j] = 1; j = map[j]; } for (i=0;i<32;i++) ring[i] = 0; j = 0; for (i=0;i<32;i++) j = map[j]; for (i=0;i<10;i++) { ring[j] = 1; j = map[j]; } IMO, none of those are even close to as readable as the first one. I suspect that even those who don't like the style of the first one will find it more readable than any of the reflowed versions. The problem is that introducing line breaks into code in a way that doesn't slaughter readability is a hard problem. There are tools, like indent, that try to partially solve it. Some of them don't do too horrible a job, but even they fail catastrohpically in some cases (as I remarked upthread, I've yet to see a rule that won't cripple readability in at least a few cases.) I suspect doing it *well* is an AI-complete problem; in support of this stance, note that humans often disagree as to which of various alternatives is more readable, and note also that tools like indent invariably utterly trash readability in various extreme cases, cases in which humans have the aesthetic judgement to realize that rules must sometimes be broken to preserve minimal readability. The analogous problem for text does exist, mostly with poetry. Consider, for example, something like Thus has it been told in the ancient recountings Of those who before us were here And their kinds and their ways, the Valar, most terrible, Holy, and bless'd, and revered. Simply reflowing that Thus has it been told in the ancient recountings Of those who before us were here And their kinds and their ways, the Valar, most terrible, Holy, and bless'd, and revered. rather mangles it. Now try to fit it into a narrow column. Just reflowing for a narrow column gives Thus has it been told in the ancient recountings Of those who before us were here And their kinds and their ways, the Valar, most terrible, Holy, and bless'd, and revered. and it's not obvious, even to a human, how to lay it out so as to both preserve the poetic structure and fit it into a narrow column. Here's about the best I've been able to do: Thus has it been told in the ancient recountings Of those who before us were here And their kinds and their ways, the Valar, most terrible, Holy, and bless'd, and revered. but even that doesn't look nearly as nice, to my eye, as the original. I've occasionally thought about trying to build tools that treat C code (because C is what I mostly work in these days) as a stream of C tokens, ignoring layout, for purposes like diff. It would be much harder to do so for purposes of code editing, because the clearest layout depends heavily on semantics. For example, in general, I would tend to format else-if chains more or less like this: if (...) ... else if (...) ... else if (...) ... else ... But I've seen cases where (I think) it's clearer to do things that, in other contexts, would look bizarre: if (!strcmp(s,"one" )) v = 1; else if (!strcmp(s,"two" )) v = 2; else if (!strcmp(s,"three" )) v = 3; else if (!strcmp(s,"ten" )) v = 10; else if (!strcmp(s,"hundred" )) v = 100; else if (!strcmp(s,"thousand")) v = 1000; else badarg(s); Making the parallel code structure into parallel visual structure is compel
Re: style change: explicitly permit braces for single statements
On Jul 16, 2020, at 12:16 PM, Gerhard Sittig wrote: > Text line length does matter to those of us who put several > copies of code side by side. It sounds like we need a better tool. FWIW, when actually working on code, I’ve found that 120 is a better width than 80—with 80, there are just too many line breaks. But I don’t mean to say that your preference is wrong—what sucks is that we have to compromise, instead of having tools that present the text the way that we want to consume it without changing anything in the underlying file. E.g. web browsers just reflow the text when you change the window width. Why don’t we have this for code editors?
Re: style change: explicitly permit braces for single statements
On Mon, 2020-07-13 at 09:18 -0700, Greg A. Woods wrote: > > At Mon, 13 Jul 2020 09:48:07 -0400 (EDT), Mouse > wrote: > Subject: Re: style change: explicitly permit braces for single statements > > > > Slavishly always > > adding them makes it difficult to keep code from walking into the right > > margin: > > These days one really should consider the right margin to be a virtual > concept -- there's really no valid reason not to have and use horizontal > scrolling (any code editor I'll ever use can do it on any display), and > even most any small-ish laptop can have a nice readable font at 50x132, > or even 50x160. (i.e. that's another style guide rule that should die) Sorry, but I strongly have to disagree. Text line length does matter to those of us who put several copies of code side by side. In that scenario your total screen size does not matter, there still is not enough room for 120 characters on a line in one of the files, or all of them. "But _my_ screen is soo wide" only kind of works when one considers a single file on the screen at any time, or only vertically split windows. That's only half the truth. Even with multiple screens you still may want to put several applications including editors or text windows side by side, and avoid having to switch between them, or chose which of them you can see at a time. And no, I would not want to _have_ to side scroll, just to (start to) see the code with runs out of the screen's right hand side. It breaks the flow, is terribly slow and tedious to control, and makes it hard(er) to spot matching braces that are vertically aligned to their opening construct. While none of the flow breaking obstacles are necessary. There are useful cases where longer text lines are appropriate ("stupid" data tables, user visible string literals that you want to be able to grep for when researching a bug report). Those _are_ useful, but should remain the exception. From personal experience I found the 80 chars limit the hardest to get used to, but once you get it, a very useful one. Even today. Because reasons, it's not as arbitrary as it may seem. There is a reason why papers and web pages are laid out in columns. It's more than just a tradition. Has to do with readability. Really. Try to find the start of the next line after the previous line was rather long. Even more so with the tiny fonts that you mention above. And screens got smaller again with mobile devices after they got bigger before. History keeps repeating. :) virtually yours Gerhard Sittig -- If you don't understand or are scared by any of the above ask your parents or an adult to help you.
Re: eMMC module not working
mar...@duskware.de (Martin Husemann) writes: >[ 1.030] mesongxmmc1 at simplebus8: eMMC/SD/SDIO controller >[ 1.030] mesongxmmc1: interrupting on GIC irq 250 >[ 1.5705756] sdmmc1 at mesongxmmc1 >[ 1.6705777] sdmmc_mmc_command: cmd=52, arg=0x8c08, flags=0x4032 >[ 1.6705777] sdmmc1: cmd 52 arg=0x8c08 data=0x0 dlen=0 flags=0x4032 >(error 60) >[ 1.6805785] sdmmc_mmc_command: cmd=5, arg=0, flags=0x4302 >[ 1.6905781] sdmmc1: cmd 5 arg=0 data=0x0 dlen=0 flags=0x4302 (error 60) >[ 1.7305788] sdmmc_mmc_command: cmd=55, arg=0, flags=0x4432 >[ 1.7305788] sdmmc1: cmd 55 arg=0 data=0x0 dlen=0 flags=0x4432 (error 60) Pretty short for a command timeout, especially the second one. -- -- Michael van Elst Internet: mlel...@serpens.de "A potential Snark may lurk in every tree."
Re: kernel stack usage
On 04.07.2020 15:51, Jaromír Doleček wrote: > Le sam. 4 juil. 2020 à 15:30, Kamil Rytarowski a écrit : >>> Kamil - what's the difference in gcc between -Wframe-larger-than= and >>> -Wstack-size= ? >>> >> >> -Wstack-size doesn't exist? > > Sorry, meant -Wstack-usage= > It looks like WStack-usage is GCC specific (absent in Clang) and it includes alloca + vla. Both are not welcome in the kernel anyway so both should give in most cases the same result. >>> I see according to gcc documentation -Wframe-larger-than doesn't count >>> size for alloca() and variable-length arrays, which makes it much less >>> useful than -Wstack-usage. >>> >> >> It's not a problem. >> >> Whenever alloca or VLA is in use, it's already breaking the stack >> protector. There are a few exceptions registered in sys/conf/ssp.mk. >> >> We could add -Walloca -Wvla for USE_SSP=yes builds to catch quickly >> inappropriate usage (frequently violated by code optimizer). > > It's already not used in our kernel code, I checked and I found it > used only in some arch-specific stand/ code. So -Walloca should be > safe to turn on unconditionally, regardless of SSP. Unless the > compiler emits alloca() calls itself. > Sounds good. I'm for adding -Walloca and ideally -Wvla wherever possible in the kernel. > Jaromir > signature.asc Description: OpenPGP digital signature
eMMC module not working
Hey folks, I have two eMMC modules that with recentish -current do not work in my Odroid C2 board (both used to work in older versions, but I don't know when exactly it did break). I enabled mmc debug and got the dump below. Jared has one very similar module and it works for him (he also has another different one that works). This is with an image from very recentish -current, only bootaa64.efi replaced with a working (newer) one, as the image yesterday still included a broken version. Plus /netbsd replaced with a version with enabled mmc debug output (but overall behaviour is the same with and w/o debug output). Any hints? Martin -- chipLoad bl33 from eMMC, src: 0x00034200, des: 0x0100, size: 0x00075f50 id: ef be ad de d f0 ad ba ef be ad de not ES chip [0.385870 Inits done] secure task start! high task start! low task start! NOTICE: BL3-1: v1.0(debug):4d2e34d NOTICE: BL3-1: Built : 17:08:35, Oct 29 2015 INFO:BL3-1: Initializing runtime services INFO:BL3-1: Preparing for EL3 exit to normal world INFO:BL3-1: Next image address = 0x100 INFO:BL3-1: Next image spsr = 0x3c9 U-Boot 2019.04-rc1-00141-g63f7e3fca3 (Feb 15 2019 - 20:11:48 -0400) odroid-c2 DRAM: 2 GiB MMC: mmc@72000: 0, mmc@74000: 1 In:serial Out: serial Err: serial Net: eth0: ethernet@c941 Hit any key to stop autoboot: 2 1 0 Card did not respond to voltage select! switch to partitions #0, OK mmc1(part 0) is current device Scanning mmc 1:1... 36543 bytes read in 2 ms (17.4 MiB/s) Found EFI removable media binary efi/boot/bootaa64.efi 7[r[999;999H[6n8Card did not respond to voltage select! Scanning disk m...@72000.blk... Disk m...@72000.blk not ready Scanning disk m...@74000.blk... Found 3 disks 182712 bytes read in 5 ms (34.8 MiB/s) ## Starting EFI application at 0808 ... [2J[0;37;40m[?25h >> NetBSD/evbarm efiboot (arm64), Revision 2.2 (Wed Jul 15 08:25:56 UTC 2020) Press return to boot now, any other key for boot prompt booting netbsd - starting in 5 seconds. 4 seconds. 3 seconds. 2 seconds. 1 seconds. 0 seconds. 8208656+3608328+3675352+1532912 [559761+934968+683973]=0x130c168 [ 1.000] NetBSD/evbarm (fdt) booting ... [ 1.000] pool redzone disabled for 'kmem-04096' [ 1.000] Copyright (c) 1996, 1997, 1998, 1999, 2000, 2001, 2002, 2003, 2004, 2005, [ 1.000] 2006, 2007, 2008, 2009, 2010, 2011, 2012, 2013, 2014, 2015, 2016, 2017, [ 1.000] 2018, 2019, 2020 The NetBSD Foundation, Inc. All rights reserved. [ 1.000] Copyright (c) 1982, 1986, 1989, 1991, 1993 [ 1.000] The Regents of the University of California. All rights reserved. [ 1.000] NetBSD 9.99.69 (GENERIC64) #150: Thu Jul 16 10:48:33 CEST 2020 [ 1.000] mar...@seven-days-to-the-wolves.aprisoft.de:/work/src/sys/arch/evbarm/compile/GENERIC64 [ 1.000] total memory = 2012 MB [ 1.000] avail memory = 1951 MB [ 1.000] pool redzone disabled for 'buf4k' [ 1.000] pool redzone disabled for 'buf64k' [ 1.000] entropy: no seed from bootloader [ 1.000] armfdt0 (root) [ 1.000] simplebus0 at armfdt0: Hardkernel ODROID-C2 [ 1.000] simplebus1 at simplebus0 [ 1.000] cpus0 at simplebus0 [ 1.000] simplebus2 at simplebus0 [ 1.000] psci0 at simplebus0: PSCI 0.2 [ 1.000] cpu0 at cpus0: Arm Cortex-A53 r0p4 (v8-A), id 0x0 [ 1.000] cpu1 at cpus0: Arm Cortex-A53 r0p4 (v8-A), id 0x1 [ 1.000] cpu2 at cpus0: Arm Cortex-A53 r0p4 (v8-A), id 0x2 [ 1.000] cpu3 at cpus0: Arm Cortex-A53 r0p4 (v8-A), id 0x3 [ 1.000] simplebus3 at simplebus1 [ 1.000] simplebus4 at simplebus1 [ 1.000] simplebus5 at simplebus1 [ 1.000] simplebus6 at simplebus1 [ 1.000] simplebus7 at simplebus1 [ 1.000] simplebus8 at simplebus1 [ 1.000] gic0 at simplebus1: GIC [ 1.000] armgic0 at gic0: Generic Interrupt Controller, 256 sources (238 valid) [ 1.000] armgic0: 16 Priorities, 224 SPIs, 6 PPIs, 8 SGIs [ 1.000] syscon0 at simplebus3: System Controller Registers [ 1.000] syscon1 at simplebus4: System Controller Registers [ 1.000] fclock0 at simplebus0: 2400 Hz fixed clock (xtal) [ 1.000] syscon2 at simplebus3: System Controller Registers [ 1.000] gtmr0 at simplebus0: Generic Timer [ 1.000] gtmr0: interrupting on GIC irq 27 [ 1.000] armgtmr0 at gtmr0: Generic Timer (24000 kHz, virtual) [ 1.030] gxbbclkc0 at syscon1: Meson GXBB clock controller [ 1.030] mesonpinctrl0 at simplebus5: Meson GXBB periphs GPIO [ 1.030] gpio0 at mesonpinctrl0: 119 pins [ 1.030] mesonresets0 at simplebus6 [ 1.030] gxbbaoclkc0 at syscon0: Meson GX AO clock controller [ 1.030] mesonpinctrl1 at simplebus3: Meson GXBB AO GPIO [ 1.030] mesonpinctrl1: usb-hub-reset GPIOAO_4 set to output (high) [ 1.030] gpio1 at mesonpinctrl1: 14 pins [ 1.03