Re: Archiving tests...
On 23.03.2013 15:12, Fred Kiefer wrote: On 23.03.2013 07:09, Richard Frith-Macdonald wrote: On 22 Mar 2013, at 19:58, Gregory Casamento wrote: I think putting tests in GUI for archiving is important since the point is not so much to test the archiver itself but that the GUI classes are, indeed, archiving themselves in a way which is universal for all platforms. Sure ... my point was simply that we already have them built in to the test framework itsself ... so the GUI testsuite should use the functionality we already have. The current coding testing functions test whether the decoded object is the same as the original object by calling -isEqual: For classes where the standard equlity test isn't enough we can implement -isEqualAfterCoding: in a category on the class. Of course, no standardised test code can possibly cope with all situations, but I'd recommend you start by calling test_NSCoding() and test_keyed_NSCoding() for all the GUI classes, then think about how things might be extended to handle any special cases. Thank you for providing this new method. I used to override the isEqual: method for the current gui coding tests, but will switch to the new method now. This didn't work out. For NSBezierPath even the copying tests fail when I use your new -isEqualAfterCoding: method. I tried under MacOS and there the behaviour is the same. I think the best solution would be to use the same method for the equality check on copies as well. It looks like Apple has a very strict understanding of equality for gui classes. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Cambridge Hackathon
Hey David, Sorry, another of my extraordinarily late replies :-( I'd love to come out for this. Some time in late June / early July sounds good. Cheers, Eric On 2013-02-22, at 6:40 AM, David Chisnall wrote: > Hi Everyone, > > Since we didn't get a DevRoom at FOSDEM this year, there was some discussion > about having a hackathon in Cambridge. The term finishes on the 18th of > June, after which it is likely to be a lot easier to put people up in college > accommodation. Who would be interested, and what are your date preferences? > > David > > > -- Sent from my IBM 1620 > > > ___ > Gnustep-dev mailing list > Gnustep-dev@gnu.org > https://lists.gnu.org/mailman/listinfo/gnustep-dev ___ Gnustep-dev mailing list Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Archiving tests...
On 23.03.2013 07:09, Richard Frith-Macdonald wrote: On 22 Mar 2013, at 19:58, Gregory Casamento wrote: Richard, I think putting tests in GUI for archiving is important since the point is not so much to test the archiver itself but that the GUI classes are, indeed, archiving themselves in a way which is universal for all platforms. Sure ... my point was simply that we already have them built in to the test framework itsself ... so the GUI testsuite should use the functionality we already have. The current coding testing functions test whether the decoded object is the same as the original object by calling -isEqual: For classes where the standard equlity test isn't enough we can implement -isEqualAfterCoding: in a category on the class. Of course, no standardised test code can possibly cope with all situations, but I'd recommend you start by calling test_NSCoding() and test_keyed_NSCoding() for all the GUI classes, then think about how things might be extended to handle any special cases. Thank you for providing this new method. I used to override the isEqual: method for the current gui coding tests, but will switch to the new method now. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Sum up of current failures
On 23.03.2013 09:11, Richard Frith-Macdonald wrote: On 22 Mar 2013, at 17:03, Riccardo Mottola wrote: Richard Frith-Macdonald wrote: On 22 Mar 2013, at 13:24, Riccardo Mottola wrote: How can I run a specific test, so that I can test NSCalendar and NSXMLNode ? gnustep-tests --help will tell you how to run tests, along with various useful options (I particularly like --debug ... runs gdb with breakpoints set immediately before failed tests) I checked the XML tests on OpenBSD and they pass. Thus strangely they only fail on NetBSD. Still, the hangs and the failures should be looked into before a release? What information can I give you for debugging, except ther esults which aren't very explicative? It's difficult with system specific failures ... really you need to do the debugging on your system. That is .. you need to run the tests with the --debug option, and then step through the code in the debugger to see what's actually going wrong. That should be enough to find most things, but of course, there's also the possibility that an underlying problem actually occurred before the testcase itsself ... in which case you need to look at the objects involved at the start of the test to see if they are in some unexpected state. I think I found the root of this issue. On 2012-12-01 I made a change to NSXMLNode that used a macro for newer releases of libxml2. But I could not check that on my machine as the version of libxml2 I was using was too old. As it turns out that change was completely wrong. libxml2 uses two different buffer structures xmlBufPtr and xmlBufferPtr, only for the former that change was needed, but here we are using the later. Reverting that change solved the problem for me. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Sum up of current failures
On 22 Mar 2013, at 17:03, Riccardo Mottola wrote: > Richard Frith-Macdonald wrote: >> On 22 Mar 2013, at 13:24, Riccardo Mottola wrote: >>> How can I run a specific test, so that I can test NSCalendar and NSXMLNode ? >> gnustep-tests --help >> >> will tell you how to run tests, along with various useful options (I >> particularly like --debug ... runs gdb with breakpoints set immediately >> before failed tests) >> > I checked the XML tests on OpenBSD and they pass. Thus strangely they only > fail on NetBSD. > > Still, the hangs and the failures should be looked into before a release? > What information can I give you for debugging, except ther esults which > aren't very explicative? It's difficult with system specific failures ... really you need to do the debugging on your system. That is .. you need to run the tests with the --debug option, and then step through the code in the debugger to see what's actually going wrong. That should be enough to find most things, but of course, there's also the possibility that an underlying problem actually occurred before the testcase itsself ... in which case you need to look at the objects involved at the start of the test to see if they are in some unexpected state. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev
