Re: Posting Netiquette [ref: Threads "look definitely like" unreadable mess. Handbook project.]
On Wednesday, 22 June 2022 at 15:41:39 -0400, grarpamp wrote: > Around 6/2x/22, Many rammed their horribly formed > msgs upon others to parse: > ... > FreeBSD needs to add an entire section on the > email post formatting netiquette to the Handbook, > and link it on the List Subscription pages, and in the List Welcome > emails, and even in quarterly automated administrivia post to all lists. In fact we have guidelines, just not exactly where you might expect. "How to get Best Results from the FreeBSD-questions Mailing List" (https://docs.freebsd.org/en/articles/freebsd-questions/) contains: Unless there is a good reason to do otherwise, reply to the sender and to FreeBSD-questions. Include relevant text from the original message. Trim it to the minimum, but do not overdo it. It should still be possible for somebody who did not read the original message to understand what you are talking about. Use some technique to identify which text came from the original message, and which text you add. I personally find that prepending â>â to the original message works best. Leaving white space after the â> ;â and leave empty lines between your text and the original text both make the result more readable. Put your response in the correct place (after the text to which it replies). It is very difficult to read a thread of responses where each reply comes before the text to which it replies. Most mailers change the subject line on a reply by prepending a text such as "Re: ". If your mailer does not do it automatically, you should do it manually. If the submitter did not abide by format conventions (lines too long, inappropriate subject line) please fix it. In the case of an incorrect subject line (such as "HELP!!??"), change the subject line to (say) "Re: Difficulties with sync PPP (was: HELP!!??)". That way other people trying to follow the thread will have less difficulty following it. In such cases, it is appropriate to say what you did and why you did it, but try not to be rude. If you find you can not answer without being rude, do not answer. Arguably these recommendations should be separated out into their own page. Re-reading them, I see that there is no explicit line length recommendation. That should be included. And yes, I agree entirely with your concerns, though without my core hat. Greg -- Sent from my desktop computer. See complete headers for address and phone numbers. This message is digitally signed. If your Microsoft mail program reports problems, please read http://lemis.com/broken-MUA.php signature.asc Description: PGP signature
Re: SAS/SATA controllers: 8 port that support 8TB Drives
On 06/18/2022 8:30 am, Michael Gmelin wrote: That certainly sounds promising. Best Michael got the new controllers, and no sweat -- saw all 8TB on the drives (modulo one bad drive -- seller is replacing). thanks all. -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 214-642-9640 E-Mail: l...@lerctr.org US Mail: 5708 Sabbia Dr, Round Rock, TX 78665-2106
Posting Netiquette [ref: Threads "look definitely like" unreadable mess. Handbook project.]
Around 6/2x/22, Many rammed their horribly formed msgs upon others to parse: > [Subject: MCE: Does this look possibly like a slot issue?] > [snip] Attention all list users... Stop top-posting and bulk-quoting. Just stop. Go search and learn about and use the email post formatting netiquette. For decades agreed reasons, please, just go learn and use those rules. Your comms peers, the efficiency of the hive, the utility of archives and search engines, and more... all thank you in advance. Emails looking rather messy lately, just look at the photos, improve that by raising awareness and examples of better... FreeBSD needs to add an entire section on the email post formatting netiquette to the Handbook, and link it on the List Subscription pages, and in the List Welcome emails, and even in quarterly automated administrivia post to all lists. Make Reading Easy Again :) [Cc'd until postmaster makes Bcc on lists work, so that useful inclusions for others awareness can occur while maintaining threading and helping minimize braindead cross-repliers.]
RES: RES: RES: vt newcons mouse paste issue FIXED
Hi This change unfortunately didnt compile on my 13-stable . I just git cloned the CURRENT code, applied the patch and the build was fine. I'll test it as soon as I finish the upgrade from stable to current here I'll get back here when its finished Thank you -Mensagem original- De: Hans Petter Selasky Enviada em: quarta-feira, 22 de junho de 2022 14:08 Para: Tomoaki AOKI ; Ivan Quitschal Cc: freebsd-current@freebsd.org; Kurt Jaeger Assunto: Re: RES: RES: vt newcons mouse paste issue FIXED On 6/22/22 18:48, Tomoaki AOKI wrote: > Hi. > > Not actually tested, but this can cause breakage on non-ascii cases. > Maybe also (or instead) iswspace() test would be needed. > Possibly additional mbrtowc() in the argument of iswspace(). > > Please see `man 3 multibyte` and `man 3 iswspace`. > (Possibly more to see.) > > Characters in buf can be multibyte or wide char depending on locale, > as vt can show at least UTF-8 characters. > > Sorry, not looked into enough how UTF-8 characters outside ascii are > handled internally on vt. > Thanks for your feedback. Now using the TCHAR_CHARACTER() macro, which is already used for space separation. See: https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Freviews.freebsd.org%2FD35552data=05%7C01%7C%7C179337d1a7a340b8a9eb08da5471c67e%7C84df9e7fe9f640afb435%7C1%7C0%7C637915144907733421%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=b4hKmkmuXxZ%2BjtSv75bG8qLIXMwo9Fzt64NfVSnuDUU%3Dreserved=0 --HPS
Re: RES: RES: vt newcons mouse paste issue FIXED
On 6/22/22 18:48, Tomoaki AOKI wrote: Hi. Not actually tested, but this can cause breakage on non-ascii cases. Maybe also (or instead) iswspace() test would be needed. Possibly additional mbrtowc() in the argument of iswspace(). Please see `man 3 multibyte` and `man 3 iswspace`. (Possibly more to see.) Characters in buf can be multibyte or wide char depending on locale, as vt can show at least UTF-8 characters. Sorry, not looked into enough how UTF-8 characters outside ascii are handled internally on vt. Thanks for your feedback. Now using the TCHAR_CHARACTER() macro, which is already used for space separation. See: https://reviews.freebsd.org/D35552 --HPS
Re: RES: RES: vt newcons mouse paste issue FIXED
On 6/22/22 18:41, Hans Petter Selasky wrote: Hi, I needed to update the patch a bit. Can you test this: https://reviews.freebsd.org/D35552 Use the download raw patch link in there to get the patch. Thank you! --HPS One more update. --HPS
Re: RES: RES: vt newcons mouse paste issue FIXED
Hi.
Not actually tested, but this can cause breakage on non-ascii cases.
Maybe also (or instead) iswspace() test would be needed.
Possibly additional mbrtowc() in the argument of iswspace().
Please see `man 3 multibyte` and `man 3 iswspace`.
(Possibly more to see.)
Characters in buf can be multibyte or wide char depending on locale,
as vt can show at least UTF-8 characters.
Sorry, not looked into enough how UTF-8 characters outside ascii are
handled internally on vt.
On Wed, 22 Jun 2022 15:01:36 +
Ivan Quitschal wrote:
> Hi Hans
>
> Actually i can , I should've cut off the '\r' , this is what was causing
> the term to go bend
>
> This is the correct diff (option -C doesn’t worked with -u)
> I also included your code for the pts anyway
>
>
>
> --- sys/dev/vt/vt_buf.c.orig2022-06-22 11:48:39.705597000 -0300
> +++ sys/dev/vt/vt_buf.c 2022-06-22 11:51:05.502415000 -0300
> @@ -41,6 +41,7 @@
> #include
> #include
> #include
> +#include
>
> #include
>
> @@ -752,6 +753,7 @@
> {
> int i, r, c, cs, ce;
> term_pos_t s, e;
> + term_char_t *end;
>
> /* Swap according to window coordinates. */
> if (POS_INDEX(vtbuf_htw(vb, vb->vb_mark_start.tp_row),
> @@ -772,10 +774,15 @@
> for (c = cs; c < ce; c++) {
> buf[i++] = vb->vb_rows[r][c];
> }
> + for (end = buf + i; end-- != buf; ) {
> + if (isspace((unsigned char)*end) == false)
> + break;
> + *end = '\0';
> + }
> /* Add new line for all rows, but not for last one. */
> if (r != e.tp_row) {
> - buf[i++] = '\r';
> buf[i++] = '\n';
> + buf[i++] = '\0';
> }
> }
> }
>
> Works fine here
>
> Thanks
>
> --tzk
>
> -Mensagem original-
> De: Hans Petter Selasky
> Enviada em: quarta-feira, 22 de junho de 2022 11:02
> Para: Ivan Quitschal ; freebsd-current@freebsd.org
> Assunto: Re: RES: vt newcons mouse paste issue FIXED
>
> On 6/22/22 15:36, Ivan Quitschal wrote:
> > Hi Hans
> >
>
> Hi Ivan,
>
> I think you should upload the diff at:
>
> https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Freviews.freebsd.org%2Fdifferential%2Fdata=05%7C01%7C%7C85e3f391dfc941f2852908da5457c75f%7C84df9e7fe9f640afb435%7C1%7C0%7C637915033252675801%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=4sxXIR9NhIbwD42gIrP4pYcdnUinqae1SNZAjclr2Aw%3Dreserved=0
>
> Make the diff like this:
>
> diff -u -C 99 sys/dev/vt/vt_buf.c.orig sys/dev/vt/vt_buf.c > a.diff
>
>
> I see two issues:
>
> 1) Pointer arithmetics is not so good!
>
> > }
> > + end = buf + i - 1;
> > + while (end > buf && isspace((unsigned char)*end))
> > + {
> > + *end = '\0';
> > + end--;
> > + }
> > +
>
> I think this would be better and avoid the ">" with pointers!
>
> for (end = buf + i; end-- != buf; ) {
> if (isspace((unsigned char)*end) == false)
> break;
> *end = '\0';
> }
>
> Can you explain this:
>
> > - buf[i++] = '\r';
> > + buf[i] = '\r';
> > buf[i++] = '\n';
>
> '\r' character is now overwritten by '\n' character.
>
> --HPS
>
--
Tomoaki AOKI
Re: RES: RES: vt newcons mouse paste issue FIXED
Hi, I needed to update the patch a bit. Can you test this: https://reviews.freebsd.org/D35552 Use the download raw patch link in there to get the patch. Thank you! --HPS
RES: RES: vt newcons mouse paste issue FIXED
Hi Hans
Actually i can , I should've cut off the '\r' , this is what was causing the
term to go bend
This is the correct diff (option -C doesn’t worked with -u)
I also included your code for the pts anyway
--- sys/dev/vt/vt_buf.c.orig2022-06-22 11:48:39.705597000 -0300
+++ sys/dev/vt/vt_buf.c 2022-06-22 11:51:05.502415000 -0300
@@ -41,6 +41,7 @@
#include
#include
#include
+#include
#include
@@ -752,6 +753,7 @@
{
int i, r, c, cs, ce;
term_pos_t s, e;
+ term_char_t *end;
/* Swap according to window coordinates. */
if (POS_INDEX(vtbuf_htw(vb, vb->vb_mark_start.tp_row),
@@ -772,10 +774,15 @@
for (c = cs; c < ce; c++) {
buf[i++] = vb->vb_rows[r][c];
}
+ for (end = buf + i; end-- != buf; ) {
+ if (isspace((unsigned char)*end) == false)
+ break;
+ *end = '\0';
+ }
/* Add new line for all rows, but not for last one. */
if (r != e.tp_row) {
- buf[i++] = '\r';
buf[i++] = '\n';
+ buf[i++] = '\0';
}
}
}
Works fine here
Thanks
--tzk
-Mensagem original-
De: Hans Petter Selasky
Enviada em: quarta-feira, 22 de junho de 2022 11:02
Para: Ivan Quitschal ; freebsd-current@freebsd.org
Assunto: Re: RES: vt newcons mouse paste issue FIXED
On 6/22/22 15:36, Ivan Quitschal wrote:
> Hi Hans
>
Hi Ivan,
I think you should upload the diff at:
https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Freviews.freebsd.org%2Fdifferential%2Fdata=05%7C01%7C%7C85e3f391dfc941f2852908da5457c75f%7C84df9e7fe9f640afb435%7C1%7C0%7C637915033252675801%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=4sxXIR9NhIbwD42gIrP4pYcdnUinqae1SNZAjclr2Aw%3Dreserved=0
Make the diff like this:
diff -u -C 99 sys/dev/vt/vt_buf.c.orig sys/dev/vt/vt_buf.c > a.diff
I see two issues:
1) Pointer arithmetics is not so good!
> }
> + end = buf + i - 1;
> + while (end > buf && isspace((unsigned char)*end))
> + {
> + *end = '\0';
> + end--;
> + }
> +
I think this would be better and avoid the ">" with pointers!
for (end = buf + i; end-- != buf; ) {
if (isspace((unsigned char)*end) == false)
break;
*end = '\0';
}
Can you explain this:
> - buf[i++] = '\r';
> + buf[i] = '\r';
> buf[i++] = '\n';
'\r' character is now overwritten by '\n' character.
--HPS
Re: RES: vt newcons mouse paste issue FIXED
On 6/22/22 15:36, Ivan Quitschal wrote:
Hi Hans
Hi Ivan,
I think you should upload the diff at:
https://reviews.freebsd.org/differential/
Make the diff like this:
diff -u -C 99 sys/dev/vt/vt_buf.c.orig sys/dev/vt/vt_buf.c > a.diff
I see two issues:
1) Pointer arithmetics is not so good!
}
+ end = buf + i - 1;
+ while (end > buf && isspace((unsigned char)*end))
+ {
+ *end = '\0';
+ end--;
+ }
+
I think this would be better and avoid the ">" with pointers!
for (end = buf + i; end-- != buf; ) {
if (isspace((unsigned char)*end) == false)
break;
*end = '\0';
}
Can you explain this:
- buf[i++] = '\r';
+ buf[i] = '\r';
buf[i++] = '\n';
'\r' character is now overwritten by '\n' character.
--HPS
RES: vt newcons mouse paste issue FIXED
Hi Hans
Please find below.
It can't paste the entire screen (mine is 1920x1080) tho, due to "sz" size I
believe.
43a44
> #include
754a756
> term_char_t *end;
774a777,783
> end = buf + i -1;
> while (end > buf && isspace((unsigned char)*end))
> {
> *end = '\0';
> end--;
> }
>
777c786
< buf[i++] = '\r';
---
> buf[i] = '\r';
778a788
> buf[i++] = '\0';
--tzk
-Mensagem original-
De: Hans Petter Selasky
Enviada em: quarta-feira, 22 de junho de 2022 10:14
Para: Ivan Quitschal ; freebsd-current@freebsd.org
Assunto: Re: vt newcons mouse paste issue FIXED
On 6/22/22 14:53, Ivan Quitschal wrote:
>
> Hi All
>
> About this anoying paste error we still have in vt console, I looked
> it up and couldnt find any fix regarding this, so i did it.
>
> Please find attached the fixed version of /usr/src/sys/dev/vt/vt_buf.c
> with trim spaces and aligned to the console size.
> I've tested with other fonts and looks fine in here.
>
> I hope this can help other ppl which finds this terminal mouse paste
> issue a pain in the neck.
>
> thanks
>
> --tzk
Can you provide the diff against the old, unmodified file?
--HPS
Re: vt newcons mouse paste issue FIXED
On 6/22/22 14:53, Ivan Quitschal wrote: Hi All About this anoying paste error we still have in vt console, I looked it up and couldnt find any fix regarding this, so i did it. Please find attached the fixed version of /usr/src/sys/dev/vt/vt_buf.c with trim spaces and aligned to the console size. I've tested with other fonts and looks fine in here. I hope this can help other ppl which finds this terminal mouse paste issue a pain in the neck. thanks --tzk Can you provide the diff against the old, unmodified file? --HPS
vt newcons mouse paste issue FIXED
Hi All
About this anoying paste error we still have in vt console, I looked it up and
couldnt find any fix regarding this, so i did it.
Please find attached the fixed version of /usr/src/sys/dev/vt/vt_buf.c with
trim spaces and aligned to the console size.
I've tested with other fonts and looks fine in here.
I hope this can help other ppl which finds this
terminal mouse paste issue a pain in the neck.
thanks
--tzk/*-
* SPDX-License-Identifier: BSD-2-Clause-FreeBSD
*
* Copyright (c) 2009, 2013 The FreeBSD Foundation
*
* This software was developed by Ed Schouten under sponsorship from the
* FreeBSD Foundation.
*
* Portions of this software were developed by Oleksandr Rybalko
* under sponsorship from the FreeBSD Foundation.
*
* Redistribution and use in source and binary forms, with or without
* modification, are permitted provided that the following conditions
* are met:
* 1. Redistributions of source code must retain the above copyright
*notice, this list of conditions and the following disclaimer.
* 2. Redistributions in binary form must reproduce the above copyright
*notice, this list of conditions and the following disclaimer in the
*documentation and/or other materials provided with the distribution.
*
* THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND
* ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
* IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
* ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE
* FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
* DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
* OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
* HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
* LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
* OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
* SUCH DAMAGE.
*/
#include
__FBSDID("$FreeBSD$");
#include
#include
#include
#include
#include
#include
#include
#include
#include
static MALLOC_DEFINE(M_VTBUF, "vtbuf", "vt buffer");
#define VTBUF_LOCK(vb) mtx_lock_spin(&(vb)->vb_lock)
#define VTBUF_UNLOCK(vb)mtx_unlock_spin(&(vb)->vb_lock)
#define POS_INDEX(c, r) (((r) << 12) + (c))
#define POS_COPY(d, s) do {\
(d).tp_col = (s).tp_col;\
(d).tp_row = (s).tp_row;\
} while (0)
#ifndef SC_NO_CUTPASTE
static int vtbuf_htw(const struct vt_buf *vb, int row);
static int vtbuf_wth(const struct vt_buf *vb, int row);
static int vtbuf_in_this_range(int begin, int test, int end, int sz);
#endif
/*
* line4
* line5 <--- curroffset (terminal output to that line)
* line0
* line1 <--- roffset (history display from that point)
* line2
* line3
*/
int
vthistory_seek(struct vt_buf *vb, int offset, int whence)
{
int diff, top, bottom, roffset;
/* No scrolling if not enabled. */
if ((vb->vb_flags & VBF_SCROLL) == 0) {
if (vb->vb_roffset != vb->vb_curroffset) {
vb->vb_roffset = vb->vb_curroffset;
return (0x);
}
return (0); /* No changes */
}
/* "top" may be a negative integer. */
bottom = vb->vb_curroffset;
top = (vb->vb_flags & VBF_HISTORY_FULL) ?
bottom + vb->vb_scr_size.tp_row - vb->vb_history_size :
0;
roffset = 0; /* Make gcc happy. */
switch (whence) {
case VHS_SET:
if (offset < 0)
offset = 0;
roffset = top + offset;
break;
case VHS_CUR:
/*
* Operate on copy of offset value, since it temporary
* can be bigger than amount of rows in buffer.
*/
roffset = vb->vb_roffset;
if (roffset >= bottom + vb->vb_scr_size.tp_row)
roffset -= vb->vb_history_size;
roffset += offset;
roffset = MAX(roffset, top);
roffset = MIN(roffset, bottom);
if (roffset < 0)
roffset = vb->vb_history_size + roffset;
break;
case VHS_END:
/* Go to current offset. */
roffset = vb->vb_curroffset;
break;
}
diff = vb->vb_roffset != roffset;
vb->vb_roffset = roffset;
return (diff);
}
void
vthistory_addlines(struct vt_buf *vb, int offset)
{
#ifndef SC_NO_CUTPASTE
int cur, sz;
#endif
vb->vb_curroffset += offset;
if (vb->vb_curroffset + vb->vb_scr_size.tp_row >= vb->vb_history_size) {
vb->vb_flags |= VBF_HISTORY_FULL;
vb->vb_curroffset %= vb->vb_history_size;
}
if
