On Thu, Jun 03, 2010 at 07:57:31PM -0700, Christopher Wingert wrote:
>>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 ou
On 6/3/2010 8:34 PM, surendar jeyadev wrote:
I have been using Cygwin for about 5 years on the same computer, without
a problem (but for a strange change in bash history behaviour about a few
months back -- more on that later, or in a separate thread). Suddenly,
today, something strange has sta
At 08:57 AM 6/3/2010, Adi B Treiner wrote:
Hello,
After upgrading to version 1.7.5 running cron tasks for normal local
users doesnt work anymore.
For those users cron always reports the following error:
cron.exe: *** fatal error - could not load user32, Win32 error 1114
This seems to be relate
> 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 function takes by subtracting. Subtracting
> timestamps
On Thu, Jun 03, 2010 at 05:32:46PM -0700, Christopher Wingert wrote:
>> 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
> 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
>> @
>>88 mSecs/file), approximately 40 mSecs are
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 @
>88 mSecs/file), approximately 40 mSecs are spent in
Ok. Thanks for the help. I'll give it a try next week when I have access
again to the environment.
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com
On 06/03/2010 03:07 PM, Bill Hoffman wrote:
> Again, I don't think this is git specific, but I would like to
> understand at what level of cygwin this is coming from.
You've got the source code, go debug it if you'd like. But I could care
less about DOS names - either they work or they don't; in
Greetings, Dave Korn!
>> Erm... how about ":type" suffix? Don't know how "POSIXy" it is, but it's
>> close
>> enough to similar functionality of NTFS (file streams).
> To save having the whole discussion again, here's the summary from last time:
> http://www.cygwin.com/ml/cygwin-developers/2006
On 6/3/2010 4:39 PM, Eric Blake wrote:
On 06/03/2010 02:32 PM, Bill Hoffman wrote:
In that case, git is just blindly treating c: as ./c: - that is, the
relative file named "c:" in the current directory. Since POSIX allows
this interpretation, there's no reason for git to special case it and
t
On 2010-06-03 18:04, Larry Hall (Cygwin) wrote:
On 6/3/2010 3:46 AM, Oleksandr Gavenko wrote:
On 2010.06.03 0:39, Eli Zaretskii wrote:
From: Oleksandr Gavenko
Date: Wed, 02 Jun 2010 23:40:46 +0300
I use Emacs 23.2 under Windows.
(call-process
"echo.exe"
nil (get-buffer "*Messages*") nil
"--bl
On 06/03/2010 02:32 PM, Bill Hoffman wrote:
> On 6/3/2010 4:20 PM, Eric Blake wrote:
>> On 06/03/2010 02:03 PM, Bill Hoffman wrote:
>>> Can someone explain why if I use c:/some/path as an argument to git
>>> clone, it fails. But if I use /cygdrive/c/some/path it works.
>>
>> Because c:/some/path l
On 6/3/2010 4:20 PM, Eric Blake wrote:
On 06/03/2010 02:03 PM, Bill Hoffman wrote:
Can someone explain why if I use c:/some/path as an argument to git
clone, it fails. But if I use /cygdrive/c/some/path it works.
Because c:/some/path looks like you are asking for protocol:file for
talking to
On 6/3/2010 4:19 PM, Nasser M. Abbasi wrote:
On 6/3/2010 12:17 PM, Larry Hall (Cygwin) wrote:
On 6/3/2010 3:02 PM, Nasser M. Abbasi wrote:
Should I try building cygwin from sources on my PC?
Debugging it further would certainly be helpful. But if you don't actually
want to build Cygwin fro
On 06/03/2010 02:03 PM, Bill Hoffman wrote:
> Can someone explain why if I use c:/some/path as an argument to git
> clone, it fails. But if I use /cygdrive/c/some/path it works.
Because c:/some/path looks like you are asking for protocol:file for
talking to a remote machine, while /cygdrive/c/som
On 6/3/2010 12:17 PM, Larry Hall (Cygwin) wrote:
On 6/3/2010 3:02 PM, Nasser M. Abbasi wrote:
Should I try building cygwin from sources on my PC?
Debugging it further would certainly be helpful. But if you don't actually
want to build Cygwin from source, you can always use a recent snapsho
Can someone explain why if I use c:/some/path as an argument to git
clone, it fails. But if I use /cygdrive/c/some/path it works.
Here is an example:
GIT_TRACE=1 git clone c:/Users/hoffman/Work/My\
Builds/CMake-gmake/Tests/ExternalProject/LocalRepositories/GIT foobar
trace: built-in: git 'clo
On 6/3/2010 2:56 PM, jayn...@us.ibm.com wrote:
To make sure I'm understanding the implication of your response, let me
summarize...
According to the link you sent, the different user environment is
resulting not because of something that the ssh server (or cygwin) is
doing/configured to do but b
On 6/3/2010 3:02 PM, Nasser M. Abbasi wrote:
Should I try building cygwin from sources on my PC?
Debugging it further would certainly be helpful. But if you don't actually
want to build Cygwin from source, you can always use a recent snapshot with
its source and debugging information as a shor
To make sure I'm understanding the implication of your response, let me
summarize...
According to the link you sent, the different user environment is
resulting not because of something that the ssh server (or cygwin) is
doing/configured to do but because of how Windows handles remote log-ins
On 6/3/2010 12:43 AM, n...@12000.org wrote:
Hello,
SUMMARY:
I installed cygwin 1.7.5 on windows 7 (64 bit OS), and when I run some
command which uses perl, I get the following error:
0 [main] perl 2528 C:\cygwin\bin\perl.exe: *** fatal error - Internal
error: TP_NUM_W_BUFS too small.
Upda
On 6/3/2010 1:40 PM, Yaakov (Cygwin/X) wrote:
Larry Hall (Cygwin) wrote:
On 6/3/2010 3:43 AM, n...@12000.org wrote:
perl-ming 0.4.3-1 Incomplete
That's not right. I'd suggest reinstalling perl-ming.
Perhaps it has something to do with the colons in the
Larry Hall (Cygwin) wrote:
> On 6/3/2010 3:43 AM, n...@12000.org wrote:
> > perl-ming 0.4.3-1 Incomplete
>
> That's not right. I'd suggest reinstalling perl-ming.
Perhaps it has something to do with the colons in the manpage filenames?
Yaakov
--
Problem
On 6/3/2010 12:32 PM, Nasser M. Abbasi wrote:
On 6/3/2010 8:08 AM, Larry Hall (Cygwin) wrote:
On 6/3/2010 3:43 AM, n...@12000.org wrote:
perl-ming 0.4.3-1 Incomplete
That's not right. I'd suggest reinstalling perl-ming.
I did the following:
1. reinstalled.
2. tried different source, downlo
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 @
88 mSecs/file), approximately 40 mSecs are spent in lstat64() and another
47 mSecs are spent in getacl().
It also *looks* lik
Hi,
I would like to use perlMagick.
I installed "perl-Image-Magick" with "setup.exe" but I can't get it work.
What's the trick ?
$ perl -e "use Image::Magick;"
Can't load
'/usr/lib/perl5/vendor_perl/5.10/i686-cygwin/auto/Image/Magick/Magick.dll' for
module Image::Magick: No such file or direc
On 6/3/2010 8:08 AM, Larry Hall (Cygwin) wrote:
On 6/3/2010 3:43 AM, n...@12000.org wrote:
perl-ming 0.4.3-1 Incomplete
That's not right. I'd suggest reinstalling perl-ming.
I did the following:
1. reinstalled.
2. tried different source, downloaded, reinstalled
I still get the same thing,
On 6/3/2010 3:43 AM, n...@12000.org wrote:
perl-ming 0.4.3-1 Incomplete
That's not right. I'd suggest reinstalling perl-ming.
--
Larry Hall http://www.rfk.com
RFK Partners, Inc. (508) 893-9779 - RFK Office
On 6/3/2010 3:46 AM, Oleksandr Gavenko wrote:
On 2010.06.03 0:39, Eli Zaretskii wrote:
From: Oleksandr Gavenko
Date: Wed, 02 Jun 2010 23:40:46 +0300
I use Emacs 23.2 under Windows.
(call-process
"echo.exe"
nil (get-buffer "*Messages*") nil
"--bla" "{rev}" "}}}xxx{1}xxx{2}xxx{{{" )
put in Mess
I quite often notice that when I try to close gnus, which is using
(several instances of) openssl, it appears to hang. Today I for some
reason got so ed off with it, I started closing the processes I
thought belonged to it, starting with the openssl ones. As soon as I
closed the last one, gnus
For example Mercurial VCS hg distributed as python script.
To able invoke hg from cmd.exe (I some times use Far file manager
and all time native GNU Emacs) I wrote wrapper:
$ cat /bin/hg.bat
@echo off
python /bin/hg %*
This script work fine except case then one of argument
contain new line (l
I've updated the version of OpenSSL to 0.9.8o-1. This also includes the
openssl-devel packages.
This is an upstream security release. The Cygwin release is build from
the vanilla sources, no additional patches.
Official release message:
==
PACKAGE DESCRIPTION
===
Homepage: http://mercurial.selenic.com
License : GPL
Distributed, efficient Python based source control system. Mercurial is
designed for efficient handling of very large distributed projects.
CHANGES SINCE LAST RELEASE
==
http://
Quoting n...@12000.org:
Hello,
SUMMARY:
I installed cygwin 1.7.5 on windows 7 (64 bit OS), and when I run some
command which uses perl, I get the following error:
0 [main] perl 2528 C:\cygwin\bin\perl.exe: *** fatal error - Internal
error: TP_NUM_W_BUFS too small.
fyi;
I found this belo
On 2010.06.03 0:39, Eli Zaretskii wrote:
From: Oleksandr Gavenko
Date: Wed, 02 Jun 2010 23:40:46 +0300
I use Emacs 23.2 under Windows.
(call-process
"echo.exe"
nil (get-buffer "*Messages*") nil
"--bla" "{rev}" "}}}xxx{1}xxx{2}xxx{{{" )
put in Message buffer
"--bla rev }
Hello,
SUMMARY:
I installed cygwin 1.7.5 on windows 7 (64 bit OS), and when I run some
command which uses perl, I get the following error:
0 [main] perl 2528 C:\cygwin\bin\perl.exe: *** fatal error - Internal
error: TP_NUM_W_BUFS too small.
DETAILS:
I installed cygwin, all of it on win
37 matches
Mail list logo
