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
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
> rem
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 as
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 ru
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
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 increase
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 fo
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 &
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 so
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/cygw
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,
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 th
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
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
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 cre
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 seem
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/ti
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
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 tha
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 connot
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://Sy
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.
--
+
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 f
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
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:
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+
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
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 ad
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()
> impo
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
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, wh
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
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 wan
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 fu
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 se
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 reba
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 gnuplo
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 pack
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 exac
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 info
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
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
>From f19ff76eb48e82dcc15fd02bc97a503f1f4a3344 Mon Sep 17 00:00:00 2001
From: Achim Gratz
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 --gi
Jon Turney writes:
> I don't think that's particularly heavyweight, and I didn't see
> anything to suggest that PDH query handles can be shared between
> processes, but I'll look into it.
So maybe something to chuck to cygserver when it's running?
Regards,
Achim.
--
+<[Q+ Matrix-12 WAVE#46+305
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.
Warren Young writes:
> The current CGI code that generates the package and file lists for
> http://cygwin.com/packages emits highly redundant HTML, and it is laid
> out using a huge slow-to-render table. The attached patch shows a
> minimal way to use instead of , along with some CSS and JS
> to
46 matches
Mail list logo
