[Gnustep-cvs] GNUstep Testfarm Results
Test results for GNUstep as of Fri Jun 17 06:34:09 EDT 2005 If a particular system failed compilation, the logs for that system will be placed at ftp://ftp.gnustep.org/pub/testfarm If you would like to add your machine to this list, set up a cron job (make sure you set up your PATH and other environment variables correctly) to run the Startup/scripts/test-gnustep script (see the script comments for more info). Success Compile i386-unknown-netbsdelf2.0.2 Fri Jun 17 03:58:20 CEST 2005 Success Compile powerpc-apple-darwin7.9.0 Thu Jun 16 04:41:40 MDT 2005 Success Compile sparc-sun-solaris2.7 Fri Jun 17 02:08:10 EDT 2005
Re: Release check
Adam Fedor wrote: On Jun 16, 2005, at 1:20 PM, Adam Fedor wrote: I looked into this. One issue is that objc/Object.h is needed by NSConnection.h, because it declares a category of Object. Is there a reason why this is there? @interface Object (NSPortCoder) - (Class) classForPortCoder; - (id) replacementObjectForPortCoder: (NSPortCoder*)aCoder; @end Well, to answer my own question. No. It appears they're just informal protocols, so the root object doesn't matter. Thanks for looking into this! Cheers, David ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
[Gnustep-cvs] gnustep dev-apps/test/Testsuite/gdl2/GDL2Testin...
CVSROOT:/cvsroot/gnustep Module name:gnustep Branch: Changes by: matt rice [EMAIL PROTECTED] 05/06/17 14:46:37 Modified files: dev-apps/test/Testsuite/gdl2: GDL2Testing.h dev-libs/gdl2/EOAccess: EOEntity.m EOModel.m dev-libs/gdl2 : ChangeLog dev-apps/test/Testsuite: ChangeLog Added files: dev-apps/test/Testsuite/gdl2/EOModel: test05.m Log message: * dev-apps/test/Testsuite/gdl2/GDL2Testing.h: Include ObjectTesting.h instead of stuff.h. * dev-apps/test/Testsuite/gdl2/EOModel/test05.m: New test for -removeEntity:. * dev-libs/gdl2/EOAccess/EOEntity.m (-_setModel:): Accept nil argument, comment. * dev-libs/gdl2/EOAccess/EOModel.m (-removeEntity:): Comment. CVSWeb URLs: http://savannah.gnu.org/cgi-bin/viewcvs/gnustep/gnustep/dev-apps/test/Testsuite/gdl2/GDL2Testing.h.diff?tr1=1.1.1.1tr2=1.2r1=textr2=text http://savannah.gnu.org/cgi-bin/viewcvs/gnustep/gnustep/dev-apps/test/Testsuite/gdl2/EOModel/test05.m?rev=1.1 http://savannah.gnu.org/cgi-bin/viewcvs/gnustep/gnustep/dev-libs/gdl2/EOAccess/EOEntity.m.diff?tr1=1.42tr2=1.43r1=textr2=text http://savannah.gnu.org/cgi-bin/viewcvs/gnustep/gnustep/dev-libs/gdl2/EOAccess/EOModel.m.diff?tr1=1.30tr2=1.31r1=textr2=text http://savannah.gnu.org/cgi-bin/viewcvs/gnustep/gnustep/dev-libs/gdl2/ChangeLog.diff?tr1=1.232tr2=1.233r1=textr2=text http://savannah.gnu.org/cgi-bin/viewcvs/gnustep/gnustep/dev-apps/test/Testsuite/ChangeLog.diff?tr1=1.1.1.1tr2=1.2r1=textr2=text
Re: GNUstep improvements bounty
Alex Perez has suggested using some of the funds that GNUstep has (and/or directed donations from individuals) to fund a part-time programmer to improve GNUstep. Some specific projects include CoreData and Predicates. Are other people interested in seeing these things added to GNUstep? Btw, how much does an advert on slashdot cost ? ;-) ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Release check
On Jun 17, 2005, at 5:04 AM, David Ayers wrote: Adam Fedor wrote: On Jun 16, 2005, at 1:20 PM, Adam Fedor wrote: I looked into this. One issue is that objc/Object.h is needed by NSConnection.h, because it declares a category of Object. Is there a reason why this is there? @interface Object (NSPortCoder) - (Class) classForPortCoder; - (id) replacementObjectForPortCoder: (NSPortCoder*)aCoder; @end Well, to answer my own question. No. It appears they're just informal protocols, so the root object doesn't matter. Thanks for looking into this! Yep. After making the change and a few minor warnings in gui and back, I didn't have to make any changes to anything else I tried (Gorm, ProjectCenter, gstep-guile, SQLClient, Renaissance, StepTalk, GWorkspace, ). So i'll probably commit it soon. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
[Gnustep-cvs] gnustep/core/gui ChangeLog Source/NSPopUpButton...
CVSROOT:/cvsroot/gnustep Module name:gnustep Branch: Changes by: Adam Fedor [EMAIL PROTECTED] 05/06/17 14:55:48 Modified files: core/gui : ChangeLog core/gui/Source: NSPopUpButtonCell.m Log message: * Source/NSPopUpButtonCell.m (-setObjectValue:): Use respondsToSelector. CVSWeb URLs: http://savannah.gnu.org/cgi-bin/viewcvs/gnustep/gnustep/core/gui/ChangeLog.diff?tr1=1.2539tr2=1.2540r1=textr2=text http://savannah.gnu.org/cgi-bin/viewcvs/gnustep/gnustep/core/gui/Source/NSPopUpButtonCell.m.diff?tr1=1.69tr2=1.70r1=textr2=text
Key-Value Observing implementation
Hi. I'm working on a CoreData implementation for GNUstep, but that depends on the Key-Value Observing feature. Is somebody already working on it, or may I start it? ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: GNUstep improvements bounty
Am Freitag, 17.06.05 um 14:06 Uhr schrieb Stefan Urbanek: Citt Riccardo [EMAIL PROTECTED]: snip I stress my point that it is only for the time being that I would stress the importance of completing and stabilizing -core before adding more meat to the fire. You port your mega-app to gnustep thanks to coredata and coreimage and then discover it is unreliable in operation because of some bug deep in -core ? wouldn't you be frustrated? This unreliable application will discover bugs that would not be discovered without this application. How can you find and fix all bugs in gnustep? You can: - Invest in full GNUstep testsuite for every feature. Is that doable in a reasonable time with reasonable number of resources? Are you able to identify all features that sohuld be teste? Are you able to identify all cases? If not, how you can be sure that the most important bugs are fixed? Some bugs are not visible at first look. - Or you can explore the code by yourself, looking at each line of code. Can anyone do that? - Or you can create or port bunch of applications and see what is wrong then fix it. The last option will kill two flies with a single hit. New applications may help in the first run, but what usually happens with software is that you introduce new bugs when trying to fix some (think of the NSTableView issues lately). While it is possible to discover those bugs with those new applications the problem here is the unsystematic procedure: All cases need to be tested by hand, so some cases will be forgotten easily or only discovered by chance later on. This is the point were a test suite comes in handy: You'll run all tests automatically and unattended, you can see the results later in a protocol nicely grouped for every architecture you test. Premise is of course that the testcases are well-kept, every bug report will be required to have a test case generated which exposes the bug and so on. This requires, some might hate this word here, some discipline. A good idea is to have a look into the software development process which the GCC team employs: - There is a main line and release branches in the CVS. At a given point in time the main line goes into a bug fixing mode where nothing else than bug fixing is permitted. Only if the number of open bugs goes below a certain limit a release branch is created where no new features but bug fixes are allowed within. Only now the addition of new features to the main line are allowed. Bug fixes must be back ported to main line too. - Also in use by the GCC team is a elaborate review process: Unless you are maintainer for a certain section you're not allowed to commit an unreviewed patch to GCC, but you have to prove that you don't reintroduce older already fixed bugs (regressions) by running the test suites and get the o.k. for the patch by someone with reviewing authority for a certain section which ensures code quality. This was only a short introduction into the software quality assurance process employed by the GCC team. It is described more detailed here: http://gcc.gnu.org/contribute.html Well this all sounds annoying and if all the fun will be taken away from your hobby, this will be the only way to increase software quality of GNUstep. And never forget: If you want to collect stamps as your hobby (for instance), you can't do that on the floor or even in your bed since the results will be disappointing. You'll need a table and some tweezers at least. Also, I think that trying to focus on perfecting GNUstep is a waste of time. Perfection will come together with usage and evolution(*). GNUstep already is perfect enough to be used. Any additional bit of perfection will not attract any new user to GNUstep, nor will motivate new developers to develop for GNUstep. No, this only results in workarounds piled on other workarounds (somewhat the situation we have now) and at some point the whole thing will colapse because nobody knows any longer why several things are done in a certain fashion. I strongly disagree (and I already have worked on a lot commercial solutions that suffered from exactly that to know that this is the software hell (mostly JAVA/J2EE/WO projects that I do for my job)). Therefore I vote for new frameworks, be them GNUstep innovations or ported frameworks. They will move GNUstep forward, will add new value, will find new bugs, will attract and motivate new developers. Core will be fixed, I am not worried about that. No, exactly that is wrong. This would give the new frameworks a broken foundation which is very hard to fix later on. Stefan Urbanek regards, Lars ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: GNUstep improvements bounty
On 2005-06-17 20:16:16 +0100 Lars Sonchocky-Helldorf [EMAIL PROTECTED] wrote: Am Freitag, 17.06.05 um 14:06 Uhr schrieb Stefan Urbanek: Citt Riccardo [EMAIL PROTECTED]: snip Also, I think that trying to focus on perfecting GNUstep is a waste of time. Perfection will come together with usage and evolution(*). GNUstep already is perfect enough to be used. Any additional bit of perfection will not attract any new user to GNUstep, nor will motivate new developers to develop for GNUstep. No, this only results in workarounds piled on other workarounds (somewhat the situation we have now) and at some point the whole thing will colapse because nobody knows any longer why several things are done in a certain fashion. I strongly disagree (and I already have worked on a lot commercial solutions that suffered from exactly that to know that this is the software hell (mostly JAVA/J2EE/WO projects that I do for my job)). I agree with your view here (though not the assessment that we currently have workarounds piled on workarounds ... I think such thing in the core libraries is very rare, though the focus handling code might still be a case in point.) and I believe that it is policy of core developers to try their best to ensure that the *correct* solutions are found rather than quick hacks being put in. This has been what we have been trying to do for years (since mGstep was forked from GNUstep, partly because its author wanted to stick with workarounds, while the majority of developers wanted clean rewrites of broken code), and has IMO been an important factor in the current success of GNUstep. Certainly the determination to fix problems correctly (and use regression testing ... something the base library has, but has been difficult to achieve for the gui) has been a major factor in improving the code. Going back to basic errors and fixing them is a much faster way to progress in the long run than continually adding workarounds. I aso agree that you can't depend on bugs showing up in applications ... if bugs break applications too often, people just won't upgrade the core libraries ... so the bugs won't show up in the applications. Therefore I vote for new frameworks, be them GNUstep innovations or ported frameworks. They will move GNUstep forward, will add new value, will find new bugs, will attract and motivate new developers. Core will be fixed, I am not worried about that. No, exactly that is wrong. This would give the new frameworks a broken foundation which is very hard to fix later on. Yes ... but it's not fun or glamorous ... we have to have a combination of both ... but I think, in the context of *paying* someone to do things rather than expecting them to do it for fun, we would be best off getting people to produce more regression tests, and review existing code behavior to ensure that it is correct (and the same as Apple's code unless their is clearly wrong). They could add/improve documentation at the same time as doing code review. Let's leave the adding of new frameworks etc for people to volunteer to work on and enjoy, rather than paying for them. Of course, picking out the highest priority areas for code review is a tricky problem in itsself. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
