Re: Base status

[Fred Kiefer]

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 last header and the 
content get reported as the rawMimeData.

As debuggin on MinGW is a rather annoying task, especially when done in 
a virtual machine, I looked through the code at GSMime to find any MinGW 
specific issue and there aren't any. So I furteher tracked this down 
until I got to the method -headerNamed: which always returned the first 
element what ever the given name was. There we use this horrible 
optimisation of implementation caching. Fine if done correctly, but here 
we use the type IMP to cache a method that returns a BOOL not an object. 
I will fix this later on and give the MinGW testing another try. in 
GSMime.m I could see about five of this misuses of IMP and we will have 
to check the rest of base as well.

Still no idea why this breaks on MinGW but seems to work on most other 
systems.

Fred


On 16.08.2011 10:47, Fred Kiefer wrote:
> On 15.08.2011 13:03, Fred Kiefer wrote:
> > On my Windows XP running in a VMware with GNUstep for MinGW things don't
> > look that well. I have 47 failed tests and one failed build. It looks
> > like everything related to character encodings, NSJSONSerialization and
> > NSURL is failing. I will look into this in more detail and report back.
>
> These tests were done with an old installation of MinGW. I switched to
> the new one yesterday and now the results look even worse :-(
>
> I have about 1400 failed tests, luckily most of these come from one
> single NSURL test. Attached you will find the the test logs.
>
> There are a few worrying tests here. For example we get a warning about
> -isClass when compiling the file NSObject/test01.m and both these tests
> there fail. (The first test in this file actually tests +isClass)
>
> I don't quite understand the test in NSObject/initialize.m, but MinGW
> doesn't have SIGALRM, we will need to have a compile time check there.
>
> Plenty of the GSMime tests fail, but I am not sure whether this is
> related to Richard's recent changes.
>
> We also have problems with NSDecimalNumber and NSNumberFormatter. The
> later may be due to ICU bugs on MinGW.
>
> There is also a more general issue on MinGW. When compiling the source
> we get plenty of warnings. These are caused by passing a char* pointer
> into Windows functions that expect wide characters. We introduced the
> type GSNativeChar to work around the issue that
> -fileSystemRepresentation should return a wide character pointer on
> Windows, but we need to use this type for all the temporary variables as
> well. Not sure, whether we should address this before the next release
> though.