Considering Gorm 1.0.0
All, Please let me know if anyone has any thoughts about this. I would also like any feedback anyone has on any last minute features or bug fixes they feel should go into the app before the 1.0 release. Gorm has been very stable for the last few releases, so I'm considering that after the next stable release of core, that Gorm should follow this with a 1.0. Does anyone have any comments? Thanks, GJC Gregory John Casamento -- CEO/President Open Logic Corp. (A MD Corp.) ## Maintainer of Gorm (IB Equiv.) for GNUstep. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
[Gnustep-cvs] gnustep/usr-apps/gworkspace GWorkspace/GWorkspa...
CVSROOT:/cvsroot/gnustep Module name:gnustep Branch: Changes by: Enrico Sersale <[EMAIL PROTECTED]> 05/06/21 23:54:12 Modified files: usr-apps/gworkspace/GWorkspace: GWorkspace.m usr-apps/gworkspace/GWorkspace/Desktop/Dock: DockIcon.m usr-apps/gworkspace/GWorkspace/FileViewer: GWSpatialViewer.m usr-apps/gworkspace/Recycler: RecyclerIcon.m Log message: CVSWeb URLs: http://savannah.gnu.org/cgi-bin/viewcvs/gnustep/gnustep/usr-apps/gworkspace/GWorkspace/GWorkspace.m.diff?tr1=1.93&tr2=1.94&r1=text&r2=text http://savannah.gnu.org/cgi-bin/viewcvs/gnustep/gnustep/usr-apps/gworkspace/GWorkspace/Desktop/Dock/DockIcon.m.diff?tr1=1.4&tr2=1.5&r1=text&r2=text http://savannah.gnu.org/cgi-bin/viewcvs/gnustep/gnustep/usr-apps/gworkspace/GWorkspace/FileViewer/GWSpatialViewer.m.diff?tr1=1.28&tr2=1.29&r1=text&r2=text http://savannah.gnu.org/cgi-bin/viewcvs/gnustep/gnustep/usr-apps/gworkspace/Recycler/RecyclerIcon.m.diff?tr1=1.7&tr2=1.8&r1=text&r2=text
[Gnustep-cvs] gnustep/core/gui ChangeLog Source/NSMenu.m
CVSROOT:/cvsroot/gnustep Module name:gnustep Branch: Changes by: Fred Kiefer <[EMAIL PROTECTED]> 05/06/21 22:48:21 Modified files: core/gui : ChangeLog core/gui/Source: NSMenu.m Log message: Corrected handling of screen size for menu. CVSWeb URLs: http://savannah.gnu.org/cgi-bin/viewcvs/gnustep/gnustep/core/gui/ChangeLog.diff?tr1=1.2541&tr2=1.2542&r1=text&r2=text http://savannah.gnu.org/cgi-bin/viewcvs/gnustep/gnustep/core/gui/Source/NSMenu.m.diff?tr1=1.128&tr2=1.129&r1=text&r2=text
Re: [Gnustep-cvs] gnustep/core/gui ChangeLog Source/NSTableView.m
Quentin Mathé wrote: > Le 20 juin 05 à 00:05, Fred Kiefer a écrit : > >> I did not see any further reply to this mail from Matt, apart from my >> own. Does this mean that the patch is generally accepted or is just >> nobody interested? >> As I uggested I would like to see the cell tracking code as a new method >> on NSTableView. Something like: >> >> - (void) trackColumn: (int) columnIndex >> row: (int) rowIndex >>withEvent: (NSEvent *) theEvent > > I fully agree because I must admit I'm unable to understand current > code in this method (I'm not talking about Matt's patch). > >> I have to admit that I still con't quite understand the event handling >> concept. Let me try to rephrase it in my words and you may correct me >> later on: When getting a mouseDown event in the NSTableView, we need to >> find out if this is starting a dragging. Only if not we send on the >> event to the cell to start tracking. > > My main concern is the fact currently table view handles selection and > tracking on mouseUp for cells by default… but selection and tracking > should be handled on mouseDown event with cells, except when dragging > is turned on and the clicked cell returns NO for > trackMouse:inRect:ofView:untilMouseUp: or startTrackingAt:inView: > methods I think. That would match moreover current Cocoa behavior > (except the minor difference decided by Matt for dragging, I think it > is a better choice that Apple's one) > > To illustrate current issues with examples: > - you have no selection change on mouseDown currently when you click on > a table view with standard cells and dragging turned off (this feedback > absence is really problematic for a combobox because its popup window > is closed on mouseUp before the clicked row highlighting becomes > visible in table view) > - popup button cell doesn't show its menu on mouseDown (only on mouseUp) > - combobox cell doesn't support editing with current delayed tracking > model (but it could involve other issues too) > >> As we may have missed a few events >> whlie determining if this is a drag operation, the cell and the table >> view needs to get one more event to process from the application >> directly. >> If I understand you correctly you say that this is the behavour on >> Cocoa. Still it looks rather strang to me. On the other hand we should >> try to get dragging from table views working again for the next release >> and your patch is currently the only one. If nobody disagrees, I would >> submit this patch, with the separate tracking method and a few comments >> added. > > My objection to the patch would be it is introducing duplicated code > between NSLeftMouseDragged and NSLeftMouseUp handling with the new 'if > (draggingPossible == YES)' statement, without implementing true custom > cell support as a counterpart. > Anyway I think we can apply the patch, it works well in my test > (dragging seems to be fixed) even if it's probably a temporary solution > in my opinion… May be when code will be reorganised, we may start to > clean mouse events handling in a definitive way in order to support any > kind of cells correctly. > Just one still unclear idea: Dowe really have to dequeue the events we get in mouseDown:? If we would first get the event and see if there is a draggging event coming, we would let the cell do the dragging, if this is allowed, with the event still in the queue. And if there isn't an upcoming drag event we could dequeue the event and do normal processing in the table view. As I wrote, just an idea... Fred ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Problem implementing faults in Objective-C
On Jun 21, 2005, at 4:12 AM, Frederic Stark wrote: I am sending this to gnustep-dev crossposted to gcc. Maybe this isn't the right mailing list. See at the end of the post for a 40 line program that exhibit the bad behavior. Problem: If a is a fault (ie: changes its isa pointer during forwardInvocation), then: [a method1:[a method2]] fails (a does not recognize 'method1:'), while: I believe the GNU runtime looks up the IMP and then calls it rather than always calling a dispatch function. In this case, the code above is possibly getting miscompiled into something like IMP imp1 = getInstanceImp(a->isa, @selector(method1:)) IMP imp2 = getInstanceImp(a->isa, @selector(method2)) id result1 = imp2(a, @selector(method2)) id result2 = imp1(a, @selector(method1:), result1) That is, the lookup of the IMP for -method1: may be happening too early. The code works correctly under Mac OS X. The Apple runtime doesn't have this design choice, so it can't really have this problem. Am I doing something horribly wrong ? I don't think so; seems like a bug in the GNU ObjC runtime support in the compiler. I suppose the runtime maintainers might choose to define this as a bug in your code, but isa-swizzling is a fairly common and _extremely_ useful pattern in ObjC (see CoreData, NSZombie, etc.) so that'd not be my stance, obviously :) -tim ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Problem implementing faults in Objective-C
Timothy J. Wood wrote:
[crunch]
The code works correctly under Mac OS X.
I just checked under linux/gcc 3.4 and the code works fine there. Maybe
this is a gcc 3.2 specific problem. I'll check gcc 3.4 windows one of
those days.
The Apple runtime doesn't have this design choice, so it can't really
have this problem.
You are right. I just disassembled a small variation on the thing, and
gcc 3.2 generates:
0x401406 : push %ebp
0x401407 : mov%esp,%ebp
0x401409 : push %edi
0x40140a : push %esi
0x40140b : push %ebx
0x40140c : sub$0xc,%esp
0x40140f : sub$0x4,%esp
0x401412 :sub$0x4,%esp
0x401415 :push $0x4041f0
0x40141a :mov0x8(%ebp),%esi
0x40141d :push %esi
0x40141e :call 0x4017b0
0x401423 :add$0xc,%esp
0x401426 :mov%eax,%edi
0x401428 :sub$0x4,%esp
0x40142b :push $0x4041e8
0x401430 :mov0x8(%ebp),%ebx
0x401433 :push %ebx
0x401434 :call 0x4017b0
0x401439 :add$0x8,%esp
0x40143c :push $0x4041e8
0x401441 :push %ebx
0x401442 :call *%eax
0x401444 :add$0xc,%esp
0x401447 :push %eax
0x401448 :push $0x4041f0
0x40144d :push %esi
0x40144e :call *%edi
0x401450 :add$0x10,%esp
0x401453 :lea0xfff4(%ebp),%esp
0x401456 :pop%ebx
0x401457 :pop%esi
0x401458 :pop%edi
0x401459 :pop%ebp
0x40145a :ret
It looks like the two objc_msg_lookup are made before the actual call
(0x401442 and 0x40144e)
I don't think so; seems like a bug in the GNU ObjC runtime support in
the compiler. I suppose the runtime maintainers might choose to define
this as a bug in your code, but isa-swizzling is a fairly common and
_extremely_ useful pattern in ObjC (see CoreData, NSZombie, etc.) so
that'd not be my stance, obviously :)
As in my code the real classes are all subclass of a specific one, I
worked around the problem by implementing:
- (void)forwardInvocation:(NSInvocation *)anInvocation
{
if (![self respondsToSelector:[anInvocation selector]])
[super forwardInvocation:anInvocation];
[anInvocation invoke];
}
in the 'B' class.
Thanks for the help (and it have been a lng time since we last
exchanged emails on the omni dev list...)
--fred
___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Problem implementing faults in Objective-C
On Jun 21, 2005, at 1:20 PM, Frederic Stark wrote: Timothy J. Wood wrote: [crunch] The code works correctly under Mac OS X. I just checked under linux/gcc 3.4 and the code works fine there. Maybe this is a gcc 3.2 specific problem. I'll check gcc 3.4 windows one of those days. It is a 3.2 specific bug. This was fixed in 3.4.0 at least for sure with: 2003-09-24 Ziemowit Laski <[EMAIL PROTECTED]> MERGE OF objc-improvements-branch into MAINLINE. See 'gcc/ChangeLog' and 'gcc/testsuite/ChangeLog' for the gory details. mainly: Fix PR objc/11754 When cascading message together under GNU runtime, GCC was sending the inner message twice, this patch fixes that. Also adds a testcase for that case. And the patch: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/objc/objc-act.c.diff? r1=1.179.2.4&r2=1.179.2.2 Thanks, Andrew Pinski ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Problem implementing faults in Objective-C
Jeremy Bettis wrote: - Original Message - From: "Frederic Stark" <[EMAIL PROTECTED]> To: ; Sent: Tuesday, June 21, 2005 6:12 AM Subject: Problem implementing faults in Objective-C : Uncaught exception NSInvalidArgumentException, reason: B(instance) does not recognize method1: Ugh nasty hackery. Never ever edit your isa pointer. Try doing things right Right ? Changing the isa pointer is how NeXTstep EOFault worked. This is also what 'db' and 'gdl2' does. And it is what I need to do too. I would agree that it is not daily objc code, but it is something one have to do sometimes... Cheers, --fred ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Problem implementing faults in Objective-C
- Original Message -
From: "Frederic Stark" <[EMAIL PROTECTED]>
To: ;
Sent: Tuesday, June 21, 2005 6:12 AM
Subject: Problem implementing faults in Objective-C
: Uncaught exception NSInvalidArgumentException, reason: B(instance) does
not recognize method1:
Ugh nasty hackery. Never ever edit your isa pointer. Try doing things right
- (void)forwardInvocation:(NSInvocation *)anInvocation
{
B* theRealObj = [B new];
[anInvocation setTarget:theRealObj];
[anInvocation invoke];
}
___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev
[Gnustep-cvs] gnustep/dev-libs/SQLClient ChangeLog SQLClient.m
CVSROOT:/cvsroot/gnustep Module name:gnustep Branch: Changes by: Richard Frith-Macdonald <[EMAIL PROTECTED]> 05/06/21 13:10:55 Modified files: dev-libs/SQLClient: ChangeLog SQLClient.m Log message: Expand tildes in paths CVSWeb URLs: http://savannah.gnu.org/cgi-bin/viewcvs/gnustep/gnustep/dev-libs/SQLClient/ChangeLog.diff?tr1=1.42&tr2=1.43&r1=text&r2=text http://savannah.gnu.org/cgi-bin/viewcvs/gnustep/gnustep/dev-libs/SQLClient/SQLClient.m.diff?tr1=1.18&tr2=1.19&r1=text&r2=text
[Gnustep-cvs] gnustep/core/base ChangeLog Source/NSBundle.m
CVSROOT:/cvsroot/gnustep Module name:gnustep Branch: Changes by: Richard Frith-Macdonald <[EMAIL PROTECTED]> 05/06/21 12:55:30 Modified files: core/base : ChangeLog core/base/Source: NSBundle.m Log message: Expand tilde in bundle path. CVSWeb URLs: http://savannah.gnu.org/cgi-bin/viewcvs/gnustep/gnustep/core/base/ChangeLog.diff?tr1=1.2543&tr2=1.2544&r1=text&r2=text http://savannah.gnu.org/cgi-bin/viewcvs/gnustep/gnustep/core/base/Source/NSBundle.m.diff?tr1=1.140&tr2=1.141&r1=text&r2=text
[Gnustep-cvs] gnustep/core/base/Source NSBundle.m
CVSROOT:/cvsroot/gnustep Module name:gnustep Branch: Changes by: Richard Frith-Macdonald <[EMAIL PROTECTED]> 05/06/21 12:57:21 Modified files: core/base/Source: NSBundle.m Log message: Add a comment explaining last change. CVSWeb URLs: http://savannah.gnu.org/cgi-bin/viewcvs/gnustep/gnustep/core/base/Source/NSBundle.m.diff?tr1=1.141&tr2=1.142&r1=text&r2=text
Problem implementing faults in Objective-C
Hi all,
I am sending this to gnustep-dev crossposted to gcc. Maybe this isn't
the right mailing list. See at the end of the post for a 40 line program
that exhibit the bad behavior.
Problem:
If a is a fault (ie: changes its isa pointer during forwardInvocation),
then:
[a method1:[a method2]]
fails (a does not recognize 'method1:'), while:
id o = [a method2];
[a method1:o];
works.
The code works correctly under Mac OS X.
Am I doing something horribly wrong ?
This is on gcc 3.2/mingw
Thanks for any help,
--fred
[EMAIL PROTECTED] /c/Dev/ObjcInvocations
$ shared_obj/invocation.exe
This one works:
method1
This one fails:
: Uncaught exception NSInvalidArgumentException, reason: B(instance)
does not recognize method1:
[EMAIL PROTECTED] /c/Dev/ObjcInvocations
$ gcc -v
Reading specs from
c:/GNUstepVersions/1.10.0/MinGW/bin/../lib/gcc-lib/mingw32/3.2/specs
Configured with: ../gcc/configure --with-gcc --with-gnu-ld --with-gnu-as
--host=mingw32 --target=mingw32 --prefix=/mingw --enable-threads
--disable-nls --enable-languages=f77,c++,objc,ada
--disable-win32-registry --disable-shared
Thread model: win32
gcc version 3.2 (mingw special 20020817-1)
$ uname -a
MINGW32_NT-5.0 FLEA 1.0.10(0.46/3/2) 2004-03-15 07:17 i686 unknown
makefile:
-
MAKEFILE_NAME = GNUstepMakefile
include $(GNUSTEP_MAKEFILES)/common.make
TOOL_NAME = invocation
invocation_OBJC_FILES = Invocation.m
invocation_C_FILES =
invocation_CC_FILES =
invocation_HEADER_FILES =
invocation_OBJ_FILES =
ADDITIONAL_OBJCFLAGS =
ADDITIONAL_INCLUDE_DIRS = -I../SystemConfiguration
ADDITIONAL_LIB_DIRS = -L../SystemConfiguration
invocation_TOOL_LIBS = -lgnustep-base \
-lobjc
-include GNUstepMakefile.preamble
-include GNUstepMakefile.local
include $(GNUSTEP_MAKEFILES)/tool.make
-include GNUstepMakefile.postamble
-
// Test for invocation problem
#import
@interface A : NSProxy
@end
@interface B : NSObject
- (void)method1:(id)o;
- (id)method2;
@end
@implementation A
- init { return self; }
- (NSMethodSignature *)methodSignatureForSelector:(SEL)aSel { return [B
instanceMethodSignatureForSelector:aSel]; }
- (void)forwardInvocation:(NSInvocation *)anInvocation
{
isa = [B class];
[anInvocation invoke];
}
@end
@implementation B
- (id)method2 { return self; }
- (void)method1:(id)a { printf( "method1\n" ); }
@end
int main()
{
[[NSAutoreleasePool alloc] init];
B *theB0 = (B *)[[A alloc] init];
B *theB1 = (B *)[[A alloc] init];
printf( "This one works:\n" );
id o = [theB0 method2];
[theB0 method1:o];
printf( "This one fails:\n" );
fflush( stdout );
[theB1 method1:[theB1 method2]];
return 0;
}
___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev
[Gnustep-cvs] GNUstep Testfarm Results
Test results for GNUstep as of Tue Jun 21 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 Tue Jun 21 03:58:26 CEST 2005 Success Compile powerpc-apple-darwin7.9.0 Tue Jun 21 03:22:18 MDT 2005 Success Compile sparc-sun-solaris2.7 Tue Jun 21 02:08:07 EDT 2005
How to find object variable?
Hi,
In latest StepTalk update I had a problem finding whether receiver knows about a
variable with a given name. I do not care whether it is a real ivar or not. I
have used following code:
NS_DURING
/* test whether variable is an ivar s*/
obj = [receiver valueForKey:varName];
NSDebugLLog(@"STCompiler", "New name: receiver variable %@",
varName);
[receiverVars addObject:varName];
NS_HANDLER
if([[localException name] isEqualToString:NSUnknownKeyException])
{
NSDebugLLog(@"STCompiler", "New name: extern %@", varName);
/* receiver has no such variable */
[externVars addObject:varName];
}
else
{
[localException raise];
}
NS_ENDHANDLER
Basically, what I do is to try to get a value for given key. If it exists, then
I assume that the receiver has that ivar.
Is there a better and cleaner way of doing that?
Thanks for any hints,
Stefan Urbanek
p.s.: GNUstep has NSUnknownKeyException where Cocoa has NSUndefinedKeyException,
I think that for compatibility reasons we should have the second instead.
--
http://stefan.agentfarms.net
First they ignore you, then they laugh at you, then they fight you, then
you win.
- Mahatma Gandhi
___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev
