On 07/15/12 14:21, Nicolas Le Cam wrote:
2012/7/4 Jacek Caban ja...@codeweavers.com:
On 07/03/12 20:10, Jacek Caban wrote:
On 06/29/12 03:35, Austin English wrote:
On Thu, Jun 28, 2012 at 6:30 PM, Nicolas Le Cam niko.le...@gmail.com
wrote:
2012/6/29 Austin English austinengl...@gmail.com:
On Mon, Jul 16, 2012 at 11:33 AM, Jacek Caban ja...@codeweavers.com wrote:
On 07/15/12 14:21, Nicolas Le Cam wrote:
2012/7/4 Jacek Caban ja...@codeweavers.com:
On 07/03/12 20:10, Jacek Caban wrote:
On 06/29/12 03:35, Austin English wrote:
On Thu, Jun 28, 2012 at 6:30 PM, Nicolas Le Cam
On 07/16/12 11:02, Ozkan Sezer wrote:
On Mon, Jul 16, 2012 at 11:33 AM, Jacek Caban ja...@codeweavers.com wrote:
On 07/15/12 14:21, Nicolas Le Cam wrote:
2012/7/4 Jacek Caban ja...@codeweavers.com:
On 07/03/12 20:10, Jacek Caban wrote:
On 06/29/12 03:35, Austin English wrote:
On Thu, Jun 28,
On 7/16/2012 16:33, Jacek Caban wrote:
On 07/15/12 14:21, Nicolas Le Cam wrote:
2012/7/4 Jacek Caban:
On 07/03/12 20:10, Jacek Caban wrote:
On 06/29/12 03:35, Austin English wrote:
On Thu, Jun 28, 2012 at 6:30 PM, Nicolas Le Cam wrote:
2012/6/29 Austin English austinengl...@gmail.com:
Fixes
On 07/16/12 11:06, JonY wrote:
On 7/16/2012 16:33, Jacek Caban wrote:
On 07/15/12 14:21, Nicolas Le Cam wrote:
2012/7/4 Jacek Caban:
On 07/03/12 20:10, Jacek Caban wrote:
On 06/29/12 03:35, Austin English wrote:
On Thu, Jun 28, 2012 at 6:30 PM, Nicolas Le Cam wrote:
2012/6/29 Austin English
On 7/16/2012 17:19, Jacek Caban wrote:
Sorry about that, I treat my git repository as a temporary place for
patch reviews, so they may disappear once I push new versions. Here is a
link to a patch already committed to the trunk (which should be
persistent since it's already in mingw-w64):
On Mon, Jul 16, 2012 at 1:38 PM, JonY jo...@users.sourceforge.net wrote:
On 7/16/2012 17:19, Jacek Caban wrote:
Sorry about that, I treat my git repository as a temporary place for
patch reviews, so they may disappear once I push new versions. Here is a
link to a patch already committed to the
On 7/16/2012 18:46, Ozkan Sezer wrote:
On Mon, Jul 16, 2012 at 1:38 PM, JonY wrote:
On 7/16/2012 17:19, Jacek Caban wrote:
Sorry about that, I treat my git repository as a temporary place for
patch reviews, so they may disappear once I push new versions. Here is a
link to a patch already
On 7/16/2012 19:10, JonY wrote:
On 7/16/2012 18:46, Ozkan Sezer wrote:
On Mon, Jul 16, 2012 at 1:38 PM, JonY wrote:
On 7/16/2012 17:19, Jacek Caban wrote:
Sorry about that, I treat my git repository as a temporary place for
patch reviews, so they may disappear once I push new versions. Here
On Mon, Jul 16, 2012 at 3:03 PM, JonY jo...@users.sourceforge.net wrote:
On 7/16/2012 19:10, JonY wrote:
On 7/16/2012 18:46, Ozkan Sezer wrote:
On Mon, Jul 16, 2012 at 1:38 PM, JonY wrote:
On 7/16/2012 17:19, Jacek Caban wrote:
Sorry about that, I treat my git repository as a temporary place
On 07/16/12 14:26, Ozkan Sezer wrote:
On Mon, Jul 16, 2012 at 3:03 PM, JonY jo...@users.sourceforge.net wrote:
On 7/16/2012 19:10, JonY wrote:
On 7/16/2012 18:46, Ozkan Sezer wrote:
On Mon, Jul 16, 2012 at 1:38 PM, JonY wrote:
On 7/16/2012 17:19, Jacek Caban wrote:
Sorry about that, I treat
On Jul 13 09:54, Corinna Vinschen wrote:
On Jul 13 10:24, Ozkan Sezer wrote:
On Fri, Jul 13, 2012 at 10:09 AM, Kai Tietz ktiet...@googlemail.com wrote:
The cause for that I was suggesting __32LONG is that name is more
unlikely to be mixed-up with a real type.
Yuck, nonetheless..
On Mon, Jul 16, 2012 at 4:43 PM, Corinna Vinschen vinsc...@redhat.com wrote:
On Jul 13 09:54, Corinna Vinschen wrote:
On Jul 13 10:24, Ozkan Sezer wrote:
On Fri, Jul 13, 2012 at 10:09 AM, Kai Tietz ktiet...@googlemail.com
wrote:
The cause for that I was suggesting __32LONG is that name
On Sat, Jul 14, 2012 at 12:23 PM, niXman i.nix...@gmail.com wrote:
Patch in attachment.
--
Regards,
niXman
This was discussed quite some time ago and the suggested changes
look OK to me at first glance. As a reference, pthreads-win32 restores
the last error for pthread_getspecific() (but not
2012/7/16 niXman i.nix...@gmail.com
2012/7/16 Ozkan Sezer:
This was discussed quite some time ago and the suggested changes
look OK to me at first glance. As a reference, pthreads-win32 restores
the last error for pthread_getspecific() (but not for
pthread_setspecific()
as far as I can
Well,
I am fine by this patch, but I would love to get additional a testcase
added for it.
So patch is ok with a testcase.
Thanks,
Kai
--
Live Security Virtual Conference
Exclusive live event will cover all the ways
On Jul 16 15:56, Kai Tietz wrote:
Well,
I would like to have here one define for long, which is then later on
used consistently to replace use of 'long' type. I don't see much
advantage in adding here a signed and a unsigned variant to _mingw.h
header. We want to replace use of 'long'
Hi,
as discussed on IRC, I propose the below patch. It changes the
calls of the Interlocked functions from the C++ Interlocked inline
functions defined at the end of winbase.h to use the system types
just as these functions are defined. Ok to apply?
Thanks,
Corinna
[New and improved: This time with attachement!]
On Jul 16 18:58, Corinna Vinschen wrote:
Hi,
as discussed on IRC, I propose the below patch. It changes the
calls of the Interlocked functions from the C++ Interlocked inline
functions defined at the end of winbase.h to use the system types
Hello Corinna,
patch looks ok for me. I assume Jacek has no objections, so please go ahead.
Thanks,
Kai
--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat
On 7/16/12, Corinna Vinschen vinsc...@redhat.com wrote:
[New and improved: This time with attachement!]
On Jul 16 18:58, Corinna Vinschen wrote:
Hi,
as discussed on IRC, I propose the below patch. It changes the
calls of the Interlocked functions from the C++ Interlocked inline
functions
On Jul 16 20:44, Ozkan Sezer wrote:
On 7/16/12, Corinna Vinschen vinsc...@redhat.com wrote:
[New and improved: This time with attachement!]
On Jul 16 18:58, Corinna Vinschen wrote:
Hi,
as discussed on IRC, I propose the below patch. It changes the
calls of the Interlocked functions
We also experience an issue with boost::filesystem::exists in blender. If
this fixes that it will be a blessing :).
--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
23 matches
Mail list logo
