[PATCH] Remove objc_mutex usage from gnustep-base

[Niels Grewe]

Hello all,

attached is a small patch that replaces all objc_mutexes in gnustep-base
with pthread_mutexes (save for the runtime mutex, of course). NSLock and
friends already use pthreads and I don't think there is anything to be
gained by sticking to the old runtime-threading layer in other places
(the new runtime doesn't even export objc_mutex_(de)allocate() anymore).
This also has the added benefit that (slightly faster) non-recursive
mutexes can be used in a few places, where they're just protecting
simple lookup or update operations on some table. As a downside, the
GSAllocateMutexAt() function from GSObjCRuntime.h had to go (but, apart
from the fact that using objc_mutexes shouldn't really be encouraged,
nobody seems to be using it).
I verified that the testsuite still passes for -base after the change
and I didn't notice any problems in day-to-day usage. Still, I'd really
appreciate somebody taking a closer look.

I'd also like to ask about whom to contact regarding copyright
assignment. I know that this is a rather insignificiant (and repetitive)
contribution, so it might not be strictly needed, but just in case…

kind regards,


Niels
Index: Source/GSFFCallInvocation.m
===
--- Source/GSFFCallInvocation.m	(revision 29331)
+++ Source/GSFFCallInvocation.m	(working copy)
@@ -32,6 +32,8 @@
 #import 
 #import "callframe.h"
 
+#include 
+
 #import "GSInvocation.h"
 
 #ifndef INLINE
@@ -136,7 +138,7 @@
 
 /* Lock that protects the ff_callback_map */
 
-static objc_mutex_t  ff_callback_map_lock = NULL;
+static pthread_mutex_t ff_callback_map_lock = PTHREAD_MUTEX_INITIALIZER;
 
 /* Static pre-computed return type info */
 
@@ -477,7 +479,7 @@
   GSIMapNode node;
 
   // Lock
-  objc_mutex_lock (ff_callback_map_lock);
+  pthread_mutex_lock (&ff_callback_map_lock);
 
   node = GSIMapNodeForKey (&ff_callback_map,
 	(GSIMapKey) ((void *) &returnInfo));
@@ -503,7 +505,7 @@
 	(GSIMapVal) forwarding_callback);
 	}
   // Unlock
-  objc_mutex_unlock (ff_callback_map_lock);
+  pthread_mutex_unlock (&ff_callback_map_lock);
 }
   return forwarding_callback;
 }
@@ -512,8 +514,6 @@
 {
   int index;
 
-  ff_callback_map_lock = objc_mutex_allocate ();
-
   for (index = 0; index < STATIC_CALLBACK_LIST_SIZE; ++index)
 {
   returnTypeInfo[index].type = index;
Index: Source/GSPThread.h
===
--- Source/GSPThread.h	(revision 0)
+++ Source/GSPThread.h	(revision 0)
@@ -0,0 +1,58 @@
+/* GSPThread.h
+   Copyright (C) 2010 Free Software Foundation, Inc.
+
+   Written by:  Niels Grewe 
+   
+   This file is part of the GNUstep Base Library.
+
+   This library is free software; you can redistribute it and/or
+   modify it under the terms of the GNU Lesser General Public
+   License as published by the Free Software Foundation; either
+   version 2 of the License, or (at your option) any later version.
+   
+   This library is distributed in the hope that it will be useful,
+   but WITHOUT ANY WARRANTY; without even the implied warranty of
+   MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+   Library General Public License for more details.
+   
+   You should have received a copy of the GNU Lesser General Public
+   License along with this library; if not, write to the Free
+   Software Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston,
+   MA 02111 USA.
+*/ 
+#ifndef _GSPThread_h_
+#define _GSPThread_h_
+
+/*
+ * Since glibc does not enable Unix98 extensions by default, we need to tell it
+ * to do so explicitly. Whether that support is switched on by _XOPEN_SOURCE or
+ * by __USE_UNIX98 depends on whether  has already been included or
+ * will be included by pthread.h. Hence both flags need to be set here. This
+ * shouldn't be be a problem with other libcs.
+ */
+#define _XOPEN_SOURCE 500
+#define __USE_UNIX98
+#include 
+
+/*
+ * Macro to initialize recursive mutexes in a portable way. Adopted from
+ * libobjc2 (lock.h).
+ */
+#	ifdef PTHREAD_RECURSIVE_MUTEX_INITIALIZER_NP
+#		define GS_INIT_RECURSIVE_MUTEX(x) x = PTHREAD_RECURSIVE_MUTEX_INITIALIZER_NP
+#	elif defined(PTHREAD_RECURSIVE_MUTEX_INITIALIZER)
+#		define GS_INIT_RECURSIVE_MUTEX(x) x = PTHREAD_RECURSIVE_MUTEX_INITIALIZER
+#	else
+#		define GS_INIT_RECURSIVE_MUTEX(x) GSPThreadInitRecursiveMutex(&(x))
+
+static inline void GSPThreadInitRecursiveMutex(pthread_mutex_t *x)
+{
+	pthread_mutexattr_t recursiveAttributes;
+	pthread_mutexattr_init(&recursiveAttributes);
+	pthread_mutexattr_settype(&recursiveAttributes, PTHREAD_MUTEX_RECURSIVE);
+	pthread_mutex_init(x, &recursiveAttributes);
+	pthread_mutexattr_destroy(&recursiveAttributes);
+}
+#   endif // PTHREAD_RECURSIVE_MUTEX_INITIALIZER(_NP)
+
+#endif // _GSPThread_h_
Index: Source/NSZone.m
==

GNUstep core builds with libobjc2 and clang!

[Niels Grewe]

Hello guys,

I just wanted to drop a little note that I've finally been successful in
building the core GNUstep components with clang (there have been some
linkage problems with libobjc2, which Richard fixed last night). Only
-gui needed a little nudging (apparently, clang is very specific about
not wanting unions with variable-sized members -- patch attached). The
combination still seems to be rough on the edges (crashes here and
there, odd effects in gdb) , but the more adventurous can surely try it
out without being totally frustated.

Cheers,


Niels
Index: Source/NSColor.m
===
--- Source/NSColor.m	(revision 29361)
+++ Source/NSColor.m	(working copy)
@@ -1265,17 +1265,14 @@
 - (NSUInteger) hash
 {
   int nums = [self numberOfComponents];
-  union {
-uint8_t	bytes[sizeof(float) * nums];
-float	floats[nums];
-  } u;
+  float floats[nums];
   NSUInteger	h = 0;
   unsigned	i;
 
-  [self getComponents: u.floats];
-  for (i = 0; i < sizeof(u); i++)
+  [self getComponents: &floats[0]];
+  for (i = 0; i < sizeof(floats); i++)
 {
-  h = (h << 5) + h + u.bytes[i];
+  h = (h << 5) + h + *(uint8_t*)(((uintptr_t)&floats[0])+(i*sizeof(uint8_t)));
 }
   return h;
 }


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

[PATCH] GSXML: Respect XML catalogs

[Niels Grewe]

Hello guys,

some months back, somebody complained that gnustep-base took ages for
them to build on a machine without network access. The problem was that
the gsdoc DTDs were not yet installed and autogsdoc was trying to fetch
them over the net, making it wait for a timeouts quite a while.
libxml2 does support a feature called xml-catalogs for such situations,
allowing you to remap xml PUBLIC/SYSTEM identifiers to new (local)
urls.

Recently, I took a look at GSXML and how it does handle DTD resolution.
It turns out that it is overriding DTD resolution in a manner that
bypasses catalogs. If a DTD is not installed to a location we explicitly
search, it will always be fetched from the original url. Attached is a
patch that corrects that by adding the DTDs GNUstep is resolving
internally to the catalog and running libxml2's builtin lookup function
afterwards. In theory, this should not break anything, but as always I
might have screwed up slightly somewhere.

Cheers,


Niels
Index: Source/Additions/GSXML.m
===
--- Source/Additions/GSXML.m	(revision 29650)
+++ Source/Additions/GSXML.m	(working copy)
@@ -77,6 +77,7 @@
 #include 
 #include 
 #include 
+#include 
 #ifdef	HAVE_LIBXML_SAX2_H
 #include 
 #else
@@ -84,6 +85,7 @@
 # define	xmlSAX2GetLineNumber	getLineNumber
 # define	xmlSAX2GetPublicId	getPublicId
 # define	xmlSAX2GetSystemId	getSystemId
+# define	xmlSAX2ResolveEntity 	resolveEntity
 #endif
 #include 
 #include 
@@ -154,6 +156,7 @@
 {
   cacheDone = YES;
   xmlMemSetup(objc_free, objc_malloc, objc_realloc, objc_strdup);
+  xmlInitializeCatalog();
 
 #if	HAVE_LIBXML_SAX2_H
   xmlDefaultSAXHandlerInit();
@@ -2417,9 +2420,7 @@
 loadEntityFunction(void *ctx,
   const unsigned char *eid, const unsigned char *url)
 {
-  extern xmlParserInputPtr	xmlNewInputFromFile();
   NSString			*file = nil;
-  xmlParserInputPtr		ret = 0;
   NSString			*entityId;
   NSString			*location;
   NSArray			*components;
@@ -2428,10 +2429,10 @@
   unsigned			index;
 
   NSCAssert(ctx, @"No Context");
-  if (url == 0)
-return 0;
+  if (url == NULL)
+return NULL;
 
-  entityId = (eid != 0) ? (id)UTF8Str(eid) : nil;
+  entityId = (eid != NULL) ? (id)UTF8Str(eid) : nil;
   location = UTF8Str(url);
   components = [location pathComponents];
   local = (NSMutableString *) [NSMutableString string];
@@ -2574,51 +2575,24 @@
 	   ofType: @""
 	  inDirectory: @"DTDs"];
 	}
-	  if (file == nil)
-	{
-	  NSURL	*aURL;
-
-	  aURL = [NSURL URLWithString: location];
-	  if ([aURL isFileURL] == YES)
-	{
-		  file = [aURL path];
-		}
-	  else
-	{
-		  NSData	*data = [aURL resourceDataUsingCache: NO];
-
-		  if ([data length] > 0)
-		{
-		  file = [@"/tmp" stringByAppendingPathComponent: local];
-		  [data writeToFile: file atomically: NO];
-		}
-		}
-	}
 	}
 }
 
+  /*
+   * If we found the DTD somewhere, add it to the catalog.
+   */
   if ([file length] > 0)
 {
-  const char	*path;
-
-#if	defined(__MINGW32__)
-  /*
-   * The xmlNewInputFromFile() function requires an eight bit string
-   * but on a modern windows filesystem the file name could be unicode
-   * which can't be represented as a cString ... and may cause an
-   * exception ... nothing we can do about it really.
-   */
-  path = [file cString];
-#else
-  path = [file fileSystemRepresentation];
-#endif
-  ret = xmlNewInputFromFile((xmlParserCtxtPtr)ctx, path);
+  NSURL *theURL = [NSURL fileURLWithPath: file];
+  xmlCatalogAdd((const unsigned char*)"public", eid,
+UTF8STRING([theURL absoluteString]));
 }
-  else
-{
-  NSLog(@"don't know how to load entity '%s' id '%s'", url, eid);
-}
-  return ret;
+
+  /*
+   * A local DTD will now be in the catalog: The builtin entity resolver can
+   * take over.
+   */
+  return xmlSAX2ResolveEntity(ctx, eid, url);
 }
 
 


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

Re: Google Summer of Code 2010

[Niels Grewe]

On Tue, Mar 02, 2010 at 09:13:59PM +, David Chisnall wrote:
> On 2 Mar 2010, at 21:03, Fred Kiefer wrote:
> 
> > That was quite an interesting discussion. I asked whether we should
> > participate in GSoC this year in any form and didn't get any reply apart
> > from Yavor's (Who repeated my own proposal).
> 
> I forwarded your post to the Étoilé list, but didn't get any replies.
> I think Eric and Niels would both be good candidates if they are
> students at the time, and I'd be happy to mentor someone.  We will
> probably put in an Étoilé proposal again even if GNUstep doesn't, but
> a joint proposal might work better, maybe with GSWeb / OGo?

I was a bit busy with other stuff last week, but better late than never:
David is right: I'll still be a student this summer, and I really like
the idea of spending more time on some fun GNUstep/Étoilé project then,
so GSoC would be a perfect excuse for doing exactly that. If lack of
mentor-manpower really is an issue, I'd also promise to be a
(relatively) low maintenance student ;-)
Anyways, not entering just because of bad experiences in the past might
perhaps be jumping to conclusions.

Cheers,

Niels


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

Re: Corrupted heap

[Niels Grewe]

On Thu, Mar 18, 2010 at 12:36:15PM +, David Chisnall wrote:
> GNUstep Make, frustratingly, has no way of removing flags.  You can, however, 
> build like this:

Actually, you can pass "debug=yes" to gnustep-make and it won't enable
any optimizations.


Niels


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

[PATCH] A NSNetService implementation using Avahi

[Niels Grewe]

Hello guys,

here [0] you will find a patch (slighly to large for attachment) that
I've been cooking up for some time now. It augements the present
implementation of NSNetService and NSNetServiceBrowser in gnustep-base
with a second implementation using the Avahi API. Some words on why that
seems to be a good idea to me:

Our present implementation of NSNetServices makes use of the API that
Apple implemented in mDNSResponder [1] to provide zeroconf (=Bonjour)
services. That is, in principle, a good idea, because we can bet that
Apple also used it to implement NSNetServices on Mac OS X. The problem
is only that (way back) mDNSResponder was APSL licensed [2], which was
hindering adoption by some Linux distributions, so it is not available
on many Linux systems.
Fortunately, the Avahi project provides a compatibility layer for the
mDNSResponder API that can be used instead. Unfortunately, that
compatibility layer is only partitially implemented and (apparently) not
very well maintained. This means that presently our NSNetServices code
will run on most Linux distributions where avahi is available, but most
of the shiny stuff you would want in an useful application (e.g.
monitoring TXT records) wont work.

Since Avahi is probably going to stick on the Linux desktop (it provides
a DBUS interface that seems to be quite popular for reasons unknown to
me), I decided not to waste my time on fixing the Avahi compatability
layer, but to reimplement NSNetServices on top of the native Avahi API.
This was actually quite easy, because avahi provides some hooks that
allowed hooking the event-handling into NSRunLoop quite transparently.
This has the following ramifications:

1. NSNetService and NSNetServiceBrowser are now abstract superclasses
   that return concrete subclasses for the configured implementation.

2. The zeroconf API to use is now configurable by the
   --with-zeroconf-api configure switch. It can take the values "mdns",
   "avahi" and "any" (with "any" being the default). If both are
   installed, it will always use avahi, since the mDNS implementation is
   most certainly the broken compatibility-layer.

3. The new avahi-based implementation has some shiny additional features
   that make it more flexible then the Apple one. I.e. it allows you not
   only to browse for (or register) services and TXT records, but also
   arbitrary records. This is nice for use-cases like serverless
   XMPP-messaging, where you are supposed to publish a buddy-icon as a
   NULL record. While these features are not yet available with our
   mDNSResponder-based implementation, they are certainly possible, and
   I would be adding them eventually if there is sufficient interest.

I'm now soliciting feedback on this patch. It still has some
non-critical FIXMEs strewn over it that I plan to resolve, but in
general it seems to be quite usable. So if you have any code that uses
NSNetService and friends, please try it out and tell me when it breaks
and where it doesn't behave as expected. To this purpose, I have also
uploaded the patch to the Étoilé reviewboard [3].

Thanks,


Niels
--
[0] http://www.halbordnung.de/~thebeing/gnustep/NSNetServices+avahi.patch
[1] http://www.opensource.apple.com/source/mDNSResponder/mDNSResponder-214/
[2] It's Apache-licensed now.
[3] http://review.etoileos.com/r/137/


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

Re: [PATCH] A NSNetService implementation using Avahi

[Niels Grewe]

On Fri, Mar 26, 2010 at 09:26:14AM +0100, Fred Kiefer wrote:
> I only had a short look at this patch and was a bit surprised to see how
> little these two implementations share. In a normal class cluster you
> would expect that most of the code is in the common super class and only
> the primitive methods get implemented separately. What was the reason
> for doing it differently here?

The "reason" (apart from general laziness) is that the Avahi-based
implementation started its life as a local out-of-tree workaround for
me. Of course that's not a good reason. I will move stuff up to
NSNetService where possible, though that will require shuffling around
the class layouts bit, because the avahi subclasses make use of
behaviours.

> Even the delegate handling methods are duplicated, with the mDNS ones
> having an additional tracing call.

I left the mDNS implementation mostly untouched (except where it was
retaining delegates…), the tracing calls where already there.

> PS: You seem to be using tabs to indent your code. Spaces (two of them
> actually) are prefered.

Okay. I guess just piping it through 'indent' won't be sufficient to get
it cleaned up? Do we have any coding-style documentation (apart from the
"GNU Coding Standards", obviously).

Thanks for having a look!


Niels


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

Re: [PATCH] A NSNetService implementation using Avahi

[Niels Grewe]

On Fri, Mar 26, 2010 at 09:26:14AM +0100, Fred Kiefer wrote:
> I only had a short look at this patch and was a bit surprised to see how
> little these two implementations share. In a normal class cluster you
> would expect that most of the code is in the common super class and only
> the primitive methods get implemented separately. What was the reason
> for doing it differently here? Even the delegate handling methods are
> duplicated, with the mDNS ones having an additional tracing call.
> Apart from that your patch makes perfectly sense to me.
> 
> Fred
> 
> PS: You seem to be using tabs to indent your code. Spaces (two of them
> actually) are prefered.

All ammended (including indentation) and available from the locations
previously announced [0,1]. But I understand you won't be wanting to
apply this until after the proposed release…

Cheers,


Niels
--
[0] http://www.halbordnung.de/~thebeing/gnustep/NSNetServices+avahi.patch
[1] http://review.etoileos.com/r/137/


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

Re: Which bugs to focus on for the release?

[Niels Grewe]

On Sun, Apr 18, 2010 at 05:34:56PM +0100, Richard Frith-Macdonald wrote:
> What I thought might be a single issue related to networking (Riccardo's 
> problem establishing a connection to gdnc on Hurd, and my problem running out 
> of file descriptors in an Java system using jigs) urned out to be two 
> separate issues (both quite rare) ... which are fixed now.  So we need a 
> period of hard testing but I think there are really no known bugs at present.

So the gdnc problem is supposed to be fixed? I just noticed that I have
an issue on my 64bit Linux system that sounds similar (applications
waiting for gdnc indefinitely). Could you give some pointers on where to
look?

Cheers,


Niels


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

Re: Which bugs to focus on for the release?

[Niels Grewe]

On Mon, Apr 19, 2010 at 07:39:14AM +0100, Richard Frith-Macdonald wrote:
> Well, 'waiting for gdnc indefinitely' is a bit vague  ... is that
> failing to connect, failing to register as an observer, failing to
> send, failing to receive etc.  Maybe gdnc is not even being started?

Sorry, that last e-mail was decisively non-helpful. (My doctors tell me
I'm suffering from a servere case of email-before-coffee related
aphasia.)
In concrete terms the problem seemed to be related to the remote side
sending replies with a non-sensible type (e.g. 37602) in -[NSConnection
_sendOutRmc:type:] and the local side waiting in -[NSConnection
_getReplyRmc:]. But I say "seemed" because after recompiling everything
without clang and libobjc2, things are working again. I'll need to go
through another recompile cycle to find out what exactly is going wrong
there.

Cheers,


Niels


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

Re: Google Summer of Code

[Niels Grewe]

Hello all,

Adam beat me to the punch on sending out an e-mail about the GSoC and I
can only thank him for the warm welcome, and of course Fred for agreeing
to mentor me. I'm really excited about working on a GNUstep project this
summer, although my proposal seems very much lackluster when compared to
Eric's project (Seriously! Let him tell you about it, it's shiny…).
What I'm going to work on is a proper bridge between GNUstep's native
Distributed Objects IPC mechanism and D-Bus (aka "poor man's DO"). The
idea is that using D-Bus objects from Objective-C code (or vending
objects via D-Bus) should be (for common cases) possible by sending the
well-known messages to NSConnection and friends. That way, we would be
able to leverage the plethora of software that exposes D-Bus interfaces.

Of course this kind of task has been attempted before, and while my
tasks will include sifting through it and salvaging whatever seems
(re-)usable, I hope to do one better and present something really
polished by the end of the summer. In the meantime, I will keep you
posted about progress, or – more likely – nag you with whatever crazy
problems I might stumble upon.

Cheers,


Niels


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

Re: [PATCH] GSXML: Respect XML catalogs

[Niels Grewe]

Hi,

On Thu, May 13, 2010 at 11:04:56AM +, Yavor Doganov wrote:
> Is there any chance to get it reviewed/approved/committed upstream?

It was committed in revision 29654. 

Cheers,

Niels

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

Re: How to fix this?

[Niels Grewe]

Hello,

On Tue, Aug 17, 2010 at 06:08:55PM -0600, Elim Qiu wrote:
> Making all for framework DBusKit...
>  Compiling file DKArgument.m ...
> cc1obj: warnings being treated as errors
> DKArgument.m: In function ‘-[DKArgument unboxValue:intoBuffer:]’:
> DKArgument.m:807: error: cast from pointer to integer of different size

Thanks for reporting this. I've just fixed it in SVN (r31180). There
might be more of this type of "error". They are usually merely warnings,
but I like to catch those so I don't miss a real error. You can disable
this paranoid behaviour by building with `make nonstrict=yes'.

Cheers,

Niels

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

Re: Do we want to apply for a FOSDEM dev room in 2011?

[Niels Grewe]

Hi Lars,

I definitely support the idea of a GNUstep devroom at FOSDEM. It's been
lots of fun this year and, if nothing interferes, I would try to be
there again next year. I also think that I'm in favour of saturday,
since starting at 12:00 would entail two more hours of sleep :-)

Cheers,


Niels

___
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/

[Niels Grewe]

Hello Richard,

On Thu, Dec 16, 2010 at 10:09:44AM -, Richard Frith-Macdonald wrote:
> Author: rfm
> Date: Thu Dec 16 11:09:43 2010
> New Revision: 31742
> 
> URL: http://svn.gna.org/viewcvs/gnustep?rev=31742&view=rev

> Modified:

> libs/base/trunk/Source/NSXMLParser.m

I've got a question about this change to NSXMLParser: What is the
rationale behind disabling the libxml2-based parser (line 49)? The
sloopy parser seems to produce results that don't exactly match those of
the libxml2 parser. At least it is causing problems for me in DBusKit,
where the sloppy parser refuses to parse the XML introspection data from
D-Bus. Any ideas on how to sort this out?

Thanks,


Niels

___
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/

[Niels Grewe]

On Fri, Dec 17, 2010 at 01:31:19PM +, Richard Frith-Macdonald wrote:
> I just want to remove the dependency on libxml2 ... I was under the 
> impression that the built-in parser worked for all valid XML.
> We want the built-in parser anyway, in order to parse apple property lists 
> because they contain escape characters which are rejected by libxml2 ... (the 
> builtin/sloppy parser accepts escapes as if they were legal).

Sounds reasonable.

> If you can produce a testcase demonstrating what's wrong/different I will try 
> to code a fix (and in the meantime you can easily revert to use libxml2 
> locally of course).

Okay. I'll put something together (I think I need to check back with my
MacOS machine for the actual behaviour of Apple's NSXMLParser). Two
problems I already could identify are the following: 

* Unless you call -_setAcceptHTML: with YES, any XML data without
   prolog is rejected by the parser, although it's  perfectly
  well-formed (according to §2.8 of the XML spec).
* It generates a -parser:didStartElement:… call to the delegate for the
  doctype declaration, which it probably shouldn't because it only
  specfies the grammar to use for validating the XML.

Cheers,

Niels

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

Re: Git?

[Niels Grewe]

On Mon, Jan 24, 2011 at 01:53:40AM +0700, Banlu Kemiyatorn wrote:
> Why would we want to move to Git? I don't see any much benefit by
> doing that. And although nobody did mention anything about moving to
> git, I still want to made this suggestion that we should stick with
> SVN forever. Anyone is against me?

Yes, me. I cannot possibly know anything about the distant future, so I
cannot subscribe to the proposition of "sticking with SVN _forever_".
Anyways: If somebody were to suggest switching revision control systems,
that person would be obligated to provide a compelling argument for
doing so. Since nobody has done that, I think the point is moot.


Niels 

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

Problems with the test framework and non-flattened namespaces

[Niels Grewe]

Hello all,

I've just tried to run the testsuites on a system that has non-flattened
namespaces enabled and it turns out that causes a little problem. The
build_and_run() function in gnustep-tests expects to find the
executables in $testdir/obj, whereas with a non-flattened install they
are in $testdir/obj/$GNUSTEP_TARGET_LDIR/, where $GNUSTEP_TARGET_LDIR is
some combination of architecture, os and runtime-library combination.
(e.g. x86_64/linux-gnu/gnu-gnu-gnu/ on my machine).
Initially I thought that this could be easily fixed, but it turns out
that $GNUSTEP_TARGET_LDIR is only defined in makefiles and I don't see
how I can get at that variable from a shell script. Could somebody
perhaps help me out here?

Cheers,

Niels

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

Re: Problems with the test framework and non-flattened namespaces

[Niels Grewe]

On Tue, Mar 01, 2011 at 12:43:41PM +, Richard Frith-Macdonald wrote:
> I've modified the code so that it should override the destination and always 
> place executables in the obj subdirectory even on a non-flattened layout.
> Within the testsuite we clean old test information and rebuild each file on 
> every test run, so there's no point keeping binaries for different 
> architectures/library combos in separate subdirectories.
> Hopefully, the trick of overriding GNUSTEP_OBJ_DIR will let us keep the 
> executables in a single location, while allowing your non-flattened structure 
> to be used elsewhere outside the test framework.
> Please let me know if this works or not.

It works like a charm!

Thanks,

Niels

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

Re: Desktop file generated with wrong path ?

[Niels Grewe]

Am 10.03.2011 um 23:10 schrieb 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.

The way Gnome and KDE handle icon lookup it rather complicated. What you are 
supposed to do is apparently the following (quoting the icon theme 
specification [0]):

> So, you're an application author, and want to install application icons so 
> that they work in the KDE and Gnome menus. Minimally you should install a 
> 48x48 icon in the hicolor theme. This means installing a PNG file in 
> $prefix/share/icons/hicolor/48x48/apps. Optionally you can install icons in 
> different sizes. For example, installing a svg icon in 
> $prefix/share/icons/hicolor/scalable/apps means most desktops will have one 
> icon that works for all sizes. You might even want to install icons with a 
> look that matches other well known themes so your application will fit in 
> with some specific desktop environment.

Please note that "$prefix" is nonesense here because they don't seem to know 
their own specifications [1]. You should use the first writable entry from 
$XDG_DATA_DIRS and find the icons subdirectory there. Also the catch is that 
they specify PNG, SVG and XPM as the only valid icon formats…

Cheers,

Niels

[0] http://standards.freedesktop.org/icon-theme-spec/icon-theme-spec-latest.html
[1] In this case, the basedir spec: 
http://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html
___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev

Re: Anyone is digging DBus Menu?

[Niels Grewe]

Am 30.04.2011 um 06:39 schrieb Banlu Kemiyatorn:

> Hi, I am quickly looking at Ubuntu Unity Application menu
> (https://wiki.ubuntu.com/DesktopExperienceTeam/ApplicationMenu) wonder
> if anyone is working on this.
> Do we have dbusmenu built around DBusKit? Niels?

It is definitely on my todo list. Creating a  class that implement the NSMenu 
interfaces and talk to a D-Bus menu server internally should be quite easy with 
DBusKit at its present state. I'm more interested in the reverse, i.e. allowing 
QT and GTK applications to display their menus on (e.g.) the Étoilé menuserver. 
But for that, DBusKit needs to have support for exposing objects on D-Bus 
(which it doesn't, yet).

Cheers,

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

Re: Could GNUStep allow for iPhone porting to Android?

[Niels Grewe]

Am 29.09.2011 11:06, schrieb Ivan Vučica:
> I think I may have some time over upcoming weekends. If someone gives me
> some example code on using Opal, I could play with getting some basic
> UIKit to work.
> 
> I don't think I'm familiar enough with GNUstep's AppKit to integrate
> this system there. Plus, it might break things on older compilers and
> systems. UIKit doesn't really *have* to be backward compatible, and
> using OpenGL for compositing in initial implementation would practically
> guarantee that ancient x86 systems won't be able to run apps at decent
> speeds.
> 
> So, can someone point me to some demo Opal program? If enough
> CoreGraphics is implemented, I think I could figure out how to get the
> RGBA pixel array out of it and start working on the really interesting
> parts.

Opal lives at svn://svn.gna.org/svn/gnustep/libs/opal/trunk and there
are some examples in the ./Tests directory. Ideally, I think, you would
want to avoid copying the pixel data from the cairo surface to an OpenGL
textzre but instead use a cairo surface that can be bound to an OpenGL
texture using EGL. This has the upside that it would also, with little
tweaks, work with OpenGL/ES (i.e. on mobile platforms) and it would give
optimal performance.

Cheers,

Niels

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

Re: cairo x11 surfaces

[Niels Grewe]

Hi Eric,

Am 13.10.2011 23:26, schrieb Eric Wasylishen:
> 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).

This is a nice change; things seem a lot faster now in the normal case.
But (at least for me) it seems to have quite the opposite effect once I
turn on compositing in the window manager (kwin, in this case). I'm
guessing that is because the compositing manager does its own
double-buffering, though the effects are a bit more servere than I would
expect from just that.
A possible workaround would be to check whether a compositing manager
has taken the _NET_WM_CM_S${ScreenNum} [0] selection and avoid the
double buffering in that case. But then we'd also have to keep track of
when compositing is enabled and disabled.

Cheers,

Niels

[0] http://standards.freedesktop.org/wm-spec/wm-spec-latest.html#id2552745

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

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

[Niels Grewe]

Am 25.01.2012 19:38, schrieb Stefan Bidi:
> On Wed, Jan 25, 2012 at 12:30 PM, Eric Wasylishen  > wrote:
> 
> 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.
> 
> 
> Have you thought about using that "global menu" thing?  I know nothing
> about the subject, but the latest move by Ubuntu to include that
> "searchable menus" thing only works for "the HUD from any standard
> Ubuntu app that supports the global menu".  I Is there some sort of
> standard out there that defined this behavior?  If so, I think it would
> be worth looking at possibly integrating it with GNUstep.

The whole global menu stuff works via D-Bus and I'm planning to add
support for that in DBusKit after I finally implement exporting objects
to D-Bus, which is required because the menu wants to be able to do
callbacks etc. My theory is that it should work in a way quite similar
to the WinUXTheme.

Cheers,

Niels



signature.asc
Description: OpenPGP digital signature
___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
https://lists.gnu.org/mailman/listinfo/gnustep-dev

[NSXML + libxml2] external retains

[Niels Grewe]

Hi Doug, Greg and all,

I've just been digging into the new libxml2 powered NSXML code and got a
bit confused about the code path that takes care of external references.
I get that we want to increase the retain count of the top node in a
tree if any object outside the tree makes reference to some node in the
tree. Otherwise, we'd get dangling parent pointers when nothing
references the top node and it gets deallocated.

But from looking at the code, I somehow think that we should also be
decreasing the top node's external retain count when a node gets
detached from the tree (which we don't do presently). But with the way
things are done now, I don't see how we would do that because once the
node is attached the record keeping for external references is taken
over by the top node. The situation basically looks like this ("|"
denotes the parent-child-relation where the parent is written above the
child and "<-" denotes an external object holding a reference to the node):

A   (externalRetains == 2)
|
B<-X(externalRetains == 0)
|
C   (externalRetains == 0)
|
D<-Y(externalRetains == 0)

Now if we detach, say, C, then we have no way to tell:

a) that we should send C and extra -retain in order to prevent D from
ending up with a dangling reference to C.

b) that we should decrease the externalRetains of A by 1. And we need to
do that, because if we don't, and X stops retaining B, we start leaking
A and B.

This would be much easier to handle if we were tracking the extra
refcount all the way through the tree:


A   (externalRetains == 2)
|
B<-X(externalRetains == 2)
|
C   (externalRetains == 1)
|
D<-X(externalRetains == 1)

Would that be about right? Also: Couldn't we just do away with this
whole contraption if we had the children retain their parents while the
parents only hold weak references to them?

Also there is another thing I cannot quite wrap my head around right now
and it would be nice if someone could elaborate on that as well: Why
does NSXMLNode's -release method decrease the externalRetains only "if
([self retainCount] == [internal->subNodes count])" (NSXMLNode.m:590)?

I already apologise if I'm just overlooking the obvious here. Also, I
hope that I don't sound overly cirtical about this code, which I think
is really a nice new feature. I already turned on some bits in DBusKit
that require NSXML, and it turns out that it's working quite well in
general :-)

Cheers,

Niels



signature.asc
Description: OpenPGP digital signature
___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
https://lists.gnu.org/mailman/listinfo/gnustep-dev

Re: OpenGL context without AppKit

[Niels Grewe]

Am 28.01.2012 13:38, schrieb Ivan Vučica:
> Any chance that this is enabled in the nearby future? Without that I'll
> probably just add extra method to pass GLX context, since the little
> amount of platform-specific code in UIKit will probably initially be
> working solely with GLX (considering that, again, I can't use -back
> without -gui).

One thing we should keep in mind is that in the long run, we also want
to support embedded platforms (hell, they're probably the primary
target, aren't they?), where we only have OpenGL-ES and probably no
X-server. So maybe we should evaluate going right to EGL here, which is
a much cleaner and platfrom independent approach to the same thing. I'm
not quite sure how stable EGL support for desktop X servers is (Debian
has a libegl1-mesa package in testing, though), but on my Efika (which
uses proprietary drivers for everything), it took very little effort to
come up with a POC that shared a surface between OpenVG (used by Opal
via cairo) and OpenGL-ES such that it could be animated while Opal was
drawing to it. I'll try to dig it up if you're interested.

Cheers,

Niels


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

Re: OpenGL context without AppKit

[Niels Grewe]

Am 28.01.2012 21:35, schrieb Ivan Vučica:
> 
> 
> On Sat, Jan 28, 2012 at 14:16, Niels Grewe  <mailto:niels.gr...@halbordnung.de>> wrote:
> 
> 
> One thing we should keep in mind is that in the long run, we also want
> to support embedded platforms (hell, they're probably the primary
> target, aren't they?), where we only have OpenGL-ES and probably no
> X-server. So maybe we should evaluate going right to EGL here, which is
> a much cleaner and platfrom independent approach to the same thing. I'm
> not quite sure how stable EGL support for desktop X servers is (Debian
> has a libegl1-mesa package in testing, though), but on my Efika (which
> uses proprietary drivers for everything), it took very little effort to
> come up with a POC that shared a surface between OpenVG (used by Opal
> via cairo) and OpenGL-ES such that it could be animated while Opal was
> drawing to it. I'll try to dig it up if you're interested.
> 
> 
> Hi,
> 
> definitely. I'm counting on supporting GLES. I'm not sure it's sensible
> to target solely GLES. Most (if not all) of CoreAnimation code will be
> shared between GL and GLES, and creation of the context is platform
> specific, anyway, isn't it?
> 
> GLES support on desktops will be flaky at best, missing at worst (see
> Win32). Targeting both GL and GLES is not difficult.
> 
> Am I wrong? :-)

No, you're quite right :-) The point about EGL is that it's not tied to
OpenGL-ES or any specific windowing system. Instead, it supports all of
OpenGL, OpenGL-ESv(1|2) and OpenVG on whatever native windowing
environment you throw at it. Basically, instead of having platform
specific calls glXMakeCurrent() or wglMakeCurrent() to tell OpenGL where
to draw to you get eglMakeCurrent() and pass it an EGLSurface which can
be (among others) an off-screen buffer or a native window that you'd get
via eglCreateWindowSurface(). So the platform specific stuff is already
abstracted away for you long before you actually start drawing. The
ability to mix OpenGL(ES) and OpenVG transparently is merely the icing
on the cake ;-) I hope I could clarify my suggestion a bit.

Cheers,

Niels

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

Re: GNUstep Code Freeze

[Niels Grewe]

Am 01.02.2012 10:25, schrieb Fred Kiefer:
> Hi Wolfgang,
> 
> your proposal is definitely cleaner than the current code, which uses
> the extensions as the file type. The problem with this proposal is that
> it will break all document based applications that call these methods. I
> remember adding these methods to get TextEdit to compile, but there I
> also had to change the defined types to get this working. That was less
> work then changing the application to use the old file extension code. I
> would expect the same to be true for other Cocoa applications being
> ported over to GNUstep.
> I would rather leave the current code in there until we get a real
> implementation for it.

Eric wrote an implementation of the UTI system for EtoileFoundation.
Maybe we should consider moving it over to GNUstep after the release?
I'd even be volunteering to do that if nobody objects.

Cheers,

Niels

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

Re: OpenGL context without AppKit

[Niels Grewe]

Am 01.02.2012 19:52, schrieb Ivan Vučica:
> 
> 
> On Sat, Jan 28, 2012 at 22:06, Niels Grewe  <mailto:niels.gr...@halbordnung.de>> wrote:
> 
> > Hi,
> >
> > definitely. I'm counting on supporting GLES. I'm not sure it's
> sensible
> > to target solely GLES. Most (if not all) of CoreAnimation code will be
> > shared between GL and GLES, and creation of the context is platform
> > specific, anyway, isn't it?
> >
> > GLES support on desktops will be flaky at best, missing at worst (see
> > Win32). Targeting both GL and GLES is not difficult.
> >
> > Am I wrong? :-)
> 
> No, you're quite right :-) The point about EGL is that it's not tied to
> OpenGL-ES or any specific windowing system.
> 
> 
> Unfortunately, upon further examination, it seems that this is not
> correct: EGL is solely for creating OpenGL ES contexts, not for creating
> OpenGL contexts. See, for example:
>  
> http://stackoverflow.com/questions/7017239/what-are-the-relations-between-egl-and-opengl

That's not quite correct. Since v1.4 EGL also specifies how to support
plain old OpenGL. Whether it's actually supported is up to the
implementation though. But the mesa implementation of EGL supports it
and that's probably what we care about on the desktop. Check out the
examples at:

http://cgit.freedesktop.org/mesa/demos/tree/src/egl/opengl

Also, you don't create Open(GL|GLES|VG) contexts explicitly with EGL.
You bind the client APIs you want to EGL and create an EGLContext that
you'll use instead.

Cheers,

Niels

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

Re: OpenGL context without AppKit

[Niels Grewe]

Hi Ivan!

Am 03.02.2012 21:15, schrieb Ivan Vučica:
> 
> But the mesa implementation of EGL supports it
> and that's probably what we care about on the desktop. Check out the
> examples at:
> 
> http://cgit.freedesktop.org/mesa/demos/tree/src/egl/opengl
> 
> 
> 
> For some reason I can't open cgit.freedesktop.org
>  for the last few days.

It was down for me as well, but now it seems to be working fine.

> Also, you don't create Open(GL|GLES|VG) contexts explicitly with EGL.
> You bind the client APIs you want to EGL and create an EGLContext that
> you'll use instead.
> 
> 
> Huh. I feel this all may be too new and non-standard (in the sense of
> "unusual") for easy adoption. 

> I'd feel more comfortable simply wrapping the small amount of
> platform-specific code and using that. If EGL turns out to be easily
> supportable on all platforms (as you say it should be), it's easy to
> kick out all the other platform-specific code and replace it with EGL.

Yes that sounds like a reasonable thing to do. Keeping EGL in mind is
more a future-proofing measure because it gives us a great deal of
platform independence and since the Khronos group says it's the future,
why shouldn't we listen ;-) Unless I'm missing something, the only
places where we would need to differentiate between WGL/GLX/EGL would be
context creation and *MakeCurrent(), anyways. Supporting both OpenGL and
GLES is probably the bigger challenge…

Cheers,

Niels

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

Re: Google Summer of Code

[Niels Grewe]

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?

Cheers,

Niels

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

Re: [Gnustep-cvs] r34996 - in /libs/base/trunk: ChangeLog Headers/Foundation/NSOperation.h Headers/GNUstepBase/GSBlocks.h Source/NSOperation.m Tests/base/NSOperation/basic.m

[Niels Grewe]

Hello Fred,

Am 27.03.2012 11:07, schrieb Fred Kiefer:
> This change breaks compilation on my OpenSuse 12.1 machine (64bit, gcc
> 4.6.2). The output I get is a bit cryptic:
> 
> Compiling file NSJSONSerialization.m ...
> In file included from ../Headers/Foundation/Foundation.h:92:0,
>  from NSJSONSerialization.m:10:
> ../Headers/Foundation/NSOperation.h:154:1: error: expected declaration
> specifiers or ‘...’ before ‘)’ token
> ../Headers/Foundation/NSOperation.h:154:1: warning: no semicolon at end
> of struct or union [enabled by default]
> make[4]: *** [obj/libgnustep-base.obj/NSJSONSerialization.m.o] Fehler 1
> make[3]: *** [internal-library-all_] Fehler 2
> make[2]: *** [libgnustep-base.all.library.variables] Fehler 2
> make[1]: *** [internal-all] Fehler 2
> make: *** [internal-all] Fehler 2
> 
> The problem seems to be the block type definition with just two
> arguments. All the other block definitions have at least four arguments.

Sorry for the screw-up. Should be fixed now. I wasn't quite paying
attention to how the block defintion macro would be expanded by GCC.
Unfortunately, it's a bit hard to switch between compiling base with
clang and with GCC because GCC just errors out on the commandline
switches set for clang by gnustep-make. I guess I have to maintain two
distinct installations to prevent this kind of mishap in the future.

Cheers,

Niels

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

Re: Jenkins build is back to normal : gnustep #12

[Niels Grewe]

Hi guys,

Am 01.04.2012 08:37, schrieb Dr. H. Nikolaus Schaller:
> Hi Greg,
> 
> Am 01.04.2012 um 02:27 schrieb Gregory Casamento:
> 
>> All of this defeats the purpose of the thing.  I don't want to do all of 
>> this work setting jenkins up only to make it easy for people to ignore by 
>> putting it on a mailing list which has no subscribers.
>>
>> I would insist that, if another list is created, that all of the current 
>> maintainers subscribe to it to ensure that the message gets out when someone 
>> breaks the build. 
>>
>> It is beneficial for as many people to know that the build is broken as 
>> possible so that it can be corrected by either the responsible party or by 
>> someone who Is knowledgeable enough to fix the problem.  There have, in the 
>> past, been regressions which have persisted for months without being 
>> discovered.  This system will help that never to happen again.  It does no 
>> good to have Jenkins announce issues with the build if no one hears about it.
> 
> I see that you want to create a feedback loop, which is IMHO a very good 
> means to stabilize the code quality.

+1 I think it's an applaudable effort that Greg is taking here.

> And if someone of these does not want to see the reports, it can be 
> questioned why he/she has write access...

I second that. My impression is that the people with svn write access
usually care enough about the project so that they are not indifferent
if their contributions cause breakage for other people. I'm fine with
subscribing to another list and monitoring it for problems that I caused
or can help with fixing. I expect that most hiccups can be easily
resolved, and it might not be desirable to further skew the SNR on
gnustep-dev with those. If noone picks up the pieces on a hypothetical
gnustep-ci (or whatever) mailing list, we can always escalate the
problem to gnustep-dev.

But I'd also like to call some attention to a problem that Fred
mentioned when comparing this to Adam's test farm: Having one Jenkins
instance that reports problems is far from enough, seeing that we do not
only have a host of architectures and OSes to support, but at least two
different compilers (gcc, clang), two runtimes, and whole bunch of ABIs
(not to mention a cornucopia of optional features that might or might
not cause issues). How are we going to tackle that? I think it would
help tremendously if you, Greg, could post a howto so that everybody
could replicate it for his or her favourite setup.

Cheers,

Niels



signature.asc
Description: OpenPGP digital signature
___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
https://lists.gnu.org/mailman/listinfo/gnustep-dev

Re: DBusKit build failure

[Niels Grewe]

On Sat, Apr 21, 2012 at 12:14:24PM +0100, David Chisnall wrote:
> 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...

Actually, it was a design decision to keep to the requirements set by
gnustep-base back when I initially wrote DBusKit, which at that time
included -Wdeclaration-after-statement. But since clang became my
household compiler, I find it increasingly tedious to keep to those
requirements. And as you mention, C99 is a sensible baseline nowadays.
So I will probably drop C90 (explicit) support after the 0.2 release.
For now, I applied Philippe‘s patch (thanks for that!).

Cheers,

Niels

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

Re: DBusKit build failure

[Niels Grewe]

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.

Cheers,

Niels

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

Re: Build failed in Jenkins: gnustep #67

[Niels Grewe]

Hi Greg,

I think this kind of email is what people were fearing that we would be
getting when you setup Jenkins. I identify a few issues:

On Sat, Apr 21, 2012 at 07:38:42AM -0400, greg.casame...@gmail.com wrote:
> See 
> 
> Changes:
> 
> [thebeing] Move declarations around (patch by Phillipe Roussel)

This change is totally unrelated to the stuff being built by Jenkins. It
shouldn‘t have triggered a new build at all. And at any rate, if the
build failed previously (#66), it shouldn‘t have sent a new email about
the failure.

> /home/gnustep/GNUstep/System/Library/Makefiles/common.make:231: 
> GNUSTEP_INSTALLATION_DIR is deprecated.  Please use 
> GNUSTEP_INSTALLATION_DOMAIN instead
>  Installing bundle directory...
> rm: cannot remove 
> `/home/gnustep/Library/Bundles/libgnustep-back-023.bundle/Resources/Swedish.lproj/nfontFaceNames.strings':
>  Permission denied
> rm: cannot remove 
> `/home/gnustep/Library/Bundles/libgnustep-back-023.bundle/Resources/Info-gnustep.plist':
>  Permission denied
> rm: cannot remove 
> `/home/gnustep/Library/Bundles/libgnustep-back-023.bundle/Resources/English.lproj/nfontFaceNames.strings':
>  Permission denied
> rm: cannot remove 
> `/home/gnustep/Library/Bundles/libgnustep-back-023.bundle/libgnustep-back-023':
>  Permission denied
> rm: cannot remove 
> `/home/gnustep/Library/Bundles/libgnustep-back-023.bundle/stamp.make': 
> Permission denied
> tar: 
> libgnustep-back-023.bundle/Resources/Swedish.lproj/nfontFaceNames.strings: 
> Cannot open: File exists
> tar: libgnustep-back-023.bundle/Resources/Swedish.lproj: Cannot utime: 
> Operation not permitted
> tar: libgnustep-back-023.bundle/Resources/Info-gnustep.plist: Cannot open: 
> File exists
> tar: 
> libgnustep-back-023.bundle/Resources/English.lproj/nfontFaceNames.strings: 
> Cannot open: File exists
> tar: libgnustep-back-023.bundle/Resources/English.lproj: Cannot utime: 
> Operation not permitted
> tar: libgnustep-back-023.bundle/Resources: Cannot utime: Operation not 
> permitted
> tar: libgnustep-back-023.bundle/libgnustep-back-023: Cannot open: File exists
> tar: libgnustep-back-023.bundle/stamp.make: Cannot open: File exists
> tar: libgnustep-back-023.bundle: Cannot utime: Operation not permitted
> tar: Exiting with failure status due to previous errors

This doesn‘t look much like a code problem but like a permissions
problem with Jenkins not being to install stuff. Maybe you could give
the whole Jenkins stuff a bit of time to mature before automatically
sending the messages to the list? (btw: Jenkins also provides RSS feeds,
which is a pretty nice way of keeping track of those things, imho)

Thanks alot,


Niels

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

Re: Build failed in Jenkins: gnustep #67

[Niels Grewe]

On Sat, Apr 21, 2012 at 09:14:31AM -0400, Gregory Casamento wrote:
> Niels,
> 
> The fact that we have had 30+ successful builds without any issues seems to
> indicate a good track record with respect to Jenkins and the ci effort.
> Honestly I am not going to put the messages on their own list because that 
> list
> will become a black hole and will be all too easy for people to ignore.  The
> dev list is relatively low traffic and a little noise every once in a wild
> shouldn't present an issue.
> 
> Given people's reluctance to accept Jenkins emailing the dev list I'm forced 
> to
> question why some people are even contributing to this project.  If you don't
> want to hear about build or test failures then I don't know what you're doing
> here.

Sorry Greg, 

I think you got me all wrong. I‘m very much in favour of CI, and I
absolutely want to hear about build and test failures. What I don‘t want
is to hear about failures of the CI tool or to receive emails that are
send in response to a commit I did but require me to wade through dozens
of lines of build output in order to figure out whether I actually broke
something or if it‘s a pre-existing issue. But then again this sounds
more harsh than intended, so please take it the wrong way: I‘m merely
worried that an initial sub-par experience with Jenkins might adversely
affect people‘s opinions against an otherwise great way to ensure code
quality.

Cheers,

Niels

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

Re: [Etoile-cvs] r7697 - in /trunk/Etoile/Frameworks/EtoileFoundation: Source/ETCollection+HOM.m Tests/TestETCollectionHOM.m UTIDefinitions.plist

[Niels Grewe]

Am 04.05.2012 10:46, schrieb Niels Grewe:
> Hi Quentin,
> 
> Am 04.05.2012 10:23, schrieb Quentin Mathé:
>>
>> I'm unable to get the test compiles because the compiler complains that void 
>> cannot be cast to void*. 
>>
>> Since it seems impossible write the code below, I'm not sure to see the 
>> motivation behind this change at least in Objective-C… 
>> Is it Smalltalk related?
>>
>> if ([[collection mappedCollection] methodReturningNil])
>> {
>>  // do something
>> }
> 
> That was an old change I had sitting on my hard drive and now that you
> mention it, I agree that it is bogus, I've rolled back the change. Sorry
> for not really checking that before committing.
> 
> Cheers,
> 
> 
> Niels

Oops. Sorry for picking the wrong mailing list for this...


Niels

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

Re: [Etoile-cvs] r7697 - in /trunk/Etoile/Frameworks/EtoileFoundation: Source/ETCollection+HOM.m Tests/TestETCollectionHOM.m UTIDefinitions.plist

[Niels Grewe]

Hi Quentin,

Am 04.05.2012 10:23, schrieb Quentin Mathé:
> 
> I'm unable to get the test compiles because the compiler complains that void 
> cannot be cast to void*. 
> 
> Since it seems impossible write the code below, I'm not sure to see the 
> motivation behind this change at least in Objective-C… 
> Is it Smalltalk related?
> 
> if ([[collection mappedCollection] methodReturningNil])
> {
>   // do something
> }

That was an old change I had sitting on my hard drive and now that you
mention it, I agree that it is bogus, I've rolled back the change. Sorry
for not really checking that before committing.

Cheers,


Niels

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

Re: DBusKit build failure

[Niels Grewe]

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.

Thanks for reporting!

Niels

Am 11.11.2012 14:08, schrieb 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


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

Re: NIB loader problem

[Niels Grewe]

On 18.12.2012 09:29, Luboš Doležel wrote:
> * Grand Central Dispatch - I've successfully compiled
> https://github.com/nickhutchinson/libdispatch/ with a few changes to
> make use of libobjc2's Blocks support. Wouldn't it we worthwhile to move
> objc/blocks_runtime.h and objc/blocks_private.h to a more OS X-like
> location/naming "Block_private.h"/"Block.h"? Symlinks would work too...

This is a long running pet peeve of mine. It shouldn't be necessary.
Mark Heily promised a while ago he'd release a version of
libBlocksRuntime that uses weak symbols so that libobjc2 can override
them if necessary and still lets plain C code use blocks without linking
an Objective-C runtime [0]. I guess I have to poke him again about that...

Cheers,

Niels

[0] It apparently only made it into this branch:
svn://mark.heily.com/libBlocksRuntime/branches/objc2


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

Re: [PATCH 18/21] Added support for libdispatch main queue in the main run loop.

[Niels Grewe]

On 04.03.2013 10:00, Richard Frith-Macdonald wrote:

> the first, smaller patch, to change configure.ac and the cofig.h.in and 
> base.make.in files to detect the presence/usability of libdispatch (would we 
> only consider it usable if we had block support?), 

We already have a working check for libdispatch, which automatically
enables it for the concurrent collection enumeration/sorting/filtering
stuff if it is usable together with libobjc2 (whether it is depends on
whether you have the recent release of libBlocksRuntime). We don't even
need blocks support for that, because we have a macro that can call a
block even if the compiler doesn't support calling it directly. The
changes Jean did to the configure scirpt seem to be to detect presence
of his personal version of libdispatch, which introduces some callbacks
that are not immediately obivous to me (with a _4GS suffix, so I expect
they are required exclusively for GNUstep).  I would prefer these
changes to be explained and suggested for inclusion into the upstream
libdispatch before we integrate those patches. I don't think we want to
maintain what effectively constitutes a fork of libdisaptch that is only
useful to us.

Cheers,

Niels



signature.asc
Description: OpenPGP digital signature
___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
https://lists.gnu.org/mailman/listinfo/gnustep-dev

Re: Android NDK - libobjc2

[Niels Grewe]

Hi Ivan,

On 08.03.2013 22:39CET Ivan Vučica wrote:

> PS: David, you said [1] you've built portions of GNUstep for webOS, and
> did some work on getting the configure tests to pass. Have you recently
> tried cross-compiling an elementary build of GNUstep -- just elementary
> features of Make and Base, with as little external dependencies as
> possible? If so, can you share a few details about that? Maybe it's
> reusable for Android as well.

I went through the configure script last fall and tweaked it a bit to be
more cross-compile friendly. It should in theory load all the values it
would otherwise check by AC_TRY_RUN OR AC_RUN_IFELSE from cross.config.
Unfortunately, I didn't try whether that's still true for quite a while.
You just have to give it a go once you get libobjc2 up and running...

Cheers,

Niels



signature.asc
Description: OpenPGP digital signature
___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
https://lists.gnu.org/mailman/listinfo/gnustep-dev

Re: [RFC] Cambridge Hackathon

[Niels Grewe]

Hi David,

On Thu, Apr 11, 2013 at 08:58:15AM +0100, David Chisnall wrote:
> How does the first  half of the first week in July sound (1-3rd, Monday, 
> Tuesday Wednesday).  I can try to find accommodation for people for then, and 
> optionally for the weekend before if people want to hang around then.

1--3rd July is also fine for me. My tentative plan is to arrive on
Saturday and to spend a few more days in the UK after the hackathon, so
if you could find room for three people (me + wife + kid) between
Saturday and Thursday, that would be pretty great. (should it prove
difficult, I'm also happy to organise that myself...)

Cheers,

Niels


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

Re: NSBundle - supporting foreign bundles

[Niels Grewe]

On 22.05.2013 14:22CEST Chan Maxthon  wrote:

> Since you mentioned this, how about adopt current OS X bundle structure as 
> default GNUstep structure? The pro of this is that OS X bundle actually can 
> allow multiple platforms of binaries coexist in a single wrapper. OS X used 
> Contents/MacOS (and a fat Mach-O binary may reside in it) as the folder where 
> the binary exists, while GNUstep can use something like 
> Contents/GNUstep-i386-linux-gnu for i386 and 
> Contents/GNUstep-x86_64-linux-unknown for amd64 (as neither ELF for Linux nor 
> COFF/PE for Windows can do fat binaries). This will allow distributing a 
> single bundle with one copy of resources while supporting multiple platforms.

You can already do that with GNUstep if configure gnustep-make with 
"--disable-flattened --enable-multi-platform". I've successfully used that for 
quite some time to provide a shared GNUstep setup to i386 and amd64 machines on 
a network share.

Cheers,

Niels


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

Re: NSBundle - supporting foreign bundles

[Niels Grewe]

On 22.05.2013 14:38CEST Chan Maxthon  wrote:

> I mean not only cross compiling, but also constructing a single bundle with 
> one copy of all resources and numerous binaries for different platforms. It 
> is intended to work right out of the box on all systems that it is compiled 
> to.

Yes. That *is* what it does.
___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
https://lists.gnu.org/mailman/listinfo/gnustep-dev

Re: NSBundle - supporting foreign bundles

[Niels Grewe]

On 22.05.2013 14:44CEST Chan Maxthon  wrote:

> Including OS X? I mean I intend to compile a single bundle, with a single 
> copy of all resources, containing both OS X binaries linked against Apple's 
> Cocoa and friends, as well as Linux binaries linked against GNUstep.

Manually merging the Mac OS X specific parts into the GNUstep bundle and 
sprinkling some links on top might work, though I never tried that. Also you 
should keep in mind that this is only ever useful if you have tight control 
over all deployment environments, otherwise you're bound to end up in trouble 
because of mismatched library versions, etc.

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

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

[Niels Grewe]

On 29.05.2013 10:06CEST Philippe Roussel  wrote:

> Hi Niels,
> 
> On Wed, May 29, 2013 at 07:27:09AM +0000, 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?
 
> DKMethod.m:618:28: error: array index of '2' indexes past the end of an array 
> (that contains 2 elements) [-Werror,-Warray-bounds]
>NSAssert2((0 == strcmp(@encode(id), [sig methodReturnType])),
>~~~^~
> /usr/include/i386-linux-gnu/bits/string2.h:812:21: note: expanded from:
>: __strcmp_cg (s1, s2, __s1_len)) \
>   ^
> /usr/include/i386-linux-gnu/bits/string2.h:882:25: note: expanded from:
> (__const char *) (s1))[2] - __s2[2]);\
>   ^
> /opt/GNUstep-trunk/include/Foundation/NSException.h:454:20: note: expanded 
> from:
>_NSAssertArgs((condition), (desc), (arg1), (arg2))
>   ^
> /opt/GNUstep-trunk/include/Foundation/NSException.h:407:8: note: expanded 
> from:
>if (!(condition)) { \
>  ^
> DKMethod.m:618:28: error: array index of '3' indexes past the end of an array 
> (that contains 2 elements) [-Werror,-Warray-bounds]
>NSAssert2((0 == strcmp(@encode(id), [sig methodReturnType])),
>~~~^~
> /usr/include/i386-linux-gnu/bits/string2.h:812:21: note: expanded from:
>: __strcmp_cg (s1, s2, __s1_len)) \
>   ^
> /usr/include/i386-linux-gnu/bits/string2.h:885:27: note: expanded from:
>  (__const char *)  (s1))[3]  \
> ^
> /opt/GNUstep-trunk/include/Foundation/NSException.h:454:20: note: expanded 
> from:
>_NSAssertArgs((condition), (desc), (arg1), (arg2))
>   ^
> /opt/GNUstep-trunk/include/Foundation/NSException.h:407:8: note: expanded 
> from:
>if (!(condition)) { \
>  ^
> 5 errors generated.

Now that looks fundamentally weird. I've got no clue what's going on there. It 
works with clang trunk. Maybe a preprocessor bug that's been fixed? Could you 
check whether replacing NSAssert2 with a plain NSAssert fixes it? 

> Money can buy bandwidth, but latency is forever. John Mashey

:-)

PS: Getting gnustep-dev back into the loop. My mailinglist mojo has yet to 
arrive this morning...
___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
https://lists.gnu.org/mailman/listinfo/gnustep-dev

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

[Niels Grewe]

Am 29.05.2013 um 11:24 schrieb Philippe Roussel :

> On Wed, May 29, 2013 at 08:44:51AM +0000, Niels Grewe wrote:
>> 
>> On 29.05.2013 10:06CEST Philippe Roussel  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.

Mystery solved. It is detected correctly, but libclang from the 3.0 release is 
missing those functions. I'll add an explicit test for them and disable the 
libclang introspection generator if they're missing.

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

Re: GNUstep WebServices in iOS app?

[Niels Grewe]

Am 24.06.2013 um 17:11 schrieb David Wetzel :

> Hi,
> 
> did anybody use the GS WebServices in a iOS application?
> I would like to talk to a SOAP service from the iPhone without having to 
> write too much ugly code ;-)

Incidentally, yes. It's possible to use WebServices with a few tweaks to work 
around some features that Apple has removed from Foundation with respect to Mac 
OS/GNUstep. The problem is rather (and this is not legal advice, mind you) that 
you can only do static linking on iOS, so you're look right up to a conflict 
between the LGPL and the App Store ToS. 

Cheers,

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

Re: GNUstep WebServices in iOS app?

[Niels Grewe]

Am 24.06.2013 um 18:08 schrieb Doug Warren :

> While I'm not qualified to discuss licensing issues, iOS does support 
> frameworks and dylibs.  It's still bundled into the IPA however.

Yes, of course, iOS is perfectly capable of dynamic linking, but it's not 
exposed for developers to use. Xcode doesn't support creating iOS frameworks 
out of the box and I have been told that using your own (as opposed to 
system-provided) dynamic libraries will get you a rejection from the App Store. 
If that's not the case, please point me to the correct resource, because I'd be 
very much interested in that.

Cheers,

Niels


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

Re: GNUstep WebServices in iOS app?

[Niels Grewe]

Am 24.06.2013 um 18:32 schrieb Riccardo Mottola :

> And how about XML support? is it enough on iOS?

Pretty minimal. NSXMLParser is there, and so is the libxml2 as a C interface, 
but not NSXMLNode and friends. 

Cheers,

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

Re: GNUstep WebServices in iOS app?

[Niels Grewe]

Am 24.06.2013 um 20:25 schrieb Gregory Casamento 
mailto:greg.casame...@gmail.com>>:

GNUstep has NSXMLNode and friends.  Please check the latest release.

Sorry Greg, of course NSXMLNode is available on GNUstep, but Riccardo seemed to 
be asking about iOS. I'll try less brevity and more clarity next time...

Cheers,

Niels

On Monday, June 24, 2013, Niels Grewe wrote:

Am 24.06.2013 um 18:32 schrieb Riccardo Mottola 
>:

> And how about XML support? is it enough on iOS?

Pretty minimal. NSXMLParser is there, and so is the libxml2 as a C interface, 
but not NSXMLNode and friends.

Cheers,

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


--
Gregory Casamento
Open Logic Corporation, Principal Consultant
yahoo/skype: greg_casamento, aol: gjcasa
(240)274-9630 (Cell)
http://www.gnustep.org<http://www.gnustep.org/>
http://heronsperch.blogspot.com<http://heronsperch.blogspot.com/>

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

Re: GNUstep WebServices in iOS app?

[Niels Grewe]

Am 25.06.2013 um 11:30 schrieb Riccardo Mottola 
mailto:riccardo.mott...@libero.it>>:

My question was if the iOS foundation was enough to run GSWS.

The only problems with GSWS on iOS are the absence of the 
NSMapTable/NSHashTable function interface and NSCalendarDate, but that can be 
hacked around. I didn't use the SOAP coder when I played with it, though. But I 
don't think it uses NSXML either.

Cheers,

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

Re: NSUUID patch

[Niels Grewe]

Am 26.06.2013 um 08:31 schrieb Eric Wasylishen 
mailto:ewasylis...@gmail.com>>:

Here's a patch I'm working on that implements NSUUID using libuuid.

I'm having trouble figuring out what to put in the autoconf.ac.

Ah yes, the joyously frivolous enigma that is GNU autoconf ;-)

Does anyone know of a template I should look at?

I've looked at the configure.ac from base when I prepared the configure.ac for 
dbuskit, except for the more arcane stuff, the patterns are mostly the same 
everywhere.

I'm sure what I'm doing now isn't correct… :

+  HAVE_UUID=1
+  UUID_CFLAGS=`pkg-config --cflags uuid`
+  UUID_LIBS=`pkg-config --libs uuid`

I think it will have the right effect, but I'd replace the above three lines 
with the following:

if test $PKGCONFIG = yes; then
PKG_CHECK_MODULES(UUID, uuid, HAVE_UUID=1, HAVE_UUID=0)
else
# do AC_CHECK_HEADERS and AC_CHECK_LIBS stuff and set UUID_CFLAGS and UUID_LIBS 
manually
fi

+  CPPFLAGS="$CPPFLAGS $UUID_CFLAGS"
+  INCLUDE_FLAGS="$INCLUDE_FLAGS $UUID_CFLAGS"
+  LIBS="$UUID_LIBS $LIBS"
+  LDFLAGS="$LDFLAGS $UUID_LIBS"
+  LDIR_FLAGS="$LDIR_FLAGS $UUID_LIBS"

I'll also need to add a regular AC_CHECK_LIBS check if pkg-config isn't present.

I'd just adapt one of the existing AC_CHECK_HEADERS/AC_CHECK_LIBS checks from 
base.

Cheers,

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

Re: [PATCH] Fix DBusKit compilation

[Niels Grewe]

Hi Philippe,

Am 08.07.2013 um 12:47 schrieb 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.

Weird, but it doesn't hurt to add the include. I've applied it to trunk.

Thanks,

Niels

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

Re: int vs. void pointer

[Niels Grewe]

Am 05.01.2014 um 20:45 schrieb Riccardo Mottola :

> Hi,
> 
> in reference to:
> http://svn.gna.org/viewcvs/gnustep/libs/gui/trunk/Source/GSDisplayServer.m?r1=37026&r2=37533
> 
> is it correct to get an int and return it as a void* ? I get a warning there.
> I suppose int goes to void, not a pointer. perhaps the method shold accept a 
> void* as a win?

Fred already mentioned to me that I probably missed something when I added that 
method, I think I’ll be rolling it back soon.

Cheers,

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

Re: int vs. void pointer

[Niels Grewe]

Am 06.01.2014 um 14:02 schrieb Riccardo Mottola :

> Hi,
> 
> Niels Grewe wrote:
>> Am 05.01.2014 um 20:45 schrieb Riccardo Mottola :
>> 
>>> Hi,
>>> 
>>> in reference to:
>>> http://svn.gna.org/viewcvs/gnustep/libs/gui/trunk/Source/GSDisplayServer.m?r1=37026&r2=37533
>>> 
>>> is it correct to get an int and return it as a void* ? I get a warning 
>>> there.
>>> I suppose int goes to void, not a pointer. perhaps the method shold accept 
>>> a void* as a win?
>> Fred already mentioned to me that I probably missed something when I added 
>> that method, I think I’ll be rolling it back soon.
> Fred is always faster or keener than me :)
> 
> Anyway, no need to roll it back, in case just improve it. I was hinting the 
> same as Markus said, about different data-types which the warning was 
> exposing, but kept my question general.

No, rolling it back was quite the thing to do, I missed the fact that we 
already have a method that serves the same purpose. Actually, I quite agree 
about the dangers of mixing pointers and integers. In this case, however, the 
method (the actual one is -windowDevice:) takes the GNUstep window number as an 
argument and returns the backend dependent window representation, which in the 
case of X11 is a 32 bit integer, but some hypothetical backend could 
potentially use an arbitrary data structure. So using a void* return type and 
requiring the caller to cast it appropriately is probably the way to go.

Cheers,

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

Fwd: Intermediate Summary: Re: GNUstep.org website redesign proposal

[Niels Grewe]

(Sorry, forgot to CC the list)

Anfang der weitergeleiteten Nachricht:

> Von: Niels Grewe 
> Betreff: Re: Intermediate Summary: Re: GNUstep.org website redesign proposal
> Datum: 7. Januar 2014 13:00:12 MEZ
> An: David Chisnall 
> 
> 
> Am 07.01.2014 um 12:06 schrieb David Chisnall :
> 
>> On 7 Jan 2014, at 10:49, Richard Frith-Macdonald 
>>  wrote:
>> 
>>>> I read 'Objective-C 2' as 'we support the features Apple introduced in 
>>>> 2005!  Yay!'
>>> 
>>> You may be unusual in that.
>> 
>> Possibly, but the 2006 WWDC was the first and last time Apple referred to a 
>> set of new Objective-C features as Objective-C 2.  The term Objective-C 2 
>> does not appear in current Apple docs,
> 
> 
> That’s not quite true: Some of the documents still talk about something 
> called "Objective-C 2.0“, most notably the runtime programming guide:
> 
> https://developer.apple.com/library/mac/documentation/Cocoa/Conceptual/ObjCRuntimeGuide/Articles/ocrtVersionsPlatforms.html#//apple_ref/doc/uid/TP40008048-CH106-SW1
> 
> 
> But that doesn’t make the term any more intelligible. I think we should 
> prefer to use a concise description of the feature set over any marketing 
> mumbo jumbo. 
> 
> Cheers,
> 
> Niels


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

Re: [bug #41125] -make documentation is un-installable

[Niels Grewe]

Hi guys,

I think I finally get what Markus’ problem is. The question is rather not 
whether installing gnustep-make should implicitly install its documentation, 
the question rather is which configuration you expect the ./Documentation 
subdirectory to use. Markus expects it to use the configuration you just set 
using make’s configure script, while it in fact will use the configuration of 
the last installed version of gnustep-make. I don’t think there is a technical 
reason why we would require that behaviour, because gnustep-make is already 
configured and we know where things will be installed. In fact it’s very, very 
easy to switch the documentation to using the present (not yet installed) 
configuration: You just have to set GNUSTEP_MAKEFILES=../ at the beginning of 
Documentation/GNUmakefile.

Cheers,

Niels

Am 08.01.2014 um 06:21 schrieb Richard Frith-Macdonald 
:

> 
> On 7 Jan 2014, at 21:31, Markus Hitter  wrote:
> 
>> This prerequisite you talk about is a
>> showstopper in some environments and does not solve the problem. If
>> having showstoppers is the intention, I feel sorry for GNUstep.
> 
> Please, please, calm down and try to help me here;
> 
> I'm asking for information about what the problem.  Saying it's 'a 
> showstopper' means something to you, but it doesn't tell anyone else 
> anything.  We need to have it explained to us in what way it's an issue for 
> you.
> It does not seem reasonable for it to be a showstopper for anything (lots of 
> packages have dependencies, so there's no obvious reason why this should be 
> special), especially given the flexibility of location/configuratrion 
> available with the environment variables and config file... so you really 
> need to explain in some detail.
> 
>>> It can't install the documentation because, at this
>>> point you haven't configured/installed gnustep-make, so the eventual
>>> installation location is unknown.
>> 
>> It could, because at this point -make is actually configured, so the
>> installation location and layout is defined. But it ignores each of
>> --prefix, --with-layout and DESTDIR. That's what I'm talking about and
>> that's what the shell snippets demonstrate.
> 
> I see your point ...  you have run the configure script on gnustep-make, and 
> you expect the documentation package to use the configuration settings you 
> specified then.
> 
> But the documentation package is consistent with all other packages (so the 
> concept is simple ... you install gnustep-make and then everything else in 
> gnustep is built/installed using that) ... it uses your currently selected 
> gnustep-make installation to determine where to install things.
> 
> When you don't have a gnustep-make installation selected, it could guess that 
> it should build/install one based on the current config in the enclosing 
> directory,
> but it hasn't been told to do that and could well be doing the wrong thing if 
> it did ... given that you haven't installed gnustep-make it's a fair 
> assumption that you have not yet configured it as you want it.  You could add 
> support for some variation of this behavior, document it clearly (since it's 
> not the nmormal behavior), and perhaps make the build/install process prompt 
> the user to confirm that they really want to do it.
> 
>> 
 I have another ~15 bugs similar to this one stacked.
>>> 
>>> Well, [...]
>> 
>> Please scratch that. Very apparently it's much easier to fix the bug
>> than to explain somebody with commit privileges that the bug is actually
>> a bug, so I'll do this next time (and keep the patch in the packaging
>> patch stack).
> 
> Perhaps if you supplied patches it would be clearer what you are trying to 
> achieve (often the code clarifies the explanation as well as an explanation 
> clarifying code).
> It's a shame you don't feel willing/able to take time to explain the 
> problems; I feel sure that if you did so you would find that many have simple 
> solutions, or could at least come up with solutions consistent with behavior 
> elsewhere.  We do need to be able to understand more about what you need to 
> do in order to suggest ways that you can do it.
> 
> 
> 
> ___
> Gnustep-dev mailing list
> Gnustep-dev@gnu.org
> https://lists.gnu.org/mailman/listinfo/gnustep-dev


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

Re: Intermediate Summary: Re: GNUstep.org website redesign proposal

[Niels Grewe]

> Am 12.01.2014 um 00:06 schrieb "Riccardo Mottola" :
> 
> ARC instead is more a "taste". It is a new addition in the GC discussion. I 
> personally prefer ref-counting.

This seems to be a common misconception: ARC *is* reference counting; it has 
very little to do with garbage collection. I also think the new ownership model 
fits the overall language design pretty well: Just as you distinguish between 
method calls (object world) and function calls (C world) in traditional 
Objective-C, ARC-support enables you to explicitly distinguish between object 
references and references to untyped blobs of memory, which (coincidentally) 
allows the compiler to do most of the reference counting for you.

Cheers,

Niels



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

Re: Intermediate Summary: Re: GNUstep.org website redesign proposal

[Niels Grewe]

Am 13.01.2014 um 11:29 schrieb Wolfgang Lux :

> Niels Grewe wrote:
> 
>>> Am 12.01.2014 um 00:06 schrieb "Riccardo Mottola" :
>>> 
>>> ARC instead is more a "taste". It is a new addition in the GC discussion. I 
>>> personally prefer ref-counting.
>> 
>> This seems to be a common misconception: ARC *is* reference counting; it has 
>> very little to do with garbage collection.
> 
> Sorry for nitpicking, Niels.

Don’t be :-)

> ARC is indeed reference counting, but reference counting *is* one way of 
> performing garbage collection :-)

Very true, though reference counting alone has certain deficiencies as a 
garbage collection mechanism... So let’s say my point is that ARC doesn’t turn 
Objective-C into a language where you don’t have to care about memory 
management (which, I assume, is what people commonly understand when they hear 
the phrase ‘a garbage-collected language’).There’s no tracing, there’s no 
attempt made at detecting cyclic references, so you still have to think 
carefully about memory management.

Cheers,

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

Re: DBus Menu in Gtk theme

[Niels Grewe]

Hi guys,

Am 01.01.2014 um 21:09 schrieb Niels Grewe :

> Unfortunately, it’s not very useful at the moment, because I haven’t 
> implemented sending signals/notifications from DBusKit out to other D-Bus 
> objects. This is required to keep the menu server updated about the current 
> status of the menu, so by the time you start interacting with the menu, the 
> structure is out of date and ends up getting a bit messed up, so many of the 
> menu items won’t work properly.

Well, about this. I’ve implemented the signal stuff, and it turns out that not 
properly updating the menu wasn’t the entire problem. The other problem was 
that D-Bus has a type called ‘variant’, which basically means ‘whatever we 
agreed upon in some obscure comment in the interface description file that 
really should be backed by a proper specification’ 
The existing approach was to make an educated guess about what D-Bus type most 
closely matches the Objective-C type of the object you’re passing, and assume 
that the other side, e.g. promote integers to the larger type if required, etc. 
That was of course a bit fragile, and as it turns out, fails for a number of 
D-Bus implementations (for example the one used in libdbusmenu). As a result, I 
have extended DBusKit with an interface for explicitly indicating the type as 
which an object should be passed over the bus.
Using these changes, our D-Bus menu implementation is now working to the point 
where it is just as usable as  the native menu. It even passes icons along to 
the global menu. That’s so cool! The one remaining problem that I can’t figure 
out right now is that the menu is not being restored when you minimise and 
re-maximise the window. But I’m sure that we’ll figure that out eventually.

Another thing I’ve been thinking about is whether we’d want to propose an 
extension to the D-Bus menu interface that allows us to request a surface for 
drawing a custom view from an NSMenuItem (because that’s the one obviously 
unsupported functionality of our native menus). I’m not sure how that would 
work exactly, but I think Unity is already doing something similar for 
indicators. I would be grateful for any pointers on what would be required to 
make something like that work.

Cheers,

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

Re: DBus Menu in Gtk theme

[Niels Grewe]

Am 15.01.2014 um 20:55 schrieb David Chisnall :

> On 15 Jan 2014, at 11:34, Niels Grewe  wrote:
> 
>> Hi guys,
>> 
>> Am 01.01.2014 um 21:09 schrieb Niels Grewe :
>> 
>>> Unfortunately, it’s not very useful at the moment, because I haven’t 
>>> implemented sending signals/notifications from DBusKit out to other D-Bus 
>>> objects. This is required to keep the menu server updated about the current 
>>> status of the menu, so by the time you start interacting with the menu, the 
>>> structure is out of date and ends up getting a bit messed up, so many of 
>>> the menu items won’t work properly.
>> 
>> Well, about this. I’ve implemented the signal stuff, and it turns out that 
>> not properly updating the menu wasn’t the entire problem. The other problem 
>> was that D-Bus has a type called ‘variant’, which basically means ‘whatever 
>> we agreed upon in some obscure comment in the interface description file 
>> that really should be backed by a proper specification’ 
>> The existing approach was to make an educated guess about what D-Bus type 
>> most closely matches the Objective-C type of the object you’re passing, and 
>> assume that the other side, e.g. promote integers to the larger type if 
>> required, etc. That was of course a bit fragile, and as it turns out, fails 
>> for a number of D-Bus implementations (for example the one used in 
>> libdbusmenu). As a result, I have extended DBusKit with an interface for 
>> explicitly indicating the type as which an object should be passed over the 
>> bus.
>> Using these changes, our D-Bus menu implementation is now working to the 
>> point where it is just as usable as  the native menu. It even passes icons 
>> along to the global menu. That’s so cool! The one remaining problem that I 
>> can’t figure out right now is that the menu is not being restored when you 
>> minimise and re-maximise the window. But I’m sure that we’ll figure that out 
>> eventually.
> 
> That's really great!  I'd love to see the Ubuntu packages use this and the 
> GNOME theme by default, so GNUstep applications looked and felt like other 
> applications out of the box.

Yes, I imagine that would do wonders for public perception. I’ve just added 
code to the Gnome theme that loads the DBusMenu bundle if it is available and 
lets the menu server display the menu if it is available.

Cheers,

Niels


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

Re: corebase runloop integration

[Niels Grewe]

HI Luboš,

Am 04.02.2014 um 10:29 schrieb Luboš Doležel :

> You're right, libdispatch would be great for this. But what I fear is that as 
> soon as I start working in that direction, someone will come and either start 
> complaining about a libdispatch dependency or Clang requirement once I dare 
> to use a block. And the last thing I would do is to write one worse 
> implementation for GCC and one nice implementation for Clang.

The ability to invoke blocks doesn’t really commit you to using clang (-base 
has support code to invoke blocks when compiled with GCC) you only need it when 
you want to create blocks (does CFRunLoop need to do that? I think it might 
not…). So the question is rather whether we could rely on a compatible 
libBlocksRuntime being reasonably widespread (libdispatch usually isn’t the 
issue, but you need the version libBlocksRuntime that exports is symbols weakly 
so that libobjc2 can override them). In other words: I don’t think 
backwards-compatibility is as important for corebase as it is for -base.

I have one comment about the 
‘weakly-load-NSCFRunLoop-if-corebase-is-also-linked’ thing: I think it’s a good 
idea in general, but how would we handle cases where you start up without 
corebase, and during runtime you load a bundle that is linked against it? That 
might be a bit tricky to get right…

Cheers,

Niels

PS: Thanks a lot for working on corebase! I especially like having the CFStream 
stuff available...
___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
https://lists.gnu.org/mailman/listinfo/gnustep-dev

Fwd: DBusKit HelloWorldService Example

[Niels Grewe]

Sorry, forgot to CC the list...

Anfang der weitergeleiteten Nachricht:

> Von: Niels Grewe 
> Betreff: Aw: DBusKit HelloWorldService Example
> Datum: 5. April 2014 18:42:08 MESZ
> An: 
> 
> Hi Sven,
> 
> Am 01.04.2014 um 08:04 schrieb sv...@gmx.net:
> 
>> Hi List,
>> 
>> I am new to DBusKit and would like to fully understand it.
>> The HelloWorldService sample main.m includes these lines:
>> 
>>// WARNING: This is not a public API. Don't use it.
>>[p _setObject: obj atPath: @"/eu/numberfour/installer/p"];
>>id pProxy = [p _objectPathNodeAtPath: @"/eu/numberfour/installer/p"];
>>[pProxy _loadIntrospectionFromFile: @"N4InstallerService.xml"];
>> 
>> How should they be correctly written without private API usage?
>> I would like to understand the DBusKit but the provided documentation is too 
>> sketchy for me
> 
> Yes, the documentation on exporting objects is virtually nonexistent. It’s a 
> new feature for 0.2 and there will be documentation when that release is 
> ready. But as a short answer: The public API is not quite ready yet. The one 
> that you are supposed to be using in the future is -[NSConnection 
> setObject:atPath:]. You can already call that method right now, but the 
> automatic introspection loading mechanism is not completed yet, so you will 
> end up with a proxy that does not respond to any method invocations. The 
> introspection loader is supposed to do the following until it succeeds
> 
> 1. If implemented, call -introspectionDataForDBus on the object being proxied 
> and use that to construct the D-Bus interfaces.
> 2. From the bundle implementing the class, try to load a ${Class}.xml file 
> and use that to construct the interfaces if available. Also do the same for 
> any protocols implemented by the class.
> 3. Dynamically generate introspection data for all methods mentioned in the 
> GSPermittedMessages user default (this is also used by GSServicesManager)
> 
> Basically, the 2. is what you would usually do: You implement a FooService 
> class to be exported via D-Bus, and just stick a FooService.xml resource into 
> the app bundle and whenever you export such an object, it will just work. 
> Option 1. would be for when you need to customize the exported methods on the 
> fly and 3. is meant for quick prototyping of bus interfaces. I’ll keep you 
> updates as to when this is ready...
> 
> Cheers,
> 
> Niels


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

Re: Crashes in recent builds related to avahi client

[Niels Grewe]

Am 05.04.2014 um 18:59 schrieb Mathias Bauer :

> Hi Niels
> 
> Am 05.04.14 18:18, schrieb Niels Grewe:
>> Hi Mathias,
>> 
>> Am 04.04.2014 um 11:09 schrieb Mathias Bauer :
>> 
>>>> #0  0x74522f94 in objc_msgSend_fpret () from 
>>>> /usr/GNUstep/Local/Library/Libraries/libobjc.so.4.6
>>>> #1  0x7403c320 in -[GSAvahiNetService 
>>>> avahiResolver:foundServiceWithName:type:domain:hostName:address:port:txtRecord:ifIndex:protocol:]
>>>>  (self=0x19a1210, _cmd=0x744b51b0,
>>>>aResolver=0x1ae7c90, name=0x1ea6da0, type=0x1b1e290, domain=0x1c269a0, 
>>>> hostName=0x195bc20, address=0x1a90b00, port=33024, txtRecord=0x1e95940, 
>>>> anIfIndex=3, aProtocol=0)
>>>>at GSAvahiNetService.m:1509
>> 
>> I have no idea what could be wrong here. But one thing that strikes me as 
>> odd is the following: At line 1509, we are calling -[NSRecursiveLock 
>> unlock], which returns void, so I’m thinking that it shouldn’t really be 
>> going via objc_msgSend_fpret(), or should it?
> 
> I've got a similar response from Richard Frith-Macdonald, so yes, that's 
> weird. Probably memory corruption due to premature deallocation.

Could be. The method is called as part of a avahi callback and it does release 
some avahi resource as part of the processing. If that were holding the last 
reference to the object, it might cause us to be deallocated before the method 
has finished executing. I currently don’t see how it would (it’s been a while 
since I wrote that code, but I think usually the Obj-C objects own the avahi 
pointers, not the other way around), but it might be worth checking out whether 
commenting out the avahi_service_resolver_free() call makes the crash go away. 
Obviously, it’s no fix (the object would just leak), but it would give some 
indication of where to look next.

Cheers,

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

Re: Colours in user defaults

[Niels Grewe]

> Am 08.09.2015 um 08:33 schrieb Germán Arias :
> 
> After update base and gui there is a problems when store colours in user
> defaults. Gemas.app store the colours with something like: 
> 
> [defaults setObject: [NSKeyedArchiver archivedDataWithRootObject: color]
> forKey: @"EditorInsertionPointColor"];
> 
> but then the Gemas.plist become unusable and can't be used the next
> time. But this worked fine some days ago.
> 
> Germán

Richard made a few changes to property list (de)serialization recently. I 
hazard that this introduced a problem with (de)serializing NSData. Some of the 
tests fail with trunk:

--- Running tests in base/PropertyLists ---

base/PropertyLists/test01.m:
Failed test: test01.m:147 ... We can generate a property list from data
Failed test: test01.m:313 ... We can generate a property list from very 
simple data
Failed test: test01.m:317 ... We can generate a property list from very 
simple data (2)
Failed test: test01.m:322 ... We can generate a property list from an array 
containing very simple data
Failed test: test01.m:340 ... We can generate a property list from an array 
containing various things

127 Passed tests
  5 Failed tests


One or more tests failed.  None of them should have.
Please submit a patch to fix the problem or send a bug report to
the package maintainer.

The tests still pass if you go back to r38951 (before the base64 change for 
GNUstep plain-text property lists). Actually (and that might be unrelated to 
this bug. On my system, defaults are written in the XML format), I’m not really 
comfortable with changing the format this way. It’s fine to support the 
deserialization from base64 <[…]> in NSPropertyListGNUstepFormat, but for 
writing we should have designated a new version of the format (e.g. 
‘NSPropertyListGNUstepFormat_v1’), so that API consumers have to opt into the 
new behaviour explicitly. 

Cheers,

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

Re: Colours in user defaults

[Niels Grewe]

Should be fixed in gnustep-base. (The code was writing base64 encoded data to 
the beginning of the archive, not appending it as it should).

Cheers,

Niels

> Am 08.09.2015 um 08:59 schrieb Niels Grewe :
> 
> 
>> Am 08.09.2015 um 08:33 schrieb Germán Arias :
>> 
>> After update base and gui there is a problems when store colours in user
>> defaults. Gemas.app store the colours with something like: 
>> 
>> [defaults setObject: [NSKeyedArchiver archivedDataWithRootObject: color]
>>forKey: @"EditorInsertionPointColor"];
>> 
>> but then the Gemas.plist become unusable and can't be used the next
>> time. But this worked fine some days ago.
>> 
>> Germán
> 
> Richard made a few changes to property list (de)serialization recently. I 
> hazard that this introduced a problem with (de)serializing NSData. Some of 
> the tests fail with trunk:
> 
> --- Running tests in base/PropertyLists ---
> 
> base/PropertyLists/test01.m:
> Failed test: test01.m:147 ... We can generate a property list from data
> Failed test: test01.m:313 ... We can generate a property list from very 
> simple data
> Failed test: test01.m:317 ... We can generate a property list from very 
> simple data (2)
> Failed test: test01.m:322 ... We can generate a property list from an 
> array containing very simple data
> Failed test: test01.m:340 ... We can generate a property list from an 
> array containing various things
> 
>127 Passed tests
>  5 Failed tests
> 
> 
> One or more tests failed.  None of them should have.
> Please submit a patch to fix the problem or send a bug report to
> the package maintainer.
> 
> The tests still pass if you go back to r38951 (before the base64 change for 
> GNUstep plain-text property lists). Actually (and that might be unrelated to 
> this bug. On my system, defaults are written in the XML format), I’m not 
> really comfortable with changing the format this way. It’s fine to support 
> the deserialization from base64 <[…]> in NSPropertyListGNUstepFormat, but for 
> writing we should have designated a new version of the format (e.g. 
> ‘NSPropertyListGNUstepFormat_v1’), so that API consumers have to opt into the 
> new behaviour explicitly. 
> 
> Cheers,
> 
> Niels
> ___
> Gnustep-dev mailing list
> Gnustep-dev@gnu.org
> https://lists.gnu.org/mailman/listinfo/gnustep-dev

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

Re: Colours in user defaults

[Niels Grewe]

> Am 09.09.2015 um 10:03 schrieb Richard Frith-Macdonald 
> :
> 
> 
>> On 8 Sep 2015, at 08:15, Niels Grewe  wrote:
>> 
>> Should be fixed in gnustep-base. (The code was writing base64 encoded data 
>> to the beginning of the archive, not appending it as it should).
> 
> 
> Thanks for fixing that.
> I would have sworn that I had run the regression tests, so I don’t know how I 
> managed to commit the broken code.

It would be nice to have that done automatically. I think we used to have a 
jenkins instance that did that, but apparently it’s not available anymore. This 
is another aspect where moving the repositories to github would really help 
(you essentially get free access to the travis-ci build server).

Cheers,

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

Jumpstarting a GNUstep development environment using vagrant

[Niels Grewe]

HI guys,
 
some of you might have heard about vagrant [0], which is a tool for managing 
virtual machines. It’s quite useful especially if you are juggling multiple 
projects because it allows you to keep dependencies and build environments 
isolated in VMs while you can still use your familiar VCS/editor configuration 
on the host for coding via a directory that is shared between the host and the 
VM. 

Additionally, vagrant has the notion of a ‘box’: a pre-made virtual environment 
for a specific task. Using vagrant boxes, you can get up and running with a 
wordpress installation, an elasticsearch node, a CoreOS cluster, etc. within a 
matter of minutes because all you have to do is point vagrant at the box you 
want to use and have it download and launch it for you. That massively reduces 
the barrier of entry because you can just dip your toe in without learning the 
intricacies of a new build system and all that stuff. 

For that reason, I made it my holiday project to create a vagrant box that 
provides a GNUstep development environment and that has now actually reached a 
working state. So for the impatient: if you have vagrant, a supported 
hypervisor (currently that would be VirtualBox or VMware Fusion/Workstation), 
and an X server, you can get Gorm on your screen by just doing the following in 
an empty directory:

> vagrant init ngrewe/gnustep-gui
> vagrant up
> vagrant ssh -- -Y Gorm

(or just `vagrant ssh` to get a shell in the VM)

To provide a bit more detail, you will get the following with the box:

* a Debian 8.2 (jessie) base system 
* clang 3.7
* libobjc2 
* libdispatch
* gnustep-make
* gnustep-base
* gnustep-gui
* gnustep-back
* gorm

It’s configured to support all the modern Objective-C features (declared 
properties, non-fragile ABI, blocks, ARC). There is also a variant of the box 
called ngrewe/gnustep-headless that omits the GUI parts if you are looking to 
do some server side Objective-C development. I really hope that this is helpful 
for people who want to try out GNUstep.

The boxes themselves are built using packer [1] and I maintain the repository 
with the provisioning templates on github [2] if you want to have a closer look 
at how it works. The process of building the boxes is mostly automated, so I 
will do my best to update them on a regular basis.

There are a few things I’m looking at for the future:

* Slimming down the box: Currently the compressed boxes are close to 700MB, and 
about 2.3GB uncompressed, so I’m looking for things to remove to get he size 
down.
* Support for Parallels Desktop: The boxes already support both VirtualBox and 
VMware so most people should be able to use them, but at least as far as Mac OS 
hosts go, Parallels seems to be the third major desktop virtualisation 
provider. Both packer and vagrant support Parallels, so I would really like to 
add support for that as well. Unfortunately, I don’t have a license for the 
software, so I’m hoping that somebody might volunteer to add this provider…
* Additional layers/components: I’ve kept the list of things in the image 
fairly minimal for now. It might make sense to ship things like CoreFoundation, 
Opal, or DBusKit, though.

I’m also not really sure about the deployment story. I think vagrant boxes 
provide a pretty nice and consistent experience for developers, but for end 
users providing proper packages are probably much more useful. Still, packer 
provides a way to build docker images from the template as well, so I’m 
wondering how difficult it would be to containerize GNUstep apps for easy 
deployment?

Anyways, I encourage y’all to check this out, see how it fits your workflow, 
and report bugs and suggestions for improvements to me.

Cheers,

Niels 
--
[0] https://www.vagrantup.com
[1] https://www.packer.io
[2] https://github.com/ngrewe/gnustep-boxes

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

Re: abnormal thread termination

[Niels Grewe]

Hi Richard,

Sorry for resurrecting an essentially dead thread, but I’ve been using 
libdispatch a bit more lately, and stumbled onto this problem again, and it 
turns out that it’s not just some annoying warning. The present way of doing 
things does leak an NSThread object (and potentially file descriptors used by 
the runloop on that thread) whenever a thread exits that is not managed by 
NSThread.

> Am 13.07.2015 um 13:02 schrieb Richard Frith-Macdonald 
> :
> 
> 
>> On 13 Jul 2015, at 10:40, David Chisnall  wrote:
>> 
>> On 13 Jul 2015, at 10:32, Richard Frith-Macdonald 
>>  wrote:
>>> 
 
 On 13 Jul 2015, at 09:57, David Chisnall  
 wrote:
 
 On 10 Jul 2015, at 20:18, Riccardo Mottola  
 wrote:
> 
> Hi,
> 
> I detach a thread "normally" with:
> 
> [updateButton setEnabled:NO];
> [NSThread detachNewThreadSelector:@selector(updateData:) toTarget:self 
> withObject:nil];
> 
> It executes everything as expected, but I continuously get:
> WARNING thread 0x2c63c1a8 terminated without calling +exit!
> 
> I have done something similar with other threads and I don't get this 
> error. What could be happening? Some sort of premature exit? It executes 
> up to the last statement.
 
 This message also appears for threads that are not created with NSThread, 
 which is quite annoying.  I use some of the C++11 threading support for 
 some worker threads and I get a message when they exit.
>>> 

[…]

> We have a documented thread cleanup mechanism for a reason; it lets you write 
> portable code; which is what gnustep is for.
> 
> Pragmatically speaking, you can’t assume that methods you call won’t call 
> other methods/classes (so you can’t assume NSThread is not used).
> 
> We can fairly easily detect a thread which hasn’t been registered, and 
> automatically register it (which is what happens, though I think explicitly 
> registering is recommended as that lets you easily check to see if you 
> already registered the thread), but we can’t easily write portable thread 
> cleanup code which will work after a thread exits; something that works in 
> the exit handler under one pthreads implementation may not work under another.

Can you elaborate on these portability problems? I suppose there is some 
wriggle room in the pthreads specification, but the only piece of unspecified 
behaviour that seems related is the following: The spec does not tell you when 
the TLS key will be set to NULL  — is it before or after the destructor runs?  
I’ve tested this on Mac OS and a couple of glibc versions, and there 
pthread_getspecific() will no longer retrieve the value assigned to the TLS key 
once the destructor starts running. So in fact the pthread_setspecific() call 
at the end of unregisterActiveThread() is a no-op on these platforms, and some 
of the comments on how destructors are handled lead me to believe that that is 
the intended behaviour.

This of course breaks calling [NSThread currentThread] in observers that are 
being invoked for the NSThreadWillExitNotification,  but this seems to be the 
only problem with the exit handler (in particular, the pointer to the NSThread 
object will still be valid at this stage). I think there might be two ways to 
work around the [NSThread currentThread] issue:

1. According to the specifications, destructors will run up to 
PTHREAD_DESTRUCTOR_ITERATIONS  times (most systems default to 4 here). So you 
could just reassign the NSThread object to the TLS key before running the 
cleanup and set a flag so that you don’t do the cleanup again when the 
destructor runs the second time (instead just deallocating the object). Maybe 
you could even reuse the existing _active/_finished flags for that.
2. pthread_self() still returns the correct thread while the destructor runs, 
so you could populate a lookup table of threads currently undergoing cleanup, 
and use that in +currentThread to look up the NSThread object if you can’t get 
it via pthread_getspecific().

> So, we have an easy option … app developer calls the function to deregister 
> the thread before exiting from it

I don’t think that’s an easy option in every case. Of course it’s perfectly 
viable if you are managing threading yourself, but it’s quite suboptimal if you 
want to use an existing thread pool/work scheduling library such as libdispatch 
— or really just any C library that is multithreaded and requires you to use 
callbacks that include Objective-C code. You  essentially have to correctly 
guess implementation details of the library you are calling so that you can 
wrap things in GSRegisterCurrentThread()/GSUnregisterCurrentThread() calls as 
needed. 


> Or we have a hard option … someone figures out how to write portable code to 
> perform cleanup within the pthread exit handler
> 
> I’d be quite happy if someone wanted to contribute portable thread cleanup 
> code which would run safely on pthread_exit() of cour

Re: abnormal thread termination

[Niels Grewe]

> Am 15.01.2016 um 12:30 schrieb Richard Frith-Macdonald 
> :
> 
>> Can you elaborate on these portability problems? I suppose there is some 
>> wriggle room in the pthreads specification, but the only piece of 
>> unspecified behaviour that seems related is the following: The spec does not 
>> tell you when the TLS key will be set to NULL  — is it before or after the 
>> destructor runs?  I’ve tested this on Mac OS and a couple of glibc versions, 
>> and there pthread_getspecific() will no longer retrieve the value assigned 
>> to the TLS key once the destructor starts running. So in fact the 
>> pthread_setspecific() call at the end of unregisterActiveThread() is a no-op 
>> on these platforms, and some of the comments on how destructors are handled 
>> lead me to believe that that is the intended behaviour.
> 
> I think that’s exactly where we get variations.  Historically I’m sure 
> pthread_getspecific() has worked during thread exit on at least some systems 
> (though for all I know, modern systrems may have gravitated towards a single 
> common behaviour of having it return zero). 
> 
>> 2. pthread_self() still returns the correct thread while the destructor 
>> runs, so you could populate a lookup table of threads currently undergoing 
>> cleanup, and use that in +currentThread to look up the NSThread object if 
>> you can’t get it via pthread_getspecific().
> 
> That sounds ideal if (and I think we can probably assume it) either 
> pthread_getspecific() works or it returns zero.
> I’m not sure about a lookup table of just the threads undergoing cleanup 
> though (how would it be populated) …

I was thinking it could be done so that the entry is only present for the 
duration of the cleanup being done. So you’d insert it at the beginning of the 
destructor function, and remove it after the observers have run.

> it might need to be a table of all registered threads (with the cleanup 
> removing threads from the table).
> Of course that would mean we have the overhead of a global lock to protect 
> the table when registering and dregistering each thread, but that’s probably 
> not a big enough overhead to worry about.
> 
> So yes, that shoulds workable to me.

Great. I’ll look into it then!

Cheers,

Niels

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

Re: abnormal thread termination

[Niels Grewe]

Hi guys,


> Am 15.01.2016 um 13:12 schrieb Niels Grewe :
> 
>>> 2. pthread_self() still returns the correct thread while the destructor 
>>> runs, so you could populate a lookup table of threads currently undergoing 
>>> cleanup, and use that in +currentThread to look up the NSThread object if 
>>> you can’t get it via pthread_getspecific().
>> 
>> That sounds ideal if (and I think we can probably assume it) either 
>> pthread_getspecific() works or it returns zero.
>> I’m not sure about a lookup table of just the threads undergoing cleanup 
>> though (how would it be populated) …
> 
> I was thinking it could be done so that the entry is only present for the 
> duration of the cleanup being done. So you’d insert it at the beginning of 
> the destructor function, and remove it after the observers have run.

I’ve now implemented this and it turns out that it was necessary to do it this 
way. The reason is that pthread_t is an opaque type. It can be a simple scalar, 
a pointer, a struct, etc. That means if you can’t have a reasonable hash table 
for these: You have to do a linear search, calling pthread_equal() until you 
find the correct thread. So you want to keep the list as small as possible 
(i.e. only those thread concurrently undergoing cleanup). 

This is now in trunk and I’d like to invite people to test this on different 
platforms (especially on MinGW). This should only have an impact if you 
actually have threads where the NSThread object lingers in TLS on thread exit, 
that is if you have not called +exit or GSUnregisterCurrentThread(). There is a 
test case in Tests/base/NSThread, so you can just run gnustep-tests on that 
directory to see whether it’s working on your platform.

Thanks,

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

gnustep-base collection classes now support generics

[Niels Grewe]

Hi guys,

A while back Apple introduced support for lightweight (type-erasing) generics 
in Objective-C. In my opinion, this is a really nice feature because it 
increases (compile-time) type safety and makes API contracts much more 
explicit. Since there is nothing particular to Apple’s flavour of Objective-C 
in respect to this feature, GNUstep automatically gained support for it through 
clang. Still, the interfaces require updating to expose this to users and I’ve 
now gone through gnustep-base and updated the collection classes (NSArray, 
NSCache, NSDictionary, NSSet and their subclasses) to properly declare the 
generic types of their elements. 
This is a huge win in terms of portability for code originally built using the 
iOS 9 or MacOS X 10.11 SDKs: Previously if you had used generics annotations on 
a collection (which I think is the most common case), your code just wouldn’t 
compile with gnustep-base.
This change should be a no-op for users of gcc or older clang versions that 
lack the objc_generics feature. If it still breaks stuff for you, please shout 
at me loudly so that I can fix things ASAP. 

Cheers,

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

Re: gnustep-base collection classes now support generics

[Niels Grewe]

> Am 23.02.2016 um 10:14 schrieb David Chisnall :
> 
> Have you also looked at adding instancetype to the various places that expect 
> it and at the nullability attributes?  The latter is primarily intended for 
> Swift interop, but does make the static analyser results more useful (and can 
> generate better code in a few places, though not by much).

I have added backwards-compatibility definitions of instancetype (defined to id 
if unsupported by the compiler) and updated the collection classes I was going 
over anyways. This promptly caught two (albeit harmless) cases in base where an 
immutable object was assigned to a variable typed for the mutable subclass. 
Regarding nullability annotations, I've already added the macros for non-null 
audited sections, but I'm still a bit unsure about how to handle/define the 
nullability qualifiers, especially since there are now three variants of them 
(the double-underscore ones, the underscore-and-capitalised ones, and the 
contextual variants without underscores in method parameters). So yeah, it’s on 
my list. 

Cheers,

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

Re: GUI updates do not show even from separate thread

[Niels Grewe]

> Am 12.07.2016 um 13:47 schrieb Richard Frith-Macdonald 
> :
> 
> It also seems that -acceptInputInMode:beforreDate: should fire timers 
> (whether there is input available or not) ... but fixing that would be a 
> bigger change.

There are two failing test cases about that in trunk:

https://travis-ci.org/ngrewe/base/jobs/144390420#L1788

Is that a bona-fide failure or should it be marked as hopeful?

Cheers,

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

Re: GUI updates do not show even from separate thread

[Niels Grewe]

> Am 13.07.2016 um 10:41 schrieb Niels Grewe :
> 
> 
>> Am 12.07.2016 um 13:47 schrieb Richard Frith-Macdonald 
>> :
>> 
>> It also seems that -acceptInputInMode:beforreDate: should fire timers 
>> (whether there is input available or not) ... but fixing that would be a 
>> bigger change.
> 
> There are two failing test cases about that in trunk:
> 
> https://travis-ci.org/ngrewe/base/jobs/144390420#L1788
> 
> Is that a bona-fide failure or should it be marked as hopeful?

r39995 seems to have fixed that. Thanks!

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

[NSData initWithBytesNoCopy:length:deallocator:]

[Niels Grewe]

Hi guys,

I just implemented the -initWithBytesNoCopy:length:deallocator: initialiser for 
NSData and NSMutableData (this appeared in OS X 10.9). This takes a block as 
the last argument which allows you to customise how memory will be deallocated. 
This is very useful when you have a memory buffer whose lifetime is tied to 
some other resource that you want to discard once the NSData is no longer 
needed.

Unfortunately this required adding an ivar to hold the block, so there is a 
slight complication: To maintain strict binary compatibility, NSDataMalloc and 
NSMutableDataMalloc instances will deallocate themselves if called with this 
initialiser and return a new object of the correct subclass instead. This could 
be avoided if we added the block ivar to NSDataMalloc and NSMutableDataMalloc 
directly, but that’d break any consumers subclassing these classes (assuming 
the fragile ABI).

Now I am of the opinion that since NSData is a class cluster, nobody should 
have any business subclassing these anyways, but I wanted to solicit some input 
on the issue before making this kind of change: Would it be acceptable to make 
this a common ivar? Should we bump the minor version to indicate that this 
might be a breaking change or do we regard the internal organisation of the 
class cluster as an implementation detail that we can change on a whim?

Thanks,

Niels


signature.asc
Description: Message signed with OpenPGP using GPGMail
___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
https://lists.gnu.org/mailman/listinfo/gnustep-dev

Re: [NSData initWithBytesNoCopy:length:deallocator:]

[Niels Grewe]

> Am 27.07.2016 um 08:40 schrieb Richard Frith-Macdonald 
> :
> 
> 
>> On 27 Jul 2016, at 01:04, Niels Grewe  wrote:
>> 
>> Hi guys,
>> 
>> I just implemented the -initWithBytesNoCopy:length:deallocator: initialiser 
>> for NSData and NSMutableData (this appeared in OS X 10.9). This takes a 
>> block as the last argument which allows you to customise how memory will be 
>> deallocated. This is very useful when you have a memory buffer whose 
>> lifetime is tied to some other resource that you want to discard once the 
>> NSData is no longer needed.
>> 
>> Unfortunately this required adding an ivar to hold the block, so there is a 
>> slight complication: To maintain strict binary compatibility, NSDataMalloc 
>> and NSMutableDataMalloc instances will deallocate themselves if called with 
>> this initialiser and return a new object of the correct subclass instead. 
>> This could be avoided if we added the block ivar to NSDataMalloc and 
>> NSMutableDataMalloc directly, but that’d break any consumers subclassing 
>> these classes (assuming the fragile ABI).
>> 
>> Now I am of the opinion that since NSData is a class cluster, nobody should 
>> have any business subclassing these anyways, but I wanted to solicit some 
>> input on the issue before making this kind of change: Would it be acceptable 
>> to make this a common ivar? Should we bump the minor version to indicate 
>> that this might be a breaking change or do we regard the internal 
>> organisation of the class cluster as an implementation detail that we can 
>> change on a whim?
> 
> 
> The next release of base is planned to be 1.25.0 (I've already started 
> updating the news/release-notes to that effect in svn) since, as announced in 
> the last release, it will be removing GC support (and making other binrary 
> incompatible changes).
> There are already too many changes in trunk to realistically make another 
> bugfix release in the 1.29.? series from it.
> So up until we actually make the 1.25.0 release any binary incompatible 
> changes are fine in trunk.

Cool. I’ve made that change in r40038.

Thanks!

Niels


signature.asc
Description: Message signed with OpenPGP using GPGMail
___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
https://lists.gnu.org/mailman/listinfo/gnustep-dev

Re: libobjc2 fails to build with gcc 5.4.0

[Niels Grewe]

Yes, it seems that gcc and clang disagree on how to interpret const. Here's a 
PR that addresses this particular problem:

https://github.com/gnustep/libobjc2/pull/22

Cheers,

Niels

Von: i...@vucica.net
Gesendet: 2. April 2017 7:05 nachm.
An: thera...@sucs.org; gnustep-dev@gnu.org
Betreff: libobjc2 fails to build with gcc 5.4.0


Hey David,

It might be that libobjc2 no longer supports gcc, but in case it does, this is 
the result of building with Ubuntu 16.04's gcc 5.4.0:

[  1%] Building C object CMakeFiles/objc.dir/category_loader.c.o
/usr/bin/cc  -DGC_DEBUG -DGNUSTEP -DNO_LEGACY -DTYPE_DEPENDENT_DISPATCH 
-D__OBJC_RUNTIME_INTERNAL__=1 -Dobjc_EXPORTS  -std=gnu99  -fexceptions -fPIC   
-o CMakeFiles/objc.dir/category_loader.c.o   -c 
/home/ivucica/projects/libobjc2/category_loader.c
In file included from /home/ivucica/projects/libobjc2/dtable.h:3:0,
 from /home/ivucica/projects/libobjc2/category_loader.c:5:
/home/ivucica/projects/libobjc2/sarray2.h:26:35: error: initializer element is 
not constant
 static const uint32_t data_mask = data_size - 1;
   ^
/home/ivucica/projects/libobjc2/sarray2.h:55:8: error: variably modified 'data' 
at file scope
  void *data[data_size];
^
CMakeFiles/objc.dir/build.make:158: recipe for target 
'CMakeFiles/objc.dir/category_loader.c.o' failed
make[2]: *** [CMakeFiles/objc.dir/category_loader.c.o] Error 1
make[2]: Leaving directory '/home/ivucica/projects/libobjc2/build'


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

Re: libobjc2 fails to build with gcc 5.4.0

[Niels Grewe]

On 03.04.2017 13:06, David Chisnall wrote:

On 3 Apr 2017, at 11:51, Ivan Vučica  wrote:


5.4 is almost a year old, so maybe this was fixed. However, I'm not sure it 
would be so bad to have a workaround for this compiler?

There is already a warning that clang should be used (which I, of course, 
switched to; I prefer it anyway). But having a workaround to make it work with 
GCC, even in a basic, unsupported way, is probably still good?


As I said in the pull request, I’m hesitant to work around this for three 
reasons:

- It’s a bug in GCC
- The work-around code requires using macros and loses type safety
- A runtime compiled with GCC lacks a number of important features

I think simply removing support for building with GCC is probably a better idea.



As I said in the pull request, I don't have any interest in GCC as an 
Objective-C compiler anymore (hell, I haven't compiled a single line of 
Objective-C code using gcc this year…). But I think outright dropping 
GCC support is a bit harsh. You'd be turning up the heat a lot on 
existing users of libobjc2 in gcc-based environments [0]. It would also 
be a half-baked measure without removal of the legacy runtime API 
(objc_msg_lookup() and friends). My favoured approach would be 
deprecation of the old runtime API (and GCC support) in the next 
release, and removal in the release after that.


Cheers,

Niels

--
[0] Even if you're stuck with manual reference counting etc., libobjc2 
buys you a lot of good improvements, such as thread-safe +initialize…


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

Re: libobjc2 fails to build with gcc 5.4.0

[Niels Grewe]

Either way, there's a difference "effectively" deprecating something and giving 
explicit and timely warning about the fact that a certain environment will no 
longer be supported, is all I'm trying to say.

Cheers,

Niels

Von: thera...@sucs.org
Gesendet: 3. April 2017 8:51 nachm.
An: niels.gr...@halbordnung.de
Cc: i...@vucica.net; gnustep-dev@gnu.org
Betreff: Re: libobjc2 fails to build with gcc 5.4.0


On 3 Apr 2017, at 19:19, Niels Grewe  wrote:
>
> As I said in the pull request, I don't have any interest in GCC as an 
> Objective-C compiler anymore (hell, I haven't compiled a single line of 
> Objective-C code using gcc this year…). But I think outright dropping GCC 
> support is a bit harsh. You'd be turning up the heat a lot on existing users 
> of libobjc2 in gcc-based environments [0]. It would also be a half-baked 
> measure without removal of the legacy runtime API (objc_msg_lookup() and 
> friends). My favoured approach would be deprecation of the old runtime API 
> (and GCC support) in the next release, and removal in the release after that.

There’s big a difference between deprecating building the runtime with gcc and 
deprecating compiling other Objective-C code compiled with GCC and using the 
runtime.  I’m in no hurry to do the latter, but the former is effectively done 
already as it implicitly disables or breaks a load of features.

David

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

Re: Dbuskit release?

[Niels Grewe]

Yepp. That makes a lot of sense. There hasn't been a lot going in the last 
years, but there's still a ton of unreleased stuff related to notifications 
that clearly warrants a release (also, I've been doing a bit of cleanup 
recently, so now might be the perfect time).

I'll put something together this week!

Cheers,

Niels
Von: i...@vucica.net
Gesendet: 21. Mai 2017 6:19 nachm.
An: niels.gr...@halbordnung.de; gnustep-dev@gnu.org
Betreff: Dbuskit release?


Looks like people might be interested in a new release of dbuskit. Looks like 
the last one was in 2013. Should a new one be cut?

-- Forwarded message -
From: Ivan Vučica mailto:i...@vucica.net>>
Date: Sun, May 21, 2017, 17:17
Subject: Re: [Debian GNUstep maintainers] Bug#862396: newer version available
To: Gürkan Myczko mailto:gur...@phys.ethz.ch>>, 
<862...@bugs.debian.org>, The Debian GNUstep 
maintainers list 
mailto:pkg-gnustep-maintain...@lists.alioth.debian.org>>


Do note that the Github repo is just a mirror, and that the new upstream code 
is not a new proper release.

On Fri, May 12, 2017, 10:57 Gürkan Myczko 
mailto:gur...@phys.ethz.ch>> wrote:
Package: dbuskit
Version: 0.1.1-2
Severity: wishlist

There's a newer version of dbuskit available at:
https://github.com/gnustep/dbuskit

Yours,

___
Debian GNUstep maintainers mailing list
pkg-gnustep-maintain...@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-gnustep-maintainers
___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
https://lists.gnu.org/mailman/listinfo/gnustep-dev

Re: CI server on GitHub repos

[Niels Grewe]

This seems to be missing some visibility, but there are all ready working 
Travis CI jobs for base (both for the legacy runtime and libobjc2): 
https://travis-ci.org/gnustep/libs-base

Cheers,

Niels

Von: thera...@sucs.org
Gesendet: 26. Juni 2017 5:21 nachm.
An: bnm...@gmail.com
Cc: gnustep-dev@gnu.org
Betreff: Re: CI server on GitHub repos


On 26 Jun 2017, at 15:42, Daniel Ferreira (theiostream)  
wrote:
>
> True. I'll see if I can come up quickly with a CI setup for gcc 3.4.5,
> as Riccardo suggested -- we really don't need to go any older than
> that, right?
>
> I'll try this out with base for now, and it'll look something like:
> 1) GNU/Linux + gcc 3.4.5
> 2) GNU/Linux + gcc 6.x
> 3) GNU/Linux + clang 4.0
>
> With Docker it should be easy to set up a cross-compilation setup for
> MinGW as well later.
>
> I appreciate the setup ease of Travis plus its seamless integration
> with GitHub (don't know about GitLab), so in the long term I'd favor
> keeping whatever Travis supports in Travis and use a Jenkins setup for
> the hosts Travis doesn't support (FreeBSD and Solaris are the two I
> can think of, but there may be more).

I would very much doubt that there are any platforms with a gcc older than 4.2 
that we should spend our (very) limited resources caring about.  With regard to 
clang, it’s usually easy to install a newer one (even though FreeBSD 9 ships 
with 3.4 in the base system, it has 4.0 in packages).

David


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

Re: GNUstep Travis

[Niels Grewe]

On 23.02.20 10:44, Fred Kiefer wrote:
> Currently our build tests for GNUstep base and gut are broken. This render 
> the automatic validation of pull requests useless. I am rather sure that the 
> issue is again not in base but rather in changes build requirements of 
> libobjc2, caused by a change in GNUstep make or that strange linker problem 
> that everybody is seeing. 
> 
> 
> David and Niels could you please have a looking into this? The most important 
> information would be if the setup of the two failing cases is still possible 
> with current libobjc2. If not we should decide whether to drop these cases or 
> use an old version of libobjc2 for them.

This was inadvertently caused by the recent gnustep-make changes in
conjunction with that pesky linker issue. PR here:

https://github.com/gnustep/libs-base/pull/105

Cheers,

Niels

Re: Next GNUstep release

[Niels Grewe]

Hi Fred,

On 27.03.20 20:31, Fred Kiefer wrote:
> Hi Ivan,
> 
> is it OK to go ahead with the release as planed?
> I just provide short descriptions of the changes in gui and back in the
> news-texi files. Everybody that contributed in the last year should have
> a short look to see whether I missed something or improve the description.
> @Richard could you do the same for base? Or if you don't have the time I
> might do that as well, just tell me.
> @Niels could you handle "make"?

Of course! I also have a bit of documentation to update for the runtime
ABI related changes, but I'll surely find time to do it this weekend.

Cheers,

Niels

> I want to thank you all for the great contributions over the last year
> and hope we get these out really soon.
> 
> Cheers,
> Fred
> 
> 
> Am 28.02.20 um 00:37 schrieb Ivan Vučica:
>> On Tue, Feb 11, 2020 at 8:09 AM Fred Kiefer 
>> wrote:
>>> And most importantly, Ivan will you have time to cut all these
>>> releases? Of course we could move that point around a week or two
>>> if that date fits better
>>
>> I've only now seen this.
>>
>> This is ok and please coordinate with me closer to the release date.
>> It's nearly zero effort for me if maintainers keep up to date
>> Documentation/news.texi and other files you can see me updating by
>> hand just before release. Most time-consuming is a) sorting out
>> through 'what changed' and revising news.texi et al, b) getting the
>> GPG signing key to work, c) coordinating what version we should have
>> actually bumped to because we might break Debian automated checks
>> etc.
>>
>> I'm ok doing all these, but more I have to do, more planning do I
>> have to put into dedicating huge blocks of time to a release.
>>
>> (Note, having package maintainers and distro packaging maintainers
>> online -- preferably in a realtime groupchat e.g. on IRC -- when
>> cutting a release would not be a bad thing. This means we can sort
>> out and test any issues within hours rather than days.)
>>
>> On Thu, Feb 27, 2020 at 9:10 PM Riccardo Mottola
>>  wrote:
>>> before a release, I would like these issues to find a solution.
>>>
>>> - understand why we don't work properly on my ThinkPad T23 neither
>>> with the Cairo nor with the xlib backend with similar issues
>>
>> Did you date when things broke and at what change?
>>
>> I'm afraid that when I'm cutting a release I only use a single
>> platform (Ubuntu or Debian amd64 with libobjc2 and clang) with
>> usually one or two backend configs (usually cairo). Sometimes I build
>> with GCC or with GCC runtime. I don't have other environments around,
>> including a working environment on Windows.
>>
>> I don't know what should be release blockers, I'm leaving that to
>> individual package maintainers.
>>
>>> - understand/fix/workaround the libobjc2 which impede me to test
>>> current GNUstep on any FreeBSD 11.x and 12.x I currently have on
>>> i386 and amd64
>>
>> Honestly, I would have expected that libobjc2 FreeBSD should work
>> out of the box given David is/was working on FreeBSD...
>>
> 
> 

Re: Next GNUstep release

[Niels Grewe]

On 28.03.20 09:59, Niels Grewe wrote:
> Hi Fred,
> 
> On 27.03.20 20:31, Fred Kiefer wrote:
>> Hi Ivan,
>>
>> is it OK to go ahead with the release as planed?
>> I just provide short descriptions of the changes in gui and back in the
>> news-texi files. Everybody that contributed in the last year should have
>> a short look to see whether I missed something or improve the description.
>> @Richard could you do the same for base? Or if you don't have the time I
>> might do that as well, just tell me.
>> @Niels could you handle "make"?
> 
> Of course! I also have a bit of documentation to update for the runtime
> ABI related changes, but I'll surely find time to do it this weekend.

I've tied up a few loose ends and prepared the NEWS file for -make, so
the masters of the GPG keys may work their magic whenever they like.

Cheers,

Niels

Re: Attempting migration from travis-ci.org -> travis-ci.com

[Niels Grewe]

Hey folks,

I have no particular knowledge of the travis org/com migration thing. Back when 
I set upthe CI pipeline, travis-ci was one of the very few options available. 
Nowadays, I‘d definitely pick Azure Pipelines over travis-ci. But GitHub 
Actions might be worth looking at if a migration is inevitable. It‘s always 
shell scripts in a YAML sandwich anyways. 

Best,

Niels

--
Sent on the road

> Am 09.07.2021 um 10:29 schrieb David Chisnall :
> 
> On 08/07/2021 13:35, Gregory Casamento wrote:
>> I am seeing the following message when trying to migrate.   David, do you 
>> own these configs on travis?
> 
> 
> I don't think I own (or have ever touched) any of the Travis things. Niels 
> set this up.  For the runtime, I use Azure Pipelines for Windows / Linux / 
> macOS tests, Cirrus CI for FreeBSD.
> 
> David
>