new upstream version and I added the direct SIGHUP of the subshell
on mc exit.
to download
wget \
http://matzeri.altervista.org/cygwin-1.7/mc/mc-4.7.5.3-1-src.tar.bz2 \
http://matzeri.altervista.org/cygwin-1.7/mc/mc-4.7.5.3-1.tar.bz2 \
http://matzeri.altervista.org/cygwin-1.7/mc/setup.hint
Collecting all Corinna reply answers here:
On 7/28/2011 3:08 AM, Corinna Vinschen wrote:
It seems that black was a bad choice for the Cygwin C.
Is there a reason we cannot change it now? I don't see that Red Hat has
filed a US trademark on the logo. Even if they had, it's usually better
On Jul 29 03:14, Warren Young wrote:
Collecting all Corinna reply answers here:
On 7/28/2011 3:08 AM, Corinna Vinschen wrote:
It seems that black was a bad choice for the Cygwin C.
Is there a reason we cannot change it now? I don't see that Red Hat
has filed a US trademark on the logo.
On Jul 29 10:23, Marco atzeri wrote:
wget \
http://matzeri.altervista.org/cygwin-1.7/mc/mc-4.7.5.3-1-src.tar.bz2 \
http://matzeri.altervista.org/cygwin-1.7/mc/mc-4.7.5.3-1.tar.bz2 \
http://matzeri.altervista.org/cygwin-1.7/mc/setup.hint
Uploaded.
Thanks,
Corinna
--
Corinna Vinschen
On Jul 29 11:42, Corinna Vinschen wrote:
On Jul 29 03:14, Warren Young wrote:
We can mix-and-match. We could go for a lone Konsole icon for the
smaller sizes and add the Cygwin C only at larger sizes, for
example. That's one of the freedoms you buy when you include
multiple sizes in a
Warren Young sent the following at Friday, July 29, 2011 10:12 AM
http://etr-usa.com/cygwin/logo/glowing.ico
http://etr-usa.com/cygwin/logo/logo-glowing.ico
On 7/29/2011 9:21 AM, Buchbinder, Barry (NIH/NIAID) [E] wrote:
Warren Young sent the following at Friday, July 29, 2011 10:12 AM
http://etr-usa.com/cygwin/logo/glowing.ico
http://etr-usa.com/cygwin/logo/logo-glowing.ico
I've fixed it so the original URL is correct. (None of the
Couldn't resist doing another. I call this one The Matrix:
http://etr-usa.com/cygwin/logo/matrix.ico
On 29 July 2011 15:11, Warren Young wrote:
On 7/29/2011 3:42 AM, Corinna Vinschen wrote:
On Jul 29 03:14, Warren Young wrote:
Is there official vector logo art I can use?
I don't think so, sorry.
Okay, here's my take:
http://etr-usa.com/cygwin/logo/traced-icon.svg
This should probably
On Jul 29 08:11, Warren Young wrote:
On 7/29/2011 3:42 AM, Corinna Vinschen wrote:
On Jul 29 03:14, Warren Young wrote:
Is there official vector logo art I can use?
I don't think so, sorry.
Okay, here's my take:
http://etr-usa.com/cygwin/logo/traced-icon.svg
[...]
I'm too tired
On Thu, 2011-07-28 at 21:55 +1000, David Billinghurst wrote:
On 27/07/2011 1:11 PM, Yaakov (Cygwin/X) wrote:
Would you be able to update the following packages to exactly these
versions:
gmp-4.3.2
mpfr-3.0.1
mpclib-0.9
ppl-0.11.2
cloog-ppl-0.15.9
Minor bugfixes
On Tue, 2011-07-26 at 22:11 -0500, Yaakov (Cygwin/X) wrote:
Would you be able to update the following packages to exactly these
versions:
gmp-4.3.2
mpfr-3.0.1
mpclib-0.9
ppl-0.11.2
cloog-ppl-0.15.9
Sorry, that needs to be cloog-ppl-0.15.11 in order to build OOTB with
ppl-0.11.x.
Yaakov
Hi Eliot,
On Thu, Jul 28, 2011 at 5:47 PM, Eliot Moss wrote:
Recently I started using startxwin and .XWinrc and am
getting used to -multiwindow mode. Something I have been
wondering is where the program icons actually come from.
For example, I cannot for the life of me find the icons
used
On 7/29/2011 3:16 AM, Csaba Raduly wrote:
Hi Eliot,
On Thu, Jul 28, 2011 at 5:47 PM, Eliot Moss wrote:
Recently I started using startxwin and .XWinrc and am
getting used to -multiwindow mode. Something I have been
wondering is where the program icons actually come from.
For example, I cannot
On Thu, Jul 28, 2011 at 5:47 PM, Eliot Moss wrote:
Recently I started using startxwin and .XWinrc and am
getting used to -multiwindow mode. Something I have been
wondering is where the program icons actually come from.
For example, I cannot for the life of me find the icons
used for xemacs
Thanks for the tip about .xpm files!
-- Eliot
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://x.cygwin.com/docs/
FAQ: http://x.cygwin.com/docs/faq/
CVSROOT:/cvs/src
Module name:src
Changes by: cori...@sourceware.org 2011-07-29 11:45:16
Modified files:
winsup/w32api : ChangeLog
winsup/w32api/include: winsock2.h
Log message:
* include/winsock2.h (SIO_UDP_CONNRESET): Define.
Patches:
CVSROOT:/cvs/src
Module name:src
Changes by: cori...@sourceware.org 2011-07-29 12:47:54
Modified files:
winsup/cygwin : ChangeLog fhandler_socket.cc net.cc select.cc
Log message:
Throughout change WinSock to Winsock in comments.
* fhandler_socket.cc
Could you spin a new snapshot? I'm having problems with CVS HEAD and
I'm trying to figure out if the problem is with GCC or with Cygwin.
Thanks,
Yaakov
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation:
-Original Message-
From: Christopher Faylor
Subject: Re: Device names in /proc/mounts
The drive letters above could be anything that
Windows maps to a drive letter. A drive does not necessarily
directly map to a physical device.
That's why the proposal suggests using /dev/sdXY
Hello jojelino,
I just rebuild cygwin1.dll latest snapshot.
I believe the attached patch workarounds delayed wait_sig problem.
Yes - it works fine!
This yielded speed improvement. i ran your testcase and same timestamp
recorded 35. approx 2x speed.
On Jul 29 09:45, Schwarz, Konrad wrote:
From: Christopher Faylor
We're not
going to introduce this level of recursive confusion to the
mount table handling.
The proposal is sound. It works on Linux, after all.
Ok, so I assume Cygwin should be able to load Linux kernel modules
and
On Jul 29 08:43, Heiko Elger wrote:
Hello jojelino,
I just rebuild cygwin1.dll latest snapshot.
I believe the attached patch workarounds delayed wait_sig problem.
Yes - it works fine!
This yielded speed improvement. i ran your testcase and same timestamp
recorded 35. approx 2x
On Jul 29 02:04, Yaakov (Cygwin/X) wrote:
Could you spin a new snapshot? I'm having problems with CVS HEAD and
I'm trying to figure out if the problem is with GCC or with Cygwin.
Hang on, please. I'm just looking into a socket problem which needs
some more debugging. I will probably apply
On 2011-07-29 오후 6:26, Corinna Vinschen wrote:
I've already recognize one positive side effect:
The CTRL-C Handler works now even faster.
With unpatched cygwin1.dll there was a realy long delay, after pressing CTRL-C.
Can you agree this too?
I agree sincerely.
The slowdown of the code was
Version 4.7.5.3-1 of Midnight Commander
has been uploaded for cygwin
CHANGES
This is an new upstream release.
For the full upstream changes
http://www.midnight-commander.org/wiki/NEWS-4.7.5.3
CYGWIN CHANGES
The closure of the subshell is now handled.
DESCRIPTION
GNU Midnight Commander is a
On 7/28/11 12:24 PM, Larry Hall (Cygwin) wrote:
On 7/28/2011 3:01 PM, Ed wrote:
Quite often when I open a Cygwin session when it runs a .bashrc script it
will show errors of basic commands not found. For example pwd or ls returns
command not found when I type it at the command prompt.
Hello,
Corinna Vinschen writes:
The slowdown of the code was the result of a patch which was supposed
to fix a potential race condition. Jojelino's patch looks nice, but
it might reintroduce a new race. Handle with care.
Oops - what king of race condition do you mean.
OK - that's a new
On Fri, Jul 29, 2011 at 12:52:47PM +, Heiko Elger wrote:
Hello,
Corinna Vinschen writes:
The slowdown of the code was the result of a patch which was supposed
to fix a potential race condition. Jojelino's patch looks nice, but
it might reintroduce a new race. Handle with care.
Oops -
Can you answer the following question:
Given a volume label, how does one figure out where the
corresponding
volume has been mounted into the Cygwin namespace?
We're not mounting volumes, we're mounting Win32 paths.
There is no direct correspondence between volumes and Cygwin
On 7/28/2011 4:03 PM, Daniel Colascione wrote:
On 7/28/11 12:24 PM, Larry Hall (Cygwin) wrote:
On 7/28/2011 3:01 PM, Ed wrote:
Quite often when I open a Cygwin session when it runs a .bashrc script it
will show errors of basic commands not found. For example pwd or ls returns
command not
On 7/29/2011 3:28 AM, Voelker, Bernhard wrote:
I'm experiencing windows time (which is right) being constantly
10-12 minutes behind GNU's time:
$ cmd.exe /c time /t ; /bin/date
09:21
Fri Jul 29 09:33:22 WEDT 2011
I've seens this for several weeks on this PC now.
Why is that? If it
* Voelker, Bernhard (Fri, 29 Jul 2011 09:28:42 +0200)
I'm experiencing windows time (which is right) being constantly 10-12
minutes behind GNU's time:
$ cmd.exe /c time /t ; /bin/date
09:21
Fri Jul 29 09:33:22 WEDT 2011
I've seens this for several weeks on this PC now.
Why is
The code below appears to have incorrect behavior. The output is:
$ ./a.exe
Enter Testcase - ./a
Create/start threads
Thread 009e0290 : Entered
Thread 009f0320 : Entered
Thread 009f03a8 : Entered
Thread 18dbce64 : INITIALIZE RESOURCE
Wait for the threads to
On 07/29/2011 10:59 AM, Jan Chludzinski wrote:
The code below appears to have incorrect behavior. The output is:
Compile with -Wall.
Thread 00a104f8 002a: The resource is 0
printf(Thread %.8x %.8x: resource is %d\n,
pthread_self(), resource);
Three uses of %, but only
Don't know why all the white space in the code turned intro ?.
Hopefully this is better:
#include pthread.h
#include stdio.h
#include stdlib.h
#include unistd.h
#define checkResults(string, val) { \
if (val) { \
printf(Failed with %d at %s,
Thanks!
This is an example (from IBM) I cut-and-paste into Emacs to better
understand pthread_once(...). Didn't notice the two %.8x in
printf().
Thanks again, Jan
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation:
Can't blame IBM either. I had to replace pthread_getthreadid_np() (in
the IBM example code) with pthread_self() because Cygwin doesn't
support/have pthread_getthreadid_np().
And the IBM docs say pthread_getthreadid_np() returns a structure
containing the hi and low order 4 bytes of the 64bit ID.
With the 20110729 snapshot (and some earlier ones), the following
command terminates early.
% find /proc/registry/HKEY_LOCAL_MACHINE/SYSTEM/CurrentControlSet/services
-maxdepth 1 -print
strace lists an exception: exception C005 at 6100296A. This is
occurring for me in both Win7 x64
Hello,
For every shell code that I write, I'd like it to be portable both to Cygwin
on Windows, and to Ubuntu Linux for example.
It's kinda possible, but am blocked with such a use case:
alias vpnup='exec sudo openvpn --config ~/config/client.vpn --writepid
/tmp/openvpn.pid '
While this
Is there any specific reason why socklen_t on cygwin is int instead of
uint32_t, like it is on Linux?
--
Eric Blake ebl...@redhat.com+1-801-349-2682
Libvirt virtualization library http://libvirt.org
--
Problem reports: http://cygwin.com/problems.html
FAQ:
On 7/29/2011 9:42 AM, Sebastien Vauban wrote:
snip
Here, I cd first to my config file, as I removed full paths from client.vpn
config file:
snip
I'm aware of cygpath, but still don't see clearly which are the best trade-off
to be able to write portable shell code -- if possible. Any hint?
Another way to be portable is to have per-system files
to set up some environment variables and then uniform
portable files that use them. You can do that same
thing *within* a file by writing conditionals or a
case on the result of uname. It's probably best to
segregate per-system stuff in a
On Jul 29 15:34, Schwarz, Konrad wrote:
Can you answer the following question:
Given a volume label, how does one figure out where the
corresponding
volume has been mounted into the Cygwin namespace?
We're not mounting volumes, we're mounting Win32 paths.
There is no
On Jul 29 15:42, Sebastien Vauban wrote:
Hello,
For every shell code that I write, I'd like it to be portable both to Cygwin
on Windows, and to Ubuntu Linux for example.
It's kinda possible, but am blocked with such a use case:
alias vpnup='exec sudo openvpn --config ~/config/client.vpn
On Jul 29 13:29, Jan Chludzinski wrote:
Can't blame IBM either. I had to replace pthread_getthreadid_np() (in
the IBM example code) with pthread_self() because Cygwin doesn't
support/have pthread_getthreadid_np().
pthread_getthreadid_np is a non-standard IBM extension. You won't find
it in
On Jul 29 11:58, David Rothenberger wrote:
With the 20110729 snapshot (and some earlier ones), the following
command terminates early.
% find /proc/registry/HKEY_LOCAL_MACHINE/SYSTEM/CurrentControlSet/services
-maxdepth 1 -print
strace lists an exception: exception C005 at 6100296A
On Jul 29 13:30, Eric Blake wrote:
Is there any specific reason why socklen_t on cygwin is int instead
of uint32_t, like it is on Linux?
Other than history? No, I don't think so. But I also don't think
it's worth the effort. All the underlying Windows functions typically
use int rather than
Schwarz, Konrad sent the following at Friday, July 29, 2011 9:34 AM
Given a volume label, how does one figure out where the
corresponding
volume has been mounted into the Cygwin namespace?
We're not mounting volumes, we're mounting Win32 paths.
There is no direct correspondence between
On Fri, 2011-07-29 at 22:23 +0200, Corinna Vinschen wrote:
On Jul 29 13:30, Eric Blake wrote:
Is there any specific reason why socklen_t on cygwin is int instead
of uint32_t, like it is on Linux?
Other than history? No, I don't think so. But I also don't think
it's worth the effort.
On Fri, 2011-07-29 at 22:21 +0200, Corinna Vinschen wrote:
On Jul 29 11:58, David Rothenberger wrote:
With the 20110729 snapshot (and some earlier ones), the following
command terminates early.
% find /proc/registry/HKEY_LOCAL_MACHINE/SYSTEM/CurrentControlSet/services
-maxdepth 1
On 7/29/2011 3:36 PM, Yaakov (Cygwin/X) wrote:
On Fri, 2011-07-29 at 22:21 +0200, Corinna Vinschen wrote:
On Jul 29 11:58, David Rothenberger wrote:
With the 20110729 snapshot (and some earlier ones), the following
command terminates early.
% find /proc/registry/HKEY_LOCAL_MACHINE/SYSTEM
On Fri, Jul 29, 2011 at 10:15:56PM +0200, Corinna Vinschen wrote:
On Jul 29 15:34, Schwarz, Konrad wrote:
Can you answer the following question:
Given a volume label, how does one figure out where the
corresponding
volume has been mounted into the Cygwin namespace?
We're not
Starting program: /usr/bin/find
/proc/registry/HKEY_LOCAL_MACHINE/SYSTEM/CurrentControlSet/services
-maxdepth 1 -print
[New Thread 4648.0xd38]
warning: section .gnu_debuglink not found in
/cygdrive/d/cygwin/bin/cygwin1.dbg
[New Thread 4648.0x16d8]
Breakpoint 9, fhandler_base::operator=
On Fri, Jul 29, 2011 at 03:41:46PM -0700, David Rothenberger wrote:
On 7/29/2011 3:36 PM, Yaakov (Cygwin/X) wrote:
On Fri, 2011-07-29 at 22:21 +0200, Corinna Vinschen wrote:
On Jul 29 11:58, David Rothenberger wrote:
With the 20110729 snapshot (and some earlier ones), the following
command
Version 4.7.5.3-1 of Midnight Commander
has been uploaded for cygwin
CHANGES
This is an new upstream release.
For the full upstream changes
http://www.midnight-commander.org/wiki/NEWS-4.7.5.3
CYGWIN CHANGES
The closure of the subshell is now handled.
DESCRIPTION
GNU Midnight Commander is a
56 matches
Mail list logo
