On Aug 17, 2011, at 5:27 PM, Riccardo Mottola wrote:
Hi,
Hey,
I don't like using PRIdPTR because it took me a while to figure out
why it works (I had to look up that it's a format string for
intptr_t, and then check the NSInteger definition to verify that
that is also intptr_t…), and PRI
Hi,
Hey,
I don't like using PRIdPTR because it took me a while to figure out why it
works (I had to look up that it's a format string for intptr_t, and then check
the NSInteger definition to verify that that is also intptr_t…), and PRIdPTR
introduces a dependency on how NSInteger is defined e
Eric,
many thanks for your efforts and suggestions.
Actually, I just placed #define CGRectEqualToRect NSRectEquals in the file you
also found (BTW, beforehand I had to manually change gnustep make path in every
GNUstep.make file)..
After that everything compiled well.
Unfortunately, now I get a
On 17 Aug 2011, at 19:36, Eric Wasylishen wrote:
> Hey,
>
> I don't like using PRIdPTR because it took me a while to figure out why it
> works
It's pretty simple: PRI (printf format string), character for int, PTR (pointer
type).
> (I had to look up that it's a format string for intptr_t, and
Hey,
I don't like using PRIdPTR because it took me a while to figure out why it
works (I had to look up that it's a format string for intptr_t, and then check
the NSInteger definition to verify that that is also intptr_t…), and PRIdPTR
introduces a dependency on how NSInteger is defined everywh
With the change in place things look normal again for MinGW.
On 17.08.2011 13:48, Richard Frith-Macdonald wrote:
On 17 Aug 2011, at 10:45, Fred Kiefer wrote:
I really would like to see the 1400 test errors we get on MinGW reduced before
the next release.
I agree ... mingw is probably our sec
Hi,
David is making many log statements more portable / 64 bit compliant by
using a macro like this:
NSLog(@"_dispatch with unexpected status %" PRIdPTR, [self
streamStatus]);
PRIdPTR will expand to the correct string.
gcc 2.95 on my sparc box barks
NSStream.m:198: syntax error bef
On 17 Aug 2011, at 10:45, Fred Kiefer wrote:
> I really would like to see the 1400 test errors we get on MinGW reduced
> before the next release.
I agree ... mingw is probably our second highest priority platform after
gnu/linux, so major problems there
How are you building it? Recent (not n
I really would like to see the 1400 test errors we get on MinGW reduced
before the next release.
As far as I can tell most of this boil down to GSMime issues (The NSURL
test seems to be a result of that as well). Even the most simple test in
GSMime build.m produces the wrong result. Only the las
Hi,
Fred Kiefer wrote:
I don't remember whether we use fake main for Cygwin or have another
mechanism to get the environment and the arguments.
You should try and add some print statements in the NSProcessInfo code
that parses the environment. In the end it may well be that Cygwin
itself alre
Hi,
apparently /bin/sh is ksh and I have no bash installed.
This would be the manpage of the test command of ksh:
http://www.openbsd.org/cgi-bin/man.cgi?query=test&apropos=0&sektion=1&manpath=OpenBSD+4.7&arch=i386&format=html
I hope that the warning message is "cosmetic" since it runs several
To me this sounds like you are having issues right inside the
gnustep-test script. Could you please check which shell /bin/bash is
pointing to and find out how "test" gets interpreted by that shell?
Perhaps somebody with more shell scripting skills has better ideas on
how to debug this?
Fred
12 matches
Mail list logo
