Just FYI, just to be clear how petty Mr. Faylor is:
I wrote my last email to the mailing list at 06/05/2010 23:16.
I unsubscribed to the cygwin@cygwin.com mailing list and received
success at 06/05/2010 23:26.
I received no further cygwin emails till 06/06/2010 01:26.
At that time, Mr Faylor ad
> I do think out loud with my "team". You are not on it.
Agreed! You would rather spend your time ridiculing any possible solution.
This is what lead to my initial reluctance to do any patch for Cygwin
software.
Good Luck with your inferior product.
Chris
--
Problem reports: http://
> Can't really parse that sentence.
Then load your English parser.
> I haven't detected any "picking on" but then I can't claim to have
> written the fhandler* code anymore Corinna has rewritten most of it. I
> do know that if you want to be taken seriously you really need to send a
> concrete
rther friends (I have
enough). I am doing analysis and looking at code that shows how we can
make great software better. If that's not welcome because of the format
of my emails then I'll stop.
Chris
> On 06/04/2010 03:14 PM, Christopher Wingert wrote:
>> Agreed, I would like
See further down the thread, the right solution is to impact ALL cygwin
executables, but I don't have the experience in the dll to make those
changes.
> On 6/4/2010 2:20 PM, Christopher Faylor wrote:
>>> "But providing a variant of stat() along the lines of what you propose
>>> above is not pract
I actually wrote my own rsync in AutoIt, but it is also limited.
However, I thought it would a nice addition to speed up Cygwin. As I have
been using it for about 10 years and made my transition from Linux to
Windows so pleasant.
> On 4 June 2010 19:50, Eliot Moss wrote:
>> I don't think there'
Agreed, I would like to make a global change, however, unless I can talk
to the current maintainer of the fhandler* functions, it seems illogical
for me to change them (as I have about a week of cygwin dll experience).
Also my interest in performance is limited to a very certain subset of
executab
> [quit top-posting]
Now you are my mom too?
> That's where you're wrong. Any patch you write that is technically
> sound and shows a measurable improvement will most likely be accepted.
Then you shouldn't have Cygwin's front line technical spokesman saying
things such as:
"If there was a way
t have any confidence that the "Cygwin organization" will
accept any patch I write (per Faylor), I really have no incentive to do
the job right.
Chris
> On 6/4/2010 12:37 PM, Christopher Wingert wrote:
>> So here is an example of a performance gain by not using cygwin stat().
>&
So here is an example of a performance gain by not using cygwin stat(). I
did this patch in about an hour (with the help of some git code), so I
wouldn't recommend it for any production use.
On a dry run rsync from my local drive to my NAS (105GB, 34k files, 4k
directories). The current release
> On Thu, Jun 03, 2010 at 05:32:46PM -0700, Christopher Wingert wrote:
> Yeah, that's what I thought you were doing. Given that the timestamps
> don't indicate "elapsed time of function X", it's not always possible to
> figure out how long a functi
> On Thu, Jun 03, 2010 at 10:35:55AM -0700, Christopher Wingert wrote:
>>Using strace I was able to look at some of the functions that are
>>enumerated by debugging calls.
>>
>>The trace below is done by ls.exe for each file (approximately 95k files
>> @
>>
740633 [main] ls 3688 acl_worker: 4 = acl
(/cygdrive/r/dropbox/MS/Dup/original/Dup.csv)
> On Wed, Jun 02, 2010 at 10:46:03AM -0700, Christopher Wingert wrote:
>>Thanks for the pointer, I just gave it a whirl, it actually didn't make
>>much of a difference.
>>
>&
Thanks for the pointer, I just gave it a whirl, it actually didn't make
much of a difference.
I am going to start looking into making a patch.
Chris
> On Jun 1 14:42, Christopher Wingert wrote:
>> I think there are a lot of use cases where the extra information (ACL
>> i
That's fine, can you propose something that is acceptable?
BTW, who does this patch need to pass muster with? The only maintainer I
could find is Dave Korn.
Thanks,
Chris
> On 6/1/2010 5:42 PM, Christopher Wingert wrote:
>> I think there are a lot of use cases where the ext
{
if ( ( strcmp( findData.cFileName, "." ) != 0 ) && ( strcmp(
findData.cFileName, ".." ) != 0 ) )
{
dodir( fname );
}
}
else
{
printf( "%s %d\n", fname, findData.nFileSizeLow );
}
}
w
I assume POSIX compatibility. However, I bet there are cases where one
can sacrifice compatibility for performance (configurable with an
environment flag of course).
See
http://marc.info/?l=git&m=122278284210941
for an example.
> On Sun, May 30, 2010 at 08:54:10AM -0700, Christopher
I was looking into speeding up stat() performance. More specifically
bash, ls, test, stat performance. I've seen the subject come up before.
Git recently implemented a native Win32 work around. Are there any cygwin
patches around?
Thanks,
Chris
--
Problem reports: http://cygwin.com/pr
.
Thanks
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Christopher Wingert wrote:
> I am trying to write a small program that does not pop up a window. I
> found the -mwindow option. It does not pop up a window, but while the
> program is running explorer shows the hour glass busy cur
I am trying to write a small program that does not pop up a window. I
found the -mwindow option. It does not pop up a window, but while the
program is running explorer shows the hour glass busy cursor until the
application ends. I am assuming that explorer is waiting for a window to
appear. Is
I'm building the cygwin source and having a bit of trouble with the
following.
/bin/sh ../../.././winsup/cygwin/speclib
/home/cwingert/cygwin-1.5.24-2/i686-pc-cygwin/winsup/cygwin/libpthread.a
"nm" "ar"
/home/cwingert/cygwin-1.5.24-2/i686-pc-cygwin/winsup/cygwin/libcygwin.a
pthread.o thread.o
in
s umpteen files in the subdirectories.
What about turning this subdirectory parsing off by feeding a -1 in
st_nlink in Cygwin? How could I propose such a change for cygwin?
Thanks again
> According to Christopher Wingert on 3/25/2007 8:35 AM:
> > Hi
> >
> > I have a directo
Hi
I have a directory where there are about 300 subdirectories in it. When I
hit tab, not only is the delay to the "Display all 300 possibilities..."
is slow but the screw draw after answer y is almost like a 300 baud modem.
I've read on these lists about the triple stat issue with cygwin, is th
23 matches
Mail list logo
