Re: [PATCH] winsup/doc/dll.xml: update MinGW/.org to MinGW-w64/.org
Brian Inglis writes: > It's normally a merge conflict which will not be satisfied by regular > commands to restore the working files to upstream. So you're pulling on an unclean work tree? That's a no-no, either keep your changes on a separate branch (that you can rebase or merge later) or stash them away for the pull. As Corinna said, if you're prepared to lose any local changes then git reset --hard will do that. But you should be sure you really didn't want any of your unfinished business around any more. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Factory and User Sound Singles for Waldorf Blofeld: http://Synth.Stromeko.net/Downloads.html#WaldorfSounds
Re: [PATCH] winsup/doc/dll.xml: update MinGW/.org to MinGW-w64/.org
Brian Inglis writes: > Thanks - I'll try to remember to try that - on a pull conflict I > normally try to checkout -- file(s), then -f, then origin/master, then > plus -f, with status checks between, then commit -m merge when > required, and re-pull origin/master to check resynced to upstream > remote. git status That usually tells you what it is that prevents pulling. Aside from that, you can always do git remote update to get the objects and then figure out how to pull the branch. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Samples for the Waldorf Blofeld: http://Synth.Stromeko.net/Downloads.html#BlofeldSamplesExtra
Re: [PATCH] Cygwin: Speed up mkimport
Achim Gratz writes: > That actually works, but the speedup is quite modest on my system > (4C/8T) even though I've allowed it to use unlimited resources. So it > basically forks slower than the runtime for each of the invocations is. > Some more speedup can be had if the assembler is run on actual files in > the same way, but the best I've come up with goes from 93s to 47s and > runs at 150% CPU (up from 85%). Most of that time is spent in system, > so forking and I/O. Not that I really know what I'm doing, but creating a single .s file and running as just once gets mkimport down to 21s / 110%. Now the resulting library doesn't actually link, because somehow the information ends up in the wrong place… Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Wavetables for the Terratec KOMPLEXER: http://Synth.Stromeko.net/Downloads.html#KomplexerWaves
Re: [PATCH] Cygwin: Speed up mkimport
Achim Gratz writes: > b) Open up two pipes to an "xargs -P $ncpu/2 L 1 …" and feed in the file > names. That actually works, but the speedup is quite modest on my system (4C/8T) even though I've allowed it to use unlimited resources. So it basically forks slower than the runtime for each of the invocations is. Some more speedup can be had if the assembler is run on actual files in the same way, but the best I've come up with goes from 93s to 47s and runs at 150% CPU (up from 85%). Most of that time is spent in system, so forking and I/O. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Factory and User Sound Singles for Waldorf Blofeld: http://Synth.Stromeko.net/Downloads.html#WaldorfSounds
Re: [PATCH] Cygwin: Speed up mkimport
Mark Geisert writes: > Still faster than two system commands :-). But thanks for the > comment; It still seems you are barking up the wrong tree. > I thought I was merely grouping args, to get around Perl's > greedy arg list building for the system command. Wot? It just takes a list which you can build any which way you desire. The other option is to give it the full command line in a string, which does work for this script (but not on Windows). If it finds shell metacharacters in the arguments it'll run a shell, otherwise the forked perl just does an execve. If it's really the forking that is causing the slowdown, why not do either of those things: a) Generate a complete shell script and fork once to run that. b) Open up two pipes to an "xargs -P $ncpu/2 L 1 …" and feed in the file names. Getting the error codes back to the script and handling the error is left as an exercise for the reader. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Factory and User Sound Singles for Waldorf Q+, Q and microQ: http://Synth.Stromeko.net/Downloads.html#WaldorfSounds
Re: [PATCH] Cygwin: Speed up mkimport
Mark Geisert writes:
> + # Do two objcopy calls at once to avoid one system() call overhead
> + system '(', $objcopy, '-R', '.text', $f, ')', '||',
> + $objcopy, '-R', '.bss', '-R', '.data', "t-$f" and exit 1;
That doesn't do what you think it does. It in fact increases the
overhead since it'll start a shell that runs those two commands sand
will even needlessly start the first objcopy in a subshell.
Regards,
Achim.
--
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+
Factory and User Sound Singles for Waldorf rackAttack:
http://Synth.Stromeko.net/Downloads.html#WaldorfSounds
Re: [PATCH] Cygwin: Provide more COM devices
Brian Inglis writes: > On 2019-12-14 11:38, Achim Gratz wrote: > > [Sorry, thought I'd sent this, it was backgrounded!] > > What are the distinctions between /dev/sd[a-c][a-z], /dev/sdd[a-z], and > /dev/sd[a-z] appearing in parts of devices.cc? /dev/sd is the base name for disks, letters denote distinct units (a..dx for a total of 128 units) and numbers the partitions (starting from 1, with no number addressing the whole device), just like Linux. The first 16 partitions of each drive have a fixed device major number (out of 8) and mangle the drive / partition into the lower nibbles of the minor. Any drive with higher partition numbers gets mapped into 25 higher device numbers where the bits for the unit number spread across major/minor and the remaining 48 partitions make up the lower part of the minor. I'd rather had kept the original numbering scheme and packed each set of 16 extra partitions into one more major number for a total of 24 extra, but that's what we have now. > There are 127 each cons,nst,pty,ptym,st,ttyS entries allocated for potential > devices, which will not exist on most systems. You'll proably won't find a system with so many tapes, not. But the way Windows deals with USB devices means that you can easily have several dozen of (virtual) COM ports, since it creates a distinct number for each device / USB port combination you've ever used. The limit is probably even higher than the 128 ports Cygwin tries to support. > Note that GPT supports 128 partitions per device. But Cygwin only supports 64. > Are there systems using more than 32 of any supported device? I have systems that are way past COM64 and I seem to remember having seen one with a COM port past 127. > Are there documented Windows I/O device addressing limits? You could have 256 since Win98 (not for DOS applications, though), but that IIRC was always a limitation of the control panel, not the underlying platform. Not sure if Win10 changed something in that regard, but probably not. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ SD adaptations for Waldorf Q V3.00R3 and Q+ V3.54R2: http://Synth.Stromeko.net/Downloads.html#WaldorfSDada
Re: [PATCH] Cygwin: Provide more COM devices
Brian Inglis writes: > On 2019-12-14 11:38, Achim Gratz wrote: > > s[6] == 'd'? Indeed. >> if (len > 7 && len < 12 && s[7] == 'd' > - if (len > 7 && len < 12 && s[7] == 'd' > + if (len > 7 && len < 12 && s[DP_LEN - 1] == 'd' Yes, that's better. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Factory and User Sound Singles for Waldorf Q+, Q and microQ: http://Synth.Stromeko.net/Downloads.html#WaldorfSounds
Re: [PATCH] Cygwin: Provide more COM devices
Achim Gratz writes:
> Corinna Vinschen writes:
> […]
>> ttyS%(0-255) takes another 23K btw. Even that should be ok, if
>> the need arises. Alternatively we could shortcut shilka as for
>> /dev/sd*, but that involved much bigger numbers.
>
> I've searched for some documentation (anywhere the glob syntax %(1-128)
> would turn up, btw?) and I think Cygwin is misusing shilka a bit here.
> It's a keyword scanner, so the arithmetically coded parts of the device
> shouldn't be targeted at all. Instead, only the device path prefix
> should be searched via the shilka lexer and the rest of the conversion
> done in code.
I've stared at the code for quite some time now and I think I've come up
with something that could work. I'm chopping the device numbers and
disk names off the end of the device name before feeding into the shilka
lexer. That creates a lexer with only 29 keywords and much less entries
in the dev_storage array, so it should be much faster to search also,
although I think a hash to access the array via the major device number
would now be feasible. I think I'll have to extend the _device
structure with one or two more function pointers to deal with putting
the minor numbers back in before handing the result to the caller. In
principle that could deal with any number of devices that fit into the
device number scheme, but we can still declare certain ranges illegal.
--8<---cut here---start->8---
void
device::parse (const char *s)
{
size_t len = strlen (s);
const char *t = s + len; /* points past s */
/* chop off any trailing digits and leave t pointing to the beginning of that
number */
for (; isdigit (t-1); len--, t--) ;
if (len > 7 && len < 12 && s[7] == 'd'
/* Generic check for /dev/sd[a-z] prefix */
&& strncmp (s, DISK_PREFIX, DP_LEN) == 0
&& s[DP_LEN] >= 'a' && s[DP_LEN] <= 'z')
{
/* /dev/sd* devices have 8192 entries, given that we support 128 disks
with up to 64 partitions. Handling them with shilka raises the size
of devices.o from ~250K to ~2 Megs. So we handle them here manually
to save this space. */
…
}
else
{
const _device *dev = KR_find_keyword (s, len);
if (!dev)
*this = *fs_dev;
else
{
*this = *dev;
/* check and process device numbers */
…
}
}
}
--8<---cut here---end--->8---
Regards,
Achim.
--
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+
Factory and User Sound Singles for Waldorf Q+, Q and microQ:
http://Synth.Stromeko.net/Downloads.html#WaldorfSounds
Re: cygrunsrv patch
Lavrentiev, Anton (NIH/NLM/NCBI) [C] via cygwin-patches writes: > $ git clone 'https://cygwin.com/git/?p=cygwin-apps/cygrunsrv.git' ./cygrunsrv > Cloning into './cygrunsrv'... > fatal: repository 'https://cygwin.com/git/?p=cygwin-apps/cygrunsrv.git/' not > found Try git://sourceware.org/git/cygwin-apps/cygrunsrv.git instead? Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ SD adaptation for Waldorf microQ V2.22R2: http://Synth.Stromeko.net/Downloads.html#WaldorfSDada
Re: [PATCH] Cygwin: Provide more COM devices
Corinna Vinschen writes: […] > ttyS%(0-255) takes another 23K btw. Even that should be ok, if > the need arises. Alternatively we could shortcut shilka as for > /dev/sd*, but that involved much bigger numbers. I've searched for some documentation (anywhere the glob syntax %(1-128) would turn up, btw?) and I think Cygwin is misusing shilka a bit here. It's a keyword scanner, so the arithmetically coded parts of the device shouldn't be targeted at all. Instead, only the device path prefix should be searched via the shilka lexer and the rest of the conversion done in code. For the disks we might keep the globbing that gets us the device major part. That of course means we construct more devices on-the-fly (or even all of them) and have a much smaller table of static device entries (which get searched linearly, so in the end that should be a net speed improvement). Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Factory and User Sound Singles for Waldorf Q+, Q and microQ: http://Synth.Stromeko.net/Downloads.html#WaldorfSounds
Re: [PATCH] Cygwin: Provide more COM devices
As requested:
>From 7908d09f547e0a7a707139d0faaccc151b88024c Mon Sep 17 00:00:00 2001
From: Achim Gratz
Date: Tue, 22 Oct 2019 19:50:50 +0200
Subject: [PATCH] Cygwin: provide more COM devices
* winsup/cygwin/devices.in: Provide for 128 COM devices since Windows
likes to create lots of these over time (one per identifiable device
and USB port).
---
winsup/cygwin/devices.in | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/winsup/cygwin/devices.in b/winsup/cygwin/devices.in
index 59f5f00d2..9a42951f6 100644
--- a/winsup/cygwin/devices.in
+++ b/winsup/cygwin/devices.in
@@ -164,7 +164,7 @@ const _device dev_error_storage =
"/dev/urandom", BRACK(FH_URANDOM), "\\Device\\Null", exists_ntdev, S_IFCHR,
=urandom_dev
"/dev/clipboard", BRACK(FH_CLIPBOARD), "\\Device\\Null", exists_ntdev, S_IFCHR
"/dev/com%(1-16)d", BRACK(FHDEV(DEV_SERIAL_MAJOR, {$1 - 1})), "\\??\\COM{$1}",
exists_ntdev_silent, S_IFCHR
-"/dev/ttyS%(0-63)d", BRACK(FHDEV(DEV_SERIAL_MAJOR, {$1})), "\\??\\COM{$1 +
1}", exists_ntdev, S_IFCHR
+"/dev/ttyS%(0-127)d", BRACK(FHDEV(DEV_SERIAL_MAJOR, {$1})), "\\??\\COM{$1 +
1}", exists_ntdev, S_IFCHR
":pipe", BRACK(FH_PIPE), "/dev/pipe", exists_internal, S_IFCHR
":fifo", BRACK(FH_FIFO), "/dev/fifo", exists_internal, S_IFCHR
"/dev/st%(0-127)d", BRACK(FHDEV(DEV_TAPE_MAJOR, {$1})), "\\Device\\Tape{$1}",
exists_ntdev, S_IFBLK
--
2.23.0
Achim.
--
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+
Waldorf MIDI Implementation & additional documentation:
http://Synth.Stromeko.net/Downloads.html#WaldorfDocs
Re: [PATCH] Cygwin: Provide more COM devices
Corinna Vinschen writes: >> So how about we only do this on 64bit as an added bonus for folks who >> "get it"? > > I'm not hot on doing that, and I'm not sure shilka likes ifdef's > inside the %% block. OK, then let's forget about that. >> One particular machine I've recently worked on presented me >> with COM144 to connect to, but I consider this to be an anomaly. But >> COM port numbers in the 70…80 range are pretty common on some of the >> more heavily used development machines. > > I just checked and changing ttyS%(0-63) to ttyS%(0-127) raises > the size of .text and .rdata by 6.5K and the size of the final DLL > by 7.6K. That should be ok. Just provide the patch so there's your > name on it. You mean just the patch to change device.in? Can do. If I also need to re-generate the other files then I'm afraid I won't be able to do it in the next two weeks, maybe a bit longer. > ttyS%(0-255) takes another 23K btw. Even that should be ok, if > the need arises. Alternatively we could shortcut shilka as for > /dev/sd*, but that involved much bigger numbers. As I said, I don't think that this is common enough, so let's wait until somebody complains. Getting rid of the static entries sounds like a good idea, but that's for later. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Factory and User Sound Singles for Waldorf Blofeld: http://Synth.Stromeko.net/Downloads.html#WaldorfSounds
Re: [PATCH] Cygwin: Provide more COM devices
Corinna Vinschen writes: > That's not the right way to patch this. devices.cc gets generated from > devices.in by the gendevices script which in turn calls shilka from the > cocom package. Now that you mention it I remember… :-( > Apart from the struct members you added here, it will > also add some code. Which, unfortunately, raise the size of devices.cc, > especially troubling the 32 bit version. So how about we only do this on 64bit as an added bonus for folks who "get it"? One particular machine I've recently worked on presented me with COM144 to connect to, but I consider this to be an anomaly. But COM port numbers in the 70…80 range are pretty common on some of the more heavily used development machines. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ SD adaptation for Waldorf rackAttack V1.04R1: http://Synth.Stromeko.net/Downloads.html#WaldorfSDada
[PATCH] Cygwin: Provide more COM devices
This was requested on IRC.
>From a80b1c9ba67f94237948e85ad2dee744cdfbdcad Mon Sep 17 00:00:00 2001
From: Achim Gratz
Date: Sun, 20 Oct 2019 15:23:04 +0200
Subject: [PATCH] Cygwin: provide more COM devices
* winsup/cygwin/devices.cc: Add another 64 COM devices since Windows
likes to create lots of these over time (one per identifiable device
and USB port).
---
winsup/cygwin/devices.cc | 64
1 file changed, 64 insertions(+)
diff --git a/winsup/cygwin/devices.cc b/winsup/cygwin/devices.cc
index 2e31ca366..7a57459d8 100644
--- a/winsup/cygwin/devices.cc
+++ b/winsup/cygwin/devices.cc
@@ -798,6 +798,70 @@ const _RDATA _device dev_storage[] =
{"/dev/ttyS61", BRACK(FHDEV(DEV_SERIAL_MAJOR, 61)), "\\??\\COM62",
exists_ntdev, S_IFCHR, true},
{"/dev/ttyS62", BRACK(FHDEV(DEV_SERIAL_MAJOR, 62)), "\\??\\COM63",
exists_ntdev, S_IFCHR, true},
{"/dev/ttyS63", BRACK(FHDEV(DEV_SERIAL_MAJOR, 63)), "\\??\\COM64",
exists_ntdev, S_IFCHR, true},
+ {"/dev/ttyS64", BRACK(FHDEV(DEV_SERIAL_MAJOR, 64)), "\\??\\COM65",
exists_ntdev, S_IFCHR, true},
+ {"/dev/ttyS65", BRACK(FHDEV(DEV_SERIAL_MAJOR, 65)), "\\??\\COM66",
exists_ntdev, S_IFCHR, true},
+ {"/dev/ttyS66", BRACK(FHDEV(DEV_SERIAL_MAJOR, 66)), "\\??\\COM67",
exists_ntdev, S_IFCHR, true},
+ {"/dev/ttyS67", BRACK(FHDEV(DEV_SERIAL_MAJOR, 67)), "\\??\\COM68",
exists_ntdev, S_IFCHR, true},
+ {"/dev/ttyS68", BRACK(FHDEV(DEV_SERIAL_MAJOR, 68)), "\\??\\COM69",
exists_ntdev, S_IFCHR, true},
+ {"/dev/ttyS69", BRACK(FHDEV(DEV_SERIAL_MAJOR, 69)), "\\??\\COM70",
exists_ntdev, S_IFCHR, true},
+ {"/dev/ttyS70", BRACK(FHDEV(DEV_SERIAL_MAJOR, 70)), "\\??\\COM71",
exists_ntdev, S_IFCHR, true},
+ {"/dev/ttyS71", BRACK(FHDEV(DEV_SERIAL_MAJOR, 71)), "\\??\\COM72",
exists_ntdev, S_IFCHR, true},
+ {"/dev/ttyS72", BRACK(FHDEV(DEV_SERIAL_MAJOR, 72)), "\\??\\COM73",
exists_ntdev, S_IFCHR, true},
+ {"/dev/ttyS73", BRACK(FHDEV(DEV_SERIAL_MAJOR, 73)), "\\??\\COM74",
exists_ntdev, S_IFCHR, true},
+ {"/dev/ttyS74", BRACK(FHDEV(DEV_SERIAL_MAJOR, 74)), "\\??\\COM75",
exists_ntdev, S_IFCHR, true},
+ {"/dev/ttyS75", BRACK(FHDEV(DEV_SERIAL_MAJOR, 75)), "\\??\\COM76",
exists_ntdev, S_IFCHR, true},
+ {"/dev/ttyS76", BRACK(FHDEV(DEV_SERIAL_MAJOR, 76)), "\\??\\COM77",
exists_ntdev, S_IFCHR, true},
+ {"/dev/ttyS77", BRACK(FHDEV(DEV_SERIAL_MAJOR, 77)), "\\??\\COM78",
exists_ntdev, S_IFCHR, true},
+ {"/dev/ttyS78", BRACK(FHDEV(DEV_SERIAL_MAJOR, 78)), "\\??\\COM79",
exists_ntdev, S_IFCHR, true},
+ {"/dev/ttyS79", BRACK(FHDEV(DEV_SERIAL_MAJOR, 79)), "\\??\\COM80",
exists_ntdev, S_IFCHR, true},
+ {"/dev/ttyS80", BRACK(FHDEV(DEV_SERIAL_MAJOR, 80)), "\\??\\COM81",
exists_ntdev, S_IFCHR, true},
+ {"/dev/ttyS81", BRACK(FHDEV(DEV_SERIAL_MAJOR, 81)), "\\??\\COM82",
exists_ntdev, S_IFCHR, true},
+ {"/dev/ttyS82", BRACK(FHDEV(DEV_SERIAL_MAJOR, 82)), "\\??\\COM83",
exists_ntdev, S_IFCHR, true},
+ {"/dev/ttyS83", BRACK(FHDEV(DEV_SERIAL_MAJOR, 83)), "\\??\\COM84",
exists_ntdev, S_IFCHR, true},
+ {"/dev/ttyS84", BRACK(FHDEV(DEV_SERIAL_MAJOR, 84)), "\\??\\COM85",
exists_ntdev, S_IFCHR, true},
+ {"/dev/ttyS85", BRACK(FHDEV(DEV_SERIAL_MAJOR, 85)), "\\??\\COM86",
exists_ntdev, S_IFCHR, true},
+ {"/dev/ttyS86", BRACK(FHDEV(DEV_SERIAL_MAJOR, 86)), "\\??\\COM87",
exists_ntdev, S_IFCHR, true},
+ {"/dev/ttyS87", BRACK(FHDEV(DEV_SERIAL_MAJOR, 87)), "\\??\\COM88",
exists_ntdev, S_IFCHR, true},
+ {"/dev/ttyS88", BRACK(FHDEV(DEV_SERIAL_MAJOR, 88)), "\\??\\COM89",
exists_ntdev, S_IFCHR, true},
+ {"/dev/ttyS89", BRACK(FHDEV(DEV_SERIAL_MAJOR, 89)), "\\??\\COM90",
exists_ntdev, S_IFCHR, true},
+ {"/dev/ttyS90", BRACK(FHDEV(DEV_SERIAL_MAJOR, 90)), "\\??\\COM91",
exists_ntdev, S_IFCHR, true},
+ {"/dev/ttyS91", BRACK(FHDEV(DEV_SERIAL_MAJOR, 91)), "\\??\\COM92",
exists_ntdev, S_IFCHR, true},
+ {"/dev/ttyS92", BRACK(FHDEV(DEV_SERIAL_MAJOR, 92)), "\\??\\COM93",
exists_ntdev, S_IFCHR, true},
+ {"/dev/ttyS93", BRACK(FHDEV(DEV_SERIAL_MAJOR, 93)), "\\??\\COM94",
exists_ntdev, S_IFCHR, true},
+ {"/dev/ttyS94", BRACK(FHDEV(DEV_SERIAL_MAJOR, 94)), "\\??\\COM95",
exists_ntdev, S_IFCHR, true},
+ {"/dev/ttyS95", BRACK(FHDEV(DEV_SERIAL_MAJOR, 95)), "\\??\\COM96",
exists_ntdev, S_IFCHR, true},
+ {"/dev/ttyS96", BRACK(FHDEV(DEV_SERIAL_MAJOR, 96)
Re: [PATCH] Cygwin: console: Revive Win7 compatibility.
Takashi Yano writes: > - The commit fca4cda7a420d7b15ac217d008527e029d05758e broke Win7 > compatibility. This patch fixes the issue. > --- > winsup/cygwin/fhandler_console.cc | 10 +- > winsup/cygwin/select.cc | 2 +- > 2 files changed, 6 insertions(+), 6 deletions(-) It seems like an attractor for future bugs to define the same constant in two different places. Would there be a header that could provide the definition instead? Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Wavetables for the Waldorf Blofeld: http://Synth.Stromeko.net/Downloads.html#BlofeldUserWavetables
[PATCH] winsup/cygwin/times.cc (times): follow Linux and allow for a NULL buf argument
Adresses a problem reported on the Cygwin list.
---
winsup/cygwin/times.cc | 17 +++--
1 file changed, 11 insertions(+), 6 deletions(-)
diff --git a/winsup/cygwin/times.cc b/winsup/cygwin/times.cc
index 8908d44f1..909cae1f1 100644
--- a/winsup/cygwin/times.cc
+++ b/winsup/cygwin/times.cc
@@ -72,12 +72,17 @@ times (struct tms *buf)
/* ticks is in in 100ns, convert to clock ticks. */
tc = (clock_t) (ticks.QuadPart * CLOCKS_PER_SEC / NS100PERSEC);
- buf->tms_stime = __to_clock_t (, 0);
- buf->tms_utime = __to_clock_t (, 0);
- timeval_to_filetime (>rusage_children.ru_stime, );
- buf->tms_cstime = __to_clock_t (, 1);
- timeval_to_filetime (>rusage_children.ru_utime, );
- buf->tms_cutime = __to_clock_t (, 1);
+ /* Linux allows a NULL buf and just returns tc in that case, so
+mimic that */
+ if (buf)
+ {
+ buf->tms_stime = __to_clock_t (, 0);
+ buf->tms_utime = __to_clock_t (, 0);
+ timeval_to_filetime (>rusage_children.ru_stime,
);
+ buf->tms_cstime = __to_clock_t (, 1);
+ timeval_to_filetime (>rusage_children.ru_utime,
);
+ buf->tms_cutime = __to_clock_t (, 1);
+ }
}
__except (EFAULT)
{
--
2.23.0
Achim.
--
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+
SD adaptation for Waldorf rackAttack V1.04R1:
http://Synth.Stromeko.net/Downloads.html#WaldorfSDada
Re: [PATCH draft 0/6] Remove the fhandler_base_overlapped class
Achim Gratz writes: > Anything triggering a race or deadlock will depend on so many other > things that it really is no surprise to see seemingly unrelated changes > making the bug appear or disappear. There are certainly races left in > Cygwin, I see them from time to time in various Perl modules, just never > reproducible enough to give anyone an idea of where to look. Ob-T-Shirt: https://vangogh.teespring.com/v3/image/xkM52lFd03VvHZMhNE9BwUpryXE/480/560.jpg :-) Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Factory and User Sound Singles for Waldorf Blofeld: http://Synth.Stromeko.net/Downloads.html#WaldorfSounds
Re: [PATCH draft 0/6] Remove the fhandler_base_overlapped class
Ken Brown writes: > I think I've found the problem. I was mishandling signals that arrived > during a > read. But after I fix that, there's still one nagging issue involving > timerfd > code. I'll write to the main list with details. I *think* it's a timerfd > bug, > but it's puzzling that I only see it when testing my new pipe implementation. Anything triggering a race or deadlock will depend on so many other things that it really is no surprise to see seemingly unrelated changes making the bug appear or disappear. There are certainly races left in Cygwin, I see them from time to time in various Perl modules, just never reproducible enough to give anyone an idea of where to look. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ SD adaptations for Waldorf Q V3.00R3 and Q+ V3.54R2: http://Synth.Stromeko.net/Downloads.html#WaldorfSDada
Re: [rebase PATCH] Introduce --merge-files (-M) flag
Michael Haubenwallner writes: >> Your earlier suggestion of --record, the verb used in the comment quoted >> above >> --update, or CV's suggestion --merge-files would make sense and be more >> descriptive. My reason for using a stronger word (even though enlist apparently calls up the wron connotaions) is that once you've registered (enlisted, enrolled) a library into the database, it'll stay there for all database operations as long the file still exists. There's an implicit contract that the "registration" stays valid for the combined lifetime of the file and the database. Since you cannot (yet) choose a different database, that requires a bit of coordination. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ DIY Stuff: http://Synth.Stromeko.net/DIY.html
Re: Cygwin patches (was Re: [PATCH 00/14] FIFO bug fixes and code simplifications)
Corinna Vinschen writes: >> No testing will be possible for me in the next two weeks, sorry. > > I'll be afk all of March, too. So, the past month? :-D Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ SD adaptation for Waldorf Blofeld V1.15B11: http://Synth.Stromeko.net/Downloads.html#WaldorfSDada
Re: [PATCH 00/14] FIFO bug fixes and code simplifications
Ken Brown writes: >> Take your time and thanks for working in that area. > > I've just sent an attempted fix. There may still be more changes needed; I > just > made a minimal change to make my STC succeed. No testing will be possible for me in the next two weeks, sorry. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Factory and User Sound Singles for Waldorf Q+, Q and microQ: http://Synth.Stromeko.net/Downloads.html#WaldorfSounds
Re: [PATCH 00/14] FIFO bug fixes and code simplifications
Ken Brown writes: > Thanks for testing. I have STCs for fork and exec that I used when first > writing the code, and I forgot to retest those after the recent changes. I > just > tried, and the fork test succeeds but the exec test fails. I'll try to debug > that. Take your time and thanks for working in that area. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Factory and User Sound Singles for Waldorf Q+, Q and microQ: http://Synth.Stromeko.net/Downloads.html#WaldorfSounds
Re: [PATCH 00/14] FIFO bug fixes and code simplifications
Corinna Vinschen writes: > Pushed with v2 of patch 13. Developer snaps should be up shortly. I gave the snapshot some testing today. The good news is that the named FIFO branch of our code works correctly again and is faster than going through pseudo-file STDIO pipes. The bad news is that there is still some problem that seems to hit while forking. I've got an empty stackdump file from sh (which gets used when exec'ing due to the way perl implements that) a few times and also one error message about a terminated thread due to "Windows WFSO error 6" (hilariously the output file was produced correctly in that case). But most of the time the processes in my data pipeline would all have execed correctly, but then none of them ever gets runnable again. So this seems to be something of a race around the exec. If I kill the stalled processes and start the same commands again, then everything works as it should most of the time. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ SD adaptations for KORG EX-800 and Poly-800MkII V0.9: http://Synth.Stromeko.net/Downloads.html#KorgSDada
Re: [PATCH RFC] fork: reduce chances for "address space is already occupied" errors
Corinna Vinschen writes: > Nick Clifton, one of the binutils maintainers, made the following > suggestion in PM: > > Allow the ld flag --enable-auto-image-base to take a filename as > argument. > > The idea: The file is used by ld to generate the start address > for the next built DLL. Mechanism: > > 1.1. If ld links a DLL and if the file given to --enable-auto-image-base > doesn't exist, ld will give the DLL the start address of the > auto image base range. > > 1.2: Next time, if ld links a DLL and if the file given to > --enable-auto-image-base exists, it will use the address in that > file as the start address for th just built DLL. > > 2. It will store that address, plus the size of the DLL, rounded up to >64K, in that file. > > 3. If the auto image base range is at an end, ld will wrap back to >the start address of the auto image base range. Sounds OK if the goal is just to avoid collisions, but it would really be nicer if there was some way to plug this together with the rebase database from the start. > TBD: A way to enable this feature without having to change all > packages' build systems. :-) > That way you could build hundreds of DLLs in a project and use them > immediately without having to rebase. > > This is just in a discussion state, nothing has happend yet, but > what do you think in general? Looking at what triggered the discussion, on would probably want to have the option of giving the linker the name of an existing DLL as the argument and have it re-use that base address (and a warning if the size gets larger than the original DLL plus some guardband). Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Waldorf MIDI Implementation & additional documentation: http://Synth.Stromeko.net/Downloads.html#WaldorfDocs
Re: [rebase PATCH] Introduce --no-rebase flag
Michael Haubenwallner writes: > The --no-rebase flag is to update the database for new files, without > performing a rebase. The file names provided should have been rebased > using the --oblivious flag just before. That name is somewhat strange, how about "--enlist"? Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Wavetables for the Waldorf Blofeld: http://Synth.Stromeko.net/Downloads.html#BlofeldUserWavetables
Re: [PATCH] Cygwin: use win pid+threadid for forkables dirname
Corinna Vinschen writes: > On Apr 12 15:32, Michael Haubenwallner wrote: >> Rather than newest last write time of all dlls loaded, use the forking >> process' windows pid and windows thread id as directory name to create >> the forkable hardlinks into. While this may create hardlinks more >> often, it does avoid conflicts between dlls not having the newest last >> write time. >> --- >> winsup/cygwin/forkable.cc | 26 +++--- >> 1 file changed, 7 insertions(+), 19 deletions(-) > > Pushed. Hmm. Is it safe to use such easily predictable names? Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ SD adaptation for Waldorf Blofeld V1.15B11: http://Synth.Stromeko.net/Downloads.html#WaldorfSDada
Re: [PATCH RFC] fork: reduce chances for "address space is already occupied" errors
Michael Haubenwallner writes: > Well... once installed, a dll may get in use quickly, because I can not > require > to shut down all Cygwin processes. So I need to rebase and register the dll > in > some staging directory before it is installed into it's final directory, hence > I'm about to add some new '--destdir' option. I don't quite understand yet what you're trying to do and why, but "--destdir" doesn't have the right ring to it for my ears. If I'm not mistaken you want to strip the staging prefix from the database entry, which incidentally would be where a make DESTDIR=/staging install would have placed the files? > When I install rebase right within Gentoo Prefix, the rebase db is stored > there > as well, to not cope with host Cygwin's rebase db. Other than cygwin1.dll, no > dll should be used by Gentoo Prefix binaries anyway (except during bootstrap). Since cygwin1.dll is always at a fixed address anyway, then you don't need to do anything extra, I think. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Factory and User Sound Singles for Waldorf Q+, Q and microQ: http://Synth.Stromeko.net/Downloads.html#WaldorfSounds
Re: [PATCH RFC] fork: reduce chances for "address space is already occupied" errors
E. Madison Bray writes: > However, I can see how this could be inconvenient for some Python > builds where you might have something within the setup.py script > (which, when building Python extension modules, is still usually used) > like (in pseudo-code): > > run_build_ext_command() > import just_built_module > # Use just_built_module to generate some files > run_install_command() > > all within the same process. One could work around this by modifying > the setup.py to call `rebase` as a subprocess and that should work, > but it would suck to have to make such extra considerations just for > Cygwin, much less get some upstream project to accept that. Well, Perl has hooks for platform specific code in ExtUtils and Module::Install, so that takes care of 99% of the module builds out there and they seem to have no trouble accepting it into their code as long as you can demonstrate that it woreks and why it's there. I won't touch Python if I can avoid it, so I have no idea what they do; but again, it would seem a glaring omission to not have _something_ that caters to the runtime platform at least. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ SD adaptation for Waldorf rackAttack V1.04R1: http://Synth.Stromeko.net/Downloads.html#WaldorfSDada
Re: [PATCH fifo 0/2] Add support for duplex FIFOs
Achim Gratz writes: > OK, a bit more info: The whole thing runs from a perl script (actually a > module) that opens pipes to gnuplot and ghostscript. This code is > _really_ old and has seen a lot of Cygwin releases, so it has options to > either use temporary files, named pipes aka FIFO or direct pipes. Using > temporary files serializes the execution and using a pipe chain is > _really_ slow (like a hundred times, which is mostly tied up in system > for a reason that I don't understand), so using FIFO is the default. > Your new FIFO code increases the system time by about a factor of 10 in > my tests, btw. So I've finalöly got around to fixing the pipe performance problem by fooling the programs involved to think they are using files: have them reading from /proc/self/fd/0 and writing to /proc/self/fd/1 gives me the same performance as using a named FIFO. Incidentally, that workaround still works when I switch to the 20190402 snapshot, while named FIFO fails as with the older snapshot (as expected), so that seems to take a different code path. Maybe that helps in finding the problem? Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ SD adaptation for Waldorf microQ V2.22R2: http://Synth.Stromeko.net/Downloads.html#WaldorfSDada
Re: [PATCH RFC] fork: reduce chances for "address space is already occupied" errors
Michael Haubenwallner writes: > Before I really can tell what I need regarding the rebase, I need to learn > what > exactly is recorded into the rebase database, and probably how the recorded > data > does influence the rebase procedure right now. Just where the DLL resides in the filesystem, what address it has been rebased to and what size it occupies. If you rebase a new DLL with the database, it will give you the first gap in the address space that this new DLL fits into for doing the rebase and record that into the database. With the --oblivious option, it keeps the database file untouched, so the information about the newly rebased DLL gets lost whenh the program exits. That's why you need to do all oblivious rebasing in a single invocation. > My thoughts so far for what I probably need: > > * First, rebase new dlls before being installed into the target file system > directory with respect to currently installed dlls (the --oblivious > option), You always rebase after the install so that the path information is correct. Pre-rebasing is useless. > * Second, register new dlls just installed into the target file system > directory into the rebase database without performing a rebase, and No, rebasing the installed DLL already does that. > * Third, unregister dlls being removed from the rebase database. Rebase already removes any entries that are no longer accessible from the database. > Also, it may make sense to allow for reusing the base address of an installed > dll by it's update replacement - while the old version dll still is in use and > the new version dll is in some temporary staging directory. Rebase already re-uses the base-address if the path for the new DLL is the same and it still fits into the gap. In general, however, that won't work when the size of any DLL changes. You can ask for more guardband around each entry, but that doesn't actually solve the problem as it's only useful for the initial (full) rebase. > As there may be multiple instances of Gentoo Prefix within one single > operating > system instance, it does not make sense to record the dll's base addresses > into > the rebase database of the underlying Cygwin instance in /etc, but still the > base addresses already recorded there should be respected when rebasing dlls > for within a particular Gentoo Prefix instance. If you can limit the address space that's used by the Cygwin base system, I'd just give your Gentoo prefix installation its own address space and rebase it independently from the base system. That probably requires some fooling around with the (currently hardcoded) rebase database files, but should otherwise just work. > Furthermore, with so called "Stacked Prefix", it is possible to have a second > level of Gentoo Prefix, so what I'm after is some option to tell the rebase > utility which database to record dll base addresses into, and which > multiple(!) > databases take into account while performing a rebase. I don't think you'll want to do that. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Wavetables for the Waldorf Blofeld: http://Synth.Stromeko.net/Downloads.html#BlofeldUserWavetables
Re: [PATCH RFC] fork: reduce chances for "address space is already occupied" errors
Brian Inglis writes:
> On 2019-03-29 14:23, Achim Gratz wrote:
>> Brian Inglis writes:
>>>> If you are packaging your own exes and dlls with your own local Cygwin
>>>> distro,
>>>> you should point to your local utility directory with a path in a file
>>>> under
>>>> /var/lib/rebase/user.d/$USER for each Cygwin userid on each system, or
>>>> perhaps
>>>> you might also need to add your own production exes and dlls into
>>>> /var/cache/rebase/rebase_user and /var/cache/rebase/rebase_user_exe: see
>>>> /usr/share/doc/Cygwin/_autorebase.README.
>
> I was wondering as my first para above stated, whether rebase_user{,_exe}
> would
> be the proper place to add 3rd party Cygwin dlls and exes, that are
> distributed
> with Cygwin (internally)?
Well, if you are distributing something (even just locally), then
preferrably you make proper Cygwin packages and you will never have to
deal with rebase yourself.
The options you allude to above are meant for cases where that just
isn't possible and so you install things without using setup and often
also outside the Cygwin install (permanently, not temporarily until it
gets packaged). You still need to run setup after each change so
autorebase can pick up on it.
Regards,
Achim.
--
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+
SD adaptation for Waldorf rackAttack V1.04R1:
http://Synth.Stromeko.net/Downloads.html#WaldorfSDada
Re: [PATCH RFC] fork: reduce chances for "address space is already occupied" errors
Brian Inglis writes: > Achim, thanks for the clarifications; could you please comment on the > suggested > approach for handling local production dlls and exes, or explain the best > approach for migrating from test to prod and handling rebase on target > systems? I'm not quite sure what you want to know. As I said before oblivious rebase was invented for running tests that use freshly built DLL (I usually package them before running the tests, so the package will have the un-rebased DLL from before the test was run). For this it suffices to simply feed in all new DLL names to rebase. If you were to build in stages and/or combine different builds then you'd somehow have to remember the DLL from each stage or build, or just collect all the DLL names again each time you change something. The important thing is that each oblivious rebase needs to get the list of _all_ DLL that need to get rebased, since the database only knows about the host system (i.e. you can't rebase incrementally with --oblivious). Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ SD adaptation for Waldorf rackAttack V1.04R1: http://Synth.Stromeko.net/Downloads.html#WaldorfSDada
Re: [PATCH fifo 0/2] Add support for duplex FIFOs
Ken Brown writes: > I found a bug in my fhandler_fifo::raw_write code that could explain the > problem. The call to NtWriteFile in that function always returns immediately > because the Windows named pipe underlying the FIFO is non-blocking. If it > can't > write because the pipe buffer is full, raw_write returns -1 with error > EAGAIN. > That's wrong if the FIFO was opened in blocking mode. Sounds like a clue or at least it doesn#t contradict what I'm seeing. I have no idea if that explains all the problems I'm seeing, I'll describe them in more detail below. > I'll have to think about how to best handle this. I think I might be able to > imitate what's done in fhandler_socket_unix::sendmsg in the topic/af_unix > branch. OK, a bit more info: The whole thing runs from a perl script (actually a module) that opens pipes to gnuplot and ghostscript. This code is _really_ old and has seen a lot of Cygwin releases, so it has options to either use temporary files, named pipes aka FIFO or direct pipes. Using temporary files serializes the execution and using a pipe chain is _really_ slow (like a hundred times, which is mostly tied up in system for a reason that I don't understand), so using FIFO is the default. Your new FIFO code increases the system time by about a factor of 10 in my tests, btw. The error with the FIFO to gnuplot is that some data that was written into the FIFO already doesn't show up at the reader end, but later data written into it does. Here somewhere around a few kiB go missing and gnuplot runs into a syntax error when it happens. If I run gnuplot through a plain pipe to skip that error, but keep ghostscript on FIFO, then it _almost_ works correctly. Except that once gnuplot has finished writing to the FIFO I need to write the bookmarks dictionary before closing the output file and that write again overwrites data that should already have been present at the other side. I've played a bit with putting in flushes and sleeps and there's between one to three pages at the end of the document that go missing, so again a handful of KiB. So either of these two errors indiqcates problems with synchronizing the reader/writer side, which makes some of the written data disappear on the receiving end of the FIFO. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Factory and User Sound Singles for Waldorf Q+, Q and microQ: http://Synth.Stromeko.net/Downloads.html#WaldorfSounds
Re: [PATCH fifo 0/2] Add support for duplex FIFOs
Ken Brown writes: >> I'm pretty sure Ken would be happy about an STC. > > Yes, please. Barring that, is there any chance I could see the relevant > code, > or at least enough of it so that I can see how FIFOs are being used? Well, I'm trying -- but got nothing so far. As the individual FIFO seem to work and the error happens pretty early, I think it has something to do with either switching between different FIFO (which the original code does) or some race between fill and drain, possibly around a buffer boundary (in my limited testing it always seemed to happen in the same place for the same data). Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Factory and User Sound Singles for Waldorf rackAttack: http://Synth.Stromeko.net/Downloads.html#WaldorfSounds
Re: [PATCH RFC] fork: reduce chances for "address space is already occupied" errors
Brian Inglis writes: > File list my-dlls.txt is your local test rebase db listing all your > test dlls. I think Michael got confused by your usage of "db" here. This is in fact just a listing of all the DLL to operate on, not the rebase database (which won't be changed at all by an oblivious rebase, only read in order to not collide the new rebase with the already existing ones). > If you are packaging your own exes and dlls with your own local Cygwin distro, > you should point to your local utility directory with a path in a file under > /var/lib/rebase/user.d/$USER for each Cygwin userid on each system, or perhaps > you might also need to add your own production exes and dlls into > /var/cache/rebase/rebase_user and /var/cache/rebase/rebase_user_exe: see > /usr/share/doc/Cygwin/_autorebase.README. What Michael is using is a fairly complex build system that would indeed benefit from a layered rebase database, i.e. the one for the base system providing the substrate for the build system and then at leat on other one that collects the information from inside the build system (maybe even a third layer for tests). How to deal with the complexities of when you want to push information down to a previous layer would likely be a main point of contention, so you'd probably best skip it in the beginning. SHTDI, PTC, etc.pp. With the current rebase, you'll have to use "--oblivious" (which, again, doesn't remember any data for the newly rebased objects) and those non-existing upper layers will have to be provided by side-channel information that the build system has to collect and maintain itself, then feed to the rebase command. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Factory and User Sound Singles for Waldorf rackAttack: http://Synth.Stromeko.net/Downloads.html#WaldorfSounds
Re: [PATCH fifo 0/2] Add support for duplex FIFOs
Corinna Vinschen writes: > Done. I also pushed out new dev snapshots. No good deed goes unpunished… Whith the 20190327 snapshot our main data processing application is broken. It looks like it should almost work, it doesn't crash or anything, but the pipe that delivers a script+data into gnuplot seems to either skip or overwrite data and then gnuplot bails with a syntax error. Depending on exactly which data I try to plot I get the first or first few plots out through the whole processing pipe (that ends in a PDF file), albeit sometimes with incomplete data. Doing each of the steps manually (i.e. writing the gnuplot script into a file, then feed that into gnuplot, then the output from gnuplot inth ghostscript) does work correctly. I have not yet been able to reduce this down to some simpler test case, so I had to roll back to the previous snapshot. I still have it installed on the development system, though. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ SD adaptation for Waldorf rackAttack V1.04R1: http://Synth.Stromeko.net/Downloads.html#WaldorfSDada
Re: [PATCH RFC] fork: reduce chances for "address space is already occupied" errors
Michael Haubenwallner writes: > It will not help for conflicts between dlls within a single package while this > package is built. I'm thinking of python modules built within the python > package > itself, where the just built modules are used within the very build process. > Not > sure if packages using local modules during build also do use fork then, > though. It does help, that's the whole point. But you will have to rebase all the in-processing DLL together, as the database will only have information on the installed DLL. So if you build in stages, you'll need to do something like incremental autorebase does and collect all DLL into some file that you can then feed to rebase -sOT dlls_to_rebase That is slightly less convenient than using the database in persistent mode, but it is much less of a headache when you want to throw things away and start over since you don't need to worry about cruft in the database file. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Wavetables for the Waldorf Blofeld: http://Synth.Stromeko.net/Downloads.html#BlofeldUserWavetables
Re: [PATCH RFC] fork: reduce chances for "address space is already occupied" errors
Michael Haubenwallner writes: > As far as I understand, rebasing is about touching already installed > dlls as well, which would require to restart all Cygwin processes. > As the problem is about some dll built during a larger build job, > this is not something that feels useful to me. That's exactly why I introduced the "--oblivious" option several years ago. It'll let you rebase a set of DLL while benefitting from the rebase database, but not recording them there, so if you later install them properly there will be no collision. I needed this for testing newly compiled Perl XS modules, but you seem to have a similar use case. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Wavetables for the Waldorf Blofeld: http://Synth.Stromeko.net/Downloads.html#BlofeldUserWavetables
Re: [PATCH] default ps -W process start time to system boot time when inaccessible, 0, -1
Brian Inglis writes: > Are there non-startup system processes for which boot time is misleading? > If you need the truth use wmic, procexp64, or run ps in an elevated shell. I don't seem to get my point across. I'm fine with getting no start time value when that ps wasn't able to obtain that information. If we have to use magic values to convey that information for one reason or another, then I'd rather opt for one that is obviously pulled out of thin air than for one that I have to compare to some other stuff before that becomes clear. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Wavetables for the Waldorf Blofeld: http://Synth.Stromeko.net/Downloads.html#BlofeldUserWavetables
Re: [PATCH] default ps -W process start time to system boot time when inaccessible, 0, -1
Corinna Vinschen writes: >> replacing one lie with another that is less easy to spot doesn't sound >> the right thing to do. How about ps if reported "N/A" or something to >> that effect instead? > > 1 Jan 1970 may also be a good hint... Well, that was the point: I can deduce just from that date that ps didn't actually get data for the start time. If it starts replacing this with the start time of the system instead, it might take a while for me to see what is going on. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ SD adaptations for KORG EX-800 and Poly-800MkII V0.9: http://Synth.Stromeko.net/Downloads.html#KorgSDada
Re: [PATCH] default ps -W process start time to system boot time when inaccessible, 0, -1
Hi Brian, replacing one lie with another that is less easy to spot doesn't sound the right thing to do. How about ps if reported "N/A" or something to that effect instead? Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Samples for the Waldorf Blofeld: http://Synth.Stromeko.net/Downloads.html#BlofeldSamplesExtra
[PATCH] Remove some dangerous advice from the FAQ
>From f19ff76eb48e82dcc15fd02bc97a503f1f4a3344 Mon Sep 17 00:00:00 2001 From: Achim Gratz <strom...@stromeko.de> Date: Sat, 2 Sep 2017 16:14:02 +0200 Subject: [PATCH] Remove some dangerous advice from the FAQ --- winsup/doc/faq-setup.xml | 12 1 file changed, 8 insertions(+), 4 deletions(-) diff --git a/winsup/doc/faq-setup.xml b/winsup/doc/faq-setup.xml index 3917f2d30..b242fbae4 100644 --- a/winsup/doc/faq-setup.xml +++ b/winsup/doc/faq-setup.xml @@ -610,16 +610,20 @@ folders that are causing the error. For example, sometimes files used by system services end up owned by the SYSTEM account and not writable by regular users. The quickest way to delete the entire tree if you run into this problem -is to change the ownership of all files and folders to your account. To do +is to take ownership of all files and folders to your account. To do this in Windows Explorer, right click on the root Cygwin folder, choose Properties, then the Security tab. If you are using Simple File Sharing, you will need to boot into Safe Mode to access the Security tab. Select Advanced, then go to the Owner tab and make sure your account is listed as the owner. Select the 'Replace owner on subcontainers and objects' checkbox and press Ok. After Explorer applies the changes you should be able to delete the entire tree -in one operation. Note that you can also achieve this in Cygwin by typing -chown -R user / or by using other tools such as -icacls.exe. +in one operation. Note that you can also achieve by using other tools such as +icacls.exe or directly from Cygwin by using +chown. Please note that you shouldn't use the +recursive form of chown on directories that have other file systems +mounted under them (specifically you must avoid +/proc) since you'd change ownership of the files under those +mount points as well. Delete the Cygwin shortcuts on the Desktop and Start Menu, and -- 2.14.1 Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Wavetables for the Waldorf Blofeld: http://Synth.Stromeko.net/Downloads.html#BlofeldUserWavetables
Re: [PATCH] [base-files] Don't clobber prompt set in /etc/profile.d
Daniel Santos writes: > When I build my own machine, I prefer to set my own default prompt in > /etc/profile.d. This makes it easier on me, but still allows other > users to set whatever prompt they please. This line in bash.bashrc > incorrectly clobbers whatever prompt is set in /etc/profile.d. Wrong list. Also, you shouldn't set any prompt in profile.d. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Waldorf MIDI Implementation & additional documentation: http://Synth.Stromeko.net/Downloads.html#WaldorfDocs
