I need xdotool to press pos1, but I don't know the name of this key. It's not pos1, POS1, Pos1, Beginning. How can I find the name of the key which is used by xdotool?
Execute
$ xev -event keyboard
and then just type the key you want to use.
Example output:
Outer window is 0x4a00001, inner window is 0x4a00002
KeymapNotify event, serial 24, synthetic NO, window 0x0,
keys: 4294967230 0 0 0 16 0 0 0 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
KeyRelease event, serial 25, synthetic NO, window 0x4a00001,
root 0x1a1, subw 0x0, time 109192145, (501,285), root:(503,393),
state 0x0, keycode 36 (keysym 0xff0d, Return), same_screen YES,
" XLookupString gives 1 bytes: (0d) "
XFilterEvent returns: False
KeyPress event, serial 28, synthetic NO, window 0x4a00001,
root 0x1a1, subw 0x0, time 109193882, (501,285), root:(503,393),
state 0x0, keycode 110 (keysym 0xff50, Home), same_screen YES,
XLookupString gives 0 bytes:
XmbLookupString gives 0 bytes:
XFilterEvent returns: False
KeyRelease event, serial 28, synthetic NO, window 0x4a00001,
root 0x1a1, subw 0x0, time 109193953, (501,285), root:(503,393),
state 0x0, keycode 110 (keysym 0xff50, Home), same_screen YES,
XLookupString gives 0 bytes:
XFilterEvent returns: False
^C
The interesting part is keycode 110 (keysym 0xff50, Home). So the name is Home.
Related
Is it possible to tell whether a process/thread has the PF_NO_SETAFFINITY flag set? I'm running taskset on a series of process ids and some are throwing errors of the following form:
taskset: failed to set pid 30's affinity: Invalid argument
I believe this is because some processes have PF_NO_SETAFFINITY set (see Answer).
Thank you!
Yes - look at /proc/PID/stat's 'flag' field
<linux/sched.h
#define PF_NO_SETAFFINITY 0x04000000 /* Userland is not allowed to meddle with cpus_allowed */
Look here for details on using /proc:
http://man7.org/linux/man-pages/man5/proc.5.html
https://supportcenter.checkpoint.com/supportcenter/portal?eventSubmit_doGoviewsolutiondetails=&solutionid=sk65143
Example:
ps -eaf
www-data 30084 19962 0 07:09 ? 00:00:00 /usr/sbin/apache2 -k start
...
cat /proc/30084/stat
30084 (apache2) S 19962 19962 19962 0 -1 4194624 554 0 3 0 0 0 0 0 20 0 1 0 298837672 509616128 5510 18446744073709551615 1 1 0 0 0 0 0 16781312 201346799 0 0 0 17 0 0 0 0 0 0 0 0 0 0 0 0 0 0
The flags are 4194624
Q: Do you mind specifying how you'd write a simple script that outputs
true/false based on whether you're allowed to set affinity?
A: I don't feel comfortable providing this without the opportunity to test, but you can try something like this...
flags=$(cut -f 9 -d ' ' /proc/30084/stat)
echo $(($flags & 0x40000000))
I've been doing some experimenting with PostGIS, and here's what I've noticed:
Suppose I have a table defined as follows:
CREATE TABLE IF NOT EXISTS geomtest (
id SERIAL PRIMARY KEY,
name TEXT NOT NULL,
geom geometry(POLYGON, 4326) NOT NULL
);
And I add the following polygon:
SRID=4326;POLYGON((0 0,0 10,10 10,10 0,0 0))
If I query the geom column on its own, I get a Hex representation of the geometry. If I instead call ST_AsBinary(geom), I get a binary representation.
However, when I convert both the hex and binary representations to an array of bytes, the results I get are slightly different. The first comment is the result I get by converting the hex into binary, and the next is straight from ST_AsBinary()
//[1 3 0 0 32 230 16 0 0 1 0 0 0 5 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 36 64 0 0 0 0 0 0 36 64 0 0 0 0 0 0 36 64 0 0 0 0 0 0 36 64 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0]
//[1 3 0 0 0 1 0 0 0 5 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 36 64 0 0 0 0 0 0 36 64 0 0 0 0 0 0 36 64 0 0 0 0 0 0 36 64 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0]
As you can see, the first 4 bytes are identical; representing whether it's in big or little endian, and the type of geometry (3, in this case a Polygon). The rest of the bytes are the same too. The only difference is there are a few extra bytes added after the first 4.
I wondered if this had to do with representing the projection (SRID=4326), but I haven't found any evidence to that.
If someone could shed some light on this, I'd greatly appreciate it.
I didn't examine the bytes, but I am sure that the difference is the SRID that's not included in the WKB format.
Try st_asewkb instead.
Here is an example interaction with dtruss on my macOS machine.
$ cat main.c
int main() {
return 0;
}
$ clang main.c
$ sudo dtruss ./a.out
dtrace: system integrity protection is on, some features will not be available
SYSCALL(args) = return
open("/dev/dtracehelper\0", 0x2, 0x7FFF5AF83930) = 3 0
ioctl(0x3, 0x80086804, 0x7FFF5AF838B8) = 0 0
close(0x3) = 0 0
thread_selfid(0x3, 0x80086804, 0x7FFF5AF838B8) = 5434813 0
bsdthread_register(0x7FFFAF245080, 0x7FFFAF245070, 0x2000) = 1073741919 0
ulock_wake(0x1, 0x7FFF5AF830EC, 0x0) = -1 Err#2
issetugid(0x1, 0x7FFF5AF830EC, 0x0) = 0 0
mprotect(0x104C7F000, 0x88, 0x1) = 0 0
mprotect(0x104C81000, 0x1000, 0x0) = 0 0
mprotect(0x104C97000, 0x1000, 0x0) = 0 0
mprotect(0x104C98000, 0x1000, 0x0) = 0 0
mprotect(0x104CAE000, 0x1000, 0x0) = 0 0
mprotect(0x104CAF000, 0x1000, 0x1) = 0 0
mprotect(0x104C7F000, 0x88, 0x3) = 0 0
mprotect(0x104C7F000, 0x88, 0x1) = 0 0
getpid(0x104C7F000, 0x88, 0x1) = 34522 0
stat64("/AppleInternal/XBS/.isChrooted\0", 0x7FFF5AF82FA8, 0x1) = -1 Err#2
stat64("/AppleInternal\0", 0x7FFF5AF83040, 0x1) = -1 Err#2
csops(0x86DA, 0x7, 0x7FFF5AF82AD0) = -1 Err#22
dtrace: error on enabled probe ID 2158 (ID 552: syscall::sysctl:return): invalid kernel access in action #10 at DIF offset 40
ulock_wake(0x1, 0x7FFF5AF83050, 0x0) = -1 Err#2
csops(0x86DA, 0x7, 0x7FFF5AF823B0) = -1 Err#22
Many of these system calls look familiar, but others don't. Specifically, what are thread_selfid, bsdthread_register, ulock_wake, csops, and dtrace? If these are system calls, they don't have man pages documenting them. Are they private system calls, or something else? Where does dtruss get their names from?
Yes, ULOCK_wake is part of a private systemcall for threads afaik.
You can see it in the xnu sourcecode as being systemcall number 516.
I've a problem I need to divide image into blocks and add zero border for each blocks, one or two zeros is enough, I added border for all image but I want to add border for each block of image.
note::: no of block any size for ex: 4X4 blocks
img=round(100*rand(4,4));
[n,m]=size(img);
x=zeros(n+2,m+2);
%%%%%Applying zero padding to the image
for i=1:n+2
for j=1:m+2
if i==1 || i==n+2 || j==1 || j==m+2
x(i,j)=0;
else
x(i,j)=img(i-1,j-1);
end
end
end
x
I need to get output like this around each block one or two zero
0 0 0 0 0 0 0 0
0 84 80 0 0 65 85 0
0 29 19 0 0 23 77 0
0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0
0 84 80 0 0 66 74 0
0 29 19 0 0 36 80 0
0 0 0 0 0 0 0 0
%n: Size of original matrix
n=size(img,1)
%prealloc new matrix
img2=zeros(n+3,n+3)
%p indicates indices to store img at
p=[(2:n/2+1),(n/2+3:n+2)]
%Copy img to the correct positions
img2(p,p)=img
In Perl, I generate a huge read-only data-structure once, then fork().
This is to take advantage of COW on RSS pages when forking. It works really well, but when a child process exits, it allocates all the RAM from itelf just prior dying.
Is there a way to avoid this useless allocation ?
Here is sample Perl code that shows the issue.
#! /usr/bin/perl
my $a = [];
# Allocate 100 MiB
for my $i (1 .. 100000) {
push #$a, "x" x 1024;
}
# Fork 10 other process
for my $j (1 .. 10) {
last unless fork();
}
# Sleep for a while to be able to see the RSS
sleep(5);
In the sample vmstat output, we can see that it first allocates only 100MiB, then after the 1rst sleep it allocates the whole for a short while, and then releases all of it.
procs -----------memory---------- ---swap-- -----io---- --system-- -----cpu------
r b swpd free buff cache si so bi bo in cs us sy id wa st
0 0 0 1329660 80596 86936 0 0 21 18 160 25 0 0 100 0 0
1 0 0 1328048 80596 86936 0 0 0 0 1013 44 0 0 100 0 0
0 0 0 1223888 80596 86936 0 0 0 0 1028 76 11 5 84 0 0
0 0 0 1223888 80596 86936 0 0 0 0 1010 40 0 0 100 0 0
0 0 0 1223888 80596 86936 0 0 0 0 1026 54 0 0 100 0 0
0 0 0 1223888 80596 86936 0 0 0 0 1006 39 0 0 100 0 0
13 0 0 741156 80596 86936 0 0 0 0 1012 66 13 58 28 0 0
0 0 0 1329288 80596 86936 0 0 0 0 1032 60 0 0 100 0 0
Note: it seems it isn't a Perl version specific issue. As I tested 5.8.8, 5.10.1 & 5.14.2 and they all do exhibit this behavior.
Update:
As #choroba asked in comments, I also tried to undef the data-structure, but it seems that it triggers the memory-touching as the RAM is then allocated.
You can add the following snippet at the end of the first script.
# Unallocate $a
undef $a;
# Sleep for a while to be able to see the RSS
sleep(5);
Actually, as I found out myself, this behavior is a feature, and the answer lies in the Perl doc:
The exit() function does not always exit immediately.
Likewise any object destructors that need to be called
are called before the real exit.
If this is a problem, you can
call POSIX::_exit($status) to avoid END and destructor processing.
And indeed, adding it at the end of the original code sample does avoid the behavior.
# XXX - To be added just before ending the process
# Use POSIX::_exit($status) to end without allocating copy-on-write RAM
use POSIX;
POSIX::_exit(0);
Note: for this to work, the child has to exit also before the data-structure goes out of scope.