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