strnstr errors in tests while on NetBSD
Hi, while building tests on NetBSD/sparc I saw that many tests failed for this reason: build.m:7:1: error: conflicting types for 'strnstr' strnstr(const uint8_t *buf, unsigned len, const uint8_t *str) ^ In file included from /home/multix/gnustep-svc/libs-base/Headers/GNUstepBase/GSConfig.h:430:0, from /home/multix/gnustep-svc/libs-base/Headers/GNUstepBase/GSVersionMacros.h:224, from /home/multix/gnustep-svc/libs-base/Headers/Foundation/Foundation.h:30, from build.m:2: /usr/include/string.h:107:7: note: previous declaration of 'strnstr' was here char *strnstr(const char *, const char *, size_t); they don't even build. Riccardo
Re: Base - color pparsing bug - Was: [Re: GNUstep releases this month?]
Hi! Richard Frith-Macdonald wrote: > Never mind, I found/fixed it. Rather than waiting to find out what > 'something like' meant exactly, I just tried testing with 1 1 1 and with 0 0 0 > The problem was the second case ... I had placed a check in the code intended > to avoid assigning the result of the scan via a nul pointer, but rather than > checking the pointer i checked the result. > That would mean that, in the case where the scanned value was zero, the > result was not returned and the memory pointed to was undefined. oh.. I was still testing while you fixed it! You are one of the best ones! Tests on Intel: 2021-01-21 15:17:27.353 ScannerTest[3312:3312] parsed: 1.00, 1.00, 1.00 - isAtEnd? 1 2021-01-21 15:17:27.354 ScannerTest[3312:3312] parsed: 0.00, 0.00, 0.00 - isAtEnd? 1 Tests on Sparc: 2021-01-21 16:19:47.859 ScannerTest[20968:3930190728] parsed: 1.00, 1.00, 1.00 - isAtEnd? 1 2021-01-21 16:19:47.913 ScannerTest[20968:3930190728] parsed: 0.00, 0.00, 0.00 - isAtEnd? 1 once again.. the code was general, but SPARC was more sensitive I was proposing to add it to the test suite, but I saw you did with a later commit. Does it make sense to have both 1 & 0 as tests? I also confirm that now interface colors come up correctly on both SPARC32-bit and SPARC64bit. With Fred's fixes in GUI... SPARC64 is working fine again, I can launch several complex applications like GWorkspace and PRICE without spotting gross errors. Riccardo
Re: GNUstep releases this month?
Hi, Riccardo Mottola wrote: > 9236 Passed tests > 202 Failed tests > 46 Dashed hopes > 14 Skipped sets > 1 Failed file > 1 Failed build if the above is sparc32 on NetBSD 8.2, below we have amd64 on NetBSD 9.1 - always with GCC runtime. 7760 Passed tests 46 Failed files 32 Dashed hopes 8 Failed tests 1 Failed build It looks different... less failures but less passes?... I tried quite a bit to get David's libobcj2 runtime on NetBSD 9.1 IA-32 for further comparison but for now I failed in any way. For comparison, tests on linux, x86-64 and gcc runtime: 9465 Passed tests 33 Dashed hopes 12 Skipped sets All OK! looks good... although Skipped set: test01.m 82 ... library built without NSURLSession support ? Anyway, I see nothing blocking, I'd love to work with Richard to smooth out some tests in base.. see if really it is correct to skip/dash all those on Linux and then see if we can improve the situation on NetBSD, both amd64 and SPARC. However applications seem to work, so I think we resolved all most blocking issues. Thumbs up for a release if it is urgent! cheers, Riccardo
Re: [ML] Hosting of gnustep.org
> Am 21.01.2021 um 19:52 schrieb Ivan Vučica : > > On Tue, Jan 19, 2021 at 9:32 PM Svetlana Tkachenko > wrote: >> However, ideally, I would recommend that a mirror of all GitHub content is >> maintained elsewhere, in case this big company decides to ask for money, >> disappear, change hosting policies, or something else happens to it. > > Use `git clone`? > Indeed. That was one of the ideas Linus Thorvalds had in mind when designing git that everybody can maintain a mirror of all git.kernel.org content so that if the server breaks down there are enough copies around to restore it.
Re: GNUstep releases this month?
I'll wait for a thumbs-up. On Thu, Jan 21, 2021 at 2:02 PM Riccardo Mottola wrote: > > Hi, > > Fred Kiefer wrote: > > If this is really a recent bug, not something that went unnoticed for years > > as nobody uses SPARC processors any more, than the only possible change > > would be the float parsing change that Richard just made. No idea why this > > would fail on something as simple as „1“ or „0“ but this is SPARC specific > > so you probably should start of by using the test suit of base on that > > machine. > > > in the meanwhile, I did run the test suite: > > Working (before) > 9231 Passed tests > 207 Failed tests > 46 Dashed hopes > 14 Skipped sets >1 Failed file >1 Failed build > > Current: > > 9236 Passed tests > 202 Failed tests > 46 Dashed hopes > 14 Skipped sets >1 Failed file >1 Failed build > > so actually we "fixed" some tests :) :) > > > Riccardo > >
Re: [ML] Re: Hosting of gnustep.org
On Tue, Jan 19, 2021 at 9:32 PM Svetlana Tkachenko wrote: > However, ideally, I would recommend that a mirror of all GitHub content is > maintained elsewhere, in case this big company decides to ask for money, > disappear, change hosting policies, or something else happens to it. Use `git clone`?
Re: Base - color pparsing bug - Was: [Re: GNUstep releases this month?]
Hi, Fred Kiefer wrote: > In a previous mail you stated that str is something like „1 1 1“ or „0 0 0“. > The next step would be to write a short test program that feeds these strings > to the code above and outputs the values for r, g and b and of course the > result of isAtEnd. That should make it easy to track down the issue. But you > are the only one with a SPARC processor I prepared a test containing this: str = @"1 1 1"; scanner = [[NSScanner alloc] initWithString: str]; [scanner scanDouble: ]; [scanner scanDouble: ]; [scanner scanDouble: ]; isAtEnd = [scanner isAtEnd]; NSLog(@"parsed: %lf, %lf, %lf - isAtEnd? %d", r, g, b, isAtEnd); [scanner release]; str = @"0 0 0"; scanner = [[NSScanner alloc] initWithString: str]; [scanner scanDouble: ]; [scanner scanDouble: ]; [scanner scanDouble: ]; isAtEnd = [scanner isAtEnd]; NSLog(@"parsed: %lf, %lf, %lf - isAtEnd? %d", r, g, b, isAtEnd); [scanner release]; does this look reasonable? it looks to me. On intel I get an unexpected result: 2021-01-21 14:09:20.967 ScannerTest[26541:26541] parsed: 1.00, 1.00, 1.00 - isAtEnd? 1 2021-01-21 14:09:20.968 ScannerTest[26541:26541] parsed: 1.00, 1.00, 1.00 - isAtEnd? 1 which is consistent with SPARC: 2021-01-21 16:02:32.466 ScannerTest[5278:3930190648] parsed: 1.00, 1.00, 1.00 - isAtEnd? 1 2021-01-21 16:02:32.555 ScannerTest[5278:3930190648] parsed: 1.00, 1.00, 1.00 - isAtEnd? 1 but why not 0.0 the second time? Riccardo
Re: Base - color pparsing bug - Was: [Re: GNUstep releases this month?]
> On 21 Jan 2021, at 14:10, Richard Frith-Macdonald > wrote: > > > >> On 20 Jan 2021, at 19:48, Fred Kiefer wrote: >> >> >> >>> Am 20.01.2021 um 20:13 schrieb Riccardo Mottola >>> : >>> >>> Hi, >>> >>> Fred Kiefer wrote: > I will try to bisect - but I'd liek to track this down before a release, > especially knowing it is something done these last months. If this is really a recent bug, not something that went unnoticed for years as nobody uses SPARC processors any more, than the only possible change would be the float parsing change that Richard just made. No idea why this would fail on something as simple as „1“ or „0“ but this is SPARC specific so you probably should start of by using the test suit of base on that machine. >>> >>> >>> Yes... I confirm it is a recent commit and I tracked it down to this commit: >>> >>> >>> r23416 | richard.frith.macdonald | 2020-12-30 12:58:19 +0100 (Wed, 30 >>> Dec 2020) | 2 lines >>> >>> Remove internal GSScanInt and GSScanDouble functions after moving >>> functionality into the -scanDouble: method. Add private class method to >>> support scanning a string for a double without having to create a new >>> scanner each time (use a shared lock-protected, instance with resetting >>> of the string being scanned). >>> >>> before this, all color look fine. >>> >>> I'm running the tests to see if some specific failed tests can be >>> identified ... but apparently they run sequentially on only one CPU and >>> it takes hours >>> >>> Anyway having an exact commit is also a good start. >> >> >> OK, so it is this code in [NSColor colorFromString:] >> >> >> double r, g, b; >> NSScanner *scanner = [[NSScanner alloc] initWithString: str]; >> >> if ([scanner scanDouble: ] && >>[scanner scanDouble: ] && >>[scanner scanDouble: ] && >>[scanner isAtEnd]) >> >> In a previous mail you stated that str is something like „1 1 1“ or „0 0 0“. >> The next step would be to write a short test program that feeds these >> strings to the code above and outputs the values for r, g and b and of >> course the result of isAtEnd. That should make it easy to track down the >> issue. But you are the only one with a SPARC processor. > > Looks interesting ... do we have the data this is failing on anywhere? > If I can get a testcase to debug I can see what's going on. Never mind, I found/fixed it. Rather than waiting to find out what 'something like' meant exactly, I just tried testing with 1 1 1 and with 0 0 0 The problem was the second case ... I had placed a check in the code intended to avoid assigning the result of the scan via a nul pointer, but rather than checking the pointer i checked the result. That would mean that, in the case where the scanned value was zero, the result was not returned and the memory pointed to was undefined.
Re: Base - color pparsing bug - Was: [Re: GNUstep releases this month?]
> On 20 Jan 2021, at 19:48, Fred Kiefer wrote: > > > >> Am 20.01.2021 um 20:13 schrieb Riccardo Mottola : >> >> Hi, >> >> Fred Kiefer wrote: I will try to bisect - but I'd liek to track this down before a release, especially knowing it is something done these last months. >>> If this is really a recent bug, not something that went unnoticed for years >>> as nobody uses SPARC processors any more, than the only possible change >>> would be the float parsing change that Richard just made. No idea why this >>> would fail on something as simple as „1“ or „0“ but this is SPARC specific >>> so you probably should start of by using the test suit of base on that >>> machine. >> >> >> Yes... I confirm it is a recent commit and I tracked it down to this commit: >> >> >> r23416 | richard.frith.macdonald | 2020-12-30 12:58:19 +0100 (Wed, 30 >> Dec 2020) | 2 lines >> >> Remove internal GSScanInt and GSScanDouble functions after moving >> functionality into the -scanDouble: method. Add private class method to >> support scanning a string for a double without having to create a new >> scanner each time (use a shared lock-protected, instance with resetting >> of the string being scanned). >> >> before this, all color look fine. >> >> I'm running the tests to see if some specific failed tests can be >> identified ... but apparently they run sequentially on only one CPU and >> it takes hours >> >> Anyway having an exact commit is also a good start. > > > OK, so it is this code in [NSColor colorFromString:] > > > doubler, g, b; > NSScanner *scanner = [[NSScanner alloc] initWithString: str]; > > if ([scanner scanDouble: ] && > [scanner scanDouble: ] && > [scanner scanDouble: ] && > [scanner isAtEnd]) > > In a previous mail you stated that str is something like „1 1 1“ or „0 0 0“. > The next step would be to write a short test program that feeds these strings > to the code above and outputs the values for r, g and b and of course the > result of isAtEnd. That should make it easy to track down the issue. But you > are the only one with a SPARC processor. Looks interesting ... do we have the data this is failing on anywhere? If I can get a testcase to debug I can see what's going on.
Re: GNUstep releases this month?
Hi, Fred Kiefer wrote: > If this is really a recent bug, not something that went unnoticed for years > as nobody uses SPARC processors any more, than the only possible change would > be the float parsing change that Richard just made. No idea why this would > fail on something as simple as „1“ or „0“ but this is SPARC specific so you > probably should start of by using the test suit of base on that machine. in the meanwhile, I did run the test suite: Working (before) 9231 Passed tests 207 Failed tests 46 Dashed hopes 14 Skipped sets 1 Failed file 1 Failed build Current: 9236 Passed tests 202 Failed tests 46 Dashed hopes 14 Skipped sets 1 Failed file 1 Failed build so actually we "fixed" some tests :) :) Riccardo
Re: Building GNUstep for Windows using Clang
Hi,
On 20/01/2021 20:30, Frederik Seiffert wrote:
There’s one more issue though: both [Test class] and [Test new] (with "Test"
being defined in the DLL) only return null pointers in my testing. However subclassing
the Test root class locally works fine and allows instantiating the subclass, as does a
locally defined root class (same implementation as Test).
The following code (with "Sub" being a subclass of "Test"):
printf("%p %p\n", [Test class], [Test new]);
printf("%p %p\n", [Sub class], [Sub new]);
Prints:
7FF73EDB0080 0291D99247A8
Any idea? All other things I tried so far seemed to be working fine, though I’m
sure this won’t be the last of my questions...
I think I misrememberd some details of the Windows ABI. I wrote a
little test compilation unit to look at it:
```obj-c
__attribute__((dllimport))
@interface Test
+ (id)new;
@end
@interface Sub : Test @end
@implementation Sub
+ (id)new
{
return (void*)1;
}
@end
int main(void)
{
[Test new];
[Sub new];
}
```
And compiled it with:
clang11 -S -fobjc-runtime=gnustep-2.0 -target x86_64-pc-windows-msvc
-O1 -o - msg.m -emit-llvm
This generates a global like this:
```llvm
@"$_OBJC_CLASS_Test" = external dllimport global i8*
```
This is a dllimport'd global, so one that can be referenced in the
instruction stream and will have relocations applied. It can't be
referenced in a global and so there's an `.objc_early_init` function
generated that initialises the isa pointer of the `Sub` class.
The message sends both directly load from the `_REF_` class pointer,
which is declared like this:
```llvm
@"$_OBJC_REF_CLASS_Test" = external dllimport local_unnamed_addr global i8*
```
So this has a canonical home in the DLL that owns the class and every
other message send must indirect via that. Without the dllimport
qualifier, clang generates:
```llvm
@"$_OBJC_CLASS_Test" = external global i8*
@"$_OBJC_REF_CLASS_Test" = external local_unnamed_addr global i8*
```
These are both local to the DLL or EXE that contains them and won't be
correctly initialised.
It looks as if you are missing the dllimport attribute on the classes
that you're referencing from another DLL.
In WinObjC, all of the classes are decorated with a macro that does the
normal Windows dance of expanding to dllimport normally and dllexport
when you are building the DLL that they come from. These are missing
from GNUstep, I'm not sure if you added them in your branch.
David
