artwork.html -- minor fixes
These small changes mainly fix a minor cosmetic issue where the
headers are closer to the items above than below them, making it look
as if the early releases were the audio CDs, etc.
Index: artwork.html
===
RCS file: /cvs/www/artwork.html,v
retrieving revision 1.11
diff -u -r1.11 artwork.html
--- artwork.html9 Jul 2020 10:22:30 - 1.11
+++ artwork.html22 Jul 2020 22:18:07 -
@@ -14,8 +14,8 @@
}
caption {
+ padding-top: 1em;
font-weight: bolder;
- margin-bottom: 1.2em;
}
tr + tr td {
@@ -23,6 +23,7 @@
}
th {
+ padding-top: 2.4em;
font-weight: normal;
}
@@ -55,7 +56,7 @@
To accompany this free software released on the internet, we make
artwork and music.
This artwork emblazoned CDs and posters up until version 6.0, after which
-we stopped producing product and only release software on the internet.
+we stopped producing merchandise. We now only release software on
the internet.
Past releases also had shirts printed along
@@ -72,7 +73,7 @@
-
+
Post-CD-ROM Era
6.7
@@ -374,7 +375,6 @@
-
Fan art
PuffyvsCthulhu
@@ -391,4 +391,6 @@
+
+
DETAILED DESCRIPTION OF CHANGES:
@@ -14,8 +14,8 @@
Lower the caption and remove its bottom margin to avoid excessive
whitespace between it and the first table header.
@@ -23,6 +23,7 @@
Add generous padding on top of all table headers instead.
@@ -55,7 +56,7 @@
Minor copyedit.
@@ -72,7 +73,7 @@
There are actually two tables on top of each other in the sauce.
Their not having been unified looks like a deliberate choice for
nicer auto-alignment, and I'm not going to mess with that. To avoid
extra vertical whitespace between the two tables here, override the
above CSS rule in just this one instance: Reduce padding for the
second table's first .
@@ -374,7 +375,6 @@
whitespace is ghetto.
@@ -391,4 +391,6 @@
Did I just say break whitespace was ghetto? Sorry, I lied! Forget
what I said. I love ghetto! If I were to define this purely cosmetic
extra bottom-of-the-page whitespace at the top, or worse, in the
middle of the page, where the second table begins, nobody would see it
there. Breakin' two time right here. Now KISS.
PS: Tough if you insist on being all gentrified and received
pronunciation and double-barrelled name and everything, you can always
decide to raze the ghetto and instead focus on being all styled up and
body-positive or whatever the twitterati want to see. I'm sure that
helps with margins. Gotta distance yourself from that bottom:
body {
margin-bottom: 3em;
}
Re: Potential grep bug?
On Wed, 22 Jul 2020 20:57:56 +0200, Martijn van Duren wrote: > Any takers? OK millert@ - todd
Re: Add ability to set control values with video(1)
On Wed, Jul 22, 2020 at 10:23:19PM +0200, Marcus Glocker wrote: Hello Marcus, > I've tested this here as well in the meantime by leaving mmap_init() on > its original location (doesn't get involved for '-c reset') with three > different cams: > > * Logitech C930e: I see the same problem like you do with your C920 > finally. > * Logitech QuickCam Pro 9000: reset works fine. > * SunplusIT Inc Integrated Camera: reset works fine. Hmph, that's slightly annoying of Logitech :/ > This seems to be a problem only with some cams when turning the > auto white balance temperature back on while the stream is off, the > setting doesn't get recognized by the cam afterwards. > > I'm basically OK with your last diff, except the mmap_init() location > change: I don't like to turn the cam stream on only for setting this > parameter because some cams can't handle the obvious. > > I tried out some things with the C930e to get the auto white balance > temperature back on without having the stream on, but no luck so far. > > I would aim to get your diff in without the mmap_init() change. Maybe > we'll find a solution/workaround for this partial problem later? If we can find a change that allows this, I'd be happy! When I briefly tested things on Windows, the Logitech app there activated the stream before changing settings, so it's quite possible that they never tested changing some settings with the stream off. v4l2-ctl might have some clues in it, but their model is subtly different than ours and forces the user to understand a lot more about their camera (e.g. they force the user to turn off auto white balance before they allow them to set manual white balance, a differentiation which IMHO only makes sense if you've read the UVC spec). That makes me think that if/when uvideo is extended to deal with terminal control requests (e.g. zoom, exposure, focus) we'll find that other settings with "auto" options have similar problems. Honestly, if the price of controlling exposure and focus is having to turn the camera stream on, I think I will consider that an acceptable trade-off, given how useful those settings are :) >> +.It Fl c Ar reset | control=value >> +Set control value (e.g. brightness) and exit. The special name >> +.Ql reset >> +resets all values to their default. The available controls can be >> found +with >> +.Fl q >> +and the default values with >> +.Fl c Ar reset >> +.Fl v . > '-c reset -v' will not only display the default values, but also do > reset the cam to them. Shouldn't the sentence be more something like > the following since this sounds like '-c reset -v' can only display the > default values? > > "The available controls can be found with -q and the default values > are displayed during a reset with -c reset -v." Works for me! Laurie
Re: Add ability to set control values with video(1)
Hello Laurie,
On Tue, 21 Jul 2020 21:18:15 +0100
Laurence Tratt wrote:
> On Tue, Jul 21, 2020 at 09:01:26PM +0200, Marcus Glocker wrote:
>
> Hello Marcus,
>
> Thanks for the comments! Again, I agree with all of them with a
> couple of comments:
>
> > I'm a bit confused by the dev_set_ctrl() function renaming. Does
> > 'inc' stand for increment? And if yes, it makes not a lot sense to
> > me since we use this function to increase and decrease values.
> > Leaving the dev_set_ctrl() as is and introduce dev_set_ctrl_abs()
> > would make more sense to me then. Or rename the dev_inc_ctrl() to
> > dev_chg_ctrl() instead.
>
> I think it needs renaming because I managed to misread "dev_set_ctrl"
> as "set absolute value" at first (hence the subtly incorrect first
> patch I sent out). Finding good names is hard, but you're right that
> "inc" is confusing here. How about dev_set_ctrl_rel, which I think
> gets the intent across clearly, and makes the relation to
> dev_set_ctrl_abs clear?
That makes much more sense to me.
> > Ouch! It really shouldn't be required to initialize the mmap
> > buffers and turn on the cams stream thereby each time you set a
> > control parameter. Think of a larger script which sets multiple
> > control parameters, turning on and off the stream each time, and
> > there are cams which are slow in turning on their streams. With my
> > C930e setting the controls works without turning on the stream
> > first, and that's what I would expect.
> >
> > Can you figure out why this is required for your C920? There must
> > be another solution to set controls without turning on the stream
> > first ...
>
> On my C920 I only need to do this to turn auto
> white_balance_temperature back on. I tested this with:
>
> $ video -c white_balance_temperature=6500
> $ video
> $ video -c reset
> $ video
>
> If pressing "r" in the final "video" call doesn't visibly change
> anything, then (assuming auto white balance doesn't set things to
> 6500K!) I conclude that resetting has worked. I wonder if it's the
> same for your C930e and auto white_balance_temperature or not?
>
> Unfortunately when I try messing with mmap_init, it seems that to
> turn on auto white_balance_temperature, the final ioctl ("start video
> stream") has to be executed. For any other control, we don't need to
> call mmap_init.
>
> I agree that this is less than ideal, but I don't know if we can do
> anything about it (other than, perhaps, only calling mmap_init for
> "-c reset", but that feels rather fragile).
Ah right, I got you wrong then, sorry. I thought you require this for
each control setting.
I've tested this here as well in the meantime by leaving mmap_init() on
its original location (doesn't get involved for '-c reset') with three
different cams:
* Logitech C930e: I see the same problem like you do with your C920
finally.
* Logitech QuickCam Pro 9000: reset works fine.
* SunplusIT Inc Integrated Camera: reset works fine.
This seems to be a problem only with some cams when turning the
auto white balance temperature back on while the stream is off, the
setting doesn't get recognized by the cam afterwards.
I'm basically OK with your last diff, except the mmap_init() location
change: I don't like to turn the cam stream on only for setting this
parameter because some cams can't handle the obvious.
I tried out some things with the C930e to get the auto white balance
temperature back on without having the stream on, but no luck so far.
I would aim to get your diff in without the mmap_init() change. Maybe
we'll find a solution/workaround for this partial problem later?
One more inline comment regarding the man page.
>
> Laurie
Thanks,
Marcus
>
> Index: video.1
> ===
> RCS file: /cvs/xenocara/app/video/video.1,v
> retrieving revision 1.15
> diff -u -r1.15 video.1
> --- video.1 17 Jul 2020 07:51:23 - 1.15
> +++ video.1 21 Jul 2020 20:15:01 -
> @@ -27,6 +27,7 @@
> .Bk -words
> .Op Fl \
> .Op Fl a Ar adaptor
> +.Op Fl c Ar reset | control=value
> .Op Fl e Ar encoding
> .Op Fl f Ar file
> .Op Fl i Ar input
> @@ -81,6 +82,15 @@
> adaptor to use.
> The default is 0, the first adaptor reported by
> .Xr X 7 .
> +.It Fl c Ar reset | control=value
> +Set control value (e.g. brightness) and exit. The special name
> +.Ql reset
> +resets all values to their default. The available controls can be
> found +with
> +.Fl q
> +and the default values with
> +.Fl c Ar reset
> +.Fl v .
'-c reset -v' will not only display the default values, but also do
reset the cam to them. Shouldn't the sentence be more something like
the following since this sounds like '-c reset -v' can only display the
default values?
"The available controls can be found with -q and the default values
are displayed during a reset with -c reset -v."
> .It Fl e Ar encoding
> Lowercase FOURCC name of video encoding to use.
> Valid arguments are
>
Re: join(1) remove redundant memory copy
On Wed, 22 Jul 2020 20:29:06 +0200, Martijn van Duren wrote:
> When r1.28 converted join(1) to getline(3) it left the old intermediate
> line variable. This means using an additional memcpy and reallocing.
> I reckon this is wasted cycles and screen filling.
>
> Major difference is that our getline allocates to the next power of 2,
> while the current code overcommits a maximum of ~100 bytes. I reckon
> this is a fair trade-off.
Looks good, one minor comment inline. Either way, OK millert@
- todd
> Index: join.c
> ===
> RCS file: /cvs/src/usr.bin/join/join.c,v
> retrieving revision 1.32
> diff -u -p -r1.32 join.c
> --- join.c14 Nov 2018 15:16:09 - 1.32
> +++ join.c22 Jul 2020 18:19:34 -
> @@ -271,9 +271,8 @@ slurp(INPUT *F)
> {
> LINE *lp, *lastlp, tmp;
> ssize_t len;
> - size_t linesize;
> u_long cnt;
> - char *bp, *fieldp, *line;
> + char *bp, *fieldp;
>
> /*
>* Read all of the lines from an input file that have the same
> @@ -281,8 +280,6 @@ slurp(INPUT *F)
>*/
>
> F->setcnt = 0;
> - line = NULL;
> - linesize = 0;
> for (lastlp = NULL; ; ++F->setcnt) {
> /*
>* If we're out of space to hold line structures, allocate
> @@ -320,22 +317,12 @@ slurp(INPUT *F)
> F->pushbool = 0;
> continue;
> }
> - if ((len = getline(, , F->fp)) == -1)
> + if ((len = getline(&(lp->line), &(lp->linealloc), F->fp)) == -1
> )
> break;
>
> /* Remove trailing newline, if it exists, and copy line. */
> - if (line[len - 1] == '\n')
> + if (lp->line[len - 1] == '\n')
> len--;
You could replace "len--" with "lp->line[len - 1] = '\0'" here (or
"lp->line[--len] = '\0'" if you prefer but len is otherwise unused).
> - if (lp->linealloc <= len + 1) {
> - char *p;
> - u_long newsize = lp->linealloc +
> - MAXIMUM(100, len + 1 - lp->linealloc);
> - if ((p = realloc(lp->line, newsize)) == NULL)
> - err(1, NULL);
> - lp->line = p;
> - lp->linealloc = newsize;
> - }
> - memcpy(lp->line, line, len);
> lp->line[len] = '\0';
Then there would be no need to NUL terminate here since getline(3)
always NUL terminates.
>
> /* Split the line into fields, allocate space as necessary. */
> @@ -363,7 +350,6 @@ slurp(INPUT *F)
> break;
> }
> }
> - free(line);
> }
>
> char *
Re: Potential grep bug?
Any takers?
On Wed, 2020-06-24 at 13:27 +0200, Martijn van Duren wrote:
> Moving to tech@
>
> On Tue, 2020-06-23 at 22:17 -0900, Philip Guenther wrote:
> > Nope. This is a grep of a single file, so procfile() must be overflowing
> > and this only 'fixes' it by relying on signed overflow, which is undefined
> > behavior, being handled in a particular way by the compiler. So, luck
> > (which fails when the compiler decides to hate you). There are more places
> > that need to change for the reported problem to be handled safely.
> >
> > Philip Guenther
>
> I'm not sure I understand exactly what you mean, but the overflow can
> still propagate through to the return value. Since everything propagated
> up from procfile is only eventually used to determine the exit value we
> can start treating it as a boolean.
>
> I gave a quick glance at freebsd and they also treat it as a boolean,
> but more explicitly. They however don't appear have overflow detection.
>
> Is this better?
>
> martijn@
> >
> > On Tue, Jun 23, 2020 at 9:58 PM Martijn van Duren <
> > open...@list.imperialat.at> wrote:
> >
> > > This seems to fix the issue for me.
> > >
> > > OK?
> > >
> > > martijn@
> > >
> > > On Tue, 2020-06-23 at 19:29 -0700, Jordan Geoghegan wrote:
> > > > Hello,
> > > >
> > > > I was working on a couple POSIX regular expressions to search for and
> > > > validate IPv4 and IPv6 addresses with optional CIDR blocks, and
> > > > encountered some strange behaviour from the base system grep.
> > > >
> > > > I wanted to validate my regex against a list of every valid IPv4
> > > > address, so I generated a list with a zsh 1 liner:
> > > >
> > > > for i in {0..255}; do; echo $i.{0..255}.{0..255}.{0..255} ; done |
> > > > tr '[:space:]' '\n' > IPv4.txt
> > > >
> > > > My intentions were to test the regex by running it with 'grep -c' to
> > > > confirm there was indeed 2^32 addresses matched, and I also wanted to
> > > > benchmark and compare performance between BSD grep, GNU grep and
> > > > ripgrep. The command I used:
> > > >
> > > > grep -Eoc
> > > >
> > > "((25[0-5]|(2[0-4]|1{0,1}[[:digit:]]){0,1}[[:digit:]])\.){3,3}(25[0-5]|(2[0-4]|1{0,1}[[:digit:]]){0,1}[[:digit:]])(/[1-9]|/[1-2][[:digit:]]|/3[0-2])?"
> > > > My findings were surprising. Both GNU grep and ripgrep were able get
> > > > through the file in roughly 10 and 20 minutes respectively, whereas the
> > > > base system grep took over 20 hours! What interested me the most was
> > > > that the base system grep when run with '-c' returned '0' for match
> > > > count. It seems that 'grep -c' will have its counter overflow if there
> > > > are more than 2^32-1 matches (4294967295) and then the counter will
> > > > start counting from zero again for further matches.
> > > >
> > > > ryzen$ time zcat IPv4.txt.gz | grep -Eoc
> > > "((25[0-5]|(2[0-4]|1{0,1}...
> > > > 0
> > > > 1222m09.32s real 1224m28.02s user 1m16.17s system
> > > >
> > > > ryzen$ time zcat allip.txt.gz | ggrep -Eoc
> > > "((25[0-5]|(2[0-4]|1{0,1}...
> > > > 4294967296
> > > > 10m00.38s real11m40.57s user 0m30.55s system
> > > >
> > > > ryzen$ time rg -zoc "((25[0-5]|(2[0-4]|1{0,1}...
> > > > 4294967296
> > > > 21m06.36s real27m06.04s user 0m50.08s system
> > > >
> > > > # See the counter overflow/reset:
> > > > jot 4294967350 | grep -c "^[[:digit:]]"
> > > > 54
> > > >
> > > > All testing was done on a Ryzen desktop machine running 6.7 stable.
> > > >
> > > > The grep counting bug can be reproduced with this command:
> > > > jot 4294967296 | nice grep -c "^[[:digit:]]"
> > > >
> > > > Regards,
> > > >
> > > > Jordan
> > > >
> Index: grep.c
> ===
> RCS file: /cvs/src/usr.bin/grep/grep.c,v
> retrieving revision 1.64
> diff -u -p -r1.64 grep.c
> --- grep.c3 Dec 2019 09:14:37 - 1.64
> +++ grep.c24 Jun 2020 11:26:25 -
> @@ -517,7 +517,7 @@ main(int argc, char *argv[])
> c = grep_tree(argv);
> else
> for (c = 0; argc--; ++argv)
> - c += procfile(*argv);
> + c |= procfile(*argv);
>
> exit(c ? (file_err ? (qflag ? 0 : 2) : 0) : (file_err ? 2 : 1));
> }
> Index: util.c
> ===
> RCS file: /cvs/src/usr.bin/grep/util.c,v
> retrieving revision 1.62
> diff -u -p -r1.62 util.c
> --- util.c3 Dec 2019 09:14:37 - 1.62
> +++ util.c24 Jun 2020 11:26:25 -
> @@ -91,7 +91,7 @@ grep_tree(char **argv)
> /* skip "./" if implied */
> if (argv == dot_argv && p->fts_pathlen >= 2)
> path += 2;
> - c += procfile(path);
> + c |= procfile(path);
> break;
> }
> }
> @@ -106,7 +106,8 @@ procfile(char *fn)
> {
> str_t
join(1) remove redundant memory copy
When r1.28 converted join(1) to getline(3) it left the old intermediate
line variable. This means using an additional memcpy and reallocing.
I reckon this is wasted cycles and screen filling.
Major difference is that our getline allocates to the next power of 2,
while the current code overcommits a maximum of ~100 bytes. I reckon
this is a fair trade-off.
regress still passes.
OK?
martijn@
Index: join.c
===
RCS file: /cvs/src/usr.bin/join/join.c,v
retrieving revision 1.32
diff -u -p -r1.32 join.c
--- join.c 14 Nov 2018 15:16:09 - 1.32
+++ join.c 22 Jul 2020 18:19:34 -
@@ -271,9 +271,8 @@ slurp(INPUT *F)
{
LINE *lp, *lastlp, tmp;
ssize_t len;
- size_t linesize;
u_long cnt;
- char *bp, *fieldp, *line;
+ char *bp, *fieldp;
/*
* Read all of the lines from an input file that have the same
@@ -281,8 +280,6 @@ slurp(INPUT *F)
*/
F->setcnt = 0;
- line = NULL;
- linesize = 0;
for (lastlp = NULL; ; ++F->setcnt) {
/*
* If we're out of space to hold line structures, allocate
@@ -320,22 +317,12 @@ slurp(INPUT *F)
F->pushbool = 0;
continue;
}
- if ((len = getline(, , F->fp)) == -1)
+ if ((len = getline(&(lp->line), &(lp->linealloc), F->fp)) == -1)
break;
/* Remove trailing newline, if it exists, and copy line. */
- if (line[len - 1] == '\n')
+ if (lp->line[len - 1] == '\n')
len--;
- if (lp->linealloc <= len + 1) {
- char *p;
- u_long newsize = lp->linealloc +
- MAXIMUM(100, len + 1 - lp->linealloc);
- if ((p = realloc(lp->line, newsize)) == NULL)
- err(1, NULL);
- lp->line = p;
- lp->linealloc = newsize;
- }
- memcpy(lp->line, line, len);
lp->line[len] = '\0';
/* Split the line into fields, allocate space as necessary. */
@@ -363,7 +350,6 @@ slurp(INPUT *F)
break;
}
}
- free(line);
}
char *
Re: receive interfacez for carp when real mac is used
The problem I was to fix had been fixed by dlg@'s commit today. https://marc.info/?l=openbsd-cvs=159538265604770=2 So the diff is not needed any more. Pointed out by dlg@. Thanks, On Wed, 22 Jul 2020 19:24:32 +0900 (JST) YASUOKA Masahiko wrote: > Hi, > > Currently when using the real mac address for carp(4) interface, all > packets are treated as their receive inteface is carp. This causes > some problems. > > For example, IPv6 ndp doesn't work on an interface which is used for > carpdev. Because it is assumed that reply packets are received with > the same interface which is used to send out the request. > > ok? > > When realmac is used for carp(4), don't pass the packets through the > interface since they are for the real interface. > > Index: sys/netinet/ip_carp.c > === > RCS file: /disk/cvs/openbsd/src/sys/netinet/ip_carp.c,v > retrieving revision 1.345 > diff -u -p -r1.345 ip_carp.c > --- sys/netinet/ip_carp.c 21 May 2020 05:24:59 - 1.345 > +++ sys/netinet/ip_carp.c 22 Jul 2020 09:52:20 - > @@ -1418,6 +1418,14 @@ carp_input(struct ifnet *ifp0, struct mb > } > m_tag_prepend(m, mtag); > } > + > + /* > + * When carp is using realmac, since the matched MAC > + * address is for the real interface, the packets are > + * not for the carp interface. > + */ > + if (sc->sc_realmac) > + sc = NULL; > break; > } > } >
receive interfacez for carp when real mac is used
Hi, Currently when using the real mac address for carp(4) interface, all packets are treated as their receive inteface is carp. This causes some problems. For example, IPv6 ndp doesn't work on an interface which is used for carpdev. Because it is assumed that reply packets are received with the same interface which is used to send out the request. ok? When realmac is used for carp(4), don't pass the packets through the interface since they are for the real interface. Index: sys/netinet/ip_carp.c === RCS file: /disk/cvs/openbsd/src/sys/netinet/ip_carp.c,v retrieving revision 1.345 diff -u -p -r1.345 ip_carp.c --- sys/netinet/ip_carp.c 21 May 2020 05:24:59 - 1.345 +++ sys/netinet/ip_carp.c 22 Jul 2020 09:52:20 - @@ -1418,6 +1418,14 @@ carp_input(struct ifnet *ifp0, struct mb } m_tag_prepend(m, mtag); } + + /* +* When carp is using realmac, since the matched MAC +* address is for the real interface, the packets are +* not for the carp interface. +*/ + if (sc->sc_realmac) + sc = NULL; break; } }
