cygrunsrv package missing in setup-x86_64

2013-10-31 Thread Bob Stayton 
I'm running Windows 8 64-bit, and I would like to use cygrunsrv.  However, 
that package is missing under the Admin category in setup-x86_64.exe version 
2.830 (64 bit).  It shows up under setup-x86.exe (32 bit).


Bob Stayton
Sagehill Enterprises
b...@sagehill.net 



--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: Problem with multiprocessing module from Python

2013-10-31 Thread Christopher Faylor 
On Thu, Oct 31, 2013 at 10:59:11PM -0400, Christopher Faylor wrote:
>On Thu, Oct 31, 2013 at 08:47:58PM +, Jean-Pierre Flori wrote:
>>Le Thu, 31 Oct 2013 14:41:14 -0400, Christopher Faylor a ??crit??:
>>
>>> On Thu, Oct 31, 2013 at 06:27:39PM +, Jean-Pierre Flori wrote:
Le Wed, 30 Oct 2013 10:33:13 +0100, Corinna Vinschen a ??crit??:

> On Oct 29 21:22, Jean-Pierre Flori wrote:
>> Le Tue, 29 Oct 2013 21:19:14 +, Jean-Pierre Flori a ??crit??:
>> 
>> > Le Tue, 29 Oct 2013 16:59:35 -0400, Christopher Faylor a ??crit??:
>> >> If you want this fixed, the easiest way to get that to happen is
>> >> to post a simple test case which reproduces the problem.  That is
>> >> not the code snippet that you sent.  A real working example would
>> >> be required.
>> > Sorry about that.
>> > 
>> > Here you go:
>> > """
>> > from multiprocessing import Pool
>> > 
>> > def f(x): return x
>> > 
>> > p = pool(2)
>> > 
>> > p.map(f, [1, 2])
>> > """
>> And I managed to introduce a typo. The third line should read Pool,
>> so it is:
>> """
>> from multiprocessing import Pool
>> 
>> def f(x): return x
>> 
>> p = Pool(2)
>> 
>> p.map(f, [1, 2])
>> """
> 
> Works for me.  I guess.  At least, if I run the script, nothing
> happens:
> 
>   $ python x.py $
> 
> Same on 32 and 64 bit Cygwin.
> 
> 
> Corinna

I think I got to the bottom of this.
It seems the new implem of sem_getvalue in cgwin1.dll is the cause, see:
http://cygwin.com/ml/cygwin-patches/2013-q3/msg6.html It may also
explain the random reproducibility if sval stays uninitialized or
something like that (I did not check it is the case though).
>>> 
>>> I doubt that was the problem.  More likely it is something related to
>>> the changes in thread.cc that followed that change.
>>> 
>>> cgf
>>
>>I must admit that was just a guess.
>>The thread.cc code changed whereas python code in Modules/
>>_multiprocessing/semaphore.c did not.
>>The python multiprocessing module (file semaphore.c) contains:
>>"""
>>if (sem_getvalue(self->handle, &sval) < 0) {
>>return PyErr_SetFromErrno(PyExc_OSError);
>>} else if (sval >= self->maxvalue) {
>>PyErr_SetString(PyExc_ValueError, "semaphore or lock "
>>"released too many times");
>>return NULL;
>>}
>>"""
>>Changing this to
>>"""
>>sval = sem_getvalue(self->handle, &sval);
>>if (sem_getvalue(self->handle, &sval) < 0) {
>>return PyErr_SetFromErrno(PyExc_OSError);
>>} else if (sval >= self->maxvalue) {
>>PyErr_SetString(PyExc_ValueError, "semaphore or lock "
>>"released too many times");
>>return NULL;
>>}
>>"""
>>to emulate the previous behavior of sem_getvalue seems to solve my problem 
>>(and was easier than rebuilding cygwin1.dll).
>
>That doesn't emulate the previous behavior.  The return value of sem_getvalue
>was changed to 0 or -1 as per POSIX.  If self->maxvalue is > 1 then
>you won't see an error but it won't be correct either.

Ok.  I was confused by the seemingly contradictory assertions that the
patch from http://cygwin.com/ml/cygwin-patches/2013-q3/msg6.html was
both the cause and the solution for the problem.  And, I thought my change
to sem_getvalue had gotten into 1.7.25.  It hadn't.

So, it's my night to be wrong.  Larry, however, is not suffering
similarly: He was right.  Snapshots after 9/25 will be the only versions
of the DLL that have the fix for this problem.  It does seem like the
problem was introduced in changes to thread.cc months before the
abovementioned patch ever went in.

http://cygwin.com/snapshots/

cgf

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: Problem with multiprocessing module from Python

2013-10-31 Thread Christopher Faylor 
On Thu, Oct 31, 2013 at 02:41:14PM -0400, Christopher Faylor wrote:
>On Thu, Oct 31, 2013 at 06:27:39PM +, Jean-Pierre Flori wrote:
>>Le Wed, 30 Oct 2013 10:33:13 +0100, Corinna Vinschen a ??crit??:
>>
>>> On Oct 29 21:22, Jean-Pierre Flori wrote:
 Le Tue, 29 Oct 2013 21:19:14 +, Jean-Pierre Flori a ??crit??:
 
 > Le Tue, 29 Oct 2013 16:59:35 -0400, Christopher Faylor a ??crit??:
 >> If you want this fixed, the easiest way to get that to happen is to
 >> post a simple test case which reproduces the problem.  That is not
 >> the code snippet that you sent.  A real working example would be
 >> required.
 > Sorry about that.
 > 
 > Here you go:
 > """
 > from multiprocessing import Pool
 > 
 > def f(x): return x
 > 
 > p = pool(2)
 > 
 > p.map(f, [1, 2])
 > """
 And I managed to introduce a typo. The third line should read Pool, so
 it is:
 """
 from multiprocessing import Pool
 
 def f(x): return x
 
 p = Pool(2)
 
 p.map(f, [1, 2])
 """
>>> 
>>> Works for me.  I guess.  At least, if I run the script, nothing happens:
>>> 
>>>   $ python x.py $
>>> 
>>> Same on 32 and 64 bit Cygwin.
>>> 
>>> 
>>> Corinna
>>
>>I think I got to the bottom of this.
>>It seems the new implem of sem_getvalue in cgwin1.dll is the cause, see:
>>http://cygwin.com/ml/cygwin-patches/2013-q3/msg6.html
>>It may also explain the random reproducibility if sval stays uninitialized 
>>or something like that (I did not check it is the case though).
>
>I doubt that was the problem.  More likely it is something related to
>the changes in thread.cc that followed that change.

Actually I misread the CVS log.  It's more likely that this is due to changes
that happened just prior to the above change.

cgf

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: Problem with multiprocessing module from Python

2013-10-31 Thread Christopher Faylor 
On Thu, Oct 31, 2013 at 08:47:58PM +, Jean-Pierre Flori wrote:
>Le Thu, 31 Oct 2013 14:41:14 -0400, Christopher Faylor a ??crit??:
>
>> On Thu, Oct 31, 2013 at 06:27:39PM +, Jean-Pierre Flori wrote:
>>>Le Wed, 30 Oct 2013 10:33:13 +0100, Corinna Vinschen a ??crit??:
>>>
 On Oct 29 21:22, Jean-Pierre Flori wrote:
> Le Tue, 29 Oct 2013 21:19:14 +, Jean-Pierre Flori a ??crit??:
> 
> > Le Tue, 29 Oct 2013 16:59:35 -0400, Christopher Faylor a ??crit??:
> >> If you want this fixed, the easiest way to get that to happen is
> >> to post a simple test case which reproduces the problem.  That is
> >> not the code snippet that you sent.  A real working example would
> >> be required.
> > Sorry about that.
> > 
> > Here you go:
> > """
> > from multiprocessing import Pool
> > 
> > def f(x): return x
> > 
> > p = pool(2)
> > 
> > p.map(f, [1, 2])
> > """
> And I managed to introduce a typo. The third line should read Pool,
> so it is:
> """
> from multiprocessing import Pool
> 
> def f(x): return x
> 
> p = Pool(2)
> 
> p.map(f, [1, 2])
> """
 
 Works for me.  I guess.  At least, if I run the script, nothing
 happens:
 
   $ python x.py $
 
 Same on 32 and 64 bit Cygwin.
 
 
 Corinna
>>>
>>>I think I got to the bottom of this.
>>>It seems the new implem of sem_getvalue in cgwin1.dll is the cause, see:
>>>http://cygwin.com/ml/cygwin-patches/2013-q3/msg6.html It may also
>>>explain the random reproducibility if sval stays uninitialized or
>>>something like that (I did not check it is the case though).
>> 
>> I doubt that was the problem.  More likely it is something related to
>> the changes in thread.cc that followed that change.
>> 
>> cgf
>
>I must admit that was just a guess.
>The thread.cc code changed whereas python code in Modules/
>_multiprocessing/semaphore.c did not.
>The python multiprocessing module (file semaphore.c) contains:
>"""
>if (sem_getvalue(self->handle, &sval) < 0) {
>return PyErr_SetFromErrno(PyExc_OSError);
>} else if (sval >= self->maxvalue) {
>PyErr_SetString(PyExc_ValueError, "semaphore or lock "
>"released too many times");
>return NULL;
>}
>"""
>Changing this to
>"""
>sval = sem_getvalue(self->handle, &sval);
>if (sem_getvalue(self->handle, &sval) < 0) {
>return PyErr_SetFromErrno(PyExc_OSError);
>} else if (sval >= self->maxvalue) {
>PyErr_SetString(PyExc_ValueError, "semaphore or lock "
>"released too many times");
>return NULL;
>}
>"""
>to emulate the previous behavior of sem_getvalue seems to solve my problem 
>(and was easier than rebuilding cygwin1.dll).

That doesn't emulate the previous behavior.  The return value of sem_getvalue
was changed to 0 or -1 as per POSIX.  If self->maxvalue is > 1 then
you won't see an error but it won't be correct either.

cgf

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: Problem with multiprocessing module from Python

2013-10-31 Thread Christopher Faylor 
On Thu, Oct 31, 2013 at 06:04:34PM -0400, Larry Hall (Cygwin) wrote:
>On 10/31/2013 4:47 PM, Jean-Pierre Flori wrote:
>
>> Commit http://cygwin.com/cgi-bin/cvsweb.cgi/src/winsup/cygwin/thread.cc?
>> rev=1.286&content-type=text/x-cvsweb-markup&cvsroot=src
>> would be exactly what I need.
>> I'll just be waiting for 1.7.26.
>
>If you want to try this, you don't need to wait for 1.7.26.  Just grab a
>recent snapshot and give it a go.
>
>

Yep. You're always welcome to try that but I don't think there have been
any changes in the thread code which would be pertinent here.

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: Problem with multiprocessing module from Python

2013-10-31 Thread Larry Hall (Cygwin) 

On 10/31/2013 4:47 PM, Jean-Pierre Flori wrote:


Commit http://cygwin.com/cgi-bin/cvsweb.cgi/src/winsup/cygwin/thread.cc?
rev=1.286&content-type=text/x-cvsweb-markup&cvsroot=src
would be exactly what I need.
I'll just be waiting for 1.7.26.


If you want to try this, you don't need to wait for 1.7.26.  Just grab a
recent snapshot and give it a go.



--
Larry

_

A: Yes.
> Q: Are you sure?
>> A: Because it reverses the logical flow of conversation.
>>> Q: Why is top posting annoying in email?

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Couldn't compute FAST_CWD pointer on Win8.1 x64

2013-10-31 Thread Alfred Theorin 
I get the following error when I start cygwin (32-bit version 1.7.25)
on Win8.1 x64:

0 [main] bash  find_fast_cwd: WARNING: Couldn't compute FAST_CWD pointer.

Kind Regards
Alfred Theorin

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

cygwin64 info.exe Exception: STATUS_ACCESS_VIOLATION if no info file found

2013-10-31 Thread Brian Inglis 
cygwin64 info.exe consistently dumps when no info file is found - whether or
not there is a man page. 
cygwin32 works as always, displaying a man page if found, or status line
message "No menu item `' in node `(dir)Top'."

Running under gdb where there is a man page but no info file:
Reading symbols from /usr/bin/info...(no debugging symbols found)...done.
(gdb) run sntp
Starting program: /usr/bin/info sntp
[New Thread 1876.0x41c]
[New Thread 1876.0x19a8]

Program received signal SIGSEGV, Segmentation fault.
0x in ?? ()
(gdb) bt
#0  0x in ?? ()
#1  0x07fefd6710dc in WaitForSingleObjectEx () from
/cygdrive/c/Windows/system32/KERNELBASE.dll
#2  0x00060001 in ?? ()
#3  0x in ?? ()
(gdb) return
Make selected stack frame return now? (y or n) y
#0  0x07fefd6710dc in WaitForSingleObjectEx ()
   from /cygdrive/c/Windows/system32/KERNELBASE.dll
(gdb) cont
Continuing.
  0 [main] info 1876 open_stackdumpfile: Dumping stack trace to
info.exe.stackdump
[Inferior 1 (process 1876) exited with code 0105400]
(gdb) q

Stackdumps:
gdb run sntp
Exception: STATUS_ACCESS_VIOLATION at rip=00180168EBD
rax= rbx= rcx=
rdx=FEFEFEFF0F030100 rsi=0004 rdi=0006000487B0
r8 =8F8B918C r9 =8080808080808080 r10=FEFEFEFEFEFEFEFF
r11=0006000487B0 r12=0005 r13=0006000487B0
r14=0006000486B0 r15=0006000493A0
rbp=000C rsp=0022A448
program=C:\usr\local\cygwin64\bin\info.exe, pid 1876, thread main
cs=0033 ds=002B es=002B fs=0053 gs=002B ss=002B

info sntp
Exception: STATUS_ACCESS_VIOLATION at rip=00180168EBD
rax= rbx= rcx=
rdx=FEFEFEFF0F030100 rsi=0004 rdi=000600048970
r8 =8F8B918C r9 =8080808080808080 r10=FEFEFEFEFEFEFEFF
r11=000600048970 r12=0005 r13=000600048970
r14=000600048870 r15=000600047AA0
rbp=000C rsp=0022A488
program=C:\usr\local\cygwin64\bin\info.exe, pid 4548, thread main
cs=0033 ds=002B es=002B fs=0053 gs=002B ss=002B

info 
Exception: STATUS_ACCESS_VIOLATION at rip=00180168EBD
rax= rbx= rcx=
rdx=FEFEFEFF01010101 rsi=0004 rdi=000600048970
r8 =85858585 r9 =8080808080808080 r10=FEFEFEFEFEFEFEFF
r11=000600048970 r12=0005 r13=000600048970
r14=000600048870 r15=000600047AA0
rbp=000C rsp=0022A488
program=C:\usr\local\cygwin64\bin\info.exe, pid 7896, thread main
cs=0033 ds=002B es=002B fs=0053 gs=002B ss=002B

Next steps?

-- 
Take care. Thanks, Brian Inglis


--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: Problem with multiprocessing module from Python

2013-10-31 Thread Jean-Pierre Flori 
Le Thu, 31 Oct 2013 14:41:14 -0400, Christopher Faylor a écrit :

> On Thu, Oct 31, 2013 at 06:27:39PM +, Jean-Pierre Flori wrote:
>>Le Wed, 30 Oct 2013 10:33:13 +0100, Corinna Vinschen a ??crit??:
>>
>>> On Oct 29 21:22, Jean-Pierre Flori wrote:
 Le Tue, 29 Oct 2013 21:19:14 +, Jean-Pierre Flori a ??crit??:
 
 > Le Tue, 29 Oct 2013 16:59:35 -0400, Christopher Faylor a ??crit??:
 >> If you want this fixed, the easiest way to get that to happen is
 >> to post a simple test case which reproduces the problem.  That is
 >> not the code snippet that you sent.  A real working example would
 >> be required.
 > Sorry about that.
 > 
 > Here you go:
 > """
 > from multiprocessing import Pool
 > 
 > def f(x): return x
 > 
 > p = pool(2)
 > 
 > p.map(f, [1, 2])
 > """
 And I managed to introduce a typo. The third line should read Pool,
 so it is:
 """
 from multiprocessing import Pool
 
 def f(x): return x
 
 p = Pool(2)
 
 p.map(f, [1, 2])
 """
>>> 
>>> Works for me.  I guess.  At least, if I run the script, nothing
>>> happens:
>>> 
>>>   $ python x.py $
>>> 
>>> Same on 32 and 64 bit Cygwin.
>>> 
>>> 
>>> Corinna
>>
>>I think I got to the bottom of this.
>>It seems the new implem of sem_getvalue in cgwin1.dll is the cause, see:
>>http://cygwin.com/ml/cygwin-patches/2013-q3/msg6.html It may also
>>explain the random reproducibility if sval stays uninitialized or
>>something like that (I did not check it is the case though).
> 
> I doubt that was the problem.  More likely it is something related to
> the changes in thread.cc that followed that change.
> 
> cgf

I must admit that was just a guess.
The thread.cc code changed whereas python code in Modules/
_multiprocessing/semaphore.c did not.
The python multiprocessing module (file semaphore.c) contains:
"""
if (sem_getvalue(self->handle, &sval) < 0) {
return PyErr_SetFromErrno(PyExc_OSError);
} else if (sval >= self->maxvalue) {
PyErr_SetString(PyExc_ValueError, "semaphore or lock "
"released too many times");
return NULL;
}
"""
Changing this to
"""
sval = sem_getvalue(self->handle, &sval);
if (sem_getvalue(self->handle, &sval) < 0) {
return PyErr_SetFromErrno(PyExc_OSError);
} else if (sval >= self->maxvalue) {
PyErr_SetString(PyExc_ValueError, "semaphore or lock "
"released too many times");
return NULL;
}
"""
to emulate the previous behavior of sem_getvalue seems to solve my problem 
(and was easier than rebuilding cygwin1.dll).

Commit http://cygwin.com/cgi-bin/cvsweb.cgi/src/winsup/cygwin/thread.cc?
rev=1.286&content-type=text/x-cvsweb-markup&cvsroot=src
would be exactly what I need.
I'll just be waiting for 1.7.26.

Hopefully this will get sorted out.

Best,
JP


--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: [ANNOUNCEMENT] Updated: cygrunsrv-1.50-1

2013-10-31 Thread Christopher Faylor 
On Thu, Oct 31, 2013 at 12:54:47PM -0400, Brian Rak wrote:
>I've found a *critical* issue with this patch.
>
>cygrunsrv now no longer appears in setup.ini

This problem is fixed now.  cygrunsrv now shows up in setup.ini.

Sorry for the inconvenience.

cgf

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: Unable to compile python 3.3 [Was: Re: Python 3.3 coming soon?]

2013-10-31 Thread Jason Tishler 
Ryan,

On Thu, Oct 31, 2013 at 02:44:49PM -0400, Ryan Johnson wrote:
> On 31/10/2013 2:11 PM, Jason Tishler wrote:
> >It appears that others have successfully built Python under 64-bit
> >Cygwin without resorting to my workaround.  Does anyone know what I'm
> >missing?
>
> Try installing pkg-config.

That worked.

Thanks,
Jason

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: Problem with multiprocessing module from Python

2013-10-31 Thread Larry Hall (Cygwin) 

On 10/31/2013 2:27 PM, Jean-Pierre Flori wrote:

I just decompressed the cygwin tarball which only overwrote the dll in /
usr/bin but not in /bin.
Is there a canonical way to do that in a proper way?


What did you use to do the decompress and extract?  Windows tools don't
understand Cygwin mount points.


Putting it in a local directory and pointing setup.exe ot it?


Sure, that works and requires no special effort. :-)

--
Larry

_

A: Yes.
> Q: Are you sure?
>> A: Because it reverses the logical flow of conversation.
>>> Q: Why is top posting annoying in email?

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: Unable to compile python 3.3 [Was: Re: Python 3.3 coming soon?]

2013-10-31 Thread Ryan Johnson 

On 31/10/2013 2:11 PM, Jason Tishler wrote:

On Tue, Oct 15, 2013 at 12:28:31PM +0900, nu774 wrote:

Installing libffi-devel will let python pick system libffi, so you
can skip that libffi building part you are currently stuck.

(2013/10/15 10:10), Ryan Johnson wrote:

"/usr/src/python3-3.3.2-3/src/Python-3.3.2/Lib/distutils/command/build_ext.py",
line 463, in build_extensions
 self.build_extension(ext)
   File "/usr/src/python3-3.3.2-3/src/Python-3.3.2/setup.py", line 279,
in build_extension
 if not self.configure_ctypes(ext):
   File "/usr/src/python3-3.3.2-3/src/Python-3.3.2/setup.py", line 1807,
in configure_ctypes
 exec(f.read(), globals(), fficonfig)
   File "", line 33, in 
KeyError: 'X86_WIN64'
Makefile:505: recipe for target 'sharedmods' failed

At this point I'm stuck... any advice from the gurus out there would be
appreciated.

I get the same build failure with Python 2.7.5 and 3.2.5 under 64-bit
Cygwin even though I configure --with-system-ffi and have libffi-devel
installed.  I noticed that libffi-devel installs its headers in a
non-standard location:

$ cygcheck -l libffi-devel | fgrep .h
/usr/lib/libffi-3.0.13/include/ffi.h
/usr/lib/libffi-3.0.13/include/ffitarget.h

AFAICT, this prevents Python's build system from using the system
provided libffi and attempt to build its own causing an error like the
one above.

I can workaround the problem by creating symlinks to the libffi header
files in /usr/include:

$ ln -s /usr/lib/libffi-3.0.13/include/* /usr/include

It appears that others have successfully built Python under 64-bit
Cygwin without resorting to my workaround.  Does anyone know what I'm
missing?

Try installing pkg-config.

Ryan


--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: Problem with multiprocessing module from Python

2013-10-31 Thread Christopher Faylor 
On Thu, Oct 31, 2013 at 06:27:39PM +, Jean-Pierre Flori wrote:
>Le Wed, 30 Oct 2013 10:33:13 +0100, Corinna Vinschen a ??crit??:
>
>> On Oct 29 21:22, Jean-Pierre Flori wrote:
>>> Le Tue, 29 Oct 2013 21:19:14 +, Jean-Pierre Flori a ??crit??:
>>> 
>>> > Le Tue, 29 Oct 2013 16:59:35 -0400, Christopher Faylor a ??crit??:
>>> >> If you want this fixed, the easiest way to get that to happen is to
>>> >> post a simple test case which reproduces the problem.  That is not
>>> >> the code snippet that you sent.  A real working example would be
>>> >> required.
>>> > Sorry about that.
>>> > 
>>> > Here you go:
>>> > """
>>> > from multiprocessing import Pool
>>> > 
>>> > def f(x): return x
>>> > 
>>> > p = pool(2)
>>> > 
>>> > p.map(f, [1, 2])
>>> > """
>>> And I managed to introduce a typo. The third line should read Pool, so
>>> it is:
>>> """
>>> from multiprocessing import Pool
>>> 
>>> def f(x): return x
>>> 
>>> p = Pool(2)
>>> 
>>> p.map(f, [1, 2])
>>> """
>> 
>> Works for me.  I guess.  At least, if I run the script, nothing happens:
>> 
>>   $ python x.py $
>> 
>> Same on 32 and 64 bit Cygwin.
>> 
>> 
>> Corinna
>
>I think I got to the bottom of this.
>It seems the new implem of sem_getvalue in cgwin1.dll is the cause, see:
>http://cygwin.com/ml/cygwin-patches/2013-q3/msg6.html
>It may also explain the random reproducibility if sval stays uninitialized 
>or something like that (I did not check it is the case though).

I doubt that was the problem.  More likely it is something related to
the changes in thread.cc that followed that change.

cgf

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: Problem with multiprocessing module from Python

2013-10-31 Thread Jean-Pierre Flori 
Le Wed, 30 Oct 2013 10:33:13 +0100, Corinna Vinschen a écrit :

> On Oct 29 21:22, Jean-Pierre Flori wrote:
>> Le Tue, 29 Oct 2013 21:19:14 +, Jean-Pierre Flori a écrit :
>> 
>> > Le Tue, 29 Oct 2013 16:59:35 -0400, Christopher Faylor a écrit :
>> >> If you want this fixed, the easiest way to get that to happen is to
>> >> post a simple test case which reproduces the problem.  That is not
>> >> the code snippet that you sent.  A real working example would be
>> >> required.
>> > Sorry about that.
>> > 
>> > Here you go:
>> > """
>> > from multiprocessing import Pool
>> > 
>> > def f(x): return x
>> > 
>> > p = pool(2)
>> > 
>> > p.map(f, [1, 2])
>> > """
>> And I managed to introduce a typo. The third line should read Pool, so
>> it is:
>> """
>> from multiprocessing import Pool
>> 
>> def f(x): return x
>> 
>> p = Pool(2)
>> 
>> p.map(f, [1, 2])
>> """
> 
> Works for me.  I guess.  At least, if I run the script, nothing happens:
> 
>   $ python x.py $
> 
> Same on 32 and 64 bit Cygwin.
> 
> 
> Corinna

I think I got to the bottom of this.
It seems the new implem of sem_getvalue in cgwin1.dll is the cause, see:
http://cygwin.com/ml/cygwin-patches/2013-q3/msg6.html
It may also explain the random reproducibility if sval stays uninitialized 
or something like that (I did not check it is the case though).

Reverting to 1.7.20 solved the issue on the install I tested.
I guess my previous attempts to downgrade cygwin1.dll were just badly 
done:
I just decompressed the cygwin tarball which only overwrote the dll in /
usr/bin but not in /bin.
Is there a canonical way to do that in a proper way?
Putting it in a local directory and pointing setup.exe ot it?

Best,
JP


--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: Unable to compile python 3.3 [Was: Re: Python 3.3 coming soon?]

2013-10-31 Thread Jason Tishler 
On Tue, Oct 15, 2013 at 12:28:31PM +0900, nu774 wrote:
> Installing libffi-devel will let python pick system libffi, so you
> can skip that libffi building part you are currently stuck.
> 
> (2013/10/15 10:10), Ryan Johnson wrote:
> >"/usr/src/python3-3.3.2-3/src/Python-3.3.2/Lib/distutils/command/build_ext.py",
> >line 463, in build_extensions
> > self.build_extension(ext)
> >   File "/usr/src/python3-3.3.2-3/src/Python-3.3.2/setup.py", line 279,
> >in build_extension
> > if not self.configure_ctypes(ext):
> >   File "/usr/src/python3-3.3.2-3/src/Python-3.3.2/setup.py", line 1807,
> >in configure_ctypes
> > exec(f.read(), globals(), fficonfig)
> >   File "", line 33, in 
> >KeyError: 'X86_WIN64'
> >Makefile:505: recipe for target 'sharedmods' failed
> >
> >At this point I'm stuck... any advice from the gurus out there would be
> >appreciated.

I get the same build failure with Python 2.7.5 and 3.2.5 under 64-bit
Cygwin even though I configure --with-system-ffi and have libffi-devel
installed.  I noticed that libffi-devel installs its headers in a
non-standard location:

$ cygcheck -l libffi-devel | fgrep .h
/usr/lib/libffi-3.0.13/include/ffi.h
/usr/lib/libffi-3.0.13/include/ffitarget.h

AFAICT, this prevents Python's build system from using the system
provided libffi and attempt to build its own causing an error like the
one above.

I can workaround the problem by creating symlinks to the libffi header
files in /usr/include:

$ ln -s /usr/lib/libffi-3.0.13/include/* /usr/include

It appears that others have successfully built Python under 64-bit
Cygwin without resorting to my workaround.  Does anyone know what I'm
missing?

Thanks,
Jason

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: [ANNOUNCEMENT] Updated: cygrunsrv-1.50-1

2013-10-31 Thread Brian Rak 
Yea.  The files are present on my mirror as well, but the package
isn't listed in setup.ini.

I ended up reverting our setup.ini to the version from the 29th
(thanks to cygwin time machine), and everything is working again.

On Thu, Oct 31, 2013 at 1:17 PM, Lavrentiev, Anton (NIH/NLM/NCBI) [C]
 wrote:
> FWIW, I was able to download it from kernel.org's mirror just fine this 
> morning:
>
> ftp://mirrors.kernel.org/sourceware/cygwin/x86/release/cygrunsrv/
>
> Anton Lavrentiev
> Contractor NIH/NLM/NCBI
>

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

RE: [ANNOUNCEMENT] Updated: cygrunsrv-1.50-1

2013-10-31 Thread Lavrentiev, Anton (NIH/NLM/NCBI) [C] 
FWIW, I was able to download it from kernel.org's mirror just fine this morning:

ftp://mirrors.kernel.org/sourceware/cygwin/x86/release/cygrunsrv/

Anton Lavrentiev
Contractor NIH/NLM/NCBI


--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: [ANNOUNCEMENT] Updated: cygrunsrv-1.50-1

2013-10-31 Thread Brian Rak 
I've found a *critical* issue with this patch.

cygrunsrv now no longer appears in setup.ini, so the package doesn't
actually get installed by anything.  Also, the packages don't actually
appear on http://cygwin.com/packages/x86/cygrunsrv/

This effectively breaks every cygwin service.

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

RE: SIGKILL and TerminateProcess

2013-10-31 Thread Lavrentiev, Anton (NIH/NLM/NCBI) [C] 
> http://cygwin.com/ml/cygwin-patches/2009-q4/msg00028.html

> Don't know if this will help in your situation, but I figured it should
> be mentioned.

Thank you for the follow up.

The idea was to use CYGWIN (and hence UNIX scripting) to control (mainly: 
launch / stop) applications (whether CYGWIN-based or native Windows beasts) on 
an
unmanned Windows box...

Anton Lavrentiev
Contractor NIH/NLM/NCBI


--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

RE: SIGKILL and TerminateProcess

2013-10-31 Thread Lavrentiev, Anton (NIH/NLM/NCBI) [C] 
> As the person who wrote the signal handling code, I

Believe it or not, I'm well aware of that.

> continuing to insist that you need this will avail you naught

There was no intention to insist on anything;  but to understand why that
has been implemented the way it is.  And the point has been taken..

Anton Lavrentiev
Contractor NIH/NLM/NCBI


--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: git clone failing with "fatal: index-pack failed"

2013-10-31 Thread Andrew DeFaria 

On 10/26/2013 03:12 PM, Balaji Venkataraman wrote:

On Sat, Oct 26, 2013 at 9:23 AM, Andrew DeFaria wrote:

It's been very quite about this issue. Usually at least somebody responds. I
fear that perhaps nobody's seeing this. Could somebody, anybody, simply
respond if even just to say "Yeah, I see this. Don't have an answer though"
I'd appreciate it.

I see something similar intermittently but only when I try to clone in
a non-Administrator shell and that too only on cygwin32. It doesn't
happen when I'm in an administrator shell. Haven't been able to figure
it out - although I'm having other problems where I can't run many
commands from a 32bit Cygwin shell - so I don't want to set you off on
a random thread. Are you able to do things like man, make etc. from
the same shell?
Interesting. Running an administrator shell works! The odd thing is that 
I logged in as the user Administrator, the local user Administrator. I 
assume it has administrator rights but I know that there are 
administrator rights and then there are administrator rights. So it 
seems the problem lies between the two. How to debug this further and 
fix it?

--
Andrew DeFaria 
Black holes really suck.


--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

bash command line limit

2013-10-31 Thread marco atzeri 

There is any expected specific limit to command line length in
bash scripts on cygwin ?

Testing octave, I am noticing that line longer than ~ 5000 characters
are aborted with no message.

The line is :

OCTAVE_BINDIR="$builddir/src" \
OCTAVE_SITE_INITFILE="$top_srcdir/scripts/startup/main-rcfile" \
OCTAVE_DEFAULT_QT_SETTINGS="$builddir/libgui/default-qt-settings" \
OCTAVE_LOCALE_DIR="$builddir/libgui/languages" \
OCTAVE_JAVA_DIR="$builddir/scripts/java" \
  exec $builddir/libtool -v --mode=execute $driver \
"$octave_executable" --no-init-path --path="$LOADPATH" \
--image-path="$IMAGEPATH" --doc-cache-file="$DOCFILE" \
--built-in-docstrings-file="$BUILT_IN_DOCSTRINGS_FILE" \
--texi-macros-file="$TEXIMACROSFILE" --info-file="$INFOFILE" "$@"
-
end its full lenght when expended is over 5000 characters.

Just removing the last "\" before exec and dropping the length ~ 4950
and the script works again


In theory , the limit should be much more:

$ getconf ARG_MAX
32000

Regards
Marco



--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: ATTENTION GCC PACKAGE MAINTAINER - Re: GCC: core, g++ version mismatch

2013-10-31 Thread JonY 
On 10/31/2013 00:09, Christopher Faylor wrote:.
> 
> I restrict the filenames that can be uploaded and neglected to add '+'.
> I just added it now so you will have to upload those files again.  Sorry
> for the inconvenience.
> 

Done, reuploaded.

>> Strange that I did not get any errors on my end, will upload again.
> 
> You should have gotten an error.  I noticed errors myself when trying
> to upload a !email file because, for a time, '!' wasn't supported either.
> 

Is this supposed to be placed in the root directory?




signature.asc
Description: OpenPGP digital signature

Re: popen: Permission denied - error opening man page

2013-10-31 Thread Balaji Venkataraman 
I finally managed to solve this. As strange (or wildly speculative) as
it may sound, I have concluded the problem is related to chere (cygwin
bash prompt here) somehow interfering with the permissions on sh.exe.
If anybody is interested in more details, I can provide them. Thanks
to Larry for his help.

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple