Re: Minimalist GNUstep possible?

[Jonathan Wolf]

Thanks again for the great info - and yes, you are correct, it's
NSInvocation. I only commented on libffi because I remember from a
while back having to manually grab this one (apologies about the
"rogue" comment in that regard - was just relating to my previous
experiences - no offense intended :p). My bigger point was just that
it worries me to see too many dependencies in any one package. Trying
to ensure that the binaries are available on a fresh target system
(and fresh means literally no dev environment at all) is always kind
of an issue - previous experience with, for instance the .NET
redistributable packages, have been hugely important for the
distribution of prior projects I've been involved in.

However, I have also been involved in certain development efforts
where the solution to almost every issue is another external
dependency (for reasons X, Y, Z, all good on their own save nothing
about the added cost of maintaining the binary through to
distribution, doing occasional updates (and maintaining code changes,
if any), etc.). I've got burned pretty badly from that experience, and
to this day have a subtle fear of overuse in dependencies. In relation
to GNUstep, libffi scared me when I had to grab it manually (this was
on a SUSE 11.1 box though - Ubuntu has been a lot nicer (and accurate)
about GNUstep integration), so my apologies if my fear was in any way
misplaced.

On the side of AppKit, we have minimal to no dependency at all on it,
although we were attempting to (and will again attempt to later down
the road) have a native AppKit built tool used to interact with our
toolset itself (just for testing mainly though - ensuring that outputs
on other export scripts have desired effects on import to the same of
that on the iPhone/Android itself (without requirement to do an actual
testing build on that end)). The majority of our display systems work
with OpenGL natively/directly with custom built GL-based widgets (just
basic ones - nothing too fancy), but the toolset does work with
NSFoundation in a variety of ways (and NSInvocation has certainly been
a big bonus to a few key architecture points, as well as just ObjC in
general).

I will need to check out MySTEP on your advice then. I am getting to
be more aware of what you mean by Android's square wheel
implementation the more I dig into it, but tbh, even with the issues
on the development end, iPhone's staunch policies have become a major
source of frustration to the point that the more open market nature of
the Android is becoming quite appealing. But after having used ObjC
for almost a year and a half now, I just can't put it down anytime
soon for (as you correctly put it) the slow VM. I apologize if I sound
like I am trying to turn this discussion into an Apple bashing - I
actually have a great deal of love for Apple's products - it's just
that our marketing differentiation relies heavily on being able to
push boundaries that are not so PC (the reverse of it, actually).
Apple doesn't like that so much.

As far as weight - I apologize if my original comments were misleading
one to thinking we were trying to reduce the memory footprint of code
- far from it. We use many megabytes of multimedia alone, so having a
few more hundred k worth of program code is a drop in the bucket at
best. As well, even with the slower dy method invocation in ObjC,
we've found great successes in caching the IMP pointers and calling
through them (in the lower code tier sections improving FPS by 5-10).
The only real thing I wish ObjC had was true static method invocation,
for instances where you know precisely that the object will always be
of one kind in all forms.


Thanks everybody again for the great help - it is greatly appreciated.
I'll be sure to stand up and put in a few good words about GNUstep
whenever I hear people knocking it.

On Fri, Jun 18, 2010 at 5:33 AM, David Chisnall <address@hidden> wrote:
> On 18 Jun 2010, at 10:16, Jonathan Wolf wrote:
>
>> I went back and did some more toying around and got exactly what I was
>> needing to get (at least on a nix box). I have yet to go try this on a
>> MinGW/Windows system, but I have high hopes that it should work pretty
>> much the same (hopefully!).
>>
>> We do want to target all three primary OS'es (major nix flavors, mac,
>> and windows), so having a toolset be cross platform like this is a
>> major boost (plus ObjC is awesome). Has anybody seen any luck with
>> using GNUstep as a .dll over on this sort of setup?
>
> I've not used Windows for some years, but I recall reading on the wiki that 
> there was a tool for producing a stand-alone Windows installer that packages 
> the GNUstep dlls and everything else that you need.  Gregory is probably the 
> best person to answer this - he's been doing a lot of work on Windows 
> recently.
>
>> One thing in particular that we're going to deal with, almost
>> assuredly, is that the user may not have a few of the libs installed
>> (ldd listed a decent number of linked libraries, including some rogue
>> ones like libffi (fast function interface if I remember from the
>> GNUstep documentation)).
>
> Foreign, not fast.  You said in your original email that you needed 
> NSInvocation, so this is not a rogue dependency, this is one that you 
> actually need (Well, actually you said NSMethodInvocation, but such a class 
> does not exist).  FFI is used by GNUstep to implement the callback that the 
> runtime uses for message forwarding.  It is needed to construct NSInvocation 
> instances, so if you use -forwardInvocation: anywhere, then you need to use 
> it.
>
> You can remove things like libxml2 as dependencies with some configure flags 
> (./configure --help to list all of them).
>
>> Is there any way, aside from scripting it out
>> in an installation script, to use a redistributable package (perhaps
>> similar to the .NET redistributables), or do people really need a full
>> installation of GNUstep for it to work? I'm not the best on dynamic
>> linkage, but is having a copy of the .so/.dll in the same folder as
>> the executable "good enough" (hopefully not breaking LGPL rules)?
>
> Yup, that should be fine for Windows.  If you're using AppKit then you 
> probably also want to bundle the UXTHEME bundle so that the app looks and 
> behaves more like a native app (native Windows menus and buttons, native 
> colour scheme, and so on).  If you're not, then you can probably get away 
> with just the gnustep-base.dll and its dependencies (libobjc.dll, not sure 
> what else).
>
>> As a side question that I am sure to be interested in moving into the
>> future, is GNUstep planning on supporting mobile architectures, say
>> like Android? I would really love to keep using a compiled language
>> (like ObjC) on such a platform and be able to take our tools with us
>> onto that end, if we ever go there. Has anybody heard of any luck with
>> any developers going this route? I did notice that there was some work
>> being done on incorporating ObjC into Android, but I'm sure somewhere
>> along that path GNUstep is going to be one of the major players.
>
> I'm not sure about Android specifically, because it uses its 
> lets-reinvent-the-wheel-and-make-it-square windowing system and doesn't seem 
> to like people not living inside their slow VM.  Mobiles like the N900 are 
> definitely of interest to us.  Supporting Android will probably be easier 
> once Cairo has been ported, otherwise we'd have to port the back end to use 
> Skia natively, which is a lot of effort.  For a minimal port, we should be 
> able to use Cairo's OpenGL or image back ends and just write the event 
> handling code (which is nontrivial, but not a huge amount of work).
>
> You might like to look at MySTEP, which is a friendly fork of GNUstep that 
> aims to target mobile devices.  Where design decisions require optimising for 
> either desktop or mobile use, GNUstep went one way and MySTEP went the other 
> way.  I'm not sure how relevant it is now - modern handhelds are more 
> powerful (in terms of RAM, CPU, and GPU power) than desktops were when MySTEP 
> was forked, but it's still pretty lightweight.
>
> Over the summer, we have a GSoC student finishing up our CoreGraphics 
> implementation, providing the core that we'd need for implementing more of 
> the iPhone APIs.  We'd like to start working on a UIKit implementation later 
> in the year, so if your company would be interested in partially funding, or 
> contributing some code to, that effort then let us know.  A lot of the 
> existing code in GNUstep's AppKit implementation can be used in UIKit, but 
> some things will need extending or rewriting.
>
> David