headers
Richard Frith-Macdonald | 1 Sep 2010 13:24
Picon

[bug #30348] NSFileManager: copyItemAtURL:toURL:error: missing


Update of bug #30348 (project gnustep):

              Item Group:                     Bug => Change Request         

    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/bugs/?30348>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/
Permalink | Reply | 1 comment |
headers
Richard Frith-Macdonald | 1 Sep 2010 13:24
Picon

[bug #30346] NSFileManager: moveItemAtPath:toPath:error: missing


Update of bug #30346 (project gnustep):

              Item Group:                     Bug => Change Request         

    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/bugs/?30346>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/
Permalink | Reply | 1 comment |
headers
Richard Frith-Macdonald | 1 Sep 2010 13:36
Picon

[task #10592] Update NSFileManager to add OSX 10.5 and 10.6 compatibility


URL:
  <http://savannah.gnu.org/task/?10592>

                 Summary: Update NSFileManager to add OSX 10.5 and 10.6
compatibility
                 Project: GNUstep
            Submitted by: CaS
            Submitted on: Wed 01 Sep 2010 11:36:34 AM GMT
                Category: Foundation
         Should Start On: Wed 01 Sep 2010 12:00:00 AM GMT
   Should be Finished on: Wed 01 Sep 2010 12:00:00 AM GMT
                Priority: 5 - Normal
                  Status: None
                 Privacy: Public
        Percent Complete: 0%
             Assigned to: None
             Open/Closed: Open
         Discussion Lock: Any
                  Effort: 0.00

    _______________________________________________________

Details:

IN OSX 10.5 Apple deprecated various methods in NSFileManager adding new
methods with similar (though generally less powerful) ways to do the same
thing.
Mostly these mean having the new method fail and return an NSError object
rather than allowing a delegate to deal with problems.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Riccardo mottola | 1 Sep 2010 23:49
Picon

[bug #30863] Segfault problem on windows (all applications) NSTask/thread


Update of bug #30863 (project gnustep):

             Open/Closed:                 In Test => Closed                 

    _______________________________________________________

Follow-up Comment #8:

applications no longer crash, seems to be fixed.

    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/bugs/?30863>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/
Permalink | Reply | 0 comments |
headers
Georg Fleischmann | 2 Sep 2010 10:41
Picon
Favicon

Fix GDL2, some include updates with current gnustep-base on Mac

Hi,

attached are three small patches for GDL2 (SVN from 2010-08-28) to replace a header (#include
<GNUstepBase/GSCategories.h>) which is no more in gnustep-base:

In EOCheapArray.m, I replaced #include <GNUstepBase/GSCategories.h> with two other includes.
In EODetailDataSource.m and EOMutableKnownKeyDictionary.m, I just added #include
<GNUstepBase/NSDebug+GNUstepBase.h> to fix the implicit declaration error of the missing macros.
I think there are a few other places where GSCategories.h is not found, but without consequences.

* EOControl/EOCheapArray.m
* EOControl/EOMutableKnownKeyDictionary.m
* EOControl/EODetailDataSource.m
include of <GNUstepBase/GSCategories.h> replaced by
<GNUstepBase/NSDebug+GNUstepBase.h> and <GNUstepBase/NSThread+GNUstepBase.h>

Best wishes,
Georg Fleischmann

C
C  Georg Fleischmann <Georg.Fleischmann <at> vhf.de>
C  vhf interservice GmbH
C
C  Cenon - Graphics Software with Style
C  Computer Aided Manufacturing
C  Research and Development of Fractal Technology
C
C  Im Marxle 3, 72119 Altingen, Germany
C  the vhf group - http://www.vhf.de
C
(Continue reading)

Permalink | Reply | 0 comments |
headers
Georg Fleischmann | 2 Sep 2010 10:41
Picon
Favicon

Fix GDL2, EODatabaseContext (-recordChangesInEditingContext)

Hi,

attached is a tiny patch for GDL2 (SVN from 2010-08-28) to fix an exception for toMany relationships.
Just a little 's' is missing.

* EOAccess/EODatabaseContext ([EODatabaseContext(EOCooperatingObjectStoreSupport) -recordChangesInEditingContext]):
for isToMany relationships, call (with 's' !):
-relayAttributesInRelationship:sourceObject:destinationObjects:

Best wishes,
Georg Fleischmann

C
C  Georg Fleischmann <Georg.Fleischmann <at> vhf.de>
C  vhf interservice GmbH
C
C  Cenon - Graphics Software with Style
C  Computer Aided Manufacturing
C  Research and Development of Fractal Technology
C
C  Im Marxle 3, 72119 Altingen, Germany
C  the vhf group - http://www.vhf.de
C
C  fon: 07032 / 97097-0
C  fax: 07032 / 97097-50
C  eMail: service <at> vhf.de
C
C  Amtsgericht Stuttgart HRB 382014
C  Geschäftsleitung: Georg Fleischmann
C
(Continue reading)

Permalink | Reply | 0 comments |
headers
Georg Fleischmann | 4 Sep 2010 09:06
Picon
Favicon

Fix GDL2, EODatabaseContext (_fireArrayFault:)

Hi,

attached is another little patch for EODatabaseContext (_fireArrayFault:) to prevent an exception,
when the fault object turns into a real object before it is passed to -clearFault:.

In my case 'object' is a fault before the following call, but turns into a real object within:
      objects = [context objectsForSourceGlobalID: gid
			 relationshipName: relationshipName
			 editingContext: context];

To prevent an exception in this case I test, if object is still a fault before calling -clearFault:.

* EOAccess/EODatabaseContext ([EODatabaseContext -_fireArrayFault:]):
test if object is still a fault before calling -clearFault:

Best wishes,
Georg Fleischmann

*** EOAccess/EODatabaseContext.m.old	2010-09-02 16:01:45.000000000 +0800
--- EOAccess/EODatabaseContext.m	2010-09-04 13:56:33.000000000 +0800
***************
*** 4884,4890 ****
  			 relationshipName: relationshipName
  			 editingContext: context];

!       [EOFault clearFault: object]; //??
        /* in clearFault 
           [handler faultWillFire:object];
           targetClass=[handler targetClass];
--- 4884,4891 ----
(Continue reading)

Permalink | Reply | 0 comments |
headers
Georg Fleischmann | 5 Sep 2010 10:23
Picon
Favicon

Fix GDL2, EODatabaseContext (-objectsWithFetchSpecification:editingContext:)

Hi,

I am working on getting my applications running with the latest SVN version of GDL2. It seems that GDL2 is
always locking everything now (that was different in 0.12.0).
The first thing that happens in [EODatabaseContext
-objectsWithFetchSpecification:editingContext:] when fetching an object is locking:

  if (_flags.beganTransaction == NO)
  {
    [_adaptorContext beginTransaction];

    _flags.beganTransaction = YES;
  }

To fix this, I added a check for pessimistic locking (see attached patch).
That seems to fix my problems.

* EOAccess/EODatabaseContext ([EODatabaseContext -objectsWithFetchSpecification:editingContext:]):
call beginTransaction only for pessimistic locking

Best wishes,
Georg Fleischmann

*** EOAccess/EODatabaseContext.m.old	2010-09-04 13:56:33.000000000 +0800
--- EOAccess/EODatabaseContext.m	2010-09-05 15:01:56.000000000 +0800
***************
*** 1544,1550 ****

  	channel = [self _obtainOpenChannel];
(Continue reading)

Permalink | Reply | 1 comment |
headers
Riccardo mottola | 7 Sep 2010 00:58
Picon

[bug #30837] [gorm] fails to parse class header


Follow-up Comment #1, bug #30837 (project gnustep):

the problem occours if a pointer is written this way:

IBOutlet Class* myVar

instead of:

IBOutlet Class *myVar

    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/bugs/?30837>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/
Permalink | Reply | 0 comments |
headers
Riccardo mottola | 7 Sep 2010 23:23
Picon

[bug #30992] [gorm] image resource handling


URL:
  <http://savannah.gnu.org/bugs/?30992>

                 Summary: [gorm] image resource handling
                 Project: GNUstep
            Submitted by: rmottola
            Submitted on: Tue 07 Sep 2010 09:23:14 PM GMT
                Category: Gorm
                Severity: 1 - Wish
              Item Group: None
                  Status: None
                 Privacy: Public
             Assigned to: None
             Open/Closed: Open
         Discussion Lock: Any

    _______________________________________________________

Details:

It would be useful and convenient to be able to use (for example when adding
static images) the images in the Resources of a project. This makes
maintenance easier, allows reusage and makes copying of the images inside gorm
(thus creating a optential out-of-date copy) unnecessary.

IB supports this and when Gorm loads NIB files created this way it looses /
misses the images.

    _______________________________________________________
(Continue reading)

Permalink | Reply | 0 comments |

Gmane