Hello,
I would really love to see pyopencl (version 2013) as a precompiled package
for cygwin.
PyOpenCL needs numpy*, scipy(?), decorator*, mako*, libboost*, pytools
(could also be included, no compilation needed, setup via python), opengl
libs of the used sdk of the installed gpu vendor on
On Jul 17 22:31, Jon TURNEY wrote:
On 19/06/2013 23:39, Yaakov (Cygwin/X) wrote:
There appears to be a bug in the MIT-SHM extension with the 64-bit
xserver; both XWin and Xvfb have manifested this so far. The easiest way to
trigger this is to install gnome-themes-standard, add
I do not know, whether it has been send correctly, so again:
Hello,
I would really love to see pyopencl (version 2013) as a precompiled package
for cygwin.
PyOpenCL needs numpy*, scipy(?), decorator*, mako*, libboost*, pytools (could
also be included, no compilation needed, setup via
On Jul 18 09:05, marcus.desto wrote:
Hello,
I would really love to see pyopencl (version 2013) as a precompiled package
for cygwin.
PyOpenCL needs numpy*, scipy(?), decorator*, mako*, libboost*, pytools
(could also be included, no compilation needed, setup via python), opengl
libs of the
On 2013-07-14, at 03:44, Andrew Schulman wrote:
There are of course other packages that could be called missing because
they haven't been ported to x86_64 yet, and other packages that depend on
them can't be released until they are. There are two that I'm waiting on:
ocaml - for orpie and
On Thu, Jul 18, 2013 at 11:06:15AM +0200, marcus.desto wrote:
I do not know, whether it has been send correctly, so again:
It was sent correctly, as in the email arrived. However, you are
sending to the wrong mailing list. This isn't a list for would be
nice requests.
Use the cygwin mailing
On 7/17/2013 5:31 PM, Jon TURNEY wrote:
On 19/06/2013 23:39, Yaakov (Cygwin/X) wrote:
There appears to be a bug in the MIT-SHM extension with the 64-bit
xserver; both XWin and Xvfb have manifested this so far. The easiest way to
trigger this is to install gnome-themes-standard, add
On 18/07/2013 09:37, Corinna Vinschen wrote:
On Jul 17 22:31, Jon TURNEY wrote:
On 19/06/2013 23:39, Yaakov (Cygwin/X) wrote:
There appears to be a bug in the MIT-SHM extension with the 64-bit
xserver; both XWin and Xvfb have manifested this so far. The easiest way to
trigger this is to
On 18/07/13 20:59, Ken Brown wrote:
Did you have cygserver running when you did your tests? It doesn't
seem good that the outcome of a configure test should depend on
whether or not the person building the package happens to have
cygserver running while doing the build.
If necessary, you
On 18/07/2013 20:59, Ken Brown wrote:
On 7/17/2013 5:31 PM, Jon TURNEY wrote:
On 19/06/2013 23:39, Yaakov (Cygwin/X) wrote:
There appears to be a bug in the MIT-SHM extension with the 64-bit
xserver; both XWin and Xvfb have manifested this so far. The easiest way to
trigger this is to
On Jul 18 22:06, Jon TURNEY wrote:
On 18/07/2013 09:37, Corinna Vinschen wrote:
On Jul 17 22:31, Jon TURNEY wrote:
After going around in circles on this a few times, this is what I now
think I
know:
The proximate cause of this error is that the x86_64 libcairo2 package
appears
Hi,
On 16 Jul 2013 03:05+1000, Christopher Faylor wrote:
I'd appreciate it if people could try the two new setup.exe's
installed at http://cygwin.com/
http://cygwin.com/setup-x86.exe for 32-bit
This is not working for me against an existing install, where I am
following a two-step process to
CVSROOT:/cvs/src
Module name:src
Changes by: cori...@sourceware.org 2013-07-18 10:11:33
Modified files:
winsup/cygwin : ChangeLog path.cc
Log message:
* path.cc (normalize_posix_path): Start checking path before .. at
dst, rather than at dst_start,
Solved. What I've done was the clean install[1]. But I don't
know what did the trick nor the cause of the problem[2] after
all. Performing rebaseall doesn't seem to do any harm in this
installation.
Regards,
[1] Rename c:\cygwin\ to c:\cygwin_old\
Install Cygwin in c:\cygwin\ using
On 2013-07-18 AM 10:53, Warren Young wrote:
Nothing so simple. Locking is handled at the OS and/or Cygwin DLL
level. The build change between 3.7.16.2 and 3.7.17-3 is that we're now
relying on new features in the Cygwin DLL to do Windows-style locking by
default.
Older versions of Cygwin
On Jul 18 17:11, jojelino wrote:
On 2013-07-18 AM 10:53, Warren Young wrote:
Nothing so simple. Locking is handled at the OS and/or Cygwin DLL
level. The build change between 3.7.16.2 and 3.7.17-3 is that we're now
relying on new features in the Cygwin DLL to do Windows-style locking by
On Jul 18 11:38, Roland Schwingel wrote:
Hi...
Today I updated my cygwin to version 1.7.21. Due to a bunch of
lockup problems I was previously sticking to 1.7.17. A short test
shows that the lockups appears to be solved (that are the good news
- thanks to all involved) - but I got a new
Hi Guys,
i dont know why ln is not working.
this is what i did.
C:\Users\test1pushd
\\ostorenas\odi\ostore_platform_logs\ostore\7.4.0\test1\linux64
Z:\ostore_platform_logs\ostore\7.4.0\test1\linux64c:\cygwin\bin\ln -s
diva_test LATEST
in the above line diva_test is a folder.
it is created a
On Jul 18 16:15, Divakar K wrote:
Hi Guys,
i dont know why ln is not working.
this is what i did.
C:\Users\test1pushd
\\ostorenas\odi\ostore_platform_logs\ostore\7.4.0\test1\linux64
Z:\ostore_platform_logs\ostore\7.4.0\test1\linux64c:\cygwin\bin\ln -s
diva_test LATEST
in the
I have a very recent version of Cygwin and using the SIPP application. This
calls nanosleep from within a thread.
Effectively , every second, the application
* Creates a thread
* Calls nanosleep 9 times.
* Deletes the thread
And every second, according to windows task
[What an odd subject line]
On Thu, Jul 18, 2013 at 04:23:32PM +0100, trefor.2.edwa...@bt.com wrote:
I have a very recent version of Cygwin and using the SIPP application.
This calls nanosleep from within a thread.
Very recent is not a precise enough distinction for debugging
problems.
See:
Hi,
sorry if this isn't the correct place. I have previously used the
mingw-* packages to create a Windows compile of tcl8.6.0, but currently
it doesn't work. It compiles without error as far as I can see, but when
you try to run the executable (tclsh8.6.0.exe) it returns immediately
with
On 2013-07-18 PM 5:59, Corinna Vinschen wrote: On Jul 18 17:11,
jojelino wrote:
On 2013-07-18 AM 10:53, Warren Young wrote:
Nothing so simple. Locking is handled at the OS and/or Cygwin DLL
level. The build change between 3.7.16.2 and 3.7.17-3 is that
we're now
relying on new features in
23 matches
Mail list logo
