Re: Opal patch

[Philippe Roussel]

Hi Ivan,

You seem to be working on opal, could you take a look at the following ?

Philippe

On Thu, Sep 19, 2013 at 07:21:40AM +0200, Philippe Roussel wrote:
 Hi,
 
 Scanning opal build warnings I found at least 2 that look like real
 bugs, see the following patch.
 
 Philippe
 
 Index: Source/OpalGraphics/CGImage.m
 ===
 --- Source/OpalGraphics/CGImage.m (révision 37110)
 +++ Source/OpalGraphics/CGImage.m (copie de travail)
 @@ -158,7 +158,7 @@
self-surf = NULL;
self-bitmapInfo = aBitmapInfo;
self-cspace = CGColorSpaceRetain(aColorspace);
 -  self-intent = intent;
 +  self-intent = anIntent;
  
return self;
  }
 Index: Source/OpalText/CTLine.m
 ===
 --- Source/OpalText/CTLine.m  (révision 37110)
 +++ Source/OpalText/CTLine.m  (copie de travail)
 @@ -30,7 +30,7 @@
  
  - (id)initWithRuns: (NSArray*)runs
  {
 -  if ((self == [super init]))
 +  if ((self = [super init]))
{
  _runs = [runs retain];
}
 
 -- 
 Letting the Internet be rewired by bureaucrats would be like handing a 
 Stradivarius to a gorilla. L. Gordon Crovitz

___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
https://lists.gnu.org/mailman/listinfo/gnustep-dev

Re: Preliminary Debian packaging support

[Philippe Roussel]

Hi Ivan,

On Fri, Sep 20, 2013 at 06:10:00AM +0200, Ivan Vučica wrote:
 Hi all,
 
 instead of sleeping, tonight I invested time in something more fun: Debian
 packaging support in gnustep-make.

Before I test this, didn't you forget to commit
deb-equivs-control.template ?

Thanks,
Philippe
-- 
The power of accurate observation is frequently called cynicism by those who 
don't have it. George Bernard Shaw


___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
https://lists.gnu.org/mailman/listinfo/gnustep-dev

Re: Preliminary Debian packaging support

[Philippe Roussel]

On Fri, Sep 20, 2013 at 07:33:56AM +0200, Ivan Vučica wrote:
 Good morning!

Yeah, reading emails while drinking my first coffee !

 On Friday, September 20, 2013, Philippe Roussel wrote:
 
 
  Before I test this, didn't you forget to commit
  deb-equivs-control.template ?
 
 
 Added!
 
 I've also kept on working and it turns out I overcomplicated by adapting
 the file enumeration taken from nsis.make. I also did not package
 everything that needed to go inside /GNUstep/System, conveniently dropping
 'Additions/base.make' and 'Additions/gui.make'. I replaced the enumeration
 with a simple 'find', and I ensured all files get copied into the package.
 
 I'm still working on some issues with locating libraries, and I'll commit
 the updated stuff soon.

Great, thanks for your work. This could be a great way to offer fresh
deb packages to potential users, even if those packages aren't
entirely debian compliant.

Philippe
-- 
Duct tape is like the Force. It has a light side and a dark side, and it holds 
the universe together.


___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
https://lists.gnu.org/mailman/listinfo/gnustep-dev

Opal patch

[Philippe Roussel]

Hi,

Scanning opal build warnings I found at least 2 that look like real
bugs, see the following patch.

Philippe

Index: Source/OpalGraphics/CGImage.m
===
--- Source/OpalGraphics/CGImage.m   (révision 37110)
+++ Source/OpalGraphics/CGImage.m   (copie de travail)
@@ -158,7 +158,7 @@
   self-surf = NULL;
   self-bitmapInfo = aBitmapInfo;
   self-cspace = CGColorSpaceRetain(aColorspace);
-  self-intent = intent;
+  self-intent = anIntent;
 
   return self;
 }
Index: Source/OpalText/CTLine.m
===
--- Source/OpalText/CTLine.m(révision 37110)
+++ Source/OpalText/CTLine.m(copie de travail)
@@ -30,7 +30,7 @@
 
 - (id)initWithRuns: (NSArray*)runs
 {
-  if ((self == [super init]))
+  if ((self = [super init]))
   {
 _runs = [runs retain];
   }

-- 
Letting the Internet be rewired by bureaucrats would be like handing a 
Stradivarius to a gorilla. L. Gordon Crovitz


___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
https://lists.gnu.org/mailman/listinfo/gnustep-dev

[PATCH] Fix DBusKit compilation

[Philippe Roussel]

Hi,

I need following patch to compile DBusKit with gcc. Don't ask me why
it works with other configurations, I don't know.

Thanks,
Philippe


Index: Source/DKOutgoingProxy.m
===
--- Source/DKOutgoingProxy.m(révision 36846)
+++ Source/DKOutgoingProxy.m(copie de travail)
@@ -29,6 +29,7 @@
 #import DKIntrospectionParserDelegate.h
 
 #import Foundation/NSData.h
+#import Foundation/NSDictionary.h
 #import Foundation/NSLock.h
 #import Foundation/NSException.h
 #import Foundation/NSMethodSignature.h

-- 
L'adulte ne croit pas au Pere Noel. Il Vote. Pierre Desproges


___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
https://lists.gnu.org/mailman/listinfo/gnustep-dev

Re: Ubuntu and Debian packages / 2013-04-10

[Philippe Roussel]

On Wed, May 29, 2013 at 08:44:51AM +, Niels Grewe wrote:
 
 On 29.05.2013 10:06CEST Philippe Roussel p.o.rous...@free.fr wrote:
 
  Hi Niels,
  
  On Wed, May 29, 2013 at 07:27:09AM +, Niels Grewe wrote:
  Compiling with clang is tempting but it seems people in the clang camp
  are moving too fast : I can't compike dbuskit with clang 3.0 from
  ubuntu 12.10 for example.
  
  Woopsie. I still had local changes to dbuskit for some clang problems. I 
  committed them now. My intention is that DBusKit trunk should always 
  compile cleanly both with (recent-ish, I guess) gcc and clang. If it 
  doesn't: Please complain loudly ;-)
  
  Ok, you asked for it !
 
 Sure :-)
 
  Errors compiling dbuskit after svn up; make distclean; ./configure
  
  DKMethod.m:211:19: error: implicit declaration of function 
  'clang_Cursor_getNumArguments' is invalid in C99 
  [-Werror,-Wimplicit-function-declaration]
   int argCount  = clang_Cursor_getNumArguments(cursor);
   ^
  DKMethod.m:214:20: error: implicit declaration of function 
  'clang_Cursor_getArgument' is invalid in C99 
  [-Werror,-Wimplicit-function-declaration]
 CXCursor arg = clang_Cursor_getArgument(cursor, i);
^
  DKMethod.m:214:14: error: initializing 'CXCursor' with an expression of 
  incompatible type 'int'; 
 CXCursor arg = clang_Cursor_getArgument(cursor, i);
  ^ ~~~
 
 That could be an incorrectly detected libclang. Is it installed? Could you 
 send me your config.log?

Here it is.

Philippe
-- 
What's tan and black and looks great on a lawyer? A doberman.

This file contains any messages produced by compilers while
running configure, to aid debugging if configure makes a mistake.

It was created by configure, which was
generated by GNU Autoconf 2.60.  Invocation command line was

  $ ./configure 

## - ##
## Platform. ##
## - ##

hostname = woody
uname -m = i686
uname -r = 3.9.4
uname -s = Linux
uname -v = #2 SMP Sun May 26 22:51:51 CEST 2013

/usr/bin/uname -p = unknown
/bin/uname -X = unknown

/bin/arch  = unknown
/usr/bin/arch -k   = unknown
/usr/convex/getsysinfo = unknown
/usr/bin/hostinfo  = unknown
/bin/machine   = unknown
/usr/bin/oslevel   = unknown
/bin/universe  = unknown

PATH: /home/philou/GNUstep/Tools
PATH: /opt/GNUstep-trunk/bin
PATH: /usr/lib/lightdm/lightdm
PATH: /usr/local/sbin
PATH: /usr/local/bin
PATH: /usr/sbin
PATH: /usr/bin
PATH: /sbin
PATH: /bin
PATH: /usr/games
PATH: /usr/local/games


## --- ##
## Core tests. ##
## --- ##

configure:1953: checking build system type
configure:1971: result: i686-pc-linux-gnu
configure:1993: checking host system type
configure:2008: result: i686-pc-linux-gnu
configure:2078: checking for gcc
configure:2105: result: clang
configure:2343: checking for C compiler version
configure:2350: clang --version 5
Ubuntu clang version 3.0-6ubuntu3 (tags/RELEASE_30/final) (based on LLVM 3.0)
Target: i386-pc-linux-gnu
Thread model: posix
configure:2353: $? = 0
configure:2360: clang -v 5
Ubuntu clang version 3.0-6ubuntu3 (tags/RELEASE_30/final) (based on LLVM 3.0)
Target: i386-pc-linux-gnu
Thread model: posix
configure:2363: $? = 0
configure:2370: clang -V 5
clang: error: argument to '-V' is missing (expected 1 value)
clang: error: no input files
configure:2373: $? = 1
configure:2396: checking for C compiler default output file name
configure:2423: clangconftest.c  5
configure:2426: $? = 0
configure:2472: result: a.out
configure:2477: checking whether the C compiler works
configure:2487: ./a.out
configure:2490: $? = 0
configure:2507: result: yes
configure:2514: checking whether we are cross compiling
configure:2516: result: no
configure:2519: checking for suffix of executables
configure:2526: clang -o conftestconftest.c  5
configure:2529: $? = 0
configure:2553: result: 
configure:2559: checking for suffix of object files
configure:2585: clang -c   conftest.c 5
configure:2588: $? = 0
configure:2611: result: o
configure:2615: checking whether we are using the GNU C compiler
configure:2644: clang -c   conftest.c 5
configure:2650: $? = 0
configure:2657: test -z $ac_c_werror_flag || test ! -s conftest.err
configure:2660: $? = 0
configure:2667: test -s conftest.o
configure:2670: $? = 0
configure:2684: result: yes
configure:2689: checking whether clang accepts -g
configure:2719: clang -c -g  conftest.c 5
configure:2725: $? = 0
configure:2732: test -z $ac_c_werror_flag || test ! -s conftest.err
configure:2735: $? = 0
configure:2742: test -s conftest.o
configure:2745: $? = 0
configure:2875: result: yes
configure:2892: checking for clang option to accept ISO C89
configure:2966: clang  -c -g -O2  conftest.c 5
configure:2972: $? = 0
configure:2979: test -z $ac_c_werror_flag || test ! -s conftest.err
configure:2982: $? = 0
configure:2989: test -s conftest.o
configure:2992: $? = 0
configure:3012: result: none needed
configure:3030: checking

Re: libobjc2 build failure

[Philippe Roussel]

On Tue, Nov 20, 2012 at 08:02:16AM +, David Chisnall wrote:
 That's odd.  Did your binutils suddenly lose the ability to assemble 
 position-independent i386 code?

Well, binutils 2.22-6ubuntu1 hasn't changed since march apparently.

Philippe


___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
https://lists.gnu.org/mailman/listinfo/gnustep-dev

libobjc2 build failure

[Philippe Roussel]

Hi,

Trying to build libobjc2 from svn with 4.6.3 gives me this :

GNUmakefile:23: GNUstep found - building for install in the GNUstep filesystem.
Assembling objc_msgSend.S...
objc_msgSend.x86-32.S: Assembler messages:
objc_msgSend.x86-32.S:92: Error: junk .get_pc_thunk.bx' after expression
objc_msgSend.x86-32.S:96: Error: junk .get_pc_thunk.bx' after expression
objc_msgSend.x86-32.S:100: Error: junk .get_pc_thunk.bx' after expression
make: *** [objc_msgSend.o] Erreur 1

Philippe
-- 
My mom had Windows at work and it hurt her eyes real bad.


___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
https://lists.gnu.org/mailman/listinfo/gnustep-dev

DBusKit build failure

[Philippe Roussel]

Hi,

gcc 4.6.3 isn't happy with dbuskit trunk :

 Compiling file DKEndpoint.m ...
 DKEndpoint.m: In function ‘DKTimeoutAdd’:
 DKEndpoint.m:816:3: erreur: ‘self’ undeclared (first use in this function)
DKEndpoint.m:816:3: note: each undeclared identifier is reported only once for 
each function it appears in
DKEndpoint.m:816:3: erreur: ‘_cmd’ undeclared (first use in this function)
DKEndpoint.m: In function ‘DKTimeoutRemove’:
DKEndpoint.m:829:3: erreur: ‘self’ undeclared (first use in this function)
DKEndpoint.m:829:3: erreur: ‘_cmd’ undeclared (first use in this function)

etc.

Am I this only one seeing this ?

Thanks,
Philippe

___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
https://lists.gnu.org/mailman/listinfo/gnustep-dev

Re: DBusKit build failure

[Philippe Roussel]

On Sun, Nov 11, 2012 at 02:32:56PM +0100, Niels Grewe wrote:
 Hi Philippe,
 
 the callback functions for libdbus where incorrectly using NSDebugMLog
 instead of NSDebugFLog. NSDebugMLog changed in r35670 to pass around
 self and _cmd, which revealed the mistake. But it should be fixed now.

Yep, it's building fine now, thanks Niels.

Philippe
-- 
Une auto-stoppeuse est souvent une jolie jeune femme légèrement habillée qui se 
trouve sur votre chemin lorsque vous êtes avec votre femme. Woody Allen


___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
https://lists.gnu.org/mailman/listinfo/gnustep-dev

Re: On linux too (was Re: Base compilation broken on NetBSD)

[Philippe Roussel]

Le 02/11/2012 14:50, Wolfgang Lux a écrit :
 Wolfgang Lux wrote:

[snip]

 I have implemented this. The configure script checks for the variant of 
 strerror_r and the _systemError: method now contains code for the glibc 
 variant of strerror_r. Doing that, I had to remove the code from common.h 
 that was undefining _GNU_SOURCE and conditionally defining _XOPEN_SOURCE, as 
 that could invalidate the result of the autoconf test. I tested this on both 
 OS X (using the POSIX variant) and Linux (using the glibc version) and this 
 seems to work. I think it should also work for systems where strerror_r is 
 not defined at all and we define our own, POSIX compatible version, but I 
 have no system to test this.

base compiles without problem for me now.

Thanks,
Philippe


___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
https://lists.gnu.org/mailman/listinfo/gnustep-dev

Re: Problem with Renaissance

[Philippe Roussel]

Hi German,

Le 07/10/2012 04:21, Germán A. Arias a écrit :
 I’m having an odd problem with Renaissance and gnustep update to svn.
 Attached a simple test that compile fine on my machine. But don't run. I
 get the error:
 
 german@german-desktop:~/Instalados/Practicas/Renan$ openapp ./Renan
 2012-10-06 20:03:00.266 Renan[11495] Problem posting notification:
 NSException: 0x9b588ac NAME:NSInvalidArgumentException
 REASON:NSBundle(class) does not recognize loadGSMarkupNamed:owner:
 INFO:(null) 

Same here.

ldd shows that Renan isn't linked with Renaissance. This is probably
because you don't call any Renaissance code directly in your code so the
linker removes it from the list of librairies.


Try with this main function :

 int main(int argc, const char *argv[])
 {
   CREATE_AUTORELEASE_POOL(pool);
   [[NSApplication sharedApplication] setDelegate:[AppController new]];
   RELEASE(pool);
   return GSMarkupApplicationMain(argc, argv);
 }

Philippe

___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
https://lists.gnu.org/mailman/listinfo/gnustep-dev

DBusKit build failure

[Philippe Roussel]

Hi,

With gcc I get the following :

 Making all for framework DBusKit...
  Compiling file NSConnection+DBus.m ...
 NSConnection+DBus.m: In function '+[NSConnection(DBusKit) load]':
 NSConnection+DBus.m:58:3: error: ISO C90 forbids mixed declarations and code 
 [-Werror=declaration-after-statement]
 cc1obj: all warnings being treated as errors

Simple fix :

Index: Source/NSConnection+DBus.m
===
--- Source/NSConnection+DBus.m  (révision 35095)
+++ Source/NSConnection+DBus.m  (copie de travail)
@@ -49,20 +49,23 @@
 @implementation NSConnection (DBusKit)
 + (void)load
 {
+  Method oldRootProxyMethod, newRootProxyMethod;
+  Method oldSetRootObjectMethod, newSetRootObjectMethod;
+
   /*
* We do some devious patching and replace some method implementations in
* NSConnection with the ones from this category.
*/
   rootProxySel = @selector(rootProxy);
   setRootObjectSel = @selector(setRootObject:);
-  Method oldRootProxyMethod =
+  oldRootProxyMethod =
 class_getInstanceMethod(objc_getClass(NSConnection), rootProxySel);
-  Method newRootProxyMethod =
+  newRootProxyMethod =
 class_getInstanceMethod(objc_getClass(NSConnection),
   @selector(_DKRootProxy));
-  Method oldSetRootObjectMethod =
+  oldSetRootObjectMethod =
 class_getInstanceMethod(objc_getClass(NSConnection),
setRootObjectSel);
-  Method newSetRootObjectMethod =
+  newSetRootObjectMethod =
 class_getInstanceMethod(objc_getClass(NSConnection),
   @selector(_DKSetRootObject:));
   _DKNSConnectionRootProxy = method_getImplementation(oldRootProxyMethod);


___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
https://lists.gnu.org/mailman/listinfo/gnustep-dev

Re: DBusKit build failure

[Philippe Roussel]

Le 21/04/2012 13:14, David Chisnall a écrit :
 I believe it was a design decision for DBusKit that it require C99 support.  
 It doesn't seem unreasonable, now C99 has now been superseded by C11, to 
 expect a compiler to support the 13 year old standard...

And it doesn't seem unreasonable to expect a once building library to
continue to build with a reasonably recent compiler, gcc 4.6.1, which
I'm sure is capable of understanding C99

I'm not the one who added -Werror to the default build of DBusKit and I
don't want to argue about standards or compiler. In my point of vue it
quite simple : if it's in the source repository it should compile with a
supported compiler (and I'm not arguing about 2.95.3 support here so
please), end of story.

Philippe


___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
https://lists.gnu.org/mailman/listinfo/gnustep-dev

Re: DBusKit build failure

[Philippe Roussel]

Le 21/04/2012 13:58, Niels Grewe a écrit :
 On Sat, Apr 21, 2012 at 01:45:45PM +0200, Philippe Roussel wrote:
 I'm not the one who added -Werror to the default build of DBusKit and I
 don't want to argue about standards or compiler. In my point of vue it
 quite simple : if it's in the source repository it should compile with a
 supported compiler (and I'm not arguing about 2.95.3 support here so
 please), end of story.
 
 True. But please note the folllowing: -Werror is not at fault here,
 -Wdeclaration-after-statement is. Also, -Werror is only used for code in
 trunk as a basic code quality check, release versions disable it since
 releases are supposed not to have known problems.

Well, -Wdeclaration-after-statement is what causes the warning and is
questionable but -Werror is what turns the warning into a build error.

Anyway, thanks for applying the patch.

Philippe

___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
https://lists.gnu.org/mailman/listinfo/gnustep-dev

Re: Renaissance and document based applications bug

[Philippe Roussel]

On Thu, Apr 19, 2012 at 09:50:03AM +0200, Fred Kiefer wrote:
 Not sure whether your approach is the right way to solve the issue.
 To me it rather looks like the way we implement things in gui makes
 it hard for subclasses to do the right thing.
 
 If I remember correctly that extra flag in NSWidnowController was
 only there to avoid loading the same failing NIB file twice. Not
 sure whether that mechanism works at all after the change Jonathan
 Gillaspie did two years ago. We could remove that flag and just
 check whether _window is set. Or combine both and first check for
 _window being non-null and next for the nib_is_loaded if we ever
 want to make the functional again.

I hadn't considered modifying NSWindowController (and I don't know
why) but I like your suggestion.
This problem with Renaissance probably is a regression in gui anyway
so it makes sense to fix the regression and allow easy subclassing.

I'll give it a try tonight if nobody beats me to it.

Thanks,
Philippe
-- 
Je n'ai jamais pu faire de yoga. Chaque fois qu'on me dit :
'Assied-toi et ne pense à rien', ça me rappelle trop le bureau.


___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
https://lists.gnu.org/mailman/listinfo/gnustep-dev

Re: Renaissance and document based applications bug

[Philippe Roussel]

Le 19/04/2012 13:03, Philippe Roussel a écrit :
 On Thu, Apr 19, 2012 at 09:50:03AM +0200, Fred Kiefer wrote:
 Not sure whether your approach is the right way to solve the issue.
 To me it rather looks like the way we implement things in gui makes
 it hard for subclasses to do the right thing.

 If I remember correctly that extra flag in NSWidnowController was
 only there to avoid loading the same failing NIB file twice. Not
 sure whether that mechanism works at all after the change Jonathan
 Gillaspie did two years ago. We could remove that flag and just
 check whether _window is set. Or combine both and first check for
 _window being non-null and next for the nib_is_loaded if we ever
 want to make the functional again.
 
 I hadn't considered modifying NSWindowController (and I don't know
 why) but I like your suggestion.
 This problem with Renaissance probably is a regression in gui anyway
 so it makes sense to fix the regression and allow easy subclassing.
 
 I'll give it a try tonight if nobody beats me to it.

The following minimal patch seems to do the trick but I must confess I
didn't study NSWindowController long enough to be sure it's correct.

With this patch I don't have to patch Renaissance.

Thanks,
Philippe

Index: Source/NSWindowController.m
===
--- Source/NSWindowController.m (révision 35090)
+++ Source/NSWindowController.m (copie de travail)
@@ -292,7 +292,7 @@

 - (NSWindow *) window
 {
-  if (_window == nil  ![self isWindowLoaded])
+  if (_window == nil)
 {
   // Do all the notifications.  Yes, the docs say this should
   // be implemented here instead of in -loadWindow itself.
@@ -435,7 +435,7 @@

 - (BOOL) isWindowLoaded
 {
-  return _wcFlags.nib_is_loaded;
+  return _window != nil;
 }

 - (void) windowDidLoad
@@ -448,8 +448,6 @@

 - (void) _windowDidLoad
 {
-  _wcFlags.nib_is_loaded = YES;
-
   [self synchronizeWindowTitleWithDocumentName];

   if ([self shouldCascadeWindows])
@@ -483,8 +481,6 @@
externalNameTable: table
withZone: [_owner zone]])
 {
-  _wcFlags.nib_is_loaded = YES;
-   
   if (_window == nil_document != nil_owner == _document)
 {
   [self setWindow: [_document _transferWindowOwnership]];
Index: Headers/AppKit/NSWindowController.h
===
--- Headers/AppKit/NSWindowController.h (révision 35090)
+++ Headers/AppKit/NSWindowController.h (copie de travail)
@@ -49,8 +49,7 @@
 {
   unsigned int should_close_document:1;
   unsigned int should_cascade:1;
-  unsigned int nib_is_loaded:1;
-  unsigned int RESERVED:29;
+  unsigned int RESERVED:30;
 } _wcFlags;
 void*_reserved1;
 void*_reserved2;

___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
https://lists.gnu.org/mailman/listinfo/gnustep-dev

Renaissance and 'Open recent' menu

[Philippe Roussel]

Hi all,

I didn't find a way to add a working 'Open recent' menu to a Renaissance
application so here is a trivial working patch. It is specific to
GNUstep as I don't know how that would work on OS X.

Comments ?

Thanks,
Philippe

Index: renaissance/Source/TagLibrary/GSMarkupTagMenu.m
===
--- renaissance/Source/TagLibrary/GSMarkupTagMenu.m (révision 35089)
+++ renaissance/Source/TagLibrary/GSMarkupTagMenu.m (copie de travail)
@@ -52,6 +52,12 @@
 @end
 #endif

+#ifdef GNUSTEP
+@interface NSDocumentController (RecentMenu)
+- (void) _setRecentDocumentsMenu: (NSMenu *)menu;
+@end
+#endif
+
 @implementation GSMarkupTagMenu
 + (NSString *) tagName
 {
@@ -159,6 +165,13 @@
  {
[NSApp setServicesMenu: platformObject];
  }
+   else if ([type isEqualToString: @recent])
+ {
+#ifdef GNUSTEP
+   [[NSDocumentController sharedDocumentController]
+  _setRecentDocumentsMenu: platformObject];
+#endif
+ }
else if ([type isEqualToString: @font])
  {
/* The menu has already been created as font menu.  */

___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
https://lists.gnu.org/mailman/listinfo/gnustep-dev

Re: pl2link : output valid categories and ease packaging

[Philippe Roussel]

Le 18/04/2012 10:28, Fred Kiefer a écrit :
 Committed. Sorry for taking that long. I was away over the weekend.

Thanks a lot Fred, and don't worry about the timing, it's nothing critical !

Maybe this should be documented somewhere, I'll explain it here.

If you want your application's .desktop file to contain valid
FreeDesktop categories (which means that your application should appear
in the right menu automatically and that the packagers won't have to
ship their own .desktop), you can use the new FreeDesktopCategories
entry in your application .plist like this :

FreeDesktopCategories = (
Office,
Calendar
);

You can find the official list of categories here :

http://standards.freedesktop.org/menu-spec/latest/apa.html

Philippe

___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
https://lists.gnu.org/mailman/listinfo/gnustep-dev

Renaissance and document based applications bug

[Philippe Roussel]

I'm not sure Nicola is still around reading his email so I'm posting
this here.

 Message original 
Sujet: Renaissance and document based applications bug
Date : Tue, 17 Apr 2012 22:44:15 +0200
De : Philippe Roussel p.o.rous...@free.fr
Pour : Nicola Pero nicola.p...@meta-innovation.com

Hi Nicola,

I'm trying to build a small document based application using Renaissance
and I ran into some problems : the title of a document window is
supposed to be automagically set when opening from or saving to a file.

I tried to reproduce the problem with Renaissance's version of Ink and
ran into another problem that you should be able to reproduce : when
opening a file, the document title isn't changed (expected) and the
content of the file isn't displayed in the window.

Long story short, it appears that NSWindowController uses a private flag
nib_is_loaded to indicate if the window is loaded.
GSMarkupWindowController methods don't (and can't) set this flag so some
code paths are never run when using Renaissance.

I'm not sure the following patch is correct but Ink seems to work
correctly with it.

What do you think ?

Thanks,
Philippe

Index: renaissance/Source/TagLibrary/GSMarkupWindowController.h
===
--- renaissance/Source/TagLibrary/GSMarkupWindowController.h	(révision 35086)
+++ renaissance/Source/TagLibrary/GSMarkupWindowController.h	(copie de travail)
@@ -55,6 +55,8 @@
* a 'release' message.  Then we destroy the array as well.
*/
   NSArray *_gsMarkupTopLevelObjects;
+
+  BOOL _windowLoaded;
 }
 
 @end
Index: renaissance/Source/TagLibrary/GSMarkupWindowController.m
===
--- renaissance/Source/TagLibrary/GSMarkupWindowController.m	(révision 35086)
+++ renaissance/Source/TagLibrary/GSMarkupWindowController.m	(copie de travail)
@@ -184,6 +184,10 @@
   ASSIGN (_gsMarkupTopLevelObjects, topLevelObjects);
 }
 
+- (BOOL) isWindowLoaded
+{
+  return _windowLoaded;
+}
 
 - (void) loadWindow
 {
@@ -217,6 +221,7 @@
 		withZone: [[self owner] zone]])
 	{
 	  [self setTopLevelObjects: topLevelObjects];
+	  _windowLoaded = YES;
 	  return;
 	}
 }
@@ -241,6 +246,7 @@
 		  withZone: [[self owner] zone]])
 	{
 	  [self setTopLevelObjects: topLevelObjects];
+	  _windowLoaded = YES;
 	  return;
 	}
   
@@ -252,6 +258,7 @@
 			  withZone: [[self owner] zone]])
 		{
 		  [self setTopLevelObjects: topLevelObjects];
+		  _windowLoaded = YES;
 		  return;
 		}
 	}

___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
https://lists.gnu.org/mailman/listinfo/gnustep-dev

Re: pl2link : output valid categories and ease packaging

[Philippe Roussel]

Le 19/03/2012 11:27, Fred Kiefer a écrit :
 On 18.03.2012 23:24, Philippe Roussel wrote:
 Hi,

 When building an application, a .desktop file is generated with data
 gathered from the .plist file when possible and from static strings when
 not. One os the fields, Categories, is set to X-GNUstep. As this isn't a
 valid freedesktop category, every package has to ship its own .desktop
 file for the application to appear in the right menu.

 To fix this, I would like to propose adding a new and optional
 FreeDesktopCategories array in the applications .plist files, together
 with the following patch :

 Index: Tools/pl2link.m
 ===
 --- Tools/pl2link.m (révision 34938)
 +++ Tools/pl2link.m (copie de travail)
 @@ -102,8 +102,18 @@
 fileContents = [NSMutableString stringWithCapacity: 200];
 [fileContents appendString:
 @[Desktop Entry]\nEncoding=UTF-8\nType=Application\n];
 - [fileContents appendString:
 - @Categories=X-GNUstep;\n];
 + list = [plist objectForKey: @FreeDesktopCategories];
 + if (list != nil  [list isKindOfClass: [NSArray class]]  [list
 count]  0)
 + {
 + [fileContents appendString: @Categories=];
 + [fileContents appendString: [list componentsJoinedByString: @;]];
 + [fileContents appendString: @;\n];
 + }
 + else
 + {
 + [fileContents appendString:
 + @Categories=X-GNUstep;\n];
 + }
 entry = [plist objectForKey: @ApplicationName];
 if (entry != nil)
 {

 Comments ?
 
 Fine by me.

Could you please commit it ?

Thanks,
Philippe

___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
https://lists.gnu.org/mailman/listinfo/gnustep-dev

pl2link : output valid categories and ease packaging

[Philippe Roussel]

Hi,

When building an application, a .desktop file is generated with data 
gathered from the .plist file when possible and from static strings when 
not. One os the fields, Categories, is set to X-GNUstep. As this isn't a 
valid freedesktop category, every package has to ship its own .desktop 
file for the application to appear in the right menu.


To fix this, I would like to propose adding a new and optional 
FreeDesktopCategories array in the applications .plist files, together 
with the following patch :


Index: Tools/pl2link.m
===
--- Tools/pl2link.m (révision 34938)
+++ Tools/pl2link.m (copie de travail)
@@ -102,8 +102,18 @@
   fileContents = [NSMutableString stringWithCapacity: 200];
   [fileContents appendString:
 @[Desktop Entry]\nEncoding=UTF-8\nType=Application\n];
-  [fileContents appendString:
-@Categories=X-GNUstep;\n];
+  list = [plist objectForKey: @FreeDesktopCategories];
+  if (list != nil  [list isKindOfClass: [NSArray class]]  [list 
count]  0)

+{
+  [fileContents appendString: @Categories=];
+  [fileContents appendString: [list componentsJoinedByString: @;]];
+  [fileContents appendString: @;\n];
+}
+  else
+{
+  [fileContents appendString:
+   @Categories=X-GNUstep;\n];
+}
   entry = [plist objectForKey: @ApplicationName];
   if (entry != nil)
 {

Comments ?

Thanks,
Philippe

___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
https://lists.gnu.org/mailman/listinfo/gnustep-dev

ICU misspelled UCI in base.make.in

[Philippe Roussel]

Hi,

Even if the symbol isn't used, I guess the following is needed. 
Strangely this is duplicated (correctly spelled) in config.mak.in, maybe 
it could be removed from one file ?


Philippe

Index: base.make.in
===
--- base.make.in(révision 34889)
+++ base.make.in(copie de travail)
@@ -66,7 +66,7 @@
   GNUSTEP_BASE_HAVE_LIBXML=@HAVE_LIBXML@
   GNUSTEP_BASE_HAVE_MDNS=@HAVE_MDNS@
   GNUSTEP_BASE_HAVE_AVAHI=@HAVE_AVAHI@
-  GNUSTEP_BASE_HAVE_UCI=@HAVE_UCI@
+  GNUSTEP_BASE_HAVE_ICU=@HAVE_ICU@


___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
https://lists.gnu.org/mailman/listinfo/gnustep-dev

Fix NSConnection bug on 64 bits archs

[Philippe Roussel]

Hi,

Lucas Schnorr ran into the following problem (I can reproduce it too) :

2012-03-05 10:08:26.409 tobjc[6709] Problem posting notification:
NSException: 0x7f22d8005658 NAME:NSRangeException REASON:Index -1 is
out of range 1 (in 'objectAtIndex:') INFO:{Array = (NSRunLoop:
0x1cfe998); Count = 1; Index = 4294967295; }

NSConnection was probably forgotten when NSArray was moved to 
NSUInteger. I think the following patch is needed :


Index: Source/NSConnection.m
===
--- Source/NSConnection.m   (révision 34875)
+++ Source/NSConnection.m   (copie de travail)
@@ -1583,11 +1583,11 @@
   GS_M_LOCK(IrefGate);
   if (IrunLoops != nil)
 {
-  unsigned pos = [IrunLoops indexOfObjectIdenticalTo: loop];
+  NSUInteger pos = [IrunLoops indexOfObjectIdenticalTo: loop];

   if (pos != NSNotFound)
{
- unsigned  c = [IrequestModes count];
+ NSUInteger c = [IrequestModes count];

  while (c--  0)
{

Philippe

___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
https://lists.gnu.org/mailman/listinfo/gnustep-dev

Re: Google Summer of Code

[Philippe Roussel]

Hi,

Le 07/02/2012 11:07, Niels Grewe a écrit :

Hi Sebastian,

Am 07.02.2012 10:56, schrieb Sebastian Reitenbach:

AFAIK, there doesn't exist something the other way around, allowing other 
application to create
an App Wrapper automatically. Even if that would exist, you'd still have to get 
others to make use of
it, which I think is then the harder part.

I'd also really like to have an applications menu in GWorkspace, built from the 
information from those
.desktop files in /usr/local/share/applications, that would allow me to browse 
all installed applications
and just start them from the menu ;)


A while ago I pondered whether it would be a good idea to write a fuse
filesystem that uses the xdg-menu data (which spread out through the
filesystem, not just in /usr/local/share/applications, mind you!) to
dynamically generate wrappers. You would just mount it at
/GNUstep/Applications/Legacy and be done :-). I still think it's a neat
idea, maybe worth putting forward as a potential GSoC project?


Well, it sure is neat but adding .desktop files support to GWorkspace is 
probably easier and would do the trick nicely I think :o)


GWorkpace could also support transparent access to remote filesystems 
(ftp, smb, ssh, webdav ?), that would be nice.


Philippe

___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
https://lists.gnu.org/mailman/listinfo/gnustep-dev

Re: GSHorizontalTypesetter flooding the log

[Philippe Roussel]

Le lundi 30 janvier 2012 à 23:43 +0100, Fred Kiefer a écrit :
 On 30.01.2012 23:17, Philippe Roussel wrote:
  Le lundi 30 janvier 2012 à 22:57 +0100, Philippe Roussel a écrit :
  Hi,
 
  Sometimes when I run my probably buggy application the console is
  flooded with the following log :
 
  GSHorizontalTypesetter - Glyph generation was triggered for a layout
  manager while the text storage it was attached to had unprocessed
  editing. This is not allowed. Glyph generation may be triggered only at
  points where calls to -beginEditing and -endEditing are balanced.
 
  Nevermind, this probably comes from running code in a thread...
 
  Sorry about the noise.
 
 Not sure whether this sufficiently explain this back trace. In 
 NSStringDrawing we use (recursive) locks to protect the text layout 
 objects. If we can get one of the text storages to change its text while 
 it is actually used for layout, then this is a serious problem that 
 needs looking into. Even when it only happens with multiple threads.
 Is there any example code that allows to reproduce this behaviour?

Not really. I can try to debug this further but it will have to wait,
real work comes first...

Philippe



___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
https://lists.gnu.org/mailman/listinfo/gnustep-dev

Re: GSHorizontalTypesetter flooding the log

[Philippe Roussel]

Le mardi 31 janvier 2012 à 09:54 +0100, Fred Kiefer a écrit :
 On 31.01.2012 09:15, Philippe Roussel wrote:
 
  Not really. I can try to debug this further but it will have to wait,
  real work comes first...
 
 Just send me the code, I am willing to debug this myself as this sounds 
 bad enough.

You can checkout 

svn co -r 963 svn://coyote.octets.fr/gnustep/SimpleAgenda/trunk SimpleAgenda

To reproduce the bug you have to add an iCalStore, if possible with lot
of data, and then repeatedly force a reload with keyboard shortcut #r.

Philippe



___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
https://lists.gnu.org/mailman/listinfo/gnustep-dev

Re: GSHorizontalTypesetter flooding the log

[Philippe Roussel]

Le mardi 31 janvier 2012 à 11:18 +0100, Sebastian Reitenbach a écrit :
 On Tuesday, January 31, 2012 10:54 CET, Fred Kiefer fredkie...@gmx.de 
 wrote: 
  
  On 31.01.2012 10:24, Philippe Roussel wrote:
   Le mardi 31 janvier 2012 à 09:54 +0100, Fred Kiefer a écrit :
   On 31.01.2012 09:15, Philippe Roussel wrote:
  
   Not really. I can try to debug this further but it will have to wait,
   real work comes first...
  
   Just send me the code, I am willing to debug this myself as this sounds
   bad enough.
  
   You can checkout
  
   svn co -r 963 svn://coyote.octets.fr/gnustep/SimpleAgenda/trunk 
   SimpleAgenda
  
   To reproduce the bug you have to add an iCalStore, if possible with lot
   of data, and then repeatedly force a reload with keyboard shortcut #r.
  
  Now you go me :-)
  
  I don't even know what an iCalStore is, do you by calendar data there?
  Are you going to attend FOSDEM? If so, we could sit down and debug this 
  together in Brussels.

Sorry, I shouldn't use class names as vocabulary... I meant you have to
add to SimpleAgenda an agenda stored as an icalendar file (like you
would do in Apple's iCal). If you don't already have one with many
events, it could take you some time to setup this all up. 

 I will present SimpleAgenda on FOSDEM in the applications talk.
 Afterwards, you can have my notebook to play with it.

That would be great, thanks Sebastian.

Philippe


___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
https://lists.gnu.org/mailman/listinfo/gnustep-dev

GSHorizontalTypesetter flooding the log

[Philippe Roussel]

Hi,

Sometimes when I run my probably buggy application the console is
flooded with the following log :

GSHorizontalTypesetter - Glyph generation was triggered for a layout
manager while the text storage it was attached to had unprocessed
editing. This is not allowed. Glyph generation may be triggered only at
points where calls to -beginEditing and -endEditing are balanced.

and the exception panel is never shown. The first backtrace I captured
looks like this :

#0  -[GSLayoutManager(GlyphsHelpers) _generateGlyphsUpToCharacter:] 
(self=0x86a46cc, _cmd=0x6ffbe520, last=0) at GSLayoutManager.m:716
#1  0x6fe02008 in -[GSLayoutManager(GlyphsHelpers) _generateGlyphsUpToGlyph:] 
(self=0x86a46cc, _cmd=0x6ffbe538, last=0) at GSLayoutManager.m:758
#2  0x6fe023f8 in -[GSLayoutManager(glyphs) glyphAtIndex:isValidIndex:] 
(self=0x86a46cc, _cmd=0x6ffbfeb0, glyphIndex=0, isValidIndex=0x77ffdf3f ) at 
GSLayoutManager.m:863
#3  0x6fe09f28 in -[GSHorizontalTypesetter _cacheMoveTo:] (self=0x86a001c, 
_cmd=0x6ffbff58, glyph=0) at GSHorizontalTypesetter.m:175
#4  0x6fe0aed4 in -[GSHorizontalTypesetter layoutLineNewParagraph:] 
(self=0x86a001c, _cmd=0x6ffc0070, newParagraph=1 '\001') at 
GSHorizontalTypesetter.m:540
#5  0x6fe0d198 in -[GSHorizontalTypesetter 
layoutGlyphsInLayoutManager:inTextContainer:startingAtGlyphIndex:previousLineFragmentRect:nextGlyphIndex:numberOfLineFragments:]
 (self=0x86a001c, _cmd=0x6ffbe5a0, layoutManager=0x86a46cc, 
textContainer=0x86a486c, glyphIndex=0, previousLineFragRect=..., 
nextGlyphIndex=0x77ffe244, howMany=0) at GSHorizontalTypesetter.m:1261
#6  0x6fe05577 in -[GSLayoutManager(LayoutHelpers) _doLayoutToContainer:] 
(self=0x86a46cc, _cmd=0x6ffbe588, cindex=0) at GSLayoutManager.m:1981
#7  0x6fe072bf in -[GSLayoutManager(layout) usedRectForTextContainer:] 
(self=0x86a46cc, _cmd=0x6ff79c60, container=0x86a486c) at GSLayoutManager.m:2607
#8  0x6fd2eed7 in cache_lookup_string (string=0x8594314, attributes=0x8595324, 
hasSize=0, size=..., useScreenFonts=1) at NSStringDrawing.m:323
#9  0x6fd306a1 in -[NSString(NSStringDrawing) sizeWithAttributes:] 
(self=0x8594314, _cmd=0x6ffcfd48, attrs=0x8595324) at NSStringDrawing.m:748
#10 0x6fe3ed0d in -[GSTitleView titleSize] (self=0x85951fc, _cmd=0x6ff4af10) at 
GSTitleView.m:204
#11 0x6fcad613 in -[NSMenuView sizeToFit] (self=0x8594efc, _cmd=0x6ff4af50) at 
NSMenuView.m:746
#12 0x6fcae1b2 in -[NSMenuView rectOfItemAtIndex:] (self=0x8594efc, 
_cmd=0x6ff4af58, index=1) at NSMenuView.m:969
#13 0x6fcae558 in -[NSMenuView setNeedsDisplayForItemAtIndex:] (self=0x8594efc, 
_cmd=0x6ff4ad88, index=1) at NSMenuView.m:1036
#14 0x6fcac0cd in -[NSMenuView itemChanged:] (self=0x8594efc, _cmd=0x6ff4acf0, 
notification=0x865c67c) at NSMenuView.m:474
#15 0x6f6c687e in -[NSNotificationCenter _postAndRelease:] (self=0x8174d2c, 
_cmd=0x6f98f108, notification=0x865c67c) at NSNotificationCenter.m:1223
#16 0x6f6c69dd in -[NSNotificationCenter postNotification:] (self=0x8174d2c, 
_cmd=0x6ff48280, notification=0x865c67c) at NSNotificationCenter.m:1252
#17 0x6fca41b2 in -[NSMenu itemChanged:] (self=0x8594344, _cmd=0x6ff4c698, 
anObject=0x86ec23c) at NSMenu.m:846
#18 0x6fcb4748 in -[NSMenuItem setTarget:] (self=0x86ec23c, _cmd=0x6fef8980, 
anObject=0x85ab2bc) at NSMenuItem.m:464
#19 0x6fbb96c0 in -[NSApplication changeWindowsItem:title:filename:] 
(self=0x835bfec, _cmd=0x6ffa55a0, aWindow=0x85ab2bc, aString=0x83294bc, 
isFilename=0 '\000') at NSApplication.m:3103
#20 0x6fdb461b in -[NSWindow setTitle:] (self=0x85ab2bc, _cmd=0x809de58, 
aString=0x83294bc) at NSWindow.m:1241
#21 0x0804f45b in -[AppController setWindowTitle] (self=0x859fc0c, 
_cmd=0x809e2a8) at AppController.m:200

but I got others with -[NSException raise] in the middle.

Any ideas ?



___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
https://lists.gnu.org/mailman/listinfo/gnustep-dev

Re: GSHorizontalTypesetter flooding the log

[Philippe Roussel]

Le lundi 30 janvier 2012 à 22:57 +0100, Philippe Roussel a écrit :
 Hi,
 
 Sometimes when I run my probably buggy application the console is
 flooded with the following log :
 
 GSHorizontalTypesetter - Glyph generation was triggered for a layout
 manager while the text storage it was attached to had unprocessed
 editing. This is not allowed. Glyph generation may be triggered only at
 points where calls to -beginEditing and -endEditing are balanced.

Nevermind, this probably comes from running code in a thread...

Sorry about the noise.



___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
https://lists.gnu.org/mailman/listinfo/gnustep-dev

Re: Dialog display problem (Re: GNUstep Code Freeze)

[Philippe Roussel]

Le mercredi 25 janvier 2012 à 11:30 -0700, Eric Wasylishen a écrit :
 Hi Philippe,
 I just got a new ubuntu 11.10 install set up natively instead of in a
 VM, so I can actually use Unity now. :-) I can reproduce this...
 unfortunately GS is almost unusable in Unity - menus often don't
 appear in the correct place, the menu selection doesn't always follow
 your mouse, etc. Hopefully, these are things we can fix at some point.

I can confirm it's really frustrating to use GNUstep under Unity, I
should probably change my desktop.

As for the menu, I've always observed the behaviour you mention, long
before Unity appeared. Maybe Unity made the problems worse but I think
they exist with other window managers.

And for what it's worth, I would love to see GNUstep use the global menu
as Stefan suggested.

Anyway, let me know if I can help with testing or anything.

Philippe


___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
https://lists.gnu.org/mailman/listinfo/gnustep-dev

Re: GNUstep Code Freeze

[Philippe Roussel]

Hi Eric,

Le lundi 23 janvier 2012 à 15:43 -0700, Eric Wasylishen a écrit :
 I committed a fix. Please test both on-screen display, and the result
 of saving a PDF from Ink (print dialog-save button-foo.pdf). Both
 work for me with the font that was previously causing problems (DejaVu
 Sans - probably many others too).

Your fix works fine here too. I've never tested the pdf export function
before so I'm not sure there are no regression but the characters look
good.

Thanks,
Philippe



___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
https://lists.gnu.org/mailman/listinfo/gnustep-dev

Re: Dialog display problem (Re: GNUstep Code Freeze)

[Philippe Roussel]

Le mardi 24 janvier 2012 à 12:32 -0700, Eric Wasylishen a écrit :
 Hm.. Are those gaps temporary, or does the window stay like that?
 Unfortunately. it's probably something difficult to fix which will
 have to wait for the release after this one.

Resizing the window generally fixes it but it also happens with non
resizeable panels.

Philippe



___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
https://lists.gnu.org/mailman/listinfo/gnustep-dev

Re: GNUstep Code Freeze

[Philippe Roussel]

Hi Fred,

Le samedi 21 janvier 2012 à 16:17 +0100, Fred Kiefer a écrit :
 I just did run the tests for base and get 12 failures. One is the know 
 +initialize bug of the gcc runtime. The other 11 come from the 
 NSNumberFormatter:
 
 
 base/NSNumberFormatter/basic10_4.m:
 Failed test: basic10_4.m:75 ... default 10.4 format same as Cocoa
 Failed test: basic10_4.m:82 ... round up for fractional part 0.5
 Failed test: basic10_4.m:87 ... round down for fractional part 0.5
 Failed test: basic10_4.m:93 ... minus sign assigned correctly
 Failed test: basic10_4.m:111 ... format width set correctly
 Failed test: basic10_4.m:115 ... positive prefix set correctly
 Failed test: basic10_4.m:119 ... default padding position is 
 before prefix
 Failed test: basic10_4.m:124 ... numeric and space padding OK
 Failed test: basic10_4.m:137 ... positive prefix is set 
 correctly for currency style
 Failed test: basic10_4.m:141 ... prefix and suffix used properly
 Failed test: basic10_4.m:145 ... negativeFormat used for -ve number
 --- Running tests in base/NSObject ---

I'm getting some of these too. After setting LANG to C the tests pass
fine.

Philippe



___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
https://lists.gnu.org/mailman/listinfo/gnustep-dev

Re: GNUstep Code Freeze

[Philippe Roussel]

Le samedi 21 janvier 2012 à 10:18 -0600, Stefan Bidi a écrit :
 On Sat, Jan 21, 2012 at 10:07 AM, Philippe Roussel p.o.rous...@free.frwrote:
 
  Hi Fred,
 
  I'm getting some of these too. After setting LANG to C the tests pass
  fine.
 
 
 Hmm... What was the value of LANG before?  I'd be interested to know what
 [NSLocale -currentLocale] is for your systems.

[[NSLocale currentLocale] description] gives me fr_FR and LANG is set to
fr_FR.UTF-8





___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
https://lists.gnu.org/mailman/listinfo/gnustep-dev

GSTheme activation

[Philippe Roussel]

Hi,

Playing with different themes I noticed that when starting an
application with GnomeTheme the debug log 'Gnome theme initialized'
appears multiple times.

I think the following patch is needed :

--- Source/GSTheme.m(revision 34503)
+++ Source/GSTheme.m(working copy)
@@ -282,19 +282,22 @@
 
 + (void) initialize
 {
-  if (themes == nil)
+  if ([GSTheme class] == self)
 {
-  themes = [NSMutableDictionary new];
-  null = RETAIN([NSNull null]);
-  defaultTheme = [[self alloc] initWithBundle: nil];
-  ASSIGN(theTheme, defaultTheme);
-  ASSIGN(currentThemeName, [defaultTheme name]);
-  names = NSCreateMapTable(NSNonOwnedPointerMapKeyCallBacks,
-   NSIntMapValueCallBacks, 0);
+  if (themes == nil)
+   {
+ themes = [NSMutableDictionary new];
+ null = RETAIN([NSNull null]);
+ defaultTheme = [[self alloc] initWithBundle: nil];
+ ASSIGN(theTheme, defaultTheme);
+ ASSIGN(currentThemeName, [defaultTheme name]);
+ names = NSCreateMapTable(NSNonOwnedPointerMapKeyCallBacks,
+  NSIntMapValueCallBacks, 0);
+   }
+  /* Establish the theme specified by the user defaults (if any);
+   */
+  [self defaultsDidChange: nil];
 }
-  /* Establish the theme specified by the user defaults (if any);
-   */
-  [self defaultsDidChange: nil];
 }
 
 + (GSTheme*) loadThemeNamed: (NSString*)aName

Or maybe just moving [self defaultsDidChange: nil] at the end of the
existing condition.

Philippe



___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
https://lists.gnu.org/mailman/listinfo/gnustep-dev

Re: GSTheme activation

[Philippe Roussel]

Le jeudi 12 janvier 2012 à 21:49 +0100, Philippe Roussel a écrit :
 Hi,
 
 Playing with different themes I noticed that when starting an
 application with GnomeTheme the debug log 'Gnome theme initialized'
 appears multiple times.
 
 I think the following patch is needed :
 
 --- Source/GSTheme.m  (revision 34503)
 +++ Source/GSTheme.m  (working copy)
 @@ -282,19 +282,22 @@
  
  + (void) initialize
  {
 -  if (themes == nil)
 +  if ([GSTheme class] == self)
  {
 -  themes = [NSMutableDictionary new];
 -  null = RETAIN([NSNull null]);
 -  defaultTheme = [[self alloc] initWithBundle: nil];
 -  ASSIGN(theTheme, defaultTheme);
 -  ASSIGN(currentThemeName, [defaultTheme name]);
 -  names = NSCreateMapTable(NSNonOwnedPointerMapKeyCallBacks,
 - NSIntMapValueCallBacks, 0);
 +  if (themes == nil)
 + {
 +   themes = [NSMutableDictionary new];
 +   null = RETAIN([NSNull null]);
 +   defaultTheme = [[self alloc] initWithBundle: nil];
 +   ASSIGN(theTheme, defaultTheme);
 +   ASSIGN(currentThemeName, [defaultTheme name]);
 +   names = NSCreateMapTable(NSNonOwnedPointerMapKeyCallBacks,
 +NSIntMapValueCallBacks, 0);
 + }
 +  /* Establish the theme specified by the user defaults (if any);
 +   */
 +  [self defaultsDidChange: nil];
  }
 -  /* Establish the theme specified by the user defaults (if any);
 -   */
 -  [self defaultsDidChange: nil];
  }
  
  + (GSTheme*) loadThemeNamed: (NSString*)aName
 
 Or maybe just moving [self defaultsDidChange: nil] at the end of the
 existing condition.

Or maybe (thanks Luiji)

--- Source/GSTheme.m(revision 34503)
+++ Source/GSTheme.m(working copy)
@@ -282,7 +282,7 @@
 
 + (void) initialize
 {
-  if (themes == nil)
+  if ([GSTheme class] == self)
 {
   themes = [NSMutableDictionary new];
   null = RETAIN([NSNull null]);
@@ -290,11 +290,11 @@
   ASSIGN(theTheme, defaultTheme);
   ASSIGN(currentThemeName, [defaultTheme name]);
   names = NSCreateMapTable(NSNonOwnedPointerMapKeyCallBacks,
-   NSIntMapValueCallBacks, 0);
+  NSIntMapValueCallBacks, 0);
+  /* Establish the theme specified by the user defaults (if any);
+   */
+  [self defaultsDidChange: nil];
 }
-  /* Establish the theme specified by the user defaults (if any);
-   */
-  [self defaultsDidChange: nil];
 }
 
 + (GSTheme*) loadThemeNamed: (NSString*)aName



___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
https://lists.gnu.org/mailman/listinfo/gnustep-dev

Re: Slow application startup when using a theme

[Philippe Roussel]

Le mardi 10 janvier 2012 à 10:56 +0100, Fred Kiefer a écrit :
 On 10.01.2012 05:54, Eric Wasylishen wrote:
  I didn't like the current approach either…  I just committed a
  rewrite of how theme images are handled which gets rid of theme
  proxies entirely, and eliminates the code in -[GSTheme activate] and
  -[GSTheme deactivate] which were setting/restoring images.
 
  Now, when a name is set on an NSImage instance, it also subscribes to
  the theme change notification. When an NSImage receives this
  notification, it does the name-to-path lookup again that +[NSImage
  imageNamed:] did, and reloads itself (discarding all reps) if the
  path has changed.
 
  It's a fairly major change but I tested Gorm, GSTest, SimpleAgenda,
  and tried switching between the GNUstep default theme, Neos, and
  Etoile's Nesedah theme while the apps were running, and all images
  seemed to update properly.
 
 I am completely impressed by what you did here. On the other hand, I 
 cannot look at code without trying to find flaws in it. Sorry, I am just 
 made that way.
 
 So this is what I found:
 
 - After your code is verified by tests we should get rid of the complete 
 class GSThemeProxy.

And there is a duplicate #import Foundation/NSNotification.h

 - The code in [NSImage imageNamed:] could be simpified, not that the 
 proxy is gone. We don't need to get the same image we just created from 
 the dictionary.
 
 - I don't quite understand what happens when we switch back from having 
 a theme to not using one. Will the standard GNUstep images get reused? 
 The question here is whether we send the notification 
 GSThemeDidActivateNotification when there is no theme at all.

I tested it (by adding NSLog) and it works : when going back from Neos
to native GNUstep theme, -themeDidActivate is called and the paths are
recomputed and the bitmaps loaded if needed.

Nitpicking : instead of registering for GSThemeDidActivateNotification
for every image (and getting x notifications), it would probably be more
efficient to register only once (but how ?) and check every image cached
in nameDict.

Anyway, this is a nice improvement of the code and of the user
experience, I like it when my computer seems faster :o)

Thanks,
Philippe


___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
https://lists.gnu.org/mailman/listinfo/gnustep-dev

Re: Slow application startup when using a theme

[Philippe Roussel]

Hi gui hero :o)

Le mardi 10 janvier 2012 à 12:16 -0700, Eric Wasylishen a écrit :

 Good idea.. just implemented that by moving the notification registration to
 +[NSImage initialize]. Theme switching actually feels noticeably faster now
 which is odd; I wasn't expecting NSNotificationCenter to have much overhead.

Works great here, thanks again,
Philippe



___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
https://lists.gnu.org/mailman/listinfo/gnustep-dev

NSImage _clearFileTypeCaches

[Philippe Roussel]

Hi,

Isn't the following patch needed for the code in +imageFileTypes and
friends to rebuild the arrays when needed ? Those methods compare the
arrays' pointers with nil and I think RELEASE doesn't affect nil to its
argument.

Index: Source/NSImage.m
===
--- Source/NSImage.m(révision 34482)
+++ Source/NSImage.m(copie de travail)
@@ -1812,10 +1812,10 @@
 
 + (void) _clearFileTypeCaches: (NSNotification*)notif
 {
-  RELEASE(imageUnfilteredFileTypes);
-  RELEASE(imageFileTypes);
-  RELEASE(imageUnfilteredPasteboardTypes);
-  RELEASE(imagePasteboardTypes);
+  DESTROY(imageUnfilteredFileTypes);
+  DESTROY(imageFileTypes);
+  DESTROY(imageUnfilteredPasteboardTypes);
+  DESTROY(imagePasteboardTypes);
 }
 
 + (void) _themeDidActivate: (NSNotification *)notif

Philippe



___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
https://lists.gnu.org/mailman/listinfo/gnustep-dev

Font rendering problems with cairo

[Philippe Roussel]

I feel like I am spamming the list these days, sorry.

I didn't follow the recent threads about font rendering so maybe this is
known but there are still some bugs in there. Take a look at the
attached screenshot.

This is with latest gui and back, cairo backend, libcairo 1.10.2 on
ubuntu 11.04 32 bits and xdpyinfo says :

screen #0:
  dimensions:1280x800 pixels (339x212 millimeters)
  resolution:96x96 dots per inch
  depths (7):24, 1, 4, 8, 15, 16, 32

Hope this helps,
Philippe

attachment: about.png___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
https://lists.gnu.org/mailman/listinfo/gnustep-dev

Re: Slow application startup when using a theme

[Philippe Roussel]

Le lundi 09 janvier 2012 à 12:59 -0700, Eric Wasylishen a écrit :
 Hi,
 Thanks for the report, Philippe; this is indeed a fairly serious problem. :-(
 
  
  That would probably works but what about changing how +imageNamed:
  works ?
  
  When this method is called with a image name lacking an extension (ie
  'GNUstep' or 'common_arrowLeft'), it tries to find a existing file by
  adding any know extension and calling a NSFileManager method, and this 3
  times (main bundle, theme bundle and then every Images directory in the
  system). With bitmaps existing only in the system directories this is
  extremely costly as it tries something like 500 paths before the good
  one. (And I know you understand all that, I'm just filling the blanks
  for the others who might be interested, sorry :o)
  
  Couldn't we inverse the thing and check if one of the existing file in
  the directories has an extension known to be an image type ? I mean :
  list the files in the main bundle, look for the ones with a matching
  name (ie 'common_arrowLeft') and then check if the extension is none.
  The list of file in a bundle could also be cached.
  
  Worth trying ?
 
 That sounds like a good idea.
 
 Much of the overhead when using Neos is caused by the section of
 -[GSTheme activate] which loads all images in the theme.
 
 Here are some tests:
 startup Ink with default theme: 51k syscalls
 startup Ink with Neos.theme: 183k syscalls
 startup Ink with Neos.theme, with GSTheme.m lines 473 to 539 commented
 out: 95k syscalls.

This code isn't working correctly then as it's supposed to load the
bundle images and cache them so that [NSImage +imageNamed:] can find
them quickly.
It should minimize the work to load all bitmap as it's using the list of
existing files, something close to what I proposed, instead of trying
every paths on the planet...

Or am I missing something here ?

 Fred, even if we implement image filter services support and move the
 ImageMagick support to a service, +[NSImage imageNamed:] would still
 do just as much work because it uses [NSImage imageFileTypes], which
 would include the types supported by filter services.
 
 
 How about adding caching to NSBundle? It already caches the budle
 info.plist, why not the directory listing of the resource directory?
 
 Also, it might be nice if NSBundle would have a private method:
 -(NSArray*)pathsForResource: (NSString*)name ofTypes: (NSArray*)types;
 
 which given a name like @common_ArrowRight and a types array
 (@tiff, @png, … )
 would return an array of paths to any matching resources in the
 bundle, and it would do so efficiently using a cache of the directory
 contents.

Sounds nice.

Philippe


___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
https://lists.gnu.org/mailman/listinfo/gnustep-dev

Re: Slow application startup when using a theme

[Philippe Roussel]

Le lundi 09 janvier 2012 à 20:51 +, Richard Frith-Macdonald a
écrit :
 On 9 Jan 2012, at 19:59, Eric Wasylishen wrote:
  
  How about adding caching to NSBundle? It already caches the budle
 info.plist, why not the directory listing of the resource directory?
 
 I hacked in some quick/dirty cacheing in NSBundle.  Does it make
 enough difference to be worth doing properly rather than reverting?

Application startup is now a little under 2 seconds down from 3 without
your changes. Better but still slow.

Unrelated : your last change in Source/GSAvahiNetService.m breaks the
build.

Thanks,
Philippe


___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
https://lists.gnu.org/mailman/listinfo/gnustep-dev

Re: Slow application startup when using a theme

[Philippe Roussel]

Le lundi 09 janvier 2012 à 22:18 +0100, Philippe Roussel a écrit :
 Le lundi 09 janvier 2012 à 20:51 +, Richard Frith-Macdonald a
 écrit :
  On 9 Jan 2012, at 19:59, Eric Wasylishen wrote:
   
   How about adding caching to NSBundle? It already caches the budle
  info.plist, why not the directory listing of the resource directory?
  
  I hacked in some quick/dirty cacheing in NSBundle.  Does it make
  enough difference to be worth doing properly rather than reverting?
 
 Application startup is now a little under 2 seconds down from 3 without
 your changes. Better but still slow.

After removing the caching code in [GSTheme -activate] mentioned by
Eric, application startup with Neos is only 0.1 second slower than with
the default GNUstep theme. That's an improvement !

Thanks,
Philippe



___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
https://lists.gnu.org/mailman/listinfo/gnustep-dev

Re: cairo x11 surfaces

[Philippe Roussel]

Hi,

On Thu, Oct 13, 2011 at 03:26:10PM -0600, Eric Wasylishen wrote:
 Hi Fred,
 
 I had a look at implementing it today, and it turned out to be
 easier than expected so I finished  committed it. 
 
 If we run in to problems we can switch back to XGCairoXImageSurface
 before the next release, but it looks promising. In particular, I
 tried X forwarding to Apple's X11.app, which only supports 24-bit
 windows, and the new surface is significantly faster than
 XGCairoXImageSurface, and the alpha channel of images is correctly
 preserved (unlike XGCairoSurface). 
 
 Riccardo, this should fix GNUstep on the 16-bit display
 configuration where it wasn't working for you. If you could test it
 some time and let me know if it works, that would be great.

I tested your modifications briefly yesterday. The gui drawing is now
really fast and responsive over ssh, comparable to gtk I would say,
but I get a lot of flickering when resizing a windows on a local
connection.

Thanks,
Philippe
-- 
Un celibataire est un homme qui a rate l'occasion de rendre une femme 
malheureuse. Jasmine Birtles


___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
https://lists.gnu.org/mailman/listinfo/gnustep-dev

Re: Compilation error

[Philippe Roussel]

Le vendredi 05 août 2011 à 18:35 +0100, David Chisnall a écrit :
 Should be fixed in svn.

Yep, thanks.

Philippe



___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
https://lists.gnu.org/mailman/listinfo/gnustep-dev

Compilation error

[Philippe Roussel]

Hi all,

My gnustep testfarm setup needs the following one liner for the
compilation to finish.

This is on GNU/Linux i686 with gcc 4.4.5. Removing the include doesn't
generate any warning for me and I get the following results for base
tests :


   6399 Passed tests
 15 Dashed hopes
  1 Failed set

Philippe

Index: base/Source/NSNumber.m
===
--- base/Source/NSNumber.m  (révision 33694)
+++ base/Source/NSNumber.m  (copie de travail)
@@ -47,7 +47,6 @@
 #import Foundation/NSException.h
 #import Foundation/NSValue.h
 #import GNUstepBase/NSObject+GNUstepBase.h
-#include objc/runtime.h
 
 /*
  * NSNumber implementation.  This matches the behaviour of Apple's



___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
https://lists.gnu.org/mailman/listinfo/gnustep-dev

Re: Compilation error

[Philippe Roussel]

Le jeudi 04 août 2011 à 21:16 +0100, David Chisnall a écrit :
 Applying this patch will break the NSSmallInt stuff.  I thought
 Richard fixed the ObjectiveC2 stuff so that it was safe to include
 objc/runtime.h anywhere - or does that only work after GNUstep is
 installed?  Did you try rerunning configure?

I'm not building base manually and running make check, I'm using the
gnustep-testfarm test-gnustep script, see

http://svn.gna.org/svn/gnustep/autotest

In the setup I use to run gnustep applications (also freshly updated
from svn), NSNumber compiles without modification but it also is
configured to use libojc2 so a lot of things differ.

Philippe





___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
https://lists.gnu.org/mailman/listinfo/gnustep-dev

Re: Graphics Rounding (was Re: Pixel-aligned autoresizing)

[Philippe Roussel]

Hi

Le dimanche 10 juillet 2011 à 21:51 +0200, Fred Kiefer a écrit :
 On 09.07.2011 21:04, Eric Wasylishen wrote:
  Hi Philippe,
 
  The jumping is caused by our use of rint() in NSButtonCell - in fact, I 
  think we should avoid rint() entirely for graphics, because it uses a 
  round halfway cases to the nearest even integer algorithm; so 1.5 rounds 
  to 2, but 2.5 also rounds to 2.
 
  The annoying thing is that none of the C standard library functions 
  implement a good rounding algorithm for graphics. c99's round() rounds 
  halfway cases away from zero. This is probably OK in practice but not 
  ideal, since it means the location of the coordinate system origin affects 
  the rounding. I think the best algorithm for graphics is 
  round-towards-infinity, so just floor(x+0.5). I wonder if we should just 
  introduce this as a function for internal use, like 
  GSRoundTowardsInfinity().
 
  Eric
 
 Hi Eric,
 
 could you please explain why you think that one of these rounding 
 methods is better suited for graphics than the others? For me they are 
 all equally problematic :-(
 If we ever change to another function we will have to make sure it is 
 available equally on all supported systems. That way why I wanted to 
 stick with rint() for all cases as we already try to support that 
 everywhere.
 
 Fred
 
 PS: I also don't see how pure horizontal resizing may affect the 
 vertical position of a subview. Is this the case that mentioned earlier, 
 but couldn't come up with a real test case for?

I'm sorry, my description of the problem wasn't really clear.
Vertical resizing of the main window affect the vertical position of the
bitmaps, horizontal resizing affect the horizontal position.

The strange thing is that the nsbox that contains those bitmap buttons
has a fixed size and so isn't affected by the window resizing but I
guess it depends at what stage the rouding is done (on relative
coordinates or not).

Philippe


___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
https://lists.gnu.org/mailman/listinfo/gnustep-dev

Re: Window resizing (X11)

[Philippe Roussel]

(sorry, wrong email address used for my last mail, corrected)

Le lundi 16 mai 2011 à 15:24 -0600, Eric Wasylishen a écrit :
  
  I can confirm that window resizing looks much better now, I don't see
  the annoying flickering anymore, thanks a lot !
  
 Good to hear!
 
  Not related to your patch but annoying, I would say that repainting is
  kind of slow compared to gtk. When resizing a GWorkspace window to a
  bigger size (in the icon view for example), the old content is repeated
  in the added area before drawing completes and displays the new content.
  Do you also see this ? With today's computing power I find this strange.
  
 I haven't tried GWorkspace but yeah, I think repainting is a lot
 slower than it should be. I have a list of things to investigate at
 some point:
 
 - for cairo, we do all drawing into cairo image surfaces. Comments I
 read on the cairo mailing list suggest using xlib surfaces should be
 (much?) faster.
 
 - the image drawing code needs reworking. As far as I understand it
 creates a window every time an image is drawn. Moving to the image
 system I implemented in Opal should bring a big improvement in
 performance.
 
 - I don't have a lot of faith in the x11 backend code as it's pretty
 complex and has a lot of legacy compatibility code. I fear it's doing
 more X roundtrips than necessary, but I don't have any evidence to
 back this up (or X programming skill..) :-)
 
 These are more or less speculation though, as I haven't seriously
 profiled window repainting.

Unfortunately I have zero knowledge in X, back and cairo but if I can
help by testing patches let me know.

Maybe x11vis (http://www.x11vis.org) could help.

Philippe



___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
https://lists.gnu.org/mailman/listinfo/gnustep-dev

Re: Window resizing (X11)

[Philippe Roussel]

Hi,

Le lundi 16 mai 2011 à 14:26 -0600, Eric Wasylishen a écrit :
 Hey,
 I committed a patch on the weekend implementing the
 _NET_WM_SYNC_REQUEST protocol described here:
 http://standards.freedesktop.org/wm-spec/1.3/ar01s06.html
 
 There isn't much info about it on the web; the best I could find is
 from the Qt blog:
 http://labs.qt.nokia.com/2009/06/10/smooth-and-solid-resizing-on-x11/
 
 Resizing feels a lot better to me now. The window contents and window
 manager's frame stay together about as well as GTK now - not perfect,
 but better than before.
 
 
 When using the window manager's window decorations (i.e.
 GSBackHandlesWindowDecorations is not NO) my patch had the side effect
 of getting rid of the black flashing when resizing. I was seeing the
 entire window repeatedly flash solid black while resizing. I saw this
 in all WM's I tried (windowmaker, metacity, enlightenment 0.17). Were
 other people seeing this as well? Is it gone now?

I can confirm that window resizing looks much better now, I don't see
the annoying flickering anymore, thanks a lot !

Not related to your patch but annoying, I would say that repainting is
kind of slow compared to gtk. When resizing a GWorkspace window to a
bigger size (in the icon view for example), the old content is repeated
in the added area before drawing completes and displays the new content.
Do you also see this ? With today's computing power I find this strange.

Philippe



___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
https://lists.gnu.org/mailman/listinfo/gnustep-dev

Re: Deadlock in base/Tests/base/NSObject/initialize.m

[Philippe Roussel]

Le vendredi 29 avril 2011 à 15:40 +0100, David Chisnall a écrit :
 On 29 Apr 2011, at 15:26, Philippe Roussel wrote:
 
  Using gcc 4.4.5 I get a deadlock with the system's libojbc and with
  libobjc2. Stacktraces are similar for both cases :
 
 
 Are you using trunk libobjc2?  This test passes for me (also passes on
 OS X).  I thought I puts timeouts in the correct places for it to
 timeout and give up, rather than deadlock, but maybe I missed one.
 Probably the easiest thing to do is just add a call to alarm() so that
 the test gets a signal and dies after 10 seconds if it hasn't already
 finished (takes about 3 seconds to run correctly - there's lots of
 sleeping in there to make sure that the threads have definitely caught
 up with each other).

I think I was using version 1.1 or something like that. But you're
right, the test passes with libobjc2 trunk.

I guess I will have to run the testsuite with libobjc2 from now on.

Thanks,
Philippe



___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
https://lists.gnu.org/mailman/listinfo/gnustep-dev

Re: NSConnection bugs

[Philippe Roussel]

Le mardi 29 mars 2011 à 09:25 +0100, Richard Frith-Macdonald a écrit :
 On 29 Mar 2011, at 01:01, David Chisnall wrote:
 
  Hello the list,
  
  I spent some time with valgrind and found out why NSConnection is so flakey 
  on 64-bit platforms.  It seems that we use the same incorrect pattern in a 
  lot of places throughout the class.  We probably use it in other places, so 
  it would be worth doing a brief audit for this bug before the next release. 
   I had a quick look, and I think that NSConnection is the only place where 
  we use GSIMap with something other than pointers.
  
  The problem is in statements like this:
  
   node = GSIMapNodeForKey(IreplyMap, (GSIMapKey)seq);
  
  Looks fine?  The problem is that (GSIMapKey) is a union (something 
  concealed by the fact that it is a macro - unions are difficult to use 
  safely, and anything that hides the fact that you are using a union is 
  generally a bad thing).  Specifically, it's a problem that GSIMapKey is a 
  union of void*, id, unsigned, and int.  On most current 64-bit platforms, 
  unsigned and int are 32-bit quantities, while void* and id are 64-bit 
  quantities. 
  
  The problem, therefore, is that the we are defining 4 bytes of an 8-byte 
  quantity and then (in the callee) accessing all 8 bytes.  This results in 
  some random behaviour.  The connection.m test was failing because sometimes 
  the uninitialised bytes were 0 (so the map was finding the value it was 
  looking for) and sometimes they were some other value from the stack.
 
 Well spotted.  I've implemented a fix for that throughout base.

Seems to break on x86-64 gcc 4.4.3 :

GSAttributedString.m:147: error: cast to union type from type not present in 
union

Philippe



___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev

Re: NSConnection bugs

[Philippe Roussel]

Le mardi 29 mars 2011 à 10:46 +0100, Richard Frith-Macdonald a écrit :
  
  Seems to break on x86-64 gcc 4.4.3 :
  
  GSAttributedString.m:147: error: cast to union type from type not present 
  in union
 
 Ah, the problems of not actually having a 64bit development system ...
 I forgot some places where explicit casts are required ... should be
 fixed now.

Yep, no more compilation errors, thanks.

Philippe



___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev

Application icon size in the open and save dialogs

[Philippe Roussel]

Hi,

The image shown in NSSavePanel has a size of 48x48 pixels. The
application image could be of a different size, resize it.

Maybe a copy of applicationIconImage should be made before setting the
image size ?

Philippe

Index: Source/NSSavePanel.m
===
--- Source/NSSavePanel.m(révision 32563)
+++ Source/NSSavePanel.m(copie de travail)
@@ -344,6 +344,7 @@
   r = NSMakeRect (8, 261, 48, 48);
   button = [[NSButton alloc] initWithFrame: r]; 
   image = [[NSApplication sharedApplication] applicationIconImage];
+  [image setSize:NSMakeSize(48,48)];
   [button setImage: image];
   [button setBordered: NO];
   [button setEnabled: NO];



___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev

Re: Application icon size in the open and save dialogs

[Philippe Roussel]

Le lundi 14 mars 2011 à 13:24 +0100, Fred Kiefer a écrit :
 Am 14.03.2011 09:48, schrieb Philippe Roussel:
  Hi,
 
  The image shown in NSSavePanel has a size of 48x48 pixels. The
  application image could be of a different size, resize it.
 
  Maybe a copy of applicationIconImage should be made before setting the
  image size ?
 
  Philippe
 
  Index: Source/NSSavePanel.m
  ===
  --- Source/NSSavePanel.m(révision 32563)
  +++ Source/NSSavePanel.m(copie de travail)
  @@ -344,6 +344,7 @@
  r = NSMakeRect (8, 261, 48, 48);
  button = [[NSButton alloc] initWithFrame: r];
  image = [[NSApplication sharedApplication] applicationIconImage];
  +  [image setSize:NSMakeSize(48,48)];
  [button setImage: image];
  [button setBordered: NO];
  [button setEnabled: NO];
 
 Yes, if we go that way we will have to use a copy of the image here. 
 What I don't like about image copies is that we wont get noticed if the 
 original image changes. Why are we using an NSButton here in the first 
 place? Wouldn't an NSImageView that scales the image work as well?

For no good reason that I can see.

The following patch works well.

Philippe

Index: Source/NSSavePanel.m
===
--- Source/NSSavePanel.m(révision 32568)
+++ Source/NSSavePanel.m(copie de travail)
@@ -181,6 +181,7 @@
   NSBox *bar;
   NSButton *button;
   NSImage *image;
+  NSImageView *imageView;
   NSRect r;
   id lastKeyView;
 
@@ -342,17 +343,12 @@
   [_browser setTarget: _okButton];
 
   r = NSMakeRect (8, 261, 48, 48);
-  button = [[NSButton alloc] initWithFrame: r]; 
   image = [[NSApplication sharedApplication] applicationIconImage];
-  [button setImage: image];
-  [button setBordered: NO];
-  [button setEnabled: NO];
-  [[button cell] setImageDimsWhenDisabled: NO];
-  [button setImagePosition: NSImageOnly];
-  [button setAutoresizingMask: NSViewMinYMargin];
-  [button setTag: NSFileHandlingPanelImageButton];
-  [_topView addSubview: button];
-  [button release];
+  imageView = [[NSImageView alloc] initWithFrame: r];
+  [imageView setAutoresizingMask: NSViewMinYMargin];
+  [imageView setImage:image];
+  [_topView addSubview: imageView];
+  [imageView release];
 
   r = NSMakeRect (67, 276, 200, 14);
   _titleField = [[NSTextField alloc] initWithFrame: r]; 



___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev

Re: Desktop file generated with wrong path ?

[Philippe Roussel]

Le jeudi 10 mars 2011 à 17:56 -0500, Gregory Casamento a écrit :
 I will have another look at this tonight to see if I cant fix some of
 these things.  I'd like to make integration with GNOME as smooth and
 seamless as possible.

It's probably the wrong way to do it but with the following patch the
icon path is set correctly and the desktop file recognized as such by
Nautilus.

Hope this helps,
Philippe


Index: base/Tools/pl2link.m
===
--- base/Tools/pl2link.m(révision 32530)
+++ base/Tools/pl2link.m(copie de travail)
@@ -30,6 +30,7 @@
 #importFoundation/NSException.h
 #importFoundation/NSFileManager.h
 #importFoundation/NSProcessInfo.h
+#importFoundation/NSPathUtilities.h
 
 int
 main(int argc, char** argv, char **env)
@@ -46,6 +47,7 @@
   NSString  *installDomain;
   NSString  *installPath = @;
   NSString  *appName = @;
+  NSDictionary  *gnustepConfig;
 
 #ifdef GS_PASS_ARGUMENTS
   GSInitializeProcess(argc, argv, env);
@@ -117,27 +119,39 @@
 {
   [fileContents appendFormat: @Comment=%@\n, entry];
 }
+  gnustepConfig = GNUstepConfig(nil);
   installDomain = [[procinfo environment] objectForKey: 
@GNUSTEP_INSTALLATION_DOMAIN];
   if(installDomain != nil)
 {
   if([installDomain isEqualToString: @SYSTEM])
{
- installPath = [[procinfo environment] objectForKey: 
@GNUSTEP_SYSTEM_ROOT];
+ if([gnustepConfig objectForKey:@GNUSTEP_SYSTEM_APPS])
+   installPath = [gnustepConfig objectForKey:@GNUSTEP_SYSTEM_APPS];
+ else
+   installPath = [[[procinfo environment] objectForKey: 
@GNUSTEP_SYSTEM_ROOT] 
+   stringByAppendingPathComponent:@Applications];
}
   else
{
- installPath = [[procinfo environment] objectForKey: 
@GNUSTEP_LOCAL_ROOT];
+ if([gnustepConfig objectForKey:@GNUSTEP_LOCAL_APPS])
+   installPath = [gnustepConfig objectForKey:@GNUSTEP_LOCAL_APPS];
+ else
+   installPath = [[[procinfo environment] objectForKey: 
@GNUSTEP_LOCAL_ROOT]
+   stringByAppendingPathComponent:@Applications];
}
 }
   else
 {
-  installPath = [[procinfo environment] objectForKey: 
@GNUSTEP_LOCAL_ROOT];
+  if([gnustepConfig objectForKey:@GNUSTEP_LOCAL_APPS])
+   installPath = [gnustepConfig objectForKey:@GNUSTEP_LOCAL_APPS];
+  else
+   installPath = [[[procinfo environment] objectForKey: 
@GNUSTEP_LOCAL_ROOT]
+   stringByAppendingPathComponent:@Applications];
 }
   entry = [plist objectForKey: @NSIcon];
   if (entry != nil)
 {
-  NSString *iconPath = [installPath stringByAppendingPathComponent: 
@Applications] 
-   stringByAppendingPathComponent:appName] 
+  NSString *iconPath = installPath 
stringByAppendingPathComponent:appName] 
   stringByAppendingPathExtension:@app] 
  stringByAppendingPathComponent:@Resources]
 stringByAppendingPathComponent:entry];
Index: make/Instance/application.make
===
--- make/Instance/application.make  (révision 32530)
+++ make/Instance/application.make  (copie de travail)
@@ -321,7 +321,8 @@
  fi$(END_ECHO)
 
 $(APP_DIR)/Resources/$(GNUSTEP_INSTANCE).desktop: $(APP_INFO_PLIST_FILE)
-   $(ECHO_CREATING)pl2link $^ 
$(APP_DIR)/Resources/$(GNUSTEP_INSTANCE).desktop$(END_ECHO)
+   $(ECHO_CREATING)pl2link $^ 
$(APP_DIR)/Resources/$(GNUSTEP_INSTANCE).desktop; \
+   chmod a+x $(APP_DIR)/Resources/$(GNUSTEP_INSTANCE).desktop$(END_ECHO)
 
 endif
 



___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev

Re: Desktop file generated with wrong path ?

[Philippe Roussel]

Le jeudi 10 mars 2011 à 16:13 -0500, Gregory Casamento a écrit :
 This is my fault and it's a bug I need to address.   
 
 
 The issue was that the .desktop file was being generated prior to my
 change completely wrong and was absolutely useless in the first place
 as it was being generated assuming that the .desktop file would live
 in the .app directory and would use relative paths.  Unfortunately,
 this is not how GNOME works.   It appears, oddly, that GNOME requires
 absolute paths to everything, the icon, the executable, etc... 

Well, almost none of the desktop files on my ubuntu machine have full
paths for the executable. It's just the name of the executable and this
executable has to be in the PATH to be found.

The icon part very often contains only a single name, without an
extension, like for example 'inkspace'. I guess when Nautilus reads the
desktop file it searches /usr/share/icons/$MyTheme$/... for an icon of
the right size named inkspace.svg.

 I need to derive the path in another way which points to the correct
 location and submit that fix.   It may indeed be possible that it will
 never be entirely possible to generate this file automatically and
 have it actually work (and NO... it wasn't working as it was
 before). ;)

Well, if we can install the application and its desktop file
in /opt/GNUstep-trunk/Local/Applications/, it should be too hard to know
that the icon in the application's Resources directory will be located
in /opt/GNUstep-trunk/Local/Applications/MyApp.app/Resources/ and write
that in the desktop file !

Of course if someone installs MyApp.app in a strange location without
using 'make install' (or a packaged version) it will break but why would
someone do that ?

Anyway, maybe I'm missing something obvious...

Philippe




___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev

Re: Thread question

[Philippe Roussel]

Hi

Le samedi 05 mars 2011 à 17:06 +, Richard Frith-Macdonald a écrit :

 I added a configure-time check in gnustep-base to detect objc runtime 
 libraries which don't support +initialise properly and warn about them.
 I also added a run-time alert to be printed if a program becomes 
 multithreaded and configure had detected that the runtime library was not 
 thread safe.

Is this test supposed to pass with libobjc2 trunk ?

I'm using gcc 4.4.3.

Philippe



___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev

Re: Thread question

[Philippe Roussel]

[Adding Daving to Cc]

Le lundi 07 mars 2011 à 09:28 +, Richard Frith-Macdonald a écrit :
 On 7 Mar 2011, at 09:04, Philippe Roussel wrote:
 
  Hi
  
  Le samedi 05 mars 2011 à 17:06 +, Richard Frith-Macdonald a écrit :
  
  I added a configure-time check in gnustep-base to detect objc runtime 
  libraries which don't support +initialise properly and warn about them.
  I also added a run-time alert to be printed if a program becomes 
  multithreaded and configure had detected that the runtime library was not 
  thread safe.
  
  Is this test supposed to pass with libobjc2 trunk ?
 
 It's supposed to pass with any runtime which supports +initialize
 properly, but I haven't tested all the different runtimes to see which
 do  but I know the old gnu runtime was buggy and that the gnustep
 libobjc in trunk ought to be OK  since I applied the patch I submitted
 to gcc a few years back.  I'm not entirely happy with that patch (I've
 never found time to clean it up properly), but it's better than
 nothing, and I've been running code using it for a couple of years.

Ok, I didn't know gnustep libobjc was still active. I guess I should try
it.

 The configure check is a new check, so it's probably not bomb-proof...
 It certainly won't work without pthreads support ... but since we now
 require pthreads to build base, this should not be a problem

Here is an snippet from config.log with libobjc2 trunk, gcc 4.4.3 and
the appended patch applied :

configure:13221: checking for thread-safe +initialize in runtime
configure:13241: gcc -o conftest -g -O2  
-I/opt/GNUstep-trunk/System/Library/Headers 
-I/opt/GNUstep-trunk/Local/Library/Headers 
-I/opt/GNUstep-trunk/Local/Library/Headers 
-I/opt/GNUstep-trunk/Local/Library/Headers -fgnu-runtime -x objective-c  
-L/opt/GNUstep-trunk/System/Library/Libraries 
-L/opt/GNUstep-trunk/Local/Library/Libraries 
-L/opt/GNUstep-trunk/Local/Library/Libraries 
-L/opt/GNUstep-trunk/Local/Library/Libraries conftest.c -lrt -ldl  -lpthread 
-lobjc 5
In file included from ./config/config.initialize.m:4,
 from conftest.c:1:
./config/objc-common.g: In function '+[NSObject new]':
./config/objc-common.g:44: warning: incompatible implicit declaration of 
built-in function 'calloc'
In file included from conftest.c:1:
./config/config.initialize.m: In function 'main':
./config/config.initialize.m:53: warning: passing argument 3 of 
'pthread_create' from incompatible pointer type
/usr/include/pthread.h:227: note: expected 'void * (*)(void *)' but argument is 
of type 'void (*)(void *)'
./config/config.initialize.m:66: warning: passing argument 3 of 
'pthread_create' from incompatible pointer type
/usr/include/pthread.h:227: note: expected 'void * (*)(void *)' but argument is 
of type 'void (*)(void *)'
configure:13245: $? = 0
configure:13251: ./conftest
problem with initialize
initialize_entered : 1
initialize_exited : 0
class_entered : 0
objc capability : 1
configure:13255: $? = 1
configure: program exited with status 1

I added a call to objc_test_capability to be sure it's using the right
libobjc as I think only libobjc2 provides it.

Philippe

Index: config/config.initialize.m
===
--- config/config.initialize.m  (révision 32479)
+++ config/config.initialize.m  (copie de travail)
@@ -2,6 +2,7 @@
  */
 
 #include objc-common.g
+#include objc/capabilities.h
 #include pthread.h
 #include stdio.h
 
@@ -88,6 +89,10 @@
  return 0; // OK
}
  fprintf(stderr, problem with initialize\n);
+ fprintf(stderr, initialize_entered : %d\n, initialize_entered);
+ fprintf(stderr, initialize_exited : %d\n, initialize_exited);
+  fprintf(stderr, class_entered : %d\n, class_entered);
+  fprintf(stderr, objc capability : %d\n, 
objc_test_capability(OBJC_CAP_EXCEPTIONS));
   return 1;
}
   else



___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev

Re: Thread question

[Philippe Roussel]

Le lundi 07 mars 2011 à 11:16 +0100, Philippe Roussel a écrit :
 [Adding Daving to Cc]

Sorry David



___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev

Re: Thread question

[Philippe Roussel]

Le lundi 07 mars 2011 à 10:49 +, Richard Frith-Macdonald a écrit :
 On 7 Mar 2011, at 10:37, Philippe Roussel wrote:
 
  Le lundi 07 mars 2011 à 11:16 +0100, Philippe Roussel a écrit :
  [Adding Daving to Cc]
  
  Sorry David
 
 I think this is a test bug ... needed to use volatile variables so
 that changes made by one thread would be noticed by others.

Works nicely now, thanks Richard.

Philippe



___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev

NSNumberFormatter tests fix

[Philippe Roussel]

Hi,

One of the tests in basic.m (round up for fractional part 0.5) is
failing only because of code ordering. The appended patch fixes it.

Philippe

Index: base/NSNumberFormatter/basic.m
===
--- base/NSNumberFormatter/basic.m  (revision 32445)
+++ base/NSNumberFormatter/basic.m  (working copy)
@@ -15,16 +15,14 @@
  +[NSNumberFormatter alloc] returns a NSNumberFormatter);
 
   fmt = [[[NSNumberFormatter alloc] init] autorelease];
-  num = [[[NSNumber alloc] initWithFloat: 1234.567] autorelease];
 
-  str = [fmt stringForObjectValue: num];
-
-  PASS_EQUAL(str, @1,234.57, default format same as Cocoa);
-
   num = [[[NSNumber alloc] initWithFloat: 1.01] autorelease];
   PASS_EQUAL([fmt stringFromNumber: num], @1.01,
 Handle leading zeroes in fractional part: 1.01);
 
+  num = [[[NSNumber alloc] initWithFloat: 1234.567] autorelease];
+  str = [fmt stringForObjectValue: num];
+  PASS_EQUAL(str, @1,234.57, default format same as Cocoa);
 
   [fmt setAllowsFloats: NO];
   PASS_EQUAL([fmt stringForObjectValue: num], @1,235,



___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev

Re: Problem with NSColorWell

[Philippe Roussel]

Le vendredi 25 février 2011 à 00:00 +, David Chisnall a écrit :
 On 24 Feb 2011, at 23:37, Fred Kiefer wrote:
 
  Am 24.02.2011 21:14, schrieb Philippe Roussel:
  Le lundi 24 janvier 2011 à 12:58 +0100, Fred Kiefer a écrit :
  
  [snip]
  
  This seems to be the problem here. There actually are two versions of
  GSColorSliderCell loaded. One from loading the wheel picker and one from
  loading the standard picker. It is exactly the same class coming from
  the same file. But of course your code is correct about warning when a
  class gets replaced by another one.
  
  Just a reminder so this problem won't be forgotten.
  
  I would like to help on this but my only idea is to move the
  GSColorSliderCell class to gui as a helper but I don't think you would
  like this...
  
  You are right, I don't like this idea too much. The code in these class
  would need a bit of rework to have it directly in the main gui code. But
  if this is the only way to get GNUstep gui working for you with libobjc2
  we will have to do that step. I was hoping for David to resolve the
  issue in a compatible way in libobjc2.
 
 In the current version, I've simply disabled this check.  I'd like to
 reenable it in the future.  Currently the Apple runtime logs a warning
 when you load a class twice and tells you that the one that will be
 used is undefined.  One of my aims with libobjc2 is to remove cases of
 undefined behaviour and turn them into hard errors.  It's easy for
 libobjc2 to ignore this, but -gui is definitely doing the wrong thing
 by loading two copies of the same class, so it is worth fixing.

Ok, I'm confused. Is this supposed to work with libobjc2 trunk, or some
released stable version ?

In trunk, objc_load_class still does abort() when loading an already
loaded class, maybe dumping a backtrace would be enough ?

Philippe



___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev

memmove instead of memcpy

[Philippe Roussel]

Hi,

Are these kind of patches considered useful ?
Documentation says memmove should be used when the memory areas overlap
and valgrind warns about it.

Philippe


Index: base/Source/NSPointerArray.m
===
--- base/Source/NSPointerArray.m(révision 32115)
+++ base/Source/NSPointerArray.m(copie de travail)
@@ -281,7 +281,7 @@
}
  if (i  _count - 1)
{
- memcpy(_contents + j, _contents + i + 1,
+ memmove(_contents + j, _contents + i + 1,
(_count - i) * sizeof(void*));
}
  _count = i = j;



___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev

Buggy change to NSPropertyList.m ?

[Philippe Roussel]

Hi,

With commit 32031 to NSPropertyList.m (and latest libobjc2) my
application crashes in weird ways. Reverting to 31997 on that file
apparently fixes it for me but I have no idea if the bug is in my
application or in NSPropertyList.

Here's backtrace with the latest change :

Program received signal SIGSEGV, Segmentation fault.
0xb770eeef in object_getClass (obj=0xb7adce30) at runtime.c:613
613 while ((Nil != isa)  objc_test_class_flag(isa, 
objc_class_flag_hidden_class))
(gdb) bt
#0  0xb770eeef in object_getClass (obj=0xb7adce30) at runtime.c:613
#1  0xb78d8f12 in OAppend (obj=0x832c5c8, loc=value optimized out, lev=1, 
step=2, x=100, dest=0x82bf448) at NSPropertyList.m:2179
#2  0xb78d9084 in OAppend (obj=value optimized out, loc=value optimized 
out, lev=0, step=2, x=100, dest=0x82bf448) at NSPropertyList.m:2266
#3  0xb78d944d in +[NSPropertyListSerialization 
dataWithPropertyList:format:options:error:] (self=0xb7adcbc0, _cmd=0xb7add078, 
aPropertyList=0x896b258, aFormat=100, anOption=0, 
error=0xbfffe3b8) at NSPropertyList.m:2411
#4  0xb78d355c in +[NSPropertyListSerialization 
dataFromPropertyList:format:errorDescription:] (self=0xb7adcbc0, 
_cmd=0xb7afb060, aPropertyList=0x896b258, aFormat=100, 
anErrorString=0xbfffe428) at NSPropertyList.m:2377
#5  0xb793d5e0 in writeDictionary (dict=0x896b258, file=value optimized out) 
at NSUserDefaults.m:157
#6  0xb793b947 in -[NSUserDefaults synchronize] (self=0x8244090, 
_cmd=0xb7afb298) at NSUserDefaults.m:1772
#7  0xb78967a4 in -[NSNotificationCenter _postAndRelease:] (self=0x8176f58, 
_cmd=0xb7acaa28, notification=0x83a9348) at NSNotificationCenter.m:1161
#8  0xb7895c4b in -[NSNotificationCenter postNotification:] (self=0x8176f58, 
_cmd=0xb7adfa70, notification=0x83a9348) at NSNotificationCenter.m:1190
#9  0xb714163f in ffi_call_SYSV () from /usr/lib/libffi.so.5
#10 0xb714146f in ffi_call () from /usr/lib/libffi.so.5
#11 0xb796a6c5 in GSFFIInvokeWithTargetAndImp (inv=0x83b4fb8, 
anObject=0x8176f58, imp=0xb7895be0 -[NSNotificationCenter postNotification:]) 
at GSFFIInvocation.m:406
#12 0xb796a88a in -[GSFFIInvocation invokeWithTarget:] (self=0x83b4fb8, 
_cmd=0xb7ac0eb8, anObject=0x8176f58) at GSFFIInvocation.m:481
#13 0xb7873643 in -[NSInvocation invoke] (self=0x83b4fb8, _cmd=0xb7aec070) at 
NSInvocation.m:640
#14 0xb7914b39 in -[NSTimer fire] (self=0x83c6670, _cmd=0xb7adfae8) at 
NSTimer.m:242
#15 0xb78e5a81 in -[NSRunLoop limitDateForMode:] (self=0x83b2038, 
_cmd=0xb7adfb40, mode=0xb7adfba0) at NSRunLoop.m:983
#16 0xb78e2375 in -[NSRunLoop runMode:beforeDate:] (self=0x83b2038, 
_cmd=0xb7fa6120, mode=0xb7adfba0, date=0x83c9cd0) at NSRunLoop.m:1247
#17 0xb7e52ac9 in -[GSDisplayServer(EventOps) 
getEventMatchingMask:beforeDate:inMode:dequeue:] (self=0x838c440, 
_cmd=0xb5364418, mask=4294967295, limit=0x83c9cd0, mode=0xb7adfba0, 
flag=1 '\001') at GSDisplayServer.m:1003
#18 0xb5332b5e in -[XGServer(X11Ops) 
getEventMatchingMask:beforeDate:inMode:dequeue:] (self=0x838c440, 
_cmd=0xb7efeeb0, mask=4294967295, limit=0x83c9cd0, mode=0xb7adfba0, 

Philippe


___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev

Possible memory leaks in NSPropertyList.m ?

[Philippe Roussel]

Using valgrind I noticed multiple memory leaks (most seem to be false
positives) when running a GNUstep app.

I *think* the following patch fixes two real leaks. Can someone review
this ?

Philippe

Index: Source/NSPropertyList.m
===
--- Source/NSPropertyList.m (révision 31995)
+++ Source/NSPropertyList.m (copie de travail)
@@ -305,11 +305,11 @@
   [self unescape];
   if (opts == NSPropertyListMutableContainersAndLeaves)
 {
- o = [value mutableCopy];
+ o = AUTORELEASE([value mutableCopy]);
}
   else
 {
- o = [value copy];
+ o = AUTORELEASE([value copy]);
}
   ASSIGN(plist, o);
 }
@@ -1750,6 +1750,7 @@
}
   NSZoneFree(NSDefaultMallocZone(), base);
   obj = [[NSString alloc] initWithCharacters: map length: len];
+  NSZoneFree(NSDefaultMallocZone(), map);
   [output appendData: [obj dataUsingEncoding: NSUTF8StringEncoding]];
   RELEASE(obj);
 }



___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev

Re: Long pauses in applications maybe due to gpbs : Timed out waiting for X...

[Philippe Roussel]

On Mon, Jan 31, 2011 at 11:56:45AM +0100, Fred Kiefer wrote:
 The interesting line is:
 Owning program failed to convert data.
 
 Could it be that the content of the pasteboard was something that wasn't
 a string, but our code always expects that it can be converted to a string?

I guess I'll have to trace the execution to answer that. But before
that I have to mention that this message appears multiple times in
this log and I only had one timeout all this time. Are you sure this
is related ?

[snip]

  2011-01-30 22:05:24.002 gpbs[7030] PasteboardObject: 0x9a0ce50 get data 
  for type 'NSStringPboardType' version 1
  2011-01-30 22:05:24.002 gpbs[7030] PropertyNotify.
  2011-01-30 22:05:24.002 gpbs[7030] Selection (PRIMARY) notify - 'None'.
  2011-01-30 22:05:24.002 gpbs[7030] Owning program failed to convert data.
  2011-01-30 22:05:24.002 gpbs[7030] SelectionNotify.
  2011-01-30 22:05:24.003 gpbs[7030] PropertyNotify.
  2011-01-30 22:05:24.003 gpbs[7030] Selection (PRIMARY) notify - 'None'.
  2011-01-30 22:05:24.003 gpbs[7030] Owning program failed to convert data.
  2011-01-30 22:05:24.003 gpbs[7030] SelectionNotify.
  2011-01-30 22:05:24.003 gpbs[7030] PasteboardObject: 0x9a0ce50 set data 
  for type 'NSStringPboardType' version 1
  2011-01-30 22:05:24.003 gpbs[7030] set data for 0x9a0b9c8
  2011-01-30 22:05:24.003 gpbs[7030] get data for 0x9a0b9c8
  2011-01-30 22:05:44.903 gpbs[7030] PasteboardObject: 0x9a0ce50 get data 
  for type 'NSStringPboardType' version 1
  2011-01-30 22:05:47.906 gpbs[7030] Timed out waiting for X append for 
  Selection
  2011-01-30 22:05:47.906 gpbs[7030] PropertyNotify.
  2011-01-30 22:05:47.906 gpbs[7030] PropertyNotify.
  2011-01-30 22:05:47.906 gpbs[7030] Selection (PRIMARY) notify - 'None'.
  2011-01-30 22:05:47.906 gpbs[7030] Owning program failed to convert data.
  2011-01-30 22:05:47.907 gpbs[7030] SelectionNotify.
  2011-01-30 22:05:47.907 gpbs[7030] PasteboardObject: 0x9a0ce50 set data 
  for type 'NSStringPboardType' version 1
  2011-01-30 22:05:47.907 gpbs[7030] set data for 0x9a0b9c8
  2011-01-30 22:05:47.907 gpbs[7030] get data for 0x9a0b9c8
-- 
Sur le plus beau trône du monde, on n'est jamais assis que sur son cul ! 
Montaigne


___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev

Re: Long pauses in applications maybe due to gpbs : Timed out waiting for X...

[Philippe Roussel]

Le samedi 29 janvier 2011 à 21:26 +0100, Philippe Roussel a écrit :
 Le samedi 29 janvier 2011 à 14:11 +0100, Fred Kiefer a écrit : 
  I remember this behaviour form way back, but cannot remember seeing it
  in recent years. I may just have been lucky, though.
  Could you please start gpbs manually and switch on debug output for Pbs?
  This command should do the trick:
  gpbs --GNU-Debug=Pbs --verbose --verbose
  
  Providing verbose twice should given even more output than using in once:-)
  
  The whole pasteboard interaction is a bit of a mess.
 
 And, how surprising, I can't reproduce the problem anymore. And I have
 no idea what could have changed since yesterday...

I managed to capture a 3 second hang but I'm not sure the log will help
much. The first panel I opened worked fine but at 22:05:44 I opened a
second one in the same application hit the timeout :

2011-01-30 22:05:24.002 gpbs[7030] PasteboardObject: 0x9a0ce50 get data for 
type 'NSStringPboardType' version 1
2011-01-30 22:05:24.002 gpbs[7030] PropertyNotify.
2011-01-30 22:05:24.002 gpbs[7030] Selection (PRIMARY) notify - 'None'.
2011-01-30 22:05:24.002 gpbs[7030] Owning program failed to convert data.
2011-01-30 22:05:24.002 gpbs[7030] SelectionNotify.
2011-01-30 22:05:24.003 gpbs[7030] PropertyNotify.
2011-01-30 22:05:24.003 gpbs[7030] Selection (PRIMARY) notify - 'None'.
2011-01-30 22:05:24.003 gpbs[7030] Owning program failed to convert data.
2011-01-30 22:05:24.003 gpbs[7030] SelectionNotify.
2011-01-30 22:05:24.003 gpbs[7030] PasteboardObject: 0x9a0ce50 set data for 
type 'NSStringPboardType' version 1
2011-01-30 22:05:24.003 gpbs[7030] set data for 0x9a0b9c8
2011-01-30 22:05:24.003 gpbs[7030] get data for 0x9a0b9c8
2011-01-30 22:05:44.903 gpbs[7030] PasteboardObject: 0x9a0ce50 get data for 
type 'NSStringPboardType' version 1
2011-01-30 22:05:47.906 gpbs[7030] Timed out waiting for X append for Selection
2011-01-30 22:05:47.906 gpbs[7030] PropertyNotify.
2011-01-30 22:05:47.906 gpbs[7030] PropertyNotify.
2011-01-30 22:05:47.906 gpbs[7030] Selection (PRIMARY) notify - 'None'.
2011-01-30 22:05:47.906 gpbs[7030] Owning program failed to convert data.
2011-01-30 22:05:47.907 gpbs[7030] SelectionNotify.
2011-01-30 22:05:47.907 gpbs[7030] PasteboardObject: 0x9a0ce50 set data for 
type 'NSStringPboardType' version 1
2011-01-30 22:05:47.907 gpbs[7030] set data for 0x9a0b9c8
2011-01-30 22:05:47.907 gpbs[7030] get data for 0x9a0b9c8

Hope this helps,
Philippe


___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev

Re: Long pauses in applications maybe due to gpbs : Timed out waiting for X...

[Philippe Roussel]

Le samedi 29 janvier 2011 à 14:11 +0100, Fred Kiefer a écrit : 
 I remember this behaviour form way back, but cannot remember seeing it
 in recent years. I may just have been lucky, though.
 Could you please start gpbs manually and switch on debug output for Pbs?
 This command should do the trick:
 gpbs --GNU-Debug=Pbs --verbose --verbose
 
 Providing verbose twice should given even more output than using in once:-)
 
 The whole pasteboard interaction is a bit of a mess.

And, how surprising, I can't reproduce the problem anymore. And I have
no idea what could have changed since yesterday...

Sorry for the noise.

Here's the log just in case there's something interesting in there : 

philou@woody:~$ gpbs --verbose --verbose --no-fork --GNU-Debug=Pbs
2011-01-29 21:21:06.125 gpbs[2547] PropertyNotify.
2011-01-29 21:21:06.126 gpbs[2547] Selection (CLIPBOARD) notify - 'None'.
2011-01-29 21:21:06.126 gpbs[2547] Owning program failed to convert data.
2011-01-29 21:21:06.126 gpbs[2547] SelectionNotify.
2011-01-29 21:21:06.126 gpbs[2547] New PasteboardEntry 1 with items - 
(PasteboardData for type 'NSStringPboardType')
2011-01-29 21:21:06.126 gpbs[2547] PasteboardObject: 0xb5b8d0c0 declare types 
'(NSStringPboardType)' version 1
2011-01-29 21:21:06.126 gpbs[2547] PropertyNotify.
2011-01-29 21:21:06.126 gpbs[2547] Selection (PRIMARY) notify - 'None'.
2011-01-29 21:21:06.126 gpbs[2547] Owning program failed to convert data.
2011-01-29 21:21:06.126 gpbs[2547] SelectionNotify.
2011-01-29 21:21:06.127 gpbs[2547] New PasteboardEntry 1 with items - 
(PasteboardData for type 'NSStringPboardType')
2011-01-29 21:21:06.127 gpbs[2547] PasteboardObject: 0xb5bb2788 declare types 
'(NSStringPboardType)' version 1
2011-01-29 21:21:06.127 gpbs[2547] PropertyNotify.
2011-01-29 21:21:06.127 gpbs[2547] Selection (SECONDARY) notify - 'None'.
2011-01-29 21:21:06.127 gpbs[2547] Owning program failed to convert data.
2011-01-29 21:21:06.127 gpbs[2547] SelectionNotify.
2011-01-29 21:21:06.127 gpbs[2547] New PasteboardEntry 1 with items - 
(PasteboardData for type 'NSStringPboardType')
2011-01-29 21:21:06.127 gpbs[2547] PasteboardObject: 0xb5bbba90 declare types 
'(NSStringPboardType)' version 1
2011-01-29 21:21:06.130 gpbs[2547] GNU pasteboard server startup.
2011-01-29 21:21:14.894 gpbs[2547] PasteboardObject: 0xb5bb2788 get data for 
type 'NSStringPboardType' version 1
2011-01-29 21:21:14.901 gpbs[2547] PropertyNotify.
2011-01-29 21:21:14.902 gpbs[2547] Selection (PRIMARY) notify - 'None'.
2011-01-29 21:21:14.902 gpbs[2547] Owning program failed to convert data.
2011-01-29 21:21:14.902 gpbs[2547] SelectionNotify.
2011-01-29 21:21:14.902 gpbs[2547] PropertyNotify.
2011-01-29 21:21:14.905 gpbs[2547] Selection (PRIMARY) notify - 'None'.
2011-01-29 21:21:14.905 gpbs[2547] Owning program failed to convert data.
2011-01-29 21:21:14.905 gpbs[2547] SelectionNotify.
2011-01-29 21:21:14.905 gpbs[2547] PasteboardObject: 0xb5bb2788 set data for 
type 'NSStringPboardType' version 1
2011-01-29 21:21:14.905 gpbs[2547] set data for 0xb5bbba68
2011-01-29 21:21:14.905 gpbs[2547] get data for 0xb5bbba68

Thanks,
Philippe



___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev

Long pauses in applications maybe due to gpbs : Timed out waiting for X...

[Philippe Roussel]

Hi all,

Running svn trunk on 32 bits Ubuntu 10.04 (xorg 1.7.6 I think), I can
observe really often long pauses in Gorm, SimpleAgenda and others. I
just found out that gpbs is logging errors like this (with SimpleAgenda,
I didn't try others) :

2011-01-27 21:35:14.082 gpbs[27311] GNU pasteboard server startup.
2011-01-27 21:35:18.505 gpbs[27311] PasteboardObject: 0x9cda098 get data for 
type 'NSStringPboardType' version 1
2011-01-27 21:35:38.515 gpbs[27311] Timed out waiting for X selection 
'UTF8_STRING'
2011-01-27 21:35:38.516 gpbs[27311] PasteboardObject: 0x9cda098 set data for 
type 'NSStringPboardType' version 1
2011-01-27 21:35:38.516 gpbs[27311] set data for 0x9cd6478
2011-01-27 21:35:38.516 gpbs[27311] get data for 0x9cd6478

You can see the timeout defined in xpbs.m:590. The panel unblocks right
when 'Timed out..' appears.

Is this a problem on my side (one more I should say..) ?

Thanks,
Philippe



___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev

Problem with NSColorWell : Objective-C runtime error. Loading two versions of GSColorSliderCell

[Philippe Roussel]

Going back to libobjc2 revision 31870 fixes it for me.

Philippe

Le dimanche 23 janvier 2011 à 20:43 +0100, Philippe Roussel a écrit :
 Hi,
 
 With libobjc2 and gnustep from trunk I'm getting the following error
 when clicking on a NSColorWell :
 
 Objective-C runtime error.  Loading two versions of GSColorSliderCell
 
 Here's a backtrace :
 
 #0  0xb7fe2424 in __kernel_vsyscall ()
 #1  0xb75ae651 in *__GI_raise (sig=6) at 
 ../nptl/sysdeps/unix/sysv/linux/raise.c:64
 #2  0xb75b1a82 in *__GI_abort () at abort.c:92
 #3  0xb770abb1 in objc_load_class (class=0xb322a2c0) at class_table.c:376
 #4  0xb77108a2 in __objc_exec_class (module=0xb322a690) at loader.c:74
 #5  0xb3225670 in __objc_gnu_init () at GSColorSliderCell.m:194
 #6  0xb322635d in __do_global_ctors_aux () from 
 /opt/GNUstep-trunk/Local/Library/ColorPickers/WheelPicker.bundle/./WheelPicker
 #7  0xb32239d4 in _init () from 
 /opt/GNUstep-trunk/Local/Library/ColorPickers/WheelPicker.bundle/./WheelPicker
 #8  0xb7ff0bbc in call_init (l=value optimized out, argc=value optimized 
 out, argv=0xbfffef44, env=0xbfffef4c) at dl-init.c:70
 #9  0xb7ff0cd9 in _dl_init (main_map=0x84ecbb8, argc=value optimized out, 
 argv=value optimized out, env=0xbfffef4c) at dl-init.c:134
 #10 0xb7ff4d99 in dl_open_worker (a=0xbfffe6b0) at dl-open.c:463
 #11 0xb7ff07e6 in _dl_catch_error (objname=value optimized out, 
 errstring=value optimized out, mallocedp=value optimized out, 
 operate=0xb7ff4a10 dl_open_worker, args=0xbfffe6b0) at dl-error.c:178
 #12 0xb7ff45e6 in _dl_open (file=0x8322090 
 /opt/GNUstep-trunk/Local/Library/ColorPickers/WheelPicker.bundle/./WheelPicker,
  
 mode=value optimized out, caller_dlopen=0xb794f861, nsid=-2, argc=1, 
 argv=0xbfffef44, env=0xbfffef4c) at dl-open.c:554
 #13 0xb7124c0b in dlopen_doit (a=0xbfffe890) at dlopen.c:67
 #14 0xb7ff07e6 in _dl_catch_error (objname=value optimized out, 
 errstring=value optimized out, mallocedp=value optimized out, 
 operate=0xb7124b70 dlopen_doit, args=0xbfffe890) at dl-error.c:178
 #15 0xb712509c in _dlerror_run (operate=value optimized out, args=value 
 optimized out) at dlerror.c:164
 #16 0xb7124b41 in __dlopen (file=0x8322090 
 /opt/GNUstep-trunk/Local/Library/ColorPickers/WheelPicker.bundle/./WheelPicker,
  mode=257)
 at dlopen.c:88
 #17 0xb794f861 in __objc_dynamic_link (filename=0x82fca80, 
 errorStream=0xb76da580, loadCallback=0xb77fd260 _bundle_load_callback, 
 header=0x0, debugFilename=0x0) at dynamic-load.h:65
 #18 GSPrivateLoadModule (filename=0x82fca80, errorStream=0xb76da580, 
 loadCallback=0xb77fd260 _bundle_load_callback, header=0x0, 
 debugFilename=0x0) at objc-load.m:167
 #19 0xb77fce7c in -[NSBundle load] (self=0x82dc850, _cmd=0xb7aa32e8) at 
 NSBundle.m:1595
 #20 0xb77fa1f1 in -[NSBundle principalClass] (self=0x82dc850, 
 _cmd=0xb7f1b7a0) at NSBundle.m:1526
 #21 0xb7d0c0ee in -[NSColorPanel(PrivateMethods) _loadPickerAtPath:] 
 (self=0x86d4a60, _cmd=0xb7f1b780, path=0x82dc7f0) at NSColorPanel.m:135
 #22 0xb7d0bf91 in -[NSColorPanel(PrivateMethods) _loadPickers] 
 (self=0x86d4a60, _cmd=0xb7f1bac0) at NSColorPanel.m:113
 #23 0xb7d0b241 in -[NSColorPanel init] (self=0x86d4a60, _cmd=0xb7f1ba60) at 
 NSColorPanel.m:486
 #24 0xb7d0ba83 in +[NSColorPanel sharedColorPanel] (self=0xb7f1b600, 
 _cmd=0xb7f1d370) at NSColorPanel.m:408
 #25 0xb7d0edc2 in -[NSColorWell activate:] (self=0x8604f68, _cmd=0xb7f1d530, 
 exclusive=1 '\001') at NSColorWell.m:86
 #26 0xb7d0f770 in -[NSColorWell mouseUp:] (self=0x8604f68, _cmd=0xb7fa01f8, 
 theEvent=0x8503978) at NSColorWell.m:386
 #27 0xb7e4187d in -[NSWindow sendEvent:] (self=0xb37007e8, _cmd=0xb7eff530, 
 theEvent=0x8503978) at NSWindow.m:3709
 #28 0xb7cbe549 in -[NSApplication sendEvent:] (self=0x8356348, 
 _cmd=0xb7eff468, theEvent=0x8503978) at NSApplication.m:2126
 #29 0xb7cc0d7f in -[NSApplication run] (self=0x8356348, _cmd=0xb7ef5140) at 
 NSApplication.m:1583
 #30 0xb7ca07ba in NSApplicationMain (argc=1, argv=0xbfffef44) at 
 Functions.m:89
 #31 0x0807eb97 in main (argc=1, argv=0xbfffef44) at SimpleAgenda.m:30
 
 Any idea ?
 
 Thanks,
 Philippe



___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev

Re: Problem with NSColorWell

[Philippe Roussel]

Le lundi 24 janvier 2011 à 10:53 +, David Chisnall a écrit :
 On 23 Jan 2011, at 19:43, Philippe Roussel wrote:
 
  With libobjc2 and gnustep from trunk I'm getting the following error
  when clicking on a NSColorWell :
  
  Objective-C runtime error.  Loading two versions of GSColorSliderCell
 
 
 Interesting.  This error is generated when you load two versions of
 the same class, outside of developer mode.  It's possible that you're
 actually loading the same version of the code twice, but NSBundle
 should be preventing this.  As far as I can tell, there is only one
 definition of GSColorSliderCell, so this error is a bit strange (and
 may be a libobjc2 bug) - can you check in a debugger whether the
 GSColorSliderCell class is loaded before you click on an NSColorWell?

If I break into the running application before clicking on the
NSColorWell, gdb tells me there is no symbol GSColorSliderCell in
current context (with 'po [GSColorSliderCell class]', my gdb knowledge
is quite limited)

 You won't see this problem with old libobjc2 (including the 1.1
 release) because, like GCC libobjc, it just replaces the old version
 with the new version and lets you deal with the potential memory
 corruption later.



___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev

Problem with NSColorWell

[Philippe Roussel]

Hi,

With libobjc2 and gnustep from trunk I'm getting the following error
when clicking on a NSColorWell :

Objective-C runtime error.  Loading two versions of GSColorSliderCell

Here's a backtrace :

#0  0xb7fe2424 in __kernel_vsyscall ()
#1  0xb75ae651 in *__GI_raise (sig=6) at 
../nptl/sysdeps/unix/sysv/linux/raise.c:64
#2  0xb75b1a82 in *__GI_abort () at abort.c:92
#3  0xb770abb1 in objc_load_class (class=0xb322a2c0) at class_table.c:376
#4  0xb77108a2 in __objc_exec_class (module=0xb322a690) at loader.c:74
#5  0xb3225670 in __objc_gnu_init () at GSColorSliderCell.m:194
#6  0xb322635d in __do_global_ctors_aux () from 
/opt/GNUstep-trunk/Local/Library/ColorPickers/WheelPicker.bundle/./WheelPicker
#7  0xb32239d4 in _init () from 
/opt/GNUstep-trunk/Local/Library/ColorPickers/WheelPicker.bundle/./WheelPicker
#8  0xb7ff0bbc in call_init (l=value optimized out, argc=value optimized 
out, argv=0xbfffef44, env=0xbfffef4c) at dl-init.c:70
#9  0xb7ff0cd9 in _dl_init (main_map=0x84ecbb8, argc=value optimized out, 
argv=value optimized out, env=0xbfffef4c) at dl-init.c:134
#10 0xb7ff4d99 in dl_open_worker (a=0xbfffe6b0) at dl-open.c:463
#11 0xb7ff07e6 in _dl_catch_error (objname=value optimized out, 
errstring=value optimized out, mallocedp=value optimized out, 
operate=0xb7ff4a10 dl_open_worker, args=0xbfffe6b0) at dl-error.c:178
#12 0xb7ff45e6 in _dl_open (file=0x8322090 
/opt/GNUstep-trunk/Local/Library/ColorPickers/WheelPicker.bundle/./WheelPicker,
 
mode=value optimized out, caller_dlopen=0xb794f861, nsid=-2, argc=1, 
argv=0xbfffef44, env=0xbfffef4c) at dl-open.c:554
#13 0xb7124c0b in dlopen_doit (a=0xbfffe890) at dlopen.c:67
#14 0xb7ff07e6 in _dl_catch_error (objname=value optimized out, 
errstring=value optimized out, mallocedp=value optimized out, 
operate=0xb7124b70 dlopen_doit, args=0xbfffe890) at dl-error.c:178
#15 0xb712509c in _dlerror_run (operate=value optimized out, args=value 
optimized out) at dlerror.c:164
#16 0xb7124b41 in __dlopen (file=0x8322090 
/opt/GNUstep-trunk/Local/Library/ColorPickers/WheelPicker.bundle/./WheelPicker,
 mode=257)
at dlopen.c:88
#17 0xb794f861 in __objc_dynamic_link (filename=0x82fca80, 
errorStream=0xb76da580, loadCallback=0xb77fd260 _bundle_load_callback, 
header=0x0, debugFilename=0x0) at dynamic-load.h:65
#18 GSPrivateLoadModule (filename=0x82fca80, errorStream=0xb76da580, 
loadCallback=0xb77fd260 _bundle_load_callback, header=0x0, 
debugFilename=0x0) at objc-load.m:167
#19 0xb77fce7c in -[NSBundle load] (self=0x82dc850, _cmd=0xb7aa32e8) at 
NSBundle.m:1595
#20 0xb77fa1f1 in -[NSBundle principalClass] (self=0x82dc850, _cmd=0xb7f1b7a0) 
at NSBundle.m:1526
#21 0xb7d0c0ee in -[NSColorPanel(PrivateMethods) _loadPickerAtPath:] 
(self=0x86d4a60, _cmd=0xb7f1b780, path=0x82dc7f0) at NSColorPanel.m:135
#22 0xb7d0bf91 in -[NSColorPanel(PrivateMethods) _loadPickers] (self=0x86d4a60, 
_cmd=0xb7f1bac0) at NSColorPanel.m:113
#23 0xb7d0b241 in -[NSColorPanel init] (self=0x86d4a60, _cmd=0xb7f1ba60) at 
NSColorPanel.m:486
#24 0xb7d0ba83 in +[NSColorPanel sharedColorPanel] (self=0xb7f1b600, 
_cmd=0xb7f1d370) at NSColorPanel.m:408
#25 0xb7d0edc2 in -[NSColorWell activate:] (self=0x8604f68, _cmd=0xb7f1d530, 
exclusive=1 '\001') at NSColorWell.m:86
#26 0xb7d0f770 in -[NSColorWell mouseUp:] (self=0x8604f68, _cmd=0xb7fa01f8, 
theEvent=0x8503978) at NSColorWell.m:386
#27 0xb7e4187d in -[NSWindow sendEvent:] (self=0xb37007e8, _cmd=0xb7eff530, 
theEvent=0x8503978) at NSWindow.m:3709
#28 0xb7cbe549 in -[NSApplication sendEvent:] (self=0x8356348, _cmd=0xb7eff468, 
theEvent=0x8503978) at NSApplication.m:2126
#29 0xb7cc0d7f in -[NSApplication run] (self=0x8356348, _cmd=0xb7ef5140) at 
NSApplication.m:1583
#30 0xb7ca07ba in NSApplicationMain (argc=1, argv=0xbfffef44) at Functions.m:89
#31 0x0807eb97 in main (argc=1, argv=0xbfffef44) at SimpleAgenda.m:30

Any idea ?

Thanks,
Philippe



___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev

Do gui applications always have 2 threads ?

[Philippe Roussel]

Hi all,

In trying to understand why my application randomly blocks, I found that
it always has 2 threads running and I don't know what the second one is
for.

It seems this thread is waiting on some condition lock :

#0  0xb7fe2424 in __kernel_vsyscall ()
#1  0xb7428015 in pthread_cond_wait@@GLIBC_2.3.2 () at 
../nptl/sysdeps/unix/sysv/linux/i386/i686/../i486/pthread_cond_wait.S:122
#2  0xb76639dd in __pthread_cond_wait (cond=0x80de870, mutex=0x80de858) at 
forward.c:139
#3  0xb771d14f in ?? () from 
/opt/GNUstep-trunk/Local/Library/Libraries/libobjc.so.4
#4  0xb742396e in start_thread (arg=0xb5db6b70) at pthread_create.c:300
#5  0xb7656a4e in clone () at ../sysdeps/unix/sysv/linux/i386/clone.S:130

Once I saw my main thread blocked on the same condition/mutex (I think
it was load_lock in NSBundle) : deadlock.

I'm wondering if my code is responsible by doing too much work in
+initialize methods (ie creating singleton).

Can someone explain where does this thread come from ?

Thanks,
Philippe


___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev

Re: Do gui applications always have 2 threads ?

[Philippe Roussel]

Le samedi 22 janvier 2011 à 21:11 +, David Chisnall a écrit :
 On 22 Jan 2011, at 20:54, Philippe Roussel wrote:
 
  Hi all,
  
  In trying to understand why my application randomly blocks, I found that
  it always has 2 threads running and I don't know what the second one is
  for.
  
  It seems this thread is waiting on some condition lock :
  
  #0  0xb7fe2424 in __kernel_vsyscall ()
  #1  0xb7428015 in pthread_cond_wait@@GLIBC_2.3.2 () at 
  ../nptl/sysdeps/unix/sysv/linux/i386/i686/../i486/pthread_cond_wait.S:122
  #2  0xb76639dd in __pthread_cond_wait (cond=0x80de870, mutex=0x80de858) at 
  forward.c:139
  #3  0xb771d14f in ?? () from 
  /opt/GNUstep-trunk/Local/Library/Libraries/libobjc.so.4
 
 Here, libobjc2 created this thread.  It exists to do cleanup on some data 
 structures.  
 
  Once I saw my main thread blocked on the same condition/mutex (I think
  it was load_lock in NSBundle) : deadlock.
 
 It shouldn't ever be blocking on that lock.  It's only ever used to
 pass off work to the background thread's queue.  If you're making a
 huge number of changes to runtime data structures then you might end
 up with this queue becoming full and the second thread having to do
 some work before the first is allowed to proceed, but it's quite
 unlikely.
 
 It's not exposed outside of the runtime, so I'm a bit surprised if
 this is really the cause of your problem.  This thread is expected to
 spend almost all of its time asleep.  If you have libdispatch
 installed it won't exist at all.

Well, I must have misread the backtraces. The application blocks but
it's not a deadlock with this libobjc2 thread, sorry about that. I'll
have to dig deeper.

  I'm wondering if my code is responsible by doing too much work in
  +initialize methods (ie creating singleton).
 
 Nope, should be fine.

Ok, thanks for the explanations David

Philippe


___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev

NSURLConnection additional tests

[Philippe Roussel]

Hi Richard,

I would like to know if you would accept something like the attached
patch to the test suite. I did go the Python route but can switch to a
WebServer based helper if needed.

The code doesn't try to locate the python executable, it will just
return if python is not in the PATH. If that's a problem on OSX I can
and will change that as the purpose of all this is to compare the two
implementations.

Let me know if you find this useful and what are the results on OSX if
by chance the tests run.

Thanks,
Philippe
Index: base/NSURLConnection/Helpers/IGNORE
===
Index: base/NSURLConnection/Helpers/server.py
===
--- base/NSURLConnection/Helpers/server.py	(révision 0)
+++ base/NSURLConnection/Helpers/server.py	(révision 0)
@@ -0,0 +1,23 @@
+import BaseHTTPServer
+
+HOST_NAME = '127.0.0.1'
+PORT_NUMBER = 54321
+
+class MyHandler(BaseHTTPServer.BaseHTTPRequestHandler):
+def do_HEAD(s):
+s.send_response(200)
+s.send_header(Content-type, text/html)
+s.end_headers()
+
+def do_GET(s):
+s.send_response(200)
+s.send_header(Content-type, text/html)
+s.end_headers()
+s.wfile.write(htmlheadtitleTitle goes here./title/head)
+s.wfile.write(bodypThis is a test./p/body/html)
+
+if __name__ == '__main__':
+server_class = BaseHTTPServer.HTTPServer
+httpd = server_class((HOST_NAME, PORT_NUMBER), MyHandler)
+httpd.serve_forever()
+httpd.server_close()
Index: base/NSURLConnection/test00.m
===
--- base/NSURLConnection/test00.m	(révision 0)
+++ base/NSURLConnection/test00.m	(révision 0)
@@ -0,0 +1,169 @@
+#import Foundation/Foundation.h
+#import Testing.h
+#import ObjectTesting.h
+
+@interface TestClass : NSObject
+{
+  BOOL done;
+  NSMutableData *data;
+  NSURLResponse *response;
+  int status;
+}
+- (int) runTests;
+@end
+
+@implementation TestClass
+- (void)dealloc
+{
+  [response release];
+  [data release];
+  [super dealloc];
+}
+
+- (id) init
+{
+  data = [[NSMutableData alloc] initWithCapacity:512];
+  return self;
+}
+
+- (void) runTest
+{
+  NSRunLoop *loop = [NSRunLoop currentRunLoop];
+  int count;
+
+  DESTROY(response);
+  done = NO;
+  count = 0;
+  status = 0;
+  while (!done  count  10) {
+[loop runMode:NSDefaultRunLoopMode beforeDate:[NSDate dateWithTimeIntervalSinceNow:0.2]];
+count++;
+  }
+}
+
+- (int) runTests
+{
+  NSURL *url;
+  NSMutableURLRequest *request;
+  NSURLConnection *connection;
+
+  url = [NSURL URLWithString: @http://localhost:54321/;];
+  if (!url) {
+NSLog(@Couldn't build an NSURL from http://localhost:54321/;);
+return 1;
+  }
+  request = [NSMutableURLRequest requestWithURL:url];
+  if (!request) {
+NSLog(@Couldn't build an NSMutableURLRequest from NSURL http://localhost:54321/;);
+return 1;
+  }
+
+  connection = [NSURLConnection connectionWithRequest:request delegate:self];
+  pass(connection != nil,
+   NSURLConnection connectionWithRequest:delegate: with a valid GET HTTP 
+   request and a delegate returns an instance);
+  [self runTest];
+  pass(status == 200, HTTP GET gets a 200 response);
+  pass([data length]  0, HTTP GET returns data);
+  passeq([response class], [NSHTTPURLResponse class], HTTP GET returns a NSHTTPURLResponse);
+
+  [request setHTTPMethod:@DELETE];
+  connection = [NSURLConnection connectionWithRequest:request delegate:self];
+  pass(connection != nil,
+   NSURLConnection connectionWithRequest:delegate: with a valid DELETE HTTP 
+   request and a delegate returns an instance);
+  [self runTest];
+  pass(response != nil, HTTP DELETE gets a NSURLResponse);
+  pass(status == 501, HTTP DELETE gets a 501 response as the server does not handle this method);
+
+  [request setHTTPMethod:@WRONGMETHOD];
+  connection = [NSURLConnection connectionWithRequest:request delegate:self];
+  pass(connection != nil,
+   NSURLConnection connectionWithRequest:delegate: 
+   with a invalid WRONGMETHOD HTTP request and a delegate returns an instance);
+  [self runTest];
+  pass(response == nil, HTTP WRONGMETHOD doesn't get a NSURLResponse);
+  pass(status == 0, 
+   HTTP WRONGMETHOD fails without an HTTP error code as the NSURLConnection doesn't allow it);
+
+  return 0;
+}
+
+- (void)connection:(NSURLConnection *)connection didFailWithError:(NSError *)error
+{
+  NSLog(@%s : %@ %d, __PRETTY_FUNCTION__, [error domain], [error code]);
+}
+
+- (void)connection:(NSURLConnection *)connection didReceiveAuthenticationChallenge:(NSURLAuthenticationChallenge *)challenge
+{
+  [[challenge sender] cancelAuthenticationChallenge:challenge];
+}
+
+- (void)connection:(NSURLConnection *)connection didReceiveData:(NSData *)newData
+{
+  NSLog(@%s : %d octets, __PRETTY_FUNCTION__, [newData length]);
+  [data appendData:newData];
+}
+
+- (void)connection:(NSURLConnection 

Re: NSURLProtocol and WebDAV

[Philippe Roussel]

Le mardi 18 janvier 2011 à 20:53 +, Richard Frith-Macdonald a
écrit :
 On 17 Jan 2011, at 20:15, Philippe Roussel wrote:
  Just one question : would you mind having a helper in the testsuite
  written in Python ? I know it could be problematic to be dependant on
  Python but it would be a lot easier to test http connections, as writing
  a http server takes maybe 20 lines.
 
 I don't think using Python is a huge problem, though a plain C or ObjC
 helper would be better because we want the testsuite to be as
 self-contained as possible.  At the moment it needs only gnumake,
 gnustep-make and the toolchain to build ObjC programs (basically gcc).
 Ideally any tests using a python helper would first check that a
 suitable version of python is available on the system.
  
  The helpers I found in NSURL and NSURLHandle directories only compile
  with GNUstep (not sure why) so the related tests are not really useful.
 
 IIRC they use GNUstep specific extensions :-(
 
  The WebServer library in dev-libs could also be used but I don't know
  how I could force its installation.
 
 That may use GNUstep specific code too (I don't recall).   Your test
 code could check to see if it's installed, and skip tests which need
 the helper if it isn't ... much like checking to see if a suitable
 Python is installed.

It seems WebServer uses gnustep additions and Performance library.

I think I'll try the easy route and check for Python availability for
now. If the tests are useful, the helper could be converted to C or ObjC
later.

Thanks,
Philippe



___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev

Re: NSURLProtocol and WebDAV

[Philippe Roussel]

Le lundi 17 janvier 2011 à 15:33 +, Richard Frith-Macdonald a
écrit :
 On 16 Jan 2011, at 20:06, Philippe Roussel wrote:
  Here's a first round of tests for NSURLRequest, NSURLProtocol and
  NSURLConnection. I'll try to create good client/server tests for
  NSURLConnection next but it will take some time.
 
 Thanks very much ... I added those to the testsuite with some small
 modifications: a couple of fixes for retain/release errors, and a
 change to the test for the canonical version of a request.

Thanks, I'll take a look.

Philippe



___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev

Re: NSURLProtocol and WebDAV

[Philippe Roussel]

Hi Richard

Le lundi 17 janvier 2011 à 17:17 +0100, Philippe Roussel a écrit :
 Le lundi 17 janvier 2011 à 15:33 +, Richard Frith-Macdonald a
 écrit :
  On 16 Jan 2011, at 20:06, Philippe Roussel wrote:
   Here's a first round of tests for NSURLRequest, NSURLProtocol and
   NSURLConnection. I'll try to create good client/server tests for
   NSURLConnection next but it will take some time.
  
  Thanks very much ... I added those to the testsuite with some small
  modifications: a couple of fixes for retain/release errors, and a
  change to the test for the canonical version of a request.
 
 Thanks, I'll take a look.

Just one question : would you mind having a helper in the testsuite
written in Python ? I know it could be problematic to be dependant on
Python but it would be a lot easier to test http connections, as writing
a http server takes maybe 20 lines.

The helpers I found in NSURL and NSURLHandle directories only compile
with GNUstep (not sure why) so the related tests are not really useful.

The WebServer library in dev-libs could also be used but I don't know
how I could force its installation.

Philippe


___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev

Re: NSURLProtocol and WebDAV

[Philippe Roussel]

Hi Richard

Le samedi 15 janvier 2011 à 06:45 +, Richard Frith-Macdonald a
écrit :

 I have an OSX system I could run tests for you on, and I'd be very
 pleased to do that if you could add tests to the testsuite at
 http://svn.gna.org/viewcvs/gnustep/tests/testsuite/trunk/
 My problem with writing tests for a class is that I need to be
 familiar with how the class is used (in order to write tests), and
 getting that familiarity means I need to be working on code which uses
 the class, or spend a lot of time reading the documentation ...
 running testcases for someone else who *is*  working with the classes,
 is very quick/easy by comparison.

Here's a first round of tests for NSURLRequest, NSURLProtocol and
NSURLConnection. I'll try to create good client/server tests for
NSURLConnection next but it will take some time.

Philippe

Index: base/NSURLConnection/basic.m
===
--- base/NSURLConnection/basic.m	(révision 0)
+++ base/NSURLConnection/basic.m	(révision 0)
@@ -0,0 +1,48 @@
+#import Foundation/Foundation.h
+#import Testing.h
+#import ObjectTesting.h
+
+int main()
+{
+  NSAutoreleasePool   *arp = [NSAutoreleasePool new];
+  NSMutableURLRequest *mutable;
+  NSURLConnection *connection;
+  NSURLResponse *response;
+  NSError *error;
+  NSData *data;
+  NSURL *httpURL;
+  NSString *path;
+
+  httpURL = [NSURL URLWithString: @http://www.gnustep.org;];
+
+  TEST_FOR_CLASS(@NSURLConnection, [NSURLConnection alloc],
+NSURLConnection +alloc returns an NSURLConnection);
+
+  mutable = [NSMutableURLRequest requestWithURL:httpURL];
+  pass([NSURLConnection canHandleRequest:mutable],
+   NSURLConnection can handle an valid HTTP request (GET));
+  [mutable setHTTPMethod:@WRONGMETHOD];
+  pass([NSURLConnection canHandleRequest:mutable],
+   NSURLConnection can handle an invalid HTTP request (WRONGMETHOD));
+
+  [mutable setHTTPMethod:@GET];
+  connection = [NSURLConnection connectionWithRequest:mutable delegate:nil];
+  pass(connection != nil,
+   NSURLConnection +connectionWithRequest:delegate: with nil as delegate returns a instance);
+
+  data = [NSURLConnection sendSynchronousRequest:mutable returningResponse:response error:error];
+  pass(data != nil  [data length]  0,
+   NSURLConnection synchronously load data from an http URL);
+  [data release];
+
+  path = [[NSFileManager defaultManager] currentDirectoryPath];
+  path = [path stringByAppendingPathComponent:@basic.m];
+  [mutable setURL:[NSURL fileURLWithPath:path]];
+  data = [NSURLConnection sendSynchronousRequest:mutable returningResponse:response error:error];
+  pass(data != nil  [data length]  0,
+   NSURLConnection synchronously load data from a local file);
+  [data release];
+
+  [arp release]; arp = nil;
+  return 0;
+}
Index: base/NSURLProtocol/basic.m
===
--- base/NSURLProtocol/basic.m	(révision 0)
+++ base/NSURLProtocol/basic.m	(révision 0)
@@ -0,0 +1,36 @@
+#import Foundation/Foundation.h
+#import Testing.h
+#import ObjectTesting.h
+
+int main()
+{
+  NSAutoreleasePool   *arp = [NSAutoreleasePool new];
+  NSMutableURLRequest *mutable, *copy;
+  NSURLProtocol *protocol;
+  NSURL *httpURL;
+
+
+  httpURL = [NSURL URLWithString: @http://www.gnustep.org;];
+
+  TEST_FOR_CLASS(@NSURLProtocol, [NSURLProtocol alloc],
+NSURLProtocol +alloc returns an NSURLProtocol);
+
+  mutable = [[NSMutableURLRequest requestWithURL:httpURL] retain];
+  TEST_EXCEPTION([NSURLProtocol canInitWithRequest:mutable], nil, YES,
+		 NSURLProtocol +canInitWithRequest throws an exeception (subclasses should be used));
+
+  pass(mutable == [NSURLProtocol canonicalRequestForRequest:mutable],
+   NSURLProtocol +canonicalRequestForRequest: return it argument);
+
+  copy = [mutable copy];
+  pass([NSURLProtocol requestIsCacheEquivalent:mutable toRequest:copy],
+   NSURLProtocol +requestIsCacheEquivalent:toRequest returns YES with a request and its copy);
+  [copy setHTTPMethod:@POST];
+  pass([NSURLProtocol requestIsCacheEquivalent:mutable toRequest:copy] == NO,
+   NSURLProtocol +requestIsCacheEquivalent:toRequest returns NO after a method change);
+  [copy release];
+  [mutable release];
+
+  [arp release]; arp = nil;
+  return 0;
+}
Index: base/NSURLRequest/basic.m
===
--- base/NSURLRequest/basic.m	(révision 0)
+++ base/NSURLRequest/basic.m	(révision 0)
@@ -0,0 +1,52 @@
+#import Foundation/Foundation.h
+#import Testing.h
+#import ObjectTesting.h
+
+int main()
+{
+  NSAutoreleasePool   *arp = [NSAutoreleasePool new];
+  NSURLRequest *request;
+  NSMutableURLRequest *mutable;
+  NSURL *httpURL, *foobarURL;
+
+
+  httpURL = [NSURL URLWithString: @http://www.gnustep.org;];
+  foobarURL = [NSURL URLWithString: @foobar://localhost/madeupscheme];
+
+  TEST_FOR_CLASS(@NSURLRequest, [NSURLRequest alloc],
+NSURLRequest +alloc returns an NSURLRequest);
+
+ 

Re: NSURLProtocol and WebDAV

[Philippe Roussel]

Le samedi 15 janvier 2011 à 06:45 +, Richard Frith-Macdonald a
écrit :

[...]

  I have no idea how Apple implemented NSHTTPURLProtocol and no way to
  test it.
 
 I have an OSX system I could run tests for you on, and I'd be very
 pleased to do that if you could add tests to the testsuite at
 http://svn.gna.org/viewcvs/gnustep/tests/testsuite/trunk/
 My problem with writing tests for a class is that I need to be
 familiar with how the class is used (in order to write tests), and
 getting that familiarity means I need to be working on code which uses
 the class, or spend a lot of time reading the documentation ...
 running testcases for someone else who *is*  working with the classes,
 is very quick/easy by comparison.

Ok, I'll take a look at the test suite.

  The thing is, I'm not sure to understand why NSHTTPURLProtocol
  doesn't let me use the methods I want. What if I want to shoot myself in
  the the foot ?
 
 I don't know that either ... perhaps it shouldn't be preventing you
 from doing it?  From looking at the Apple documentation it seems to me
 that another place to check for these methods might be in the
 +canInitWithRequest: method, and I don't know which Apple actually
 does.

Good point.

  Maybe NSHTTPURLProtocol could be Apple compliant while providing a way
  to change the accepted methods, as a GNUstep addition or through a
  subclass ?
 
 That's fine ... we add such code to the gnustep-additions library
 (built into the base library on gnustep, but standalone on OSX) but
 we'd want to make sure that the addition/subclass worked with the
 Apple foundation as well as with gnustep-base, so we'd need to
 understand how you would go about changing the accepted methods on OSX
 before we start.

Ok, thanks Richard. I'll go look at the code of the testsuite and see if
I can add something useful for NSURLConnection and NSURLProtocol.

Philippe


___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev

NSURLProtocol and WebDAV

[Philippe Roussel]

Hi,

I'm trying to use NSURLConnection instead of NSURLHandle to access a
WebDAV server (mainly because NSURLConnection seems to be the future).

WebDAV only adds new methods to http so implementing a WebDAVURLProtocol
from scratch would mean a lot of code duplication. On the other hand,
subclassing _NSHTTPURLProtocol seems to be difficult as it is mostly
hidden.
As the only thing that needs to be modified is the list of accepted
methods, I propose the following patch to allow the use of WebDAV
specific methods.

Would that be acceptable ?

Thanks,
Philippe

Index: Source/NSURLProtocol.m
===
--- Source/NSURLProtocol.m  (révision 31888)
+++ Source/NSURLProtocol.m  (copie de travail)
@@ -610,6 +610,13 @@
self, @TRACE,
self, @OPTIONS,
self, @CONNECT,
+   self, @PROPFIND,
+   self, @PROPPATCH,
+   self, @MKCOL,
+   self, @COPY,
+   self, @MOVE,
+   self, @LOCK,
+   self, @UNLOCK,
nil];
   }
   if ([methods objectForKey: [this-request HTTPMethod]] == nil)



___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev

Re: NSURLProtocol and WebDAV

[Philippe Roussel]

Le vendredi 14 janvier 2011 à 21:03 +, Richard Frith-Macdonald a
écrit :
 On 14 Jan 2011, at 19:44, Philippe Roussel wrote:
 
  Hi,
  
  I'm trying to use NSURLConnection instead of NSURLHandle to access a
  WebDAV server (mainly because NSURLConnection seems to be the future).
 
 Well, it's the direction Apple has gone ... that doesn't mean it's better in 
 GNUstep.

True, I hadn't thought about that. This could also be seen as a way to
test NSURLConnection and friends. It seems _NSFileURLProtocol isn't
really full featured.

  WebDAV only adds new methods to http so implementing a WebDAVURLProtocol
  from scratch would mean a lot of code duplication. On the other hand,
  subclassing _NSHTTPURLProtocol seems to be difficult as it is mostly
  hidden.
  As the only thing that needs to be modified is the list of accepted
  methods, I propose the following patch to allow the use of WebDAV
  specific methods.
  
  Would that be acceptable ?
 
 
 If you want to use NSURLConnection for Apple compatibility, then your
 code needs to work with the Apple Foundation, so you can't change the
 behavior of _NSHTTPURLProtocol (though of course if the GNUstep
 implementation differs from the Apple one we can change it to match).
 As a general rule we don't want to introduce incompatibilities between
 Apple and GNUstep, so  I think the answer is 'no', it's not acceptable
 to add methods in _NSHTTPURLProtocol unless Apple's implementation
 already supports them (you could write some testcases to find out).

I have no idea how Apple implemented NSHTTPURLProtocol and no way to
test it. The thing is, I'm not sure to understand why NSHTTPURLProtocol
doesn't let me use the methods I want. What if I want to shoot myself in
the the foot ?

Maybe NSHTTPURLProtocol could be Apple compliant while providing a way
to change the accepted methods, as a GNUstep addition or through a
subclass ?

Anyway, I can go back to NSURLHandle easily.

Thanks,
Philippe


___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev

File GSFFIInvocation.m: 610. In GSFFIInvocationCallback Changed type signature...

[Philippe Roussel]

Hi all,

With svn head, I get the following message when running any application
(SystemPreferences, Gorm etc) with --GNU-Debug=dflt :

File GSFFIInvocation.m: 610. In GSFFIInvocationCallback Changed type
signature 'v...@0:4...@8@1...@16c20@24' to 'v...@0:4...@8@1...@16c20@22' for
'postNotificationName:object:userInfo:deliverImmediately:for:'

I don't know how bad this is (applications seem to run fine except for
some latencies when showing a panel with text fields but I don't know if
it's related) but I thought it should be investigated.

Thanks,
Philippe



___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev

Re: [Gnustep-cvs] r31742 - in /libs/base/trunk: ./ Headers/Additions/GNUstepBase/ Source/

[Philippe Roussel]

Le dimanche 19 décembre 2010 à 18:03 +, Richard Frith-Macdonald a
écrit :

 Thanks ... I guess the thing to do is create testcases and add them to 
 testsuite in svn to see how these things behave.
 That way we can easily check that the GNUstep and OSX behaviors are the same 
 simply by running the testsuite on OSX with the Apple Foundation, and on a 
 GNUstep system.
 I guess it might be the case that the GNUstep libxml2 implementation of 
 NSXMLParser is actually 'wrong'... if it differs from what Apple's 
 NSXMLParser does.

Just for you information, the latest version of NSXMLParser and DBusKit
works for me and my simple use case.

Thanks,
Philippe



___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev

Re: gnustep-testfarm stopped working

[Philippe Roussel]

Le dimanche 28 novembre 2010 à 21:48 -0700, Adam Fedor a écrit :
 I
 On Nov 21, 2010, at 3:02 AM, Philippe Roussel wrote:
  
  So it creates /home/philou/gnustep-woody/share/GNUstep/Makefiles and
  then looks
  for /home/philou/gnustep-woody/System/Library/Makefiles/GNUstep.sh.
  
  
 
 
 I'm not sure why this is happening.  Perhaps you should just
 completely remove /home/philou/gnustep-woody and try again. 

Same problem after removing /home/philou/gnustep-woody.

 Are you using a completely fresh checkout
 (http://wiki.gnustep.org/index.php/Developer_FAQ#How_can_I_take_part_with_a_GNUstep_autobuilder_for_the_testfarm.3F)
  like this?
 
 
 svn co http://svn.gna.org/svn/gnustep/autotest gnustep-testfarm

Yes.

phi...@woody:~/sources/gnustep-testfarm$ svn info .
Chemin : .
URL : http://svn.gna.org/svn/gnustep/autotest
Racine du dépôt : http://svn.gna.org/svn/gnustep
UUID du dépôt : 72102866-910b-0410-8b05-ffd578937521
Révision : 31691
Type de nœud : répertoire
Tâche programmée : normale
Auteur de la dernière modification : fedor
Révision de la dernière modification : 28168
Date de la dernière modification: 2009-04-02 16:34:22 +0200 (jeu. 02 avril 2009)

phi...@woody:~/sources/gnustep-testfarm$ 




___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev

gnustep-testfarm stopped working

[Philippe Roussel]

Hi all,

I have a gnustep-testfarm checkout that I used to run from time to time
(last run visible on http://www.gnustep.org/developers/testfarm.html :
woody i686-pc-linux-gnu OK jeudi 9 septembre 2010, 09:29:50 (UTC+0200)
Pass: 5379 Fail: 0 Complete: 263 Details).

I wanted to run it this morning and it failed. I tried with a fresh
checkout but it fails with the same error about not finding
Makefiles/GNUstep.sh :

config.status: executing default commands
Thanks.  All is ready: type 'make install' to install gnustep-make.
Creating system tools directory: /home/philou/gnustep-woody/bin
Creating makefile directories in: 
/home/philou/gnustep-woody/share/GNUstep/Makefiles
Installing GNUstep configuration file in /home/philou/gnustep-woody/GNUstep.conf
Installing gnustep-make support software
Installing makefiles
Installing (and compressing) manpages
.: 577: Can't open 
/home/philou/gnustep-woody/System/Library/Makefiles/GNUstep.sh
--- Archive Results ---
mv: impossible d'évaluer 
«/home/philou/sources/gnustep-testfarm/startup/scripts/../../core/logs.tar.gz»: 
Aucun fichier ou dossier de ce type
--- Upload Results ---
woody-i686-pc-linux-gnu-results.txt: Overwrite permission denied
local: woody-i686-pc-linux-gnu-logs.tar.gz: No such file or directory
local: woody-i686-pc-linux-gnu-testsuite.log: No such file or directory


So it creates /home/philou/gnustep-woody/share/GNUstep/Makefiles and
then looks
for /home/philou/gnustep-woody/System/Library/Makefiles/GNUstep.sh.

Philippe


___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev

Re: Problem with NSDateFormatter

[Philippe Roussel]

Le mercredi 25 août 2010 à 08:55 +0200, Wolfgang Lux a écrit :
 Philippe Roussel wrote:
 
  Last detail : if I remove [AppointmentEditor controlTextDidChange:] or
  just don't call [NSTextField objectValue] everything works correctly.
  I could rework my code to avoid controlTextDidChange: but even if my
  code is ugly it should work as is I think.
 
 I don't think so. AFAICT, your code wouldn't work on OS X either.

Ok, so it used to work by luck I guess.

  A NSTextField method returning the current string without validating
  it could be useful.
 
 You should ask the field editor directly for the current input. You can
 look up the field editor under the NSFieldEditor key in the userInfo
 dictionary of the notification passed to -controlTextDidChange:. And you
 probably then want to ask the formatter whether the input text is valid.

Thanks for the tip.

Philippe



___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev

Re: Problem with NSDateFormatter

[Philippe Roussel]

On Tue, Aug 24, 2010 at 01:06:56AM +0200, Fred Kiefer wrote:
 Am 24.08.2010 00:16, schrieb Fred Kiefer:
  Am 23.08.2010 15:20, schrieb Philippe Roussel:
  In SimpleAgenda I use an instance of NSDateFormatter created with
 
  dateFormatter = AUTORELEASE([[NSDateFormatter alloc]
  initWithDateFormat:[[NSUserDefaults standardUserDefaults]
  objectForKey:NSShortDateFormatString] allowNaturalLanguage:NO]);
 
  in the appointment editor for a textbox where you can enter the last
  date of a recurring event. I *think* it used to work but with latest svn
  I'm unable to change the date and the textbox has a really strange
  behaviour.
 
  I'm using a French locale but the problem exists in English too.
 
  Is my code wrong or is this a bug in NSDateFormatter ?
  Did someone recently tested that code ?
  
  I was able to reproduce a problem here (probably with an older version
  of SimpleAgenda). Could you please write a detailed bug report. I am
  going to look into this in the next days and it would be great to have a
  place where we gather all relevant information.
 
 My first impression when looking at a back trace from the code is that
 [NSCell setObjectValue:] gets called too often. I would expect that we
 only get that call, when the editor actually finished editing the text.
 But I get it each time I delete a character from the string.
 I still don't understand whether this is actually wrong and if so, where
 it goes wrong. Perhaps it is just too late over here. :-(

You probably understood that already but here's what I found :

setObjectValue is called because the NSTextField has a formatter so
when I asked for its objectValue it does the validation and, if the
validation succeeds, sets the objectValue.

As I call objectValue in controlTextDidChange, setObjectValue is
called almost for each text modification.

I just did an test: the field contains 24/09/2010, I press the end key
to move the cursor after the last character and press backspace. In
[AppointmentEditor controlTextDidChange:] I ask for the field
stringValue: and the result is '24/09/0201' instead of '24/09/201'.
This is because NSDateFormatter getObjectValue:forString: accepts
24/09/201 as a date which is formatted as 24/09/0201 and set as the
field string.


Last detail : if I remove [AppointmentEditor controlTextDidChange:] or
just don't call [NSTextField objectValue] everything works correctly.
I could rework my code to avoid controlTextDidChange: but even if my
code is ugly it should work as is I think.

A NSTextField method returning the current string without validating
it could be useful.

Would you like a bug report on savannah with these informations ?

Philippe

 Breakpoint 1, -[NSCell setObjectValue:] (self=0xe007a0,
 _cmd=0x778108a0,
 object=0xcde270) at NSCell.m:331
 331 {
 (gdb) po object
 29.09.2010
 (gdb) bt
 #0  -[NSCell setObjectValue:] (self=0xe007a0, _cmd=0x778108a0,
 object=0xcde270)
 at NSCell.m:331
 #1  0x77384577 in -[NSActionCell setObjectValue:] (self=0xe007a0,
 _cmd=value optimized out, anObject=0xcde270) at NSActionCell.m:228
 #2  0x774d70cf in -[NSTextField validateEditing] (self=value
 optimized out,
 _cmd=value optimized out) at NSTextField.m:485
 #3  0x7738415f in -[NSActionCell objectValue] (self=0xe007a0,
 _cmd=value optimized out) at NSActionCell.m:153
 #4  0x0040d0aa in -[AppointmentEditor controlTextDidChange:]
 (self=0xd70210,
 _cmd=value optimized out, aNotification=value optimized out)
 at AppointmentEditor.m:169
 #5  0x76d5fb03 in -[NSNotificationCenter _postAndRelease:]
 (self=0x6dc210,
 _cmd=value optimized out, notification=0x800020) at
 NSNotificationCenter.m:1161
 #6  0x773f64bc in -[NSControl textDidChange:] (self=0xc95d30,
 _cmd=value optimized out, aNotification=0x875a10) at NSControl.m:577
 #7  0x774d796c in -[NSTextField textDidChange:] (self=0xc95d30,
 _cmd=value optimized out, aNotification=0x875a10) at NSTextField.m:522
 #8  0x76d5fb03 in -[NSNotificationCenter _postAndRelease:]
 (self=0x6dc210,
 _cmd=value optimized out, notification=0x875a10) at
 NSNotificationCenter.m:1161
 #9  0x7754f0db in -[NSTextView didChangeText] (self=0x802e30,
 _cmd=value optimized out) at NSTextView.m:2659
 #10 0x77436c5a in -[NSInputManager handleKeyboardEvents:client:]
 (self=0x92c530,
 _cmd=value optimized out, eventArray=value optimized out,
 client=0x802e30)
 at NSInputManager.m:652
 #11 0x77555a13 in -[NSTextView(leftovers) keyDown:] (self=0x802e30,
 _cmd=value optimized out, theEvent=0xaf72f0) at NSTextView.m:5392
 ---Type return to continue, or q return to quit---
 #12 0x773a0578 in -[NSApplication run] (self=0x930e00,
 _cmd=value optimized out)
 at NSApplication.m:1532
 #13 0x77380857 in NSApplicationMain (argc=value optimized out,
 argv=value optimized out) at Functions.m:89
 

-- 
My mom had Windows at work and it hurt

Problem with NSDateFormatter

[Philippe Roussel]

Hi,

In SimpleAgenda I use an instance of NSDateFormatter created with

dateFormatter = AUTORELEASE([[NSDateFormatter alloc]
initWithDateFormat:[[NSUserDefaults standardUserDefaults]
objectForKey:NSShortDateFormatString] allowNaturalLanguage:NO]);

in the appointment editor for a textbox where you can enter the last
date of a recurring event. I *think* it used to work but with latest svn
I'm unable to change the date and the textbox has a really strange
behaviour.

I'm using a French locale but the problem exists in English too.

Is my code wrong or is this a bug in NSDateFormatter ?
Did someone recently tested that code ?

Thanks,
Philippe



___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev

Re: Problem with services (DO ?) with svn trunk

[Philippe Roussel]

Hi Richard

On Tue, Aug 17, 2010 at 04:48:06PM +0100, Richard Frith-Macdonald wrote:
 
 On 17 Aug 2010, at 16:19, David Chisnall wrote:
 
  On 17 Aug 2010, at 16:18, Philippe Roussel wrote:
  
  Things work a lot better with the appended patch.
  
  
  The patch looks good to me, but it's worth getting a sanity-check from 
  Richard.
 
 Looks OK to me too ...
 I added a testcase to the testsuite and ran it on OSX to see whether Apple's 
 implementation of NSSelectorFromString() registers a new selector if given a 
 name for a selector which doesn't exist.
 It does create a new selector, so the patch would change behavior improving 
 OSX compatibility.  

I tested the latest svn trunk and I can confirm what you commited to
base makes the problem disappear for me.

Thanks,
Philippe
-- 
Its always easier short term to pee in the pond than install a toilet - it's 
just not a good long term plan. Alan Cox


___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev

Re: NSTabView problem

[Philippe Roussel]

Le vendredi 13 août 2010 à 10:57 +0200, Fred Kiefer a écrit :
 Am 13.08.2010 10:48, schrieb Matt Rice:
  looking at this,
  http://coyote.octets.fr/simpleagenda/browser/trunk/CalendarView.m
  and the _1left, _1right etc, i'm guessing those are the images we're
  seeing in the screenshot
  and they are loaded not by name but by file, so i'm guessing that
  libffi being the problem is still in play.

Except that those images are correctly shown in the calendar on the
right in the screenshot so I don't get your reasoning.

 This is strange code, why would somebody not use imageNamed: to get an
 image by its name?

Because somebody wouldn't know the API ?!

Philippe



___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev

Re: NSTabView problem

[Philippe Roussel]

Le vendredi 13 août 2010 à 11:11 +0200, Philippe Roussel a écrit :
 Le vendredi 13 août 2010 à 10:57 +0200, Fred Kiefer a écrit :
  Am 13.08.2010 10:48, schrieb Matt Rice:
   looking at this,
   http://coyote.octets.fr/simpleagenda/browser/trunk/CalendarView.m
   and the _1left, _1right etc, i'm guessing those are the images we're
   seeing in the screenshot
   and they are loaded not by name but by file, so i'm guessing that
   libffi being the problem is still in play.
 
 Except that those images are correctly shown in the calendar on the
 right in the screenshot so I don't get your reasoning.

Forget that, now I understand and I go hide...

Philippe



___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev

Re: NSTabView problem

[Philippe Roussel]

Le vendredi 13 août 2010 à 11:45 +0200, ici...@mail.cg.tuwien.ac.at a
écrit :
 Hi!
 
 Related thread on mailing list is here:
 http://lists.gnu.org/archive/html/gnustep-dev/2010-03/msg00041.html
 
 Looks like it began to fail in SVN during March. I do not use specific 
 GNUstep releases, so I am not any help regarding releases which work 
 and which don't. I think I removed the libffi-dev package I had on my 
 system , in order to avoid conflicts with the new one I compiled and 
 installed myself.

Ok, thanks for all the informations. I guess I'll have to somehow try
with a new libffi.

Philippe



___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev

Re: NSTabView problem [Confirmed libffi problem]

[Philippe Roussel]

Le vendredi 13 août 2010 à 11:57 +0200, Philippe Roussel a écrit :
 Le vendredi 13 août 2010 à 11:45 +0200, ici...@mail.cg.tuwien.ac.at a
 écrit :
  Hi!
  
  Related thread on mailing list is here:
  http://lists.gnu.org/archive/html/gnustep-dev/2010-03/msg00041.html
  
  Looks like it began to fail in SVN during March. I do not use specific 
  GNUstep releases, so I am not any help regarding releases which work 
  and which don't. I think I removed the libffi-dev package I had on my 
  system , in order to avoid conflicts with the new one I compiled and 
  installed myself.
 
 Ok, thanks for all the informations. I guess I'll have to somehow try
 with a new libffi.

Done. And it works... Sorry for the noise everybody.

Just for the record I had to use the following to configure base :

./configure --disable-xmltest 
--with-ffi-include=/usr/local/lib/libffi-3.0.9/include 
--with-ffi-library=/usr/local/lib

It would be good if a test could be added to configure so that it would
fail with a incompatible libffi.

Philippe



___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev

Re: NSTabView problem

[Philippe Roussel]

On Wed, Aug 11, 2010 at 11:40:59PM +0200, Philippe Roussel wrote:
  NSTabView should itself be flipped but at the moment this isn't done in
  code as there was a drawing problem for flipped views.
  Or it could be an issue with a theme. Could you please switch to the
  default theme if you are using any other?
 
 I think I tested with all the themes I had installed with similar
 results but I will check tomorrow, I just erased everything...

I can confirm that the bug is there with the default theme and latest
svn.

I can test patches easily.

Philippe
-- 
Linux, le système qui exploite l'ordinateur pas l'utilisateur


___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev

Re: NSTabView problem

[Philippe Roussel]

Hi Fred,

Le mercredi 11 août 2010 à 19:19 +0200, Fred Kiefer a écrit :
 The libffi problem will result in no images being displayed. As this
 isn't the case for you, this looks like some different issue.
 From the picture I would say the the tab border images are drawn to the
 wrong side of the view. This could be an issue with a flipped view.

Yup, it looks like it.

 NSTabView should itself be flipped but at the moment this isn't done in
 code as there was a drawing problem for flipped views.
 Or it could be an issue with a theme. Could you please switch to the
 default theme if you are using any other?

I think I tested with all the themes I had installed with similar
results but I will check tomorrow, I just erased everything...

Philippe



___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev

Re: NSTabView problem

[Philippe Roussel]

On Tue, Aug 10, 2010 at 02:01:42PM +0200, Philippe Roussel wrote:
 Hi all,
 
 I'm trying to update my GNUstep environment and I'm facing drawing
 problems, whether I use svn head or the lastest unstable release. Have
 a look at the attached screenshot.
 
 Is anyone else having this problem ?
 
 This is a 64 bits build with the cairo backend (I think the same
 problem happens with the art backend), gcc 4.2.4.

And now with the screenshot...
-- 
When Dilbert has a better working environment than you its time to leave

attachment: simpleagenda-tabs.png___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev

NSTabView problem

[Philippe Roussel]

Hi all,

I'm trying to update my GNUstep environment and I'm facing drawing
problems, whether I use svn head or the lastest unstable release. Have
a look at the attached screenshot.

Is anyone else having this problem ?

This is a 64 bits build with the cairo backend (I think the same
problem happens with the art backend), gcc 4.2.4.

Thanks,
Philippe
-- 
NT is to UNIX what a doughnut is to a particle accelerator.


___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev