> And then... can we reduce wakeup latency in general without raising HZ? Other
> systems (e.g. DFly) have better wakeup latencies and still have HZ=100. What
> are they doing? Can we borrow it?
https://frenchfries.net/paul/dfly/nanosleep.html
OpenBSD is still adding that one tick which result
I had a little debugging session with awolk@ over at #openbsd-daily. His
smtpd would over time end up with hung sessions that never timeout.
The problem is related to the data_io path's congestion control which
may pause the session. In this case the io system will not wait for
read events and a
> > Nice catch, the diff reads fine to me, I'll commit later today when I
> > have another ok from eric@
> Yes, this looks correct. But, I would rather move the resume test before
> the EOM test, to avoid touching the session after the transfer has been
> finalized by smtp_data_io_done().
It ough
If you look at the diff that went in already, it's using mallocarray.
It wouldn't even compile otherwise.
> I might dig deeper once I find the time, but perhaps someone already
> > familiar with the code might want to take a look at it before I waste a
> > week on it ;-)
> >
>
> The issue is the change in ld.so/library_subr.c rev 1.34. If you back that
> change out, the crash disappears.
>
> The probl
> > The issue is the change in ld.so/library_subr.c rev 1.34. If you back that
> > change out, the crash disappears.
> >
> > The problem is that no one makes changes to the linkages inside ld.so out
> > of boredom: there was some previous program that crashed without that
> > change, but the detai
> I noticed that chmod.c have uninitialized variable char *ep that was
> used. This diff clarify what I mean.
It might be a good idea to take a careful look at the man page of
strtoul(3). Pay attention to what it does with errno and endptr.
Also, take a look at the example.
> Unnecessary goto
Or the most straightforward and obvious way to break out of a switch
in a loop.
> variables defined far away from where they are used,
Variables defined predictably at the start of the function, as the
convention is in BSD code. Yes, they can be a little far if the
function i
> That is good convention. But while the function is so big, it is harder
> to read.
>
> >You then also need to shovel
> >data back and forth between these functions.
>
> Not necessarily. When the program is this tiny, single file source,
> it may not so bad thing to use global scope for that share
> > Tested on my x230t and will continue to test. No regrssions noticed on
> > relative pointing devices.
> >
> > OK?
>
> Anyone?
>
> I appreciate that I am probably the only one using OpenBSD on a tablet,
> but a "looks OK" and "no regressions for relative pointing devices"
> would be great.
Wha
> From: Alexandr Shadchin
>
> Before (on example pms(4)):
> * user move mouse
> * pms(4) read state mouse and process it
> * pms(4) send dx, dy and buttons in wscons
> * wscons generate simple events
> * ws(4) reads one event and process it immediately
>
> After applying diff:
> * user move mouse
>
> Alternative solution without extra magic (need rebuild kernel).
>
> Before (on example pms(4)):
> * user move mouse
> * pms(4) read state mouse and process it
> * pms(4) send dx, dy and buttons in wscons
> * wscons generate simple events
> * ws(4) reads one event and process it immediately
>
> Af
Matthew Dempsky writes:
> Diff below tweaks the logic from "allow double space after /[.?!]/" to
> "allow double space after /[.?!]\)?/".
I gave it a spin (since Kjell says it's hard to find people to test mg
diffs). No problems, the code looks fine, and this behavior certainly
makes sense.
I felt hacking custom scripts to add the In-Reply-To header in a reply
is a bad solution if there's no reason we can't just make mail do it
automagically. So, here comes the diff.
There are a few additional changes here:
- Names starting with underscores are reserved, so I gave
_respond and
> Logan has already tested this. Any other test's/oks?
Is there a good reason to all those if/else blocks which
call d_warpdot twice if it succeeds? I don't see one. At
the very least, I'd remove the redundant call. But we can do
better: just be sane and default to zero on error. In the long
r
> In the long run, the error could be removed entirely by making
> dired behave like the rest of mg -- that is, abort somewhere up
> the stream if lalloc fails. This way the rest of the functions
> will never have to worry about a NULL ltext.
Actually, this seems to be the case already. dired ca
> The idea of removing the error to behave like the rest
> of mg would lead to a brittle design. It's like assuming
> errors can only happen once. It makes code faster, but
> later changes could cause subtle bugs that could be hard to
> track IMHO.
Quite the opposite
> The warpdot() has at least one issue. It leads to
> segfaults if you try to open a directory like (BCD).
[.. diff ..]
> ed
>
> mg doesn't segfault.
Your fix is wrong, and only works by chance. If you craft
a directory with enough spaces in its name, it'll segfault
again. And you cannot fix t
> > The warpdot() has at least one issue. It leads to
> > segfaults if you try to open a directory like (BCD).
New diff below. I wanted to make d_warpdot behave exactly
like the rest of mg functions in that it'd take the two standard
int (f, n) arguments, and dereference curwp->* to do its job.
> > > The warpdot() has at least one issue. It leads to
> > > segfaults if you try to open a directory like (BCD).
> >
> > [.. diff ..]
> > > ed
> > >
> > > mg doesn't segfault.
> >
> > Your fix is wrong, and only works by chance. If you craft
> > a directory with enough spaces in its name, it'
> It fixes the issue that if a filename has a space at the start of
> it, the point will stay in the first character column and not jump
> to the first non ' ' character in the filename.
Yup, this looks good to me.
> However, it does seem to expose a bug in dired, that if a filename
> has a space
> > However, it does seem to expose a bug in dired, that if a filename
> > has a space at the start of it, mg doesn't find it if you try and
> > open it. mg gives a message of (New File) and creates and empty
> > buffer. But in the mean time, I think this change does make this
> > diff more corre
> And here's that diff. [..]
It never hurts to re-read a diff before going to bed. Indeed, I
forgot to free argv (execlp uses alloca). The number of things
to clean up after one thing fails is almost getting out of hand,
and at least the fork() case wasn't handled properly. In this new
revisio
> Being a little less stupid this time. Rewrote the string handling
> part, style(9) formatting and refactored pushtag function.
Some thoughts about this. Are you sure you're not going to overflow
t in re_tag_conv when you insert escapes? Correct me if I'm wrong,
but I think ctags patterns aren
> On Thu, Jul 04, 2013 at 05:24:20PM +0200, Mark Kettenis wrote:
> > > From: Theo de Raadt
> > > Date: Thu, 04 Jul 2013 09:04:54 -0600
> > >
> > > I suspect the best approach would be a hybrid value. The upper half
> > > of the address should try to land in an unmapped zone, or into the zero
> >
So I needed to see my thoughts on paper but my desk was so full of stuff
I couldn't make room for pen and paper. Instead I fired up Gimp, and
drawing with the mouse worked fine until I realized it's next to impossible
to draw diagonal lines that look like lines.
Instead of straight lines, I got w
> The issue that input drivers devices need high refresh frequency to be
> able to achieve high-precision freehand drawing is quite well known¹.
Yes. But the bug here isn't about that. I think I'll have to elaborate
a little.
When you move the mouse, it will report its motion in an event with a
> > I do fear that with some devices your patch will collapse too many
> > events and make it harder to follow small radius curves.
>
> Right, I did not consider this case. If this is a problem, perhaps
> the code could be changed to only collapse a pair of DELTA_X and
> DELTA_Y events, but never
This adds the command that moves the dot to the first non-whitespace
character on the line.
Index: src/usr.bin/mg/def.h
===
RCS file: /cvs/src/usr.bin/mg/def.h,v
retrieving revision 1.113
diff -u -p -r1.113 def.h
--- src/usr.bin/mg/de
Here's another command I always miss while working with mg.
diff -up src/usr.bin/mg.old/def.h src/usr.bin/mg/def.h
--- src/usr.bin/mg.old/def.hFri Jan 14 17:27:17 2011
+++ src/usr.bin/mg/def.hFri Jan 14 17:49:34 2011
@@ -512,6 +512,7 @@ int forwdel(int, int);
int
> Looks pretty good. I might add an undo boundary
> around the whole thing (I note emacs doesn't do this
> properly, at least on the version I have here)...
I like it. If undo is a concern, then it might be a good idea to
check the other functions while we're here.
I found at least the following
> Comments?
Looks quite fine, but I noticed there are no NULL checks for the
newly allocated strings. Aborting a command gracefully might be
better than crashing, should anyone ever be unfortunate enough
to hit this.
Also:
> @@ -415,8 +421,11 @@
> ewprintf("Directory name too long
> Thus, I propose the following respin: implement xdirname and xbasename
> using a strlcat/strlcpy semantic. This is more natural in most calls anyway.
Good idea. Being used to the strlfoo functions, it looks a bit strange
to make xplen the middlemost argument, but I'm just being me now. :-)
> +
I noticed route treats the flags -iface and -interface as synonyms.
Almost synonyms.
This little diff makes monitor accept -interface as the other commands
do. It also makes the manual consistent such that only -iface is used
throughout it.
Index: src/sbin/route/route.8
As the subject says: the -w flag is no longer necessary (nor documented)
for setting vars with wsconsctl, so don't advise people to use it.
Index: src/share/man/man4/akbd.4
===
RCS file: /cvs/src/share/man/man4/akbd.4,v
retrieving rev
35 matches
Mail list logo
