[ANN] PyObjC for GNUstep

[David Chisnall]

Hi Everyone,

Are you worried that your Objective-C code is too fast? Too readable? Too maintainable? Well now you can fix that, by adding Python!

Attached is a diff against PyObjC that allows it to build with GNUstep[1]. This allows Python to use Objective-C objects, to subclass them, and to pass Python objects to Objective-C. There are still some bugs, but please try it, play with it, and see what breaks!

With PyObjC, it's trivial to export a Python interface for scripting your Objective-C code, so you can allow Python programmers to write plugins and so forth without needing to modify your Objective-C code.

This port was funded by Inverse: http://www.inverse.ca/.

David

[1] Tested with libobjc2 1.5, GNUstep-base and corebase from trunk on Linux/PowerPC and FreeBSD/x86.

[Fred Kiefer]

I am not interested in Python, but looked over your changes to see what
functionality is missing or different in GNUstep. One thing that I
noticed was that this code expects that result of a copy operation on an
NSMutableArray is a mutable array, and that on GNUstep you had to use
mutableCopy. If this is true we should change the GNustep behaviour and
add a test case for this.
Any other interesting stuff you found while working on this?

Fred

[Stefan Bidi]

On Thu, Jul 21, 2011 at 2:10 AM, Fred Kiefer <fredk...@gmx.de> wrote:

I am not interested in Python, but looked over your changes to see what functionality is missing or different in GNUstep. One thing that I noticed was that this code expects that result of a copy operation on an NSMutableArray is a mutable array, and that on GNUstep you had to use mutableCopy. If this is true we should change the GNustep behaviour and add a test case for this.
Any other interesting stuff you found while working on this?

That's probably because NS(Mutable)Array objects in Cocoa are actually NSCFArray objects (due to the toll-free bridging mechanism), which can be either mutable or immutable.

I'd be interested to know if this is true about all toll-free bridged classes.  The NSCFString class in corebase inherits from NSMutableString, however, CFStringCreateCopy(), for example, is called, will create an immutable version of CFString.  Only a call to CFStringCreateMutableCopy() creates a mutable version.
 
Stef

On 20.07.2011 19:15, David Chisnall wrote:

Hi Everyone,

Are you worried that your Objective-C code is too fast?  Too readable?  Too maintainable?  Well now you can fix that, by adding Python!

Attached is a diff against PyObjC that allows it to build with GNUstep[1].  This allows Python to use Objective-C objects, to subclass them, and to pass Python objects to Objective-C.  There are still some bugs, but please try it, play with it, and see what breaks!

With PyObjC, it's trivial to export a Python interface for scripting your Objective-C code, so you can allow Python programmers to write plugins and so forth without needing to modify your Objective-C code.

This port was funded by Inverse: http://www.inverse.ca/.

David

[1] Tested with libobjc2 1.5, GNUstep-base and corebase from trunk on Linux/PowerPC and FreeBSD/x86.

_______________________________________________
Discuss-gnustep mailing list
Discuss...@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnustep

[David Chisnall]

On 21 Jul 2011, at 13:13, Stefan Bidi wrote:

> On Thu, Jul 21, 2011 at 2:10 AM, Fred Kiefer <fredk...@gmx.de> wrote:
>> I am not interested in Python, but looked over your changes to see what functionality is missing or different in GNUstep. One thing that I noticed was that this code expects that result of a copy operation on an NSMutableArray is a mutable array, and that on GNUstep you had to use mutableCopy. If this is true we should change the GNustep behaviour and add a test case for this.
>> Any other interesting stuff you found while working on this?
>
> That's probably because NS(Mutable)Array objects in Cocoa are actually NSCFArray objects (due to the toll-free bridging mechanism), which can be either mutable or immutable.

I just tested it, and the GNUstep behaviour is correct. [NSMutableArray -copy] does return an immutable array:

NSMutableArray *a = [NSMutableArray new];
id b = [a copy];
[b addObject: @"foo"];

This terminates with an exception:

2011-07-21 13:17:19.940 a.out[15566:903] *** Terminating app due to uncaught exception 'NSInternalInconsistencyException', reason: '*** -[NSCFArray insertObject:atIndex:]: mutating method sent to immutable object'

So, it's probably one of the many bits in the PyObjC code that didn't work on GNUstep because it was Just Plain Wrong™ and shouldn't work on OS X either.

David

[Ivan Vučica]

Hi David,

that's great! Will this be submitted upstream?

On Wed, Jul 20, 2011 at 19:15, David Chisnall <ther...@sucs.org> wrote:

Hi Everyone,

Are you worried that your Objective-C code is too fast?  Too readable?  Too maintainable?  Well now you can fix that, by adding Python!

Attached is a diff against PyObjC that allows it to build with GNUstep[1].  This allows Python to use Objective-C objects, to subclass them, and to pass Python objects to Objective-C.  There are still some bugs, but please try it, play with it, and see what breaks!

With PyObjC, it's trivial to export a Python interface for scripting your Objective-C code, so you can allow Python programmers to write plugins and so forth without needing to modify your Objective-C code.

This port was funded by Inverse: http://www.inverse.ca/.

David

[1] Tested with libobjc2 1.5, GNUstep-base and corebase from trunk on Linux/PowerPC and FreeBSD/x86.





_______________________________________________
Discuss-gnustep mailing list
Discuss...@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnustep

--
Ivan Vučica - iv...@vucica.net

[David Chisnall]

On 21 Jul 2011, at 14:04, Ivan Vučica wrote:

> Hi David,
>
> that's great! Will this be submitted upstream?

Ask Ludovic. I'm not sure if the plan is to merge it or for Inverse to maintain a GNUstep branch of PyObjC. I'd imagine the latter in the short term and the former in the longer term.

David

[Ludovic Marcotte]

That patch should indeed be submitted upstream.

Ludo

[Gerold Rupprecht]

Hi Ludovic,

Thanks for your contribution to GNUstep. It has been a long time since I
have seen you on the list.

Is there any chance of seeing GNUMail being updated to the latest
GNUstep?

Thanks,

Gerold

> _______________________________________________
> Discuss-gnustep mailing list
> Discuss...@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnustep

--
Gerold Rupprecht <ger...@bluewin.ch>
10, rue Louis-Curval
CH-1206 Genève, Suisse
Mobile: +41 (0) 79 914 29 52

[Gregory Casamento]

Hey guys,

I had heard that the PyObjC runtime was used by the guys who did rubycocoa.  I'm wondering if this might serve as a basis for getting ruby working with GNUstep.  

GC

2011/7/21 Ludovic Marcotte <lud...@sophos.ca>

On 21/07/11 09:07, David Chisnall wrote:

On 21 Jul 2011, at 14:04, Ivan Vučica wrote:

Hi David,

that's great! Will this be submitted upstream?

Ask Ludovic.  I'm not sure if the plan is to merge it or for Inverse to maintain a GNUstep branch of PyObjC.  I'd imagine the latter in the short term and the former in the longer term.

That patch should indeed be submitted upstream.

Ludo

_______________________________________________
Discuss-gnustep mailing list
Discuss...@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnustep

--
Gregory Casamento - GNUstep Lead/Principal Consultant, OLC, Inc.
yahoo/skype: greg_casamento, aol: gjcasa
(240)274-9630 (Cell)

[Sebastian Reitenbach]

Hi Ludovic,

On Thursday, July 21, 2011 17:48 CEST, Gerold Rupprecht <ger...@bluewin.ch> wrote:

> Hi Ludovic,
>
> Thanks for your contribution to GNUstep. It has been a long time since I
> have seen you on the list.
>
> Is there any chance of seeing GNUMail being updated to the latest
> GNUstep?

In case of GNUmail, and Pantomime, I have a couple of patches in the OpenBSD ports tree, that make GNUmail work fairly well. You can find the patches here:

http://www.openbsd.org/cgi-bin/cvsweb/ports/x11/gnustep/pantomime/patches/
http://www.openbsd.org/cgi-bin/cvsweb/ports/x11/gnustep/gnumail/patches/

I'd also love to see new releases of both, to get rid of all the patches from the ports tree. Since the last release was looong time ago, I did not bothered you regarding a new release. But now, I take the opportunity ;)

cheers,
Sebastian

>
> Thanks,
>
> Gerold
>
> On Thu, 2011-07-21 at 10:02 -0400, Ludovic Marcotte wrote:

> > On 21/07/11 09:07, David Chisnall wrote:
> > > On 21 Jul 2011, at 14:04, Ivan Vučica wrote:
> > >
> > >> Hi David,
> > >>
> > >> that's great! Will this be submitted upstream?
> > > Ask Ludovic. I'm not sure if the plan is to merge it or for Inverse to maintain a GNUstep branch of PyObjC. I'd imagine the latter in the short term and the former in the longer term.
> > That patch should indeed be submitted upstream.
> >
> > Ludo
> >
> > _______________________________________________
> > Discuss-gnustep mailing list
> > Discuss...@gnu.org
> > https://lists.gnu.org/mailman/listinfo/discuss-gnustep
>
>
> --

[Jens Ayton]

On Jul 21, 2011, at 17:09, Gregory Casamento wrote:
>
> I had heard that the PyObjC runtime was used by the guys who did rubycocoa. I'm wondering if this might serve as a basis for getting ruby working with GNUstep.

I don't know of any such link, but I haven't looked hard. In any case, RubyCocoa is effectively abandoned in favour of the more sophisticated MacRuby; the RubyCocoa project hasn't seen any activity for a couple of years, and it's no longer supported in Xcode. Given that MacRuby has syntax enhancements for better integration and is being actively developed, it would be a better target.

--
Jens Ayton

[Ludovic Marcotte]

On 21/07/11 11:48, Gerold Rupprecht wrote:
> Thanks for your contribution to GNUstep. It has been a long time since I
> have seen you on the list.
>
> Is there any chance of seeing GNUMail being updated to the latest
> GNUstep?

I'm unfortunately too busy with SOGo (www.sogo.nu) and PacketFence
(www.packetfence.org) right now.

We eventually want to use Pantomime in SOGo too - when that will happen,
I will probably personally start working again on GNUMail.

Thanks,

[Germán Arias]

Hi Ludovic, currently I'm trying to get GNUMail with the latest gnustep
packages. For that reason I have a copy of GNUMail at "GNUstep Non FSF"
in GNA. I sent you a email about this, but no reply. If I achieve this,
I suppose there isn't problem to release an unofficial package, right?
At least while you back to work on it.

[Ludovic Marcotte]

On 21/07/11 19:53, Germán Arias wrote:
> Hi Ludovic, currently I'm trying to get GNUMail with the latest gnustep
> packages. For that reason I have a copy of GNUMail at "GNUstep Non FSF"
> in GNA. I sent you a email about this, but no reply.

When? I looked at all mails received from you and I see nothing about
that - anyway...

> If I achieve this,
> I suppose there isn't problem to release an unofficial package, right?
> At least while you back to work on it.

Yeah, no problem with this. As long as you maintain some patches you
developed to get things working and you send those to me for inclusion.

Regards,

[Ludovic Marcotte]

On 20/07/11 13:15, David Chisnall wrote:
> [1] Tested with libobjc2 1.5, GNUstep-base and corebase from trunk on Linux/PowerPC and FreeBSD/x86.

After more work with David, here's an updated version that compiles with
gcc's runtimes (< 4.6 and >= 4.6).

There's a bug with the gcc 4.6 runtime since objc_getSuperClass() on a
newly allocated - but not registered - class returns nil. Some tests
will fail due to this.

There's also some bugs with the gcc runtimes, prior to 4.6 - probably
due to missing features.

In any case, here's the updated patch.

Regards,

[Matt Rice]

Thanks, is there a msg_send_compat.h which was supposed to be included
with this patch?

[Ludovic Marcotte]

On 28/08/11 12:23, Matt Rice wrote:
> Thanks, is there a msg_send_compat.h which was supposed to be included
> with this patch?

Indeed, here is the file. All tests were done with revision #2606.

I also have a complete example that I could send which shows SOGo
(www.sogo.nu) instantiating and class and invoking a method which is
provided by a Python script (class definition and the implementation of
that method).

Regards,

[Matt Rice]

Thanks, unfortunately required some modifications,
apparently my constructor call order here is the opposite
of yours,

sure would be nice if +load would accept the constructor attribute
priority, or a gcc option to set the default priority at compile time.

# Load order is important here. Linking -corebase after -base causes a
# crash trying to register for a notification with a string that is not yet
# initialized.
OBJC_LDFLAGS = str(subprocess.Popen(["gnustep-config",
"--base-libs"], stdout=subprocess.PIPE).communicate()[0]).split()
OBJC_LDFLAGS.extend(["-lgnustep-corebase"])

[Fred Kiefer]

On 29.08.2011 22:05, Ludovic Marcotte wrote:
> On 28/08/11 12:23, Matt Rice wrote:
>> Thanks, is there a msg_send_compat.h which was supposed to be included
>> with this patch?
> Indeed, here is the file. All tests were done with revision #2606.
>
> I also have a complete example that I could send which shows SOGo
> (www.sogo.nu) instantiating and class and invoking a method which is
> provided by a Python script (class definition and the implementation of
> that method).

Shouldn't this line:

#define objc_impMsgSendPtr ((IMP(*)(id,SEL,SEL))objc_msgSendSuper)

read something like this:

#define objc_impMsgSendSuperPtr ((IMP(*)(id,SEL,SEL))objc_msgSendSuper)

[luke.l...@gmail.com]

On Wednesday, July 20, 2011 at 6:15:45 PM UTC+1, David Chisnall wrote:
> Hi Everyone,
>
> Are you worried that your Objective-C code is too fast? Too readable? Too maintainable? Well now you can fix that, by adding Python!

david, hi,

i appreciate that this is *eight* years ago :)

you may be aware of the correlation between microsoft's runaway success and
its use of DCOM, and likewise apple's success and its use of Objective-{C/J/M}.

software libre has *systematically* failed - for two decades - to recognise the
strategic and fundamental importance of these dynamic runtime introspection
methods.

Mozilla for example funded "XPCOM" (implemented in XULRunner) however due to
their failure to understand co-classes, XPCOM releases systematically and
persistently were forced to publish a *different* UUID for any changes to
the APIs, driving third party c++ and java XUL developers with every release
into fits of rage for over fifteen years. Even ActiveState, a long-time
supporter and user of Mozilla Technology, eventually abandoned XUL in favour
of webkit.

boost - and likewise python-boost - is also driving people nuts due to its
massive instability and incompatibility. i have no less than *six* versions
presently installed on my laptop (1.49, 1.54, 1.55, 1.58, 1.62 and 1.67)

$ dpkg -l | grep boost | wc
102

question.

if there was a way to fund the updating and upstreaming of these patches
with up to EUR 50,000, would you (or anyone else) be interested to bring
them back and make sure that they stay up-to-date?

i have a project (coriolis2) that our team is critically dependent on, and
it required a *home-grown* dynamic c++ to python co-class converter to be
written (and maintained) by its developer, just to deal with the fact that
software libre simply categorically and systematically fails to understand
quite how powerful systems like GNUStep and the Objective- family of
languages really are.

best,

l.

[Ivan Vučica]

Luke,

I don't know if you'll see this message, but note that as a subscriber to disucss-gnustep@, I did not receive your message in my inbox.