On 8/4/2011 3:59 AM, texas salsa wrote:
Nothing in the above indicates that there is a problem in wait_sig.
The delta times in an strace do not mean "This is how long an operation
took". They just indicate the number of microseconds since the last
update to strace output.
What the above says i
On 8/4/2011 1:09 AM, Eric Blake wrote:
A while ago, I tested pipe() for EMFILE failures [1]. Well, I repeated
those tests for socketpair() [2], and cygwin is once again the odd man out.
[1] http://cygwin.com/ml/cygwin/2011-06/msg00328.html
[2] http://austingroupbugs.net/view.php?id=483
$ cat fo
On Wed, Aug 03, 2011 at 11:31:54PM -0500, Yaakov (Cygwin/X) wrote:
>On Wed, 2011-08-03 at 21:33 -0500, Yaakov (Cygwin/X) wrote:
>> I'm working on /proc/devices, but upon comparing to Linux[1], I
>> noticed some differences in character device numbering:
>>
>> * /dev/tty
>> Linux is 5,0, Cygwin is
On Wed, 2011-08-03 at 21:33 -0500, Yaakov (Cygwin/X) wrote:
> I'm working on /proc/devices, but upon comparing to Linux[1], I
> noticed some differences in character device numbering:
>
> * /dev/tty
> Linux is 5,0, Cygwin is 3,0
>
> * /dev/tty[N]
> Linux is 4,[N], Cygwin 136,N (major 136 is /dev/
On Wed, Aug 03, 2011 at 09:33:32PM -0500, Yaakov (Cygwin/X) wrote:
>I'm working on /proc/devices, but upon comparing to Linux[1], I
>noticed some differences in character device numbering:
>
>* /dev/tty
>Linux is 5,0, Cygwin is 3,0
You're using a snapshot. After my pty reorg, Cygwin, probably
err
I'm working on /proc/devices, but upon comparing to Linux[1], I
noticed some differences in character device numbering:
* /dev/tty
Linux is 5,0, Cygwin is 3,0
* /dev/tty[N]
Linux is 4,[N], Cygwin 136,N (major 136 is /dev/pts/N on Linux)
* /dev/console
Linux is 5,1, Cygwin is 3,0 (same as /dev/tt
> Nothing in the above indicates that there is a problem in wait_sig.
> The delta times in an strace do not mean "This is how long an operation
> took". They just indicate the number of microseconds since the last
> update to strace output.
>
> What the above says is:
>
> 1) wait_sig is about to c
On 3 August 2011 15:44, Yaakov (Cygwin/X) wrote:
> On Wed, 2011-08-03 at 06:33 -0400, Chris Sutcliffe wrote:
>> Passing '--with-python=/usr/bin/python' as opposed to messing with
>> CPPFLAGS, etc. might be easier. I just recently built if for MinGW
>> and specifying the python interpreter in '--wi
A while ago, I tested pipe() for EMFILE failures [1]. Well, I repeated
those tests for socketpair() [2], and cygwin is once again the odd man out.
[1] http://cygwin.com/ml/cygwin/2011-06/msg00328.html
[2] http://austingroupbugs.net/view.php?id=483
$ cat foo.c
#define _POSIX_C_SOURCE 200811L
#d
On 8/3/2011 5:36 PM, Eliot Moss wrote:
> Yes; but to use Oracle (or other Windows-based) JVMs mostly
> requires setting PATH and CLASSPATH properly. Most particularly,
> CLASSPATH needs to be in Windows format (';' separator, not ':',
> and \ in file/directory paths, not /). This mostly requires
>
On 8/3/2011 4:05 PM, Yaakov (Cygwin/X) wrote:
On Wed, 2011-08-03 at 09:58 -0400, Larry W. Virden wrote:
Cygwin Ports provides a Java environment based on JamVM and GNU
Classpath, which includes Ant, ECJ, OpenJDK langtools (apt, javac,
javah, javadoc, javap), Java-GNOME programs, fop, and sever
On 8/3/2011 1:32 PM, David Rothenberger wrote:
> On 8/3/2011 1:19 PM, Corinna Vinschen wrote:
>> Other than that I don't have an answer for you. There's only
>> so much you can do within the 32 bit address space. That's only one
>> reason why a 64 bit Cygwin would be a good idea.
>
> What was th
On 8/3/2011 1:19 PM, Corinna Vinschen wrote:
> On Aug 3 15:02, Yaakov (Cygwin/X) wrote:
>> On Wed, 2011-08-03 at 21:03 +0200, Corinna Vinschen wrote:
>>> Better drop the large address stuff for now. Since the heap is now in
>>> the large addres area(*), and since mmaps will go there, too(*), we h
On Aug 3 22:19, Corinna Vinschen wrote:
> On Aug 3 15:02, Yaakov (Cygwin/X) wrote:
> > On Wed, 2011-08-03 at 21:03 +0200, Corinna Vinschen wrote:
> > > Better drop the large address stuff for now. Since the heap is now in
> > > the large addres area(*), and since mmaps will go there, too(*), we
On Aug 3 15:02, Yaakov (Cygwin/X) wrote:
> On Wed, 2011-08-03 at 21:03 +0200, Corinna Vinschen wrote:
> > Better drop the large address stuff for now. Since the heap is now in
> > the large addres area(*), and since mmaps will go there, too(*), we have
> > basically a lot more free space in the a
On Wed, 2011-08-03 at 09:58 -0400, Larry W. Virden wrote:
> Also, we have some java developers who have commented in the past that
> trying to start, manage, and stop java processes were more difficult
> in cygwin than using other similar toolsets (which live purely in the
> windows process model).
On Wed, 2011-08-03 at 21:03 +0200, Corinna Vinschen wrote:
> Better drop the large address stuff for now. Since the heap is now in
> the large addres area(*), and since mmaps will go there, too(*), we have
> basically a lot more free space in the area up to 0x7fff.
At this moment, I've got DL
On Wed, 2011-08-03 at 06:33 -0400, Chris Sutcliffe wrote:
> On 2 August 2011 03:44, Yaakov (Cygwin/X) wrote:
> > If I may, based on looking at configure, you'll need libpython2.6.dll.a
> > in $sysroot/usr/lib and the Python headers in
> > $sysroot/usr/include/python2.6, and add -I$sysroot/usr/incl
On Aug 3 11:40, David Rothenberger wrote:
> On 8/3/2011 11:02 AM, Christopher Faylor wrote:
> > It actually wasn't a SIGSEGV. It really was a strange rebase error.
> > Unfortunately, the error was silent both to the standard output and,
> > more irritatingly, to strace. I've checked in changes w
On 8/3/2011 11:02 AM, Christopher Faylor wrote:
> On Wed, Aug 03, 2011 at 10:00:13AM -0400, Christopher Faylor wrote:
>> On Wed, Aug 03, 2011 at 09:45:28AM -0400, Christopher Faylor wrote:
>>> On Wed, Aug 03, 2011 at 10:44:27AM +0200, Corinna Vinschen wrote:
On Aug 2 10:58, David Rothenberger
On Wed, Aug 03, 2011 at 10:00:13AM -0400, Christopher Faylor wrote:
>On Wed, Aug 03, 2011 at 09:45:28AM -0400, Christopher Faylor wrote:
>>On Wed, Aug 03, 2011 at 10:44:27AM +0200, Corinna Vinschen wrote:
>>>On Aug 2 10:58, David Rothenberger wrote:
I use git-svn extensively in my day-to-day
On 21:59, Larry Hall (Cygwin) wrote:
On 8/2/2011 7:32 AM, Alexey Luchko wrote:
Cygwin Configuration Diagnostics atteched.
>
> Maybe crank up the debugging flags to maximum? I assume sshd is still
> stopped from your last run of sshd -d. If that doesn't sound right to
> you, you may want to inve
> * Eliot Moss (Tue, 02 Aug 2011 11:40:44 -0400)
> > On 8/2/2011 8:24 AM, Sebastien Vauban wrote:
> > > Thorsten Kampe wrote:
> > >> * Sebastien Vauban (Mon, 01 Aug 2011 08:46:52 +0200)
> > >>> My goal is to have just 1 alias that would work both under Win32
> > >>> (Cygwin) and Ubuntu
> > >>
> > >
On Wed, Aug 03, 2011 at 04:56:05PM +0200, Corinna Vinschen wrote:
>Is git-svn using perl?
Yes, very heavily. Setting CYGWIN_DEBUG=perl filled my screen with gdb
windows.
>I have constant problems using perl after a rebase. The problem starts
>with perl.exe(!) being rebased(!) to 0x5000(!).
> On 6/6/2011 9:01 AM, Andrew Schulman wrote:
> > Am I right that bzr is just completely broken in Cygwin? If so, is there
> > an ETA to get it fixed?
> >
> > My bzr is 2.3.1-1, in Cygwin 1.7.9. No matter what bzr command I run, I
> > always get the same result:
>
> As a quick workaround, you c
> On Aug 3 10:48, Henry S. Thompson wrote:
> > Corinna Vinschen writes:
> >
> > > . . .
> >
> > > We're working on a new release of rebase anyway. This new release
> > > checks for writability and prints just a warning without stopping
> > > dead in its track:
> > >
> > > /usr/bin/foo.dll: sk
On Aug 3 16:56, Corinna Vinschen wrote:
> On Aug 3 10:00, Christopher Faylor wrote:
> > Huh. I ran rebaseall before reporting the above but, on inspecting the
> > output from strace, I saw that dlls were getting located in non-rebased
> > locations. So, I ran rebaseall again. *Now* I see the h
On Aug 3 09:22, Jason Tishler wrote:
> On Wed, Aug 03, 2011 at 01:52:21PM +0200, Corinna Vinschen wrote:
> > On Aug 3 12:29, Jon TURNEY wrote:
> > > On 03/08/2011 08:49, Corinna Vinschen wrote:
> > > >[snip]
> > > >
> > > >Can you have a look and, perhaps, provide a new python with a bigger
> > >
On Aug 3 10:00, Christopher Faylor wrote:
> On Wed, Aug 03, 2011 at 09:45:28AM -0400, Christopher Faylor wrote:
> >On Wed, Aug 03, 2011 at 10:44:27AM +0200, Corinna Vinschen wrote:
> >>On Aug 2 10:58, David Rothenberger wrote:
> >>> I use git-svn extensively in my day-to-day work, and I noticed w
On Wed, Aug 03, 2011 at 09:45:28AM -0400, Christopher Faylor wrote:
>On Wed, Aug 03, 2011 at 10:44:27AM +0200, Corinna Vinschen wrote:
>>On Aug 2 10:58, David Rothenberger wrote:
>>> I use git-svn extensively in my day-to-day work, and I noticed with
>>> recent snapshots that some of the git-svn c
I work in an environment where we have been using cygwin 1.5 and
cygwin/X (along with xterm, mintty, and putty) on a variety of Windows
XP desktops, as well as an older cygwin 1.7, cygwin/X, and a variety
of pretty traditional packages on development XP desktops.
Now we are considering creating a
On Wed, Aug 03, 2011 at 10:44:27AM +0200, Corinna Vinschen wrote:
>On Aug 2 10:58, David Rothenberger wrote:
>> I use git-svn extensively in my day-to-day work, and I noticed with
>> recent snapshots that some of the git-svn commands are hanging. I
>> narrowed it down to the 20110721 snapshot. 201
On Wed, Aug 03, 2011 at 01:52:21PM +0200, Corinna Vinschen wrote:
> On Aug 3 12:29, Jon TURNEY wrote:
> > On 03/08/2011 08:49, Corinna Vinschen wrote:
> > >[snip]
> > >
> > >Can you have a look and, perhaps, provide a new python with a bigger
> > >internal FD_SETSIZE? The 256 from /usr/include/py
On Wed, Aug 03, 2011 at 04:44:29PM +0900, texas salsa wrote:
>
>Hello there,
>
>I use Cygwin to do some complex text processing jobs using shell scripts on
>Thinkpad X200s Windows XP sp3. It had worked fine before but at some point I
>noticed the job started to take much time to complete. It is t
On Aug 3 12:29, Jon TURNEY wrote:
> On 03/08/2011 08:49, Corinna Vinschen wrote:
> >Hi Jason,
> >
> >it looks like there's a build glitch in python:
> >
> > $ cat> sel.py< > from socket import *
> > from select import select
> >
> > ins = []
> >
> > for i in range(1024):
> > s = s
On 03/08/2011 08:49, Corinna Vinschen wrote:
Hi Jason,
it looks like there's a build glitch in python:
$ cat> sel.py<
select(ins, [], [], 0)
ValueError: filedescriptor out of range in select()
I debugged this and it turns out that python does not call Cygwin's
select function any
On Aug 3 12:04, Reini Urban wrote:
> 2011/8/3 Corinna Vinschen:
> > $ python sel.py
> > socket opened with fd 3
> > socket opened with fd 4
> > socket opened with fd 5
> > [...]
> > socket opened with fd 62
> > socket opened with fd 63
> > socket opened with fd 64
> > socket opened with f
On Aug 3 10:48, Henry S. Thompson wrote:
> Corinna Vinschen writes:
>
> > . . .
>
> > We're working on a new release of rebase anyway. This new release
> > checks for writability and prints just a warning without stopping
> > dead in its track:
> >
> > /usr/bin/foo.dll: skipped because not wr
On 2 August 2011 03:44, Yaakov (Cygwin/X) wrote:
> On Sun, 2011-07-31 at 13:59 -0400, Christopher Faylor wrote:
>> As usual, I forgot an item of news that I wanted to impart a second
>> after hitting 'y'. For those who follow this type of thing, gdb now has
>> a python scripting interface. That
2011/8/3 Corinna Vinschen:
> $ python sel.py
> socket opened with fd 3
> socket opened with fd 4
> socket opened with fd 5
> [...]
> socket opened with fd 62
> socket opened with fd 63
> socket opened with fd 64
> socket opened with fd 64
> Traceback (most recent call last):
> File "te
Corinna Vinschen writes:
> . . .
> We're working on a new release of rebase anyway. This new release
> checks for writability and prints just a warning without stopping
> dead in its track:
>
> /usr/bin/foo.dll: skipped because not writable
> Otherwise, what we can do is to open the file with
On Aug 2 10:58, David Rothenberger wrote:
> I use git-svn extensively in my day-to-day work, and I noticed with
> recent snapshots that some of the git-svn commands are hanging. I
> narrowed it down to the 20110721 snapshot. 20110713 is the last one
> that works fine.
>
> I realize this isn't exa
On 8/3/2011 9:44 AM, texas salsa wrote:
Hello there,
I use Cygwin to do some complex text processing jobs using shell scripts on
Thinkpad X200s Windows XP sp3. It had worked fine before but at some point I
noticed the job started to take much time to complete. It is taking about ten
times pe
On Wed, 2011-08-03 at 09:06 +0200, Corinna Vinschen wrote:
> > * Opening multiple VTE-based terminals (gnome-terminal, Xfce Terminal,
> > etc.), or even one after a mintty terminal is already open, produces the
> > following message when starting a bash login shell:
> >
> > > -bash: cannot set ter
Hi Jason,
it looks like there's a build glitch in python:
$ cat > sel.py <
select(ins, [], [], 0)
ValueError: filedescriptor out of range in select()
I debugged this and it turns out that python does not call Cygwin's
select function anymore, as soon as there's a file descriptor in the
On Aug 2 15:25, Andrew Schulman wrote:
> > On Aug 2 10:07, Andrew Schulman wrote:
> > > > >> > $ rebaseall
> > > > >> > ReBaseImage (/usr/bin/cygcrypt-0.dll) failed with last error = 6
> > > [...]
> >
> > chmod u+w /usr/bin/cygcrypt-0.dll
> >
> > ?
>
> Uh... yes.
>
> Thanks. It works now. A
On Aug 3 01:01, Yaakov (Cygwin/X) wrote:
> I am having the following issues with the 20110801 snapshot:
>
> * Previously I had my DLLs rebased from 0x8000 up, but now, all
> fork() calls failed until I rebased from 0x down.
Yes, that was to be expected. Sorry about that. However, s
47 matches
Mail list logo
