Re: [dev] slock: anti OOM killer - proper priv dropping - etc.
On 26.07.2013, at 00:46, Joerg Jung wrote: > > hence shoul be in an ifdef linux or something. > Or use setpriority() to make it portable. ~koneu
Re: [dev] Re: coreutils / moreutils - DC a directory counter
Its called unionfs if I recall On Jul 25, 2013 9:28 PM, "Thorsten Glaser" wrote: > Calvin Morrison dixit: > > >I was sick of ls | wc -l being so damned slow on large directories, so > > What, besides the printing and sorting, is the slow part anyway? > Is it the VFS API or just the filesystem code? > > In the latter case… could workarounds exist? Someone asked this… > http://fenski.pl/2013/07/looking-for-a-specific-fuse-based-filesystem/ > … on Planet Debian this night. > > Something to think about. (No further input from me, besides > mumbling that I had a vague idea of similar concept and wouldn’t > be surprised if something like that already existed, and probably > only in the Plan 9 world…) > > bye, > //mirabilos > -- > (gnutls can also be used, but if you are compiling lynx for your own use, > there is no reason to consider using that package) > -- Thomas E. Dickey on the Lynx mailing list, about OpenSSL > >
[dev] Re: coreutils / moreutils - DC a directory counter
Calvin Morrison dixit: >I was sick of ls | wc -l being so damned slow on large directories, so What, besides the printing and sorting, is the slow part anyway? Is it the VFS API or just the filesystem code? In the latter case… could workarounds exist? Someone asked this… http://fenski.pl/2013/07/looking-for-a-specific-fuse-based-filesystem/ … on Planet Debian this night. Something to think about. (No further input from me, besides mumbling that I had a vague idea of similar concept and wouldn’t be surprised if something like that already existed, and probably only in the Plan 9 world…) bye, //mirabilos -- (gnutls can also be used, but if you are compiling lynx for your own use, there is no reason to consider using that package) -- Thomas E. Dickey on the Lynx mailing list, about OpenSSL
[dev] [st] [PATCH] Fix blink mode check
ATTR_BLINK is an attribute for a Glyph and will not be set in term.mode.
---
Again, I haven't actually run into any problems caused by this, but this seems
like a typo to me.
st.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/st.c b/st.c
index 8992998..734c345 100644
--- a/st.c
+++ b/st.c
@@ -3544,8 +3544,8 @@ run(void) {
ttyread();
if(blinktimeout) {
blinkset = tattrset(ATTR_BLINK);
- if(!blinkset && term.mode & ATTR_BLINK)
- term.mode &= ~(MODE_BLINK);
+ if(!blinkset)
+ MODBIT(term.mode, 0, MODE_BLINK);
}
}
--
1.8.3
[dev] [st] [PATCH] Fix some bugs in mouse tracking logic
* Button number in X10 mode:
I believe the button - 1 came from "C b is button - 1" from [0].
However, above this section, it states
"Normally, parameters (such as pointer poisition and button number)
for all mouse tracking escape sequences generated by xterm encode
numeric parameters in a single character as value+32. For example, !
specifies the value 1."
Also, from the description of SGR,
"The encoded button value in this case does not add 32 since that
was useful only in the X10 scheme for ensuring that the byte
containing the button value is a printable code."
This suggests that we should still add 32 to the button value when in
MODE_MOUSEX10.
* No button release reporting in X10 mode:
"X10 compatibility mode sends an escape sequence only on button press,
encoding the location and the mouse button pressed."
* Fix MODE_MOUSEMOTION:
Currently, motion reporting is skipped when oldbutton == 3
(corresponding to no button being pressed). However, oldbutton is
only set on a button press, which will never be 3.
[0]: http://invisible-island.net/xterm/ctlseqs/ctlseqs.html
---
I came across these when porting st to wayland (if you're interested in that,
watch the wayland mailing list).
I haven't actually run into any of these bugs (I don't use terminal mouse
support), but these changes seem correct to me based on [0].
Any feedback or testing is welcome!
st.c | 22 +-
1 file changed, 13 insertions(+), 9 deletions(-)
diff --git a/st.c b/st.c
index 947373f..8992998 100644
--- a/st.c
+++ b/st.c
@@ -818,18 +818,23 @@ mousereport(XEvent *e) {
button = oldbutton + 32;
ox = x;
oy = y;
- } else if(!IS_SET(MODE_MOUSESGR)
- && (e->xbutton.type == ButtonRelease
- || button == AnyButton)) {
- button = 3;
} else {
- button -= Button1;
- if(button >= 3)
- button += 64 - 3;
+ if(!IS_SET(MODE_MOUSESGR) && e->xbutton.type == ButtonRelease) {
+ button = 3;
+ } else {
+ button -= Button1;
+ if(button >= 3)
+ button += 64 - 3;
+ }
if(e->xbutton.type == ButtonPress) {
oldbutton = button;
ox = x;
oy = y;
+ } else if(e->xbutton.type == ButtonRelease) {
+ oldbutton = 3;
+ /* MODE_MOUSEX10: no button release reporting */
+ if(IS_SET(MODE_MOUSEX10))
+ return;
}
}
@@ -846,8 +851,7 @@ mousereport(XEvent *e) {
e->xbutton.type == ButtonRelease ? 'm' : 'M');
} else if(x < 223 && y < 223) {
len = snprintf(buf, sizeof(buf), "\033[M%c%c%c",
- IS_SET(MODE_MOUSEX10)? button-1 : 32+button,
- 32+x+1, 32+y+1);
+ 32+button, 32+x+1, 32+y+1);
} else {
return;
}
--
1.8.3
Re: [dev] slock: anti OOM killer - proper priv dropping - etc.
Am 23.07.2013 um 15:50 schrieb Robert Schneider : >> In dontkillme(), wouldn't it be desirable to close the file descriptor? > > Shit, good catch. [1_dontkillme_v2.patch] > -- > ziggomatic > <1_dontkillme_v2.patch> I think this unportable and totally linux specific, hence shoul be in an ifdef linux or something. Regards Joerg
