bugGNUstep - Bugs: bug #25415, Gorm GDL2 objects vanish or cause...

 
 

You are not allowed to post comments on this tracker with your current authentication level.

bug #25415: Gorm GDL2 objects vanish or cause errors when loading nib when linked to ui components

Submitted by:  Peter Cooper <comrade>
Submitted on:  Mon 26 Jan 2009 09:10:07 PM UTC  
 
Category: gdl2Severity: 3 - Normal
Item Group: NoneStatus: Invalid
Privacy: PublicAssigned to: David Ayers <ayers>
Open/Closed: Declined

(Jump to the original submission Jump to the original submission)

Wed 25 Feb 2009 09:00:37 AM UTC, comment #7:

Hello Peter,

the we decided to remove the convenience makefile fragments. In fact GDL2 (and possibly GSWeb) were the only project installing them.

I figured since we all so use libGorm and Renaissance either we should all use these fragments and have a cascade of includes to track the dependencies or we delegate the responsibility to the developer using the code.

Personally I don't like either approach much. But more importantly the -make maintainer advised to remove the fragments since -make should be simple enough and I should unsure that the dependency is documented.

http://lists.gnu.org/archive/html/gnustep-dev/2009-02/msg00063.html [Thread discussing the issue]

I've added that Documentation to the README now. Therefor I shall close this report now. Thanks for your report though... it was important to clarify which way we should go.

David Ayers <ayers>
Project MemberIn charge of this item.
Fri 30 Jan 2009 04:37:09 PM UTC, comment #6:

Hi David

I'd only use gdl2-access.make (for tools) and gdl2-interface.make (for apps).

It wouldn't worry me if the other ones didn't exist or did. I think I'm fairly typical in this regard?

If you only have two, names like gdl2.make and gdl2-gui.make would be nice and short ;-)

Thanks!

Peter

Peter Cooper <comrade>
Thu 29 Jan 2009 08:04:56 AM UTC, comment #5:

Hello Peter, Hi Matt,

I'm currently at a trade fair so please excuse my late replies. As you suggested, the reason we cannot automagically link against all GDL2 frameworks is that for gsweb for example, we would start linking in EOInterface and -gui/AppKit which is something we definitely don't want.

I had originally considered installing something like separate gdl2-control.make, gdl2-access.make and gdl2-interface.make files, but all these files would contain solely the one line and an include of the dependent library. I figured thatadding the ADDITIONAL_NATIVE_LIBRARY was not really worth the extra files. But maybe it is from a usability standpoint.

So what would people think of the approach that we install 4 -make fragments:

gdl2.make - merely sets version variables
gdl2-control.make - contains ADDITIONAL_NATIVE_LIBRARY += EOControl
gdl2-access.make - includes gdl2-control.make and contains ADDITIONAL_NATIVE_LIBRARY += EOControl
gdl2-interface.make - includes gdl2-access.make and contains ADDITIONAL_NATIVE_LIBRARY += EOInterface

And then you application would simple include gdl2-interface.make

It seems a bit overkill to me, but maybe it would make it easier to handle? I do like to get it that issue stabilized though.

Cheers,
David

David Ayers <ayers>
Project MemberIn charge of this item.
Wed 28 Jan 2009 04:35:46 PM UTC, comment #4:

I was tracking Gorm/GDL2 from svn daily. (Your videos were perfectly timed for a proof-of-concept for one of my clients next week, thus the reason for my enthusiastic bug reports ;)

I think making the error messages more explicit are a good idea, possibly even better than documentation. Talking of documentation, I'll start updating the wiki with a couple of snippets.

My 2c on makefiles and linking below:

I have a preference for sensible behaviour from the make system. I don't have to explicitly link gnustep-gui for an app, and I'd prefer not to have to do the same for a gdl2 project either. Magic, thus in preference to making build scripts.

If I need something weird, I won't include the gdl2.make and I'll spec things out by hand.

But my test is if 99% of cases need the link flags in a standard way, then just do it. I see two use cases, one is tool-based, one is gui-based. And of course the hidden case, of GSW, I don't think a manual link definition for the list of libraries for that case should be necessary either!

Thanks for your help!

Peter Cooper <comrade>
Tue 27 Jan 2009 07:51:15 PM UTC, comment #3:

yeah Auxiliary/gdl2.make no longer provides the link flags, we just leave it up to the makefile to provide, i don't recall the exact reasons for removing them but I can make some up :)

other information is contained in gdl2.make and one might want to just check if gdl2 is installed, or the version installed and not really link to it at the top level, just using it to check it and enable compiling of subdirectories or something

that and as you mention gdl2.make previously just caused linking to EOAccess/EOControl and then we added EOInterface so what it should contain is under the interpretation of the program including it... so it was just easier to let the application decide what it is going to link to.

it also just seems like the more 'normal' behaviour, to just set what you want to link to, rather than including something which does some 'magic' which makes it work.

anyhow straying a little off topic,
are you also using gorm from svn? or a release?

matt rice <ratmice>
Project Member
Tue 27 Jan 2009 08:36:30 AM UTC, comment #2:

Ok - weird about the vanishing objects. When I look at the gorm nib in test2 I don't see the class names using strings on the nib after saving - but not linking them - to ui objects.

In the test3 nib, I see datasource, EODatabaseDataSource and fetch: in the strings output, but not in test2, yet I had dragged the items from DBModeler and inspected them in Gorm.

Many thanks for finding my error in not linking EOAccess, I linked just what was necessary for compile, and missed what was necessary for runtime.

An already-linked library is a fine idea, but otherwise shouldn't Auxiliary/gdl2.make provide link flags for EOAccess and EOControl? Perhaps an Auxiliary/gdl2app.make which provides link flags for EOInterface and includes Auxiliary/gdl2.make?

Many thanks for your help!

Peter Cooper <comrade>
Tue 27 Jan 2009 02:31:14 AM UTC, comment #1:

I am unable to reproduce the disappearing objects in gorm, whenever I drop things from DBModeler to Gorm, and save, and reload them the objects stay, if they are linked to anything or not.

as far as the 'Exception occured while loading model: decoded nil class' that is occuring because you aren't linking to EOAccess framework, and so it cannot find the EODatabaseDataSource class

I'd attempted to get EOInterface to link directly to these but it isn't working.. e.g. adding

ADDITIONAL_NATIVE_LIBS+=EOAccess EOControl
to EOInterface, but gnustep-make isn't doing anything with it.

note I see you use -lEOInterface in your makefile the above with the addition of EOInterface should work with gnustep-make under cocoa where GDL2 is compiled as a framework.

attached is a patch which tries to make that error message in base a little more descriptive and fixes the format on the original error, so that it outputs the class name.

(file #17337)

matt rice <ratmice>
Project Member
Mon 26 Jan 2009 09:10:07 PM UTC, original submission:

Gorm files containing GDL2 entities that are linked to the user interface fail at load time in applications. I receive the following errors:

Got nil when trying to unarchive class
Exception occured while loading model: decoded nil class
Failed to load Gorm
Could not load Gorm file: <filepath>
Cannot load the main model file '<relativepath>'

This occurs using a clean build of r27435 on Ubuntu 8.10/x86_64.

Steps to replicate:

1. Demonstrate that Gorm and test app work

1a. Open DBModeler, and create an entity. Create a key and a class variable and set the adaptor. Save the eomodel to disk.

1b. Open Gorm, and create a simple interface with a button to load the entity from a database. Save the gorm nib to disk in the same directory as the eomodel.

1c. Create a simple gui app. Compile and run in place. All should work as expected.

2. Gorm loses unlinked GDL2 objects when re-opening gorm nib later

2a. Drag the entity from the DBModeler into the object window of Gorm. Save the gorm nib.

2b. Clean, compile and run in place. The app should work as expected.

2c. Quit Gorm. Restart and open the gorm nib. The EOEditingContext and entity object are missing from the object window.

3. Application fails to load the gorm file when the entity is linked to an object in the user interface.

3a. In Gorm, link a button in the user interface to the entity's fetch target. Save the gorm nib.

3b. Clean, compile and run in place. The nib is not loaded for the application's interface.

3c. Quit Gorm. Restart and open the gorm nib. The EOEditingContext and entity object are visible in the object window.

I've attached the three different scenarios, and perhaps the second and third gorm nib files will give some clue about what's going on.

Peter Cooper <comrade>

 

Attached Files
file #17337:  foo.diff added by ratmice (424B - application/octet-stream)
file #17335:  nib-loading-error.tgz added by comrade (3KiB - application/x-compressed-tar - Test cases)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -unavailable- added by ayers (Posted a comment)
  • -unavailable- added by ratmice (Updated the item)
  • -unavailable- added by comrade (Submitted the item)
  •  

    Do you think this task is very important?
    If so, you can click here to add your encouragement to it.
    This task has 0 encouragements so far.

    Only logged-in users can vote.

     

    Please enter the title of George Orwell's famous dystopian book (it's a date):

     

     

    Follow 5 latest changes.

    Date Changed By Updated Field Previous Value => Replaced By
    Wed 25 Feb 2009 09:00:37 AM UTCayersStatusNone=>Invalid
      Assigned toNone=>ayers
      Open/ClosedOpen=>Declined
    Tue 27 Jan 2009 02:31:14 AM UTCratmiceAttached File-=>Added foo.diff, #17337
    Mon 26 Jan 2009 09:10:09 PM UTCcomradeAttached File-=>Added nib-loading-error.tgz, #17335

    Back to the top


    Powered by Savane 3.1-cleanup1