Mon 02 Jan 2006 07:36:38 PM UTC, comment #12:
Argh.
'openapp Gorm -GSFilePath ~/Entwicklung/objc/Calendar/Resources/Calendar.gorm' -> "NSInvalidArgumentException: GormDocument(class) does not recognize readableTypes." -> Abort.
This one is mystifying me.. the compiler doesn't complain and readableTypes is a class method, so why isn't it recognized?
|
Sun 18 Dec 2005 01:17:36 PM UTC, comment #11:
Originally submitter tested and found it working.
|
Sun 18 Dec 2005 10:05:51 AM UTC, comment #10:
Works. :)
|
Sat 17 Dec 2005 02:24:01 PM UTC, comment #9:
Made a further correction in CVS. Try it again please.
|
Thu 15 Dec 2005 04:44:20 PM UTC, comment #8:
You forgot that 'objects.gorm' is also a gorm file -- it still crashes with that. Yes, it's an obscure bordercase nobody else is going to stumble over but it would be nice to have it fixed anyway.
|
Thu 15 Dec 2005 03:11:42 AM UTC, comment #7:
Good catch on this one. The problem stemmed from the fact that the document was being allocated and loadDocument called on the instance. When the unarchiver crashed (because the file isn't a gorm file) the state of the document object is inconsistent.
The solution was to externalize the check (as is done with NSDocument) and not to instantiate a document object, unless the type of file passed in warrents it.
Please test the version in CVS to make sure this is corrected. My tests here on Linux and FreeBSD work fine.
The workaround for Gorm 1.0.1 users is simply to avoid loading files which are not .gorm files from the command-line. :)
GJC
|
Tue 13 Dec 2005 10:48:15 PM UTC, comment #6:
You shouldn't load the objects.gorm file directly. I'm not exactly sure why there's a compulsion to do this, perhaps I'll add a warning or something like that to the code which will alert the user to the problem.
I will try to load some other file and see if it yields the problem you described.
Thanks, GJC
|
Tue 13 Dec 2005 09:11:05 PM UTC, comment #5:
Thanks for the libobjc hint :).
Silly me also forgot to mention that I don't open the .gorm "directory-file" but the objects.gorm file within >_>. Of course it works fine otherwise, sorry for the confusion.
Further testing revealed that Gorm crashes on exit with any file that is not the gorm directory-file it expected. Do a '/usr/local/GNUstep/System/Applications/Gorm.app/Gorm -GSFilePath randomfile', quit and see.
|
Tue 13 Dec 2005 06:40:57 AM UTC, comment #4:
Also tried the same test with Gorm and several files on FreeBSD 5.4. I currently don't have 6.0 installed, but will try that soon. In the meantime, please attach the .gorm file which you are using to this bug.
Thanks, GJC
|
Tue 13 Dec 2005 06:20:10 AM UTC, comment #3:
It should also be mentioned that the gnustep-objc library is not needed since you're using gcc 3.4.4. That version of the compiler has a newer version of libobjc.
gnustep-libobjc is meant to be used with older gcc compilers which don't have a working libobjc.
GJC
|
Tue 13 Dec 2005 05:56:17 AM UTC, comment #2:
I have tried both methods with a number of files on Linux and have been unable to recreate the problem using Gorm 1.0.1. I will compile and build on FreeBSD and check to see if there is a problem there.
Please attach the .gorm file you are having trouble with to this bug, if possible and I will test with that. GJC
|
Fri 09 Dec 2005 09:21:23 PM UTC, comment #1:
Forgot to add that I use Gorm 1.0.1.
|
Fri 09 Dec 2005 09:13:16 PM UTC, original submission:
'Directly' meaning using either 'gopen file.gorm' or 'Gorm.app -GSFilePath file.gorm'. Gorm complains about not being able to load those files directly and crashes when you try to quit.
Opening a .gorm file in the shelf or from within ProjectCenter works just fine.
OS: FreeBSD/x86 6.0
GCC version: 3.4.4 [FreeBSD] 20050518
Libraries:
- gnustep-back-0.10.1 (Standard backend)
- gnustep-base-1.11.1
- gnustep-gui-0.10.1
- gnustep-make-1.11.1
- gnustep-objc-1.4.0,1 ("A snapshot of libobjc, meant to be used with GNUstep")
|