Mac OS X and GemStone users

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

Mac OS X and GemStone users

Eli Green-5
Hi everybody,

I've been lurking for a while now and obsessively working on this in
what spare time I can find. It's a project to integrate Objective-C
with GemStone in as transparent a manner as possible. The end result
is supposed to be binding-enabled (minimal code) OS X user interfaces
with GemStone models as the persistent data store.

Some sample code to try and show what I'm talking about (from a test
case) is here:

NSMutableArray * obj = [con execute:@"OrderedCollection new add: 1;
add: 2; add: 3; add: 'test'; yourself"];
GHAssertEqualObjects([obj objectAtIndex:0], [NSNumber
numberWithInteger:1], @"");
GHAssertEqualObjects([obj objectAtIndex:1], [NSNumber
numberWithInteger:2], @"");
GHAssertEqualObjects([obj objectAtIndex:2], [NSNumber
numberWithInteger:3], @"");
GHAssertEqualObjects([obj objectAtIndex:3], @"test", @"");

Notice that Collection classes are automatically wrapped in a special
version of the proxy class which emulates NSMutableArray (or
NSMutableDictionary). It should not be necessary to create NSNumber
classes manually, as the Objective-C runtime is smart enough to tell
us when we receive an integer or char * or other. It would be a simple
matter to convert those to objects before sending them to the GemStone
server.

I haven't opened the repository up to the world yet because I haven't
looked into the licensing issues but I wanted to gauge interest in the
project and see if anybody was interested in it (including possibly
the GemStone folks themselves).

Because the repository is private, bitbucket won't let me give people
access to binaries or the wiki, so I've put up a single pre-built
binary of my barely-functional browser here:

http://sites.google.com/site/gskitdownloads/home

I'm sure this currently breaks in all sorts of interesting ways so if
you want to e-mail me on or off the list, I'd be happy to help people
get it working.

If the GEMSTONE environment variable is not set, it will assume
"/opt/gemstone/product". When I want to connect, I run GemStone/S
with:

startnet && startstone

Then in the login window, I put this in the Stone field:
!tcp@localhost#server!gs64stone

This should connect and pull up a browser window. There's a transcript
that doesn't work properly yet, although you can "Do It" and "Print
It" and "Inspect It" (the inspector isn't working either!) on selected
Smalltalk code.

Eli

Reply | Threaded
Open this post in threaded view
|

Re: Mac OS X and GemStone users

jgfoster
Hi Eli,

I haven't looked at your application yet, but would be interested in how it overlaps with my work. See http://seaside.gemstone.com/jade for a Cocoa application that allows you to execute code in a transcript.

James

On May 5, 2010, at 3:52 AM, Eli Green wrote:

> Hi everybody,
>
> I've been lurking for a while now and obsessively working on this in
> what spare time I can find. It's a project to integrate Objective-C
> with GemStone in as transparent a manner as possible. The end result
> is supposed to be binding-enabled (minimal code) OS X user interfaces
> with GemStone models as the persistent data store.
>
> Some sample code to try and show what I'm talking about (from a test
> case) is here:
>
> NSMutableArray * obj = [con execute:@"OrderedCollection new add: 1;
> add: 2; add: 3; add: 'test'; yourself"];
> GHAssertEqualObjects([obj objectAtIndex:0], [NSNumber
> numberWithInteger:1], @"");
> GHAssertEqualObjects([obj objectAtIndex:1], [NSNumber
> numberWithInteger:2], @"");
> GHAssertEqualObjects([obj objectAtIndex:2], [NSNumber
> numberWithInteger:3], @"");
> GHAssertEqualObjects([obj objectAtIndex:3], @"test", @"");
>
> Notice that Collection classes are automatically wrapped in a special
> version of the proxy class which emulates NSMutableArray (or
> NSMutableDictionary). It should not be necessary to create NSNumber
> classes manually, as the Objective-C runtime is smart enough to tell
> us when we receive an integer or char * or other. It would be a simple
> matter to convert those to objects before sending them to the GemStone
> server.
>
> I haven't opened the repository up to the world yet because I haven't
> looked into the licensing issues but I wanted to gauge interest in the
> project and see if anybody was interested in it (including possibly
> the GemStone folks themselves).
>
> Because the repository is private, bitbucket won't let me give people
> access to binaries or the wiki, so I've put up a single pre-built
> binary of my barely-functional browser here:
>
> http://sites.google.com/site/gskitdownloads/home
>
> I'm sure this currently breaks in all sorts of interesting ways so if
> you want to e-mail me on or off the list, I'd be happy to help people
> get it working.
>
> If the GEMSTONE environment variable is not set, it will assume
> "/opt/gemstone/product". When I want to connect, I run GemStone/S
> with:
>
> startnet && startstone
>
> Then in the login window, I put this in the Stone field:
> !tcp@localhost#server!gs64stone
>
> This should connect and pull up a browser window. There's a transcript
> that doesn't work properly yet, although you can "Do It" and "Print
> It" and "Inspect It" (the inspector isn't working either!) on selected
> Smalltalk code.
>
> Eli
>
>


Reply | Threaded
Open this post in threaded view
|

Re: Mac OS X and GemStone users

Eli Green-5
In reply to this post by Eli Green-5
Hi James,

For starters, it looks like yours was written by somebody who knows a
lot more about GemStone/S than I do. There's no database management
tools built into mine and that's not the focus.

The browser I'm building is really just me eating my own dog food; the
ultimate goal I have is to make GemStone objects live in Cocoa-land as
though they were native (or as close as I can get). For example, Apple
has the concept of Key-Value Coding which really just turns a list of
dot-separated strings into a bunch of getters or setters. Let's say
you had a dictionary called 'roles' where the key 'guru' mapped to a
Person object which has a getter for 'firstName'. In the UI, you could
specify that a text field is bound to 'roles.guru.firstName'.

Cocoa doesn't have to know that the Person is actually a GemStone
object; there's a GSProxy class that bundles up all messages received
by the proxy and forwards them to your GemStone server.

Right now I have some hard-coded conversions: Strings become NSString
objects, numerics get bundled up as NSValues, Collection (and its
sub-classes) become a proxy that implements NSMutableArray, Dictionary
(and its subclasses) become a proxy that implements
NSMutableDictionary. A handful of other special classes would be
helpful: Sets and Symbols come to mind.

The library that allows you to do all of this right now is linked
against gcirtlobj.o and is about 60K on disk. So anybody developing a
GemStone-backed application could just add this to their application
as a private framework. Of course, the afore-mentioned target user of
this library may not exist since large installations of OS X are rare
at best.

It was basically born out of my belief that Cocoa is the best, easiest
way to build good user interfaces and that it would be a shame to mar
it with some terrible ORM.

I hope I'm explaining myself and not just muddying the waters.

Eli

On Wed, May 5, 2010 at 15:25, James Foster <[hidden email]> wrote:
> Hi Eli,
>
> I haven't looked at your application yet, but would be interested in how it overlaps with my work. See http://seaside.gemstone.com/jade for a Cocoa application that allows you to execute code in a transcript.
>
> James
>

Reply | Threaded
Open this post in threaded view
|

Re: Mac OS X and GemStone users

Eli Green-5
In reply to this post by Eli Green-5
I forgot to mention:

A wifi or 3G-enabled iPad, iPod Touch or iPhone could make use of this
library to seamlessly access a GemStone server as well. It might not
be the most bandwidth-efficient method of performing certain
operations but it could be of great use to some sectors (factories,
shipping and hospitals come to mind).

Eli

On Wed, May 5, 2010 at 16:24, Eli Green <[hidden email]> wrote:

> Hi James,
>
> For starters, it looks like yours was written by somebody who knows a
> lot more about GemStone/S than I do. There's no database management
> tools built into mine and that's not the focus.
>
> The browser I'm building is really just me eating my own dog food; the
> ultimate goal I have is to make GemStone objects live in Cocoa-land as
> though they were native (or as close as I can get). For example, Apple
> has the concept of Key-Value Coding which really just turns a list of
> dot-separated strings into a bunch of getters or setters. Let's say
> you had a dictionary called 'roles' where the key 'guru' mapped to a
> Person object which has a getter for 'firstName'. In the UI, you could
> specify that a text field is bound to 'roles.guru.firstName'.
>
> Cocoa doesn't have to know that the Person is actually a GemStone
> object; there's a GSProxy class that bundles up all messages received
> by the proxy and forwards them to your GemStone server.
>
> Right now I have some hard-coded conversions: Strings become NSString
> objects, numerics get bundled up as NSValues, Collection (and its
> sub-classes) become a proxy that implements NSMutableArray, Dictionary
> (and its subclasses) become a proxy that implements
> NSMutableDictionary. A handful of other special classes would be
> helpful: Sets and Symbols come to mind.
>
> The library that allows you to do all of this right now is linked
> against gcirtlobj.o and is about 60K on disk. So anybody developing a
> GemStone-backed application could just add this to their application
> as a private framework. Of course, the afore-mentioned target user of
> this library may not exist since large installations of OS X are rare
> at best.
>
> It was basically born out of my belief that Cocoa is the best, easiest
> way to build good user interfaces and that it would be a shame to mar
> it with some terrible ORM.
>
> I hope I'm explaining myself and not just muddying the waters.
>
> Eli
>
> On Wed, May 5, 2010 at 15:25, James Foster <[hidden email]> wrote:
>> Hi Eli,
>>
>> I haven't looked at your application yet, but would be interested in how it overlaps with my work. See http://seaside.gemstone.com/jade for a Cocoa application that allows you to execute code in a transcript.
>>
>> James
>>
>
>

Reply | Threaded
Open this post in threaded view
|

Re: Mac OS X and GemStone users

jgfoster
In reply to this post by Eli Green-5
Hi Eli,

I've posted the Xcode files I used to create a library (see GciLibrary.* and GsObject.*) that wraps gcirtlobj.o. I don't have as many conversions into Objective-C since I'm primarily sending very basic types back and forth (String, Integer, Boolean, Character, nil).

Are you familiar with GemBuilder for Smalltalk? Managing a two-object space model can become quite complex. If you replicated the same String twice, would it end up as the same Cocoa object? If you added it to a collection would it create a new instance in GemStone? Are you familiar with the 'export set' in the GCI?

I've tried out your browser and it looks nice. I was able to browse code, but not edit or search. Do you have access to a Windows machine that can connect to a GemStone system? If so, then you might take a look at Jade (Dolphin-based) to see what I hope to do with Cocoa.

I really like your vision for the iPad. I had one for a day and found it quite compelling. Now if only I could figure out what application people want since I have the perfect client/server platform!

James

On May 5, 2010, at 7:24 AM, Eli Green wrote:

> Hi James,
>
> For starters, it looks like yours was written by somebody who knows a
> lot more about GemStone/S than I do. There's no database management
> tools built into mine and that's not the focus.
>
> The browser I'm building is really just me eating my own dog food; the
> ultimate goal I have is to make GemStone objects live in Cocoa-land as
> though they were native (or as close as I can get). For example, Apple
> has the concept of Key-Value Coding which really just turns a list of
> dot-separated strings into a bunch of getters or setters. Let's say
> you had a dictionary called 'roles' where the key 'guru' mapped to a
> Person object which has a getter for 'firstName'. In the UI, you could
> specify that a text field is bound to 'roles.guru.firstName'.
>
> Cocoa doesn't have to know that the Person is actually a GemStone
> object; there's a GSProxy class that bundles up all messages received
> by the proxy and forwards them to your GemStone server.
>
> Right now I have some hard-coded conversions: Strings become NSString
> objects, numerics get bundled up as NSValues, Collection (and its
> sub-classes) become a proxy that implements NSMutableArray, Dictionary
> (and its subclasses) become a proxy that implements
> NSMutableDictionary. A handful of other special classes would be
> helpful: Sets and Symbols come to mind.
>
> The library that allows you to do all of this right now is linked
> against gcirtlobj.o and is about 60K on disk. So anybody developing a
> GemStone-backed application could just add this to their application
> as a private framework. Of course, the afore-mentioned target user of
> this library may not exist since large installations of OS X are rare
> at best.
>
> It was basically born out of my belief that Cocoa is the best, easiest
> way to build good user interfaces and that it would be a shame to mar
> it with some terrible ORM.
>
> I hope I'm explaining myself and not just muddying the waters.
>
> Eli
>
> On Wed, May 5, 2010 at 15:25, James Foster <[hidden email]> wrote:
>> Hi Eli,
>>
>> I haven't looked at your application yet, but would be interested in how it overlaps with my work. See http://seaside.gemstone.com/jade for a Cocoa application that allows you to execute code in a transcript.
>>
>> James
>>
>
>


Reply | Threaded
Open this post in threaded view
|

Re: Mac OS X and GemStone users

Eli Green-5
In reply to this post by Eli Green-5
I will look at the library - right now I have to use .mm files
(Objective-C++) because the GCI headers won't compile as pure C. I
used some tricky typedefs so I could minimize the number of files that
are in C++ because the Clang compiler is really fast and the static
analysis is really nice.

I grabbed a copy of Jade to put on a Windows XP virtual machine I have
here, I'll take a look at it.

I'm not familiar with GemBuilder but have run into problems with the
two object spaces:

Object Identity: Asking for the same string twice will return two
different objects. I decided not to wrap "value" objects in special
proxy classes, choosing to copy them instead (are strings immutable in
GemStone? That's an assumption I've been making). This isn't so bad on
the client side but in GemStone, where everything is persistent, I
guess it could be negative. There is a partial solution which is to
wrap NSString in its own proxy object which knows its OOP and when
sent back to GemStone will just pass in the OOP instead of creating a
new string object. However, strings initially created in Objective-C
won't benefit from this. Assume we have brother and sister objects
representing Person objects in GS:

NSString * aString = @"Smith";
[brother lastName:aString];
[sister lastName:aString];

They would have equal but not identical last names after this and we'd
be wasting space in memory and on disk. If we had become:, we would
have a potentially dangerous solution: when an NSString is passed to
GemStone, make it become: a GSString with the same value. It may be
possible to emulate become: by forcing the free'ing of the NSString
and creating a GSString in the same location, since "id" in
Objective-C is really just a pointer. If there's a supported way to do
this, it'd be great but it sounds like playing with fire.

Garbage Collection: the library is meant to work under normal
retain/release/autorelease operation and Objective-C 2.0 garbage
collection since the mobile devices don't support GC. One problem with
the collection classes is that they have to retain references to the
proxies that represent the real objects or they will leak. It was
worse under garbage collection, where the proxies would vanish as soon
as I returned them from the collection and the browser would
consistently crash. The end result is that every collection has a
dictionary just to hold the proxy objects in it. There's probably some
leaks in there now but at least no crashing.

Everything I know about GCI has been from the reference PDF (which is
quite good), a single example I managed to find online and a lot of
trial and error. I still don't have any idea what it means to traverse
an object and no, I don't know what an export set is. Are these the
objects that are currently being prevented from being garbage
collected on the assumption that the GCI user is using them?

The browser still needs a lot of work. I got side-tracked recently
writing a GS smalltalk parser (based on SHOUT) that I am now
refactoring into good OO code so that I can have syntax highlighting
and some nicer context menus (not to mention refactoring). In real
life, I am a C++, Java, Python and JavaScript programmer working on 3
separate projects so I don't get to play with this as much as I would
like.

I assume there's no ARM version of the GCI library out there at the
moment. Would that be terribly difficult to get a version compiled? I
don't actually have any of their mobile devices but just seeing it
running in the emulator would be a kick.

Eli

On Wed, May 5, 2010 at 18:04, James Foster <[hidden email]> wrote:

> Hi Eli,
>
> I've posted the Xcode files I used to create a library (see GciLibrary.* and GsObject.*) that wraps gcirtlobj.o. I don't have as many conversions into Objective-C since I'm primarily sending very basic types back and forth (String, Integer, Boolean, Character, nil).
>
> Are you familiar with GemBuilder for Smalltalk? Managing a two-object space model can become quite complex. If you replicated the same String twice, would it end up as the same Cocoa object? If you added it to a collection would it create a new instance in GemStone? Are you familiar with the 'export set' in the GCI?
>
> I've tried out your browser and it looks nice. I was able to browse code, but not edit or search. Do you have access to a Windows machine that can connect to a GemStone system? If so, then you might take a look at Jade (Dolphin-based) to see what I hope to do with Cocoa.
>
> I really like your vision for the iPad. I had one for a day and found it quite compelling. Now if only I could figure out what application people want since I have the perfect client/server platform!
>
> James
>
> On May 5, 2010, at 7:24 AM, Eli Green wrote:
>
>> Hi James,
>>
>> For starters, it looks like yours was written by somebody who knows a
>> lot more about GemStone/S than I do. There's no database management
>> tools built into mine and that's not the focus.
>>
>> The browser I'm building is really just me eating my own dog food; the
>> ultimate goal I have is to make GemStone objects live in Cocoa-land as
>> though they were native (or as close as I can get). For example, Apple
>> has the concept of Key-Value Coding which really just turns a list of
>> dot-separated strings into a bunch of getters or setters. Let's say
>> you had a dictionary called 'roles' where the key 'guru' mapped to a
>> Person object which has a getter for 'firstName'. In the UI, you could
>> specify that a text field is bound to 'roles.guru.firstName'.
>>
>> Cocoa doesn't have to know that the Person is actually a GemStone
>> object; there's a GSProxy class that bundles up all messages received
>> by the proxy and forwards them to your GemStone server.
>>
>> Right now I have some hard-coded conversions: Strings become NSString
>> objects, numerics get bundled up as NSValues, Collection (and its
>> sub-classes) become a proxy that implements NSMutableArray, Dictionary
>> (and its subclasses) become a proxy that implements
>> NSMutableDictionary. A handful of other special classes would be
>> helpful: Sets and Symbols come to mind.
>>
>> The library that allows you to do all of this right now is linked
>> against gcirtlobj.o and is about 60K on disk. So anybody developing a
>> GemStone-backed application could just add this to their application
>> as a private framework. Of course, the afore-mentioned target user of
>> this library may not exist since large installations of OS X are rare
>> at best.
>>
>> It was basically born out of my belief that Cocoa is the best, easiest
>> way to build good user interfaces and that it would be a shame to mar
>> it with some terrible ORM.
>>
>> I hope I'm explaining myself and not just muddying the waters.
>>
>> Eli
>>
>> On Wed, May 5, 2010 at 15:25, James Foster <[hidden email]> wrote:
>>> Hi Eli,
>>>
>>> I haven't looked at your application yet, but would be interested in how it overlaps with my work. See http://seaside.gemstone.com/jade for a Cocoa application that allows you to execute code in a transcript.
>>>
>>> James
>>>
>>
>>
>
>
>

Reply | Threaded
Open this post in threaded view
|

Re: Mac OS X and GemStone users

jgfoster
In reply to this post by Eli Green-5
Eli,

You have a good grasp of the two object spaces problem. One approach is to keep a two-way mapping of client ID to server OOP and use it whenever crossing the boundary. Of course, this creates a new reference that needs special GC handling.

In GemStone, Strings are mutable unless they have been sent the #'immediateInvariant' message.

In addition to the GC issues you describe on the client, you should also consider GC issues on the server if you are retaining an OOP in the context of it being a proxy. Specifically, if after you get the OOP of an object the server object is dereferenced its OOP could be recycled to be used by another object. If you send messages using the OOP, then it will be the wrong object! Solving this problem involves the export set (a list of OOPs being held by the client that should not be subject to GC on the server).

While there is an Intel version of the GCI for Mac OS 10.5+, there is no ARM version. If someone were looking at a real application on the iPad with a GemStone back-end, I would probably use sockets and define a new 'wire' protocol. With the Intel Mac, however, the GCI library is a good approach.

James

On May 5, 2010, at 9:35 AM, Eli Green wrote:

> I will look at the library - right now I have to use .mm files
> (Objective-C++) because the GCI headers won't compile as pure C. I
> used some tricky typedefs so I could minimize the number of files that
> are in C++ because the Clang compiler is really fast and the static
> analysis is really nice.
>
> I grabbed a copy of Jade to put on a Windows XP virtual machine I have
> here, I'll take a look at it.
>
> I'm not familiar with GemBuilder but have run into problems with the
> two object spaces:
>
> Object Identity: Asking for the same string twice will return two
> different objects. I decided not to wrap "value" objects in special
> proxy classes, choosing to copy them instead (are strings immutable in
> GemStone? That's an assumption I've been making). This isn't so bad on
> the client side but in GemStone, where everything is persistent, I
> guess it could be negative. There is a partial solution which is to
> wrap NSString in its own proxy object which knows its OOP and when
> sent back to GemStone will just pass in the OOP instead of creating a
> new string object. However, strings initially created in Objective-C
> won't benefit from this. Assume we have brother and sister objects
> representing Person objects in GS:
>
> NSString * aString = @"Smith";
> [brother lastName:aString];
> [sister lastName:aString];
>
> They would have equal but not identical last names after this and we'd
> be wasting space in memory and on disk. If we had become:, we would
> have a potentially dangerous solution: when an NSString is passed to
> GemStone, make it become: a GSString with the same value. It may be
> possible to emulate become: by forcing the free'ing of the NSString
> and creating a GSString in the same location, since "id" in
> Objective-C is really just a pointer. If there's a supported way to do
> this, it'd be great but it sounds like playing with fire.
>
> Garbage Collection: the library is meant to work under normal
> retain/release/autorelease operation and Objective-C 2.0 garbage
> collection since the mobile devices don't support GC. One problem with
> the collection classes is that they have to retain references to the
> proxies that represent the real objects or they will leak. It was
> worse under garbage collection, where the proxies would vanish as soon
> as I returned them from the collection and the browser would
> consistently crash. The end result is that every collection has a
> dictionary just to hold the proxy objects in it. There's probably some
> leaks in there now but at least no crashing.
>
> Everything I know about GCI has been from the reference PDF (which is
> quite good), a single example I managed to find online and a lot of
> trial and error. I still don't have any idea what it means to traverse
> an object and no, I don't know what an export set is. Are these the
> objects that are currently being prevented from being garbage
> collected on the assumption that the GCI user is using them?
>
> The browser still needs a lot of work. I got side-tracked recently
> writing a GS smalltalk parser (based on SHOUT) that I am now
> refactoring into good OO code so that I can have syntax highlighting
> and some nicer context menus (not to mention refactoring). In real
> life, I am a C++, Java, Python and JavaScript programmer working on 3
> separate projects so I don't get to play with this as much as I would
> like.
>
> I assume there's no ARM version of the GCI library out there at the
> moment. Would that be terribly difficult to get a version compiled? I
> don't actually have any of their mobile devices but just seeing it
> running in the emulator would be a kick.
>
> Eli
>
> On Wed, May 5, 2010 at 18:04, James Foster <[hidden email]> wrote:
>> Hi Eli,
>>
>> I've posted the Xcode files I used to create a library (see GciLibrary.* and GsObject.*) that wraps gcirtlobj.o. I don't have as many conversions into Objective-C since I'm primarily sending very basic types back and forth (String, Integer, Boolean, Character, nil).
>>
>> Are you familiar with GemBuilder for Smalltalk? Managing a two-object space model can become quite complex. If you replicated the same String twice, would it end up as the same Cocoa object? If you added it to a collection would it create a new instance in GemStone? Are you familiar with the 'export set' in the GCI?
>>
>> I've tried out your browser and it looks nice. I was able to browse code, but not edit or search. Do you have access to a Windows machine that can connect to a GemStone system? If so, then you might take a look at Jade (Dolphin-based) to see what I hope to do with Cocoa.
>>
>> I really like your vision for the iPad. I had one for a day and found it quite compelling. Now if only I could figure out what application people want since I have the perfect client/server platform!
>>
>> James
>>
>> On May 5, 2010, at 7:24 AM, Eli Green wrote:
>>
>>> Hi James,
>>>
>>> For starters, it looks like yours was written by somebody who knows a
>>> lot more about GemStone/S than I do. There's no database management
>>> tools built into mine and that's not the focus.
>>>
>>> The browser I'm building is really just me eating my own dog food; the
>>> ultimate goal I have is to make GemStone objects live in Cocoa-land as
>>> though they were native (or as close as I can get). For example, Apple
>>> has the concept of Key-Value Coding which really just turns a list of
>>> dot-separated strings into a bunch of getters or setters. Let's say
>>> you had a dictionary called 'roles' where the key 'guru' mapped to a
>>> Person object which has a getter for 'firstName'. In the UI, you could
>>> specify that a text field is bound to 'roles.guru.firstName'.
>>>
>>> Cocoa doesn't have to know that the Person is actually a GemStone
>>> object; there's a GSProxy class that bundles up all messages received
>>> by the proxy and forwards them to your GemStone server.
>>>
>>> Right now I have some hard-coded conversions: Strings become NSString
>>> objects, numerics get bundled up as NSValues, Collection (and its
>>> sub-classes) become a proxy that implements NSMutableArray, Dictionary
>>> (and its subclasses) become a proxy that implements
>>> NSMutableDictionary. A handful of other special classes would be
>>> helpful: Sets and Symbols come to mind.
>>>
>>> The library that allows you to do all of this right now is linked
>>> against gcirtlobj.o and is about 60K on disk. So anybody developing a
>>> GemStone-backed application could just add this to their application
>>> as a private framework. Of course, the afore-mentioned target user of
>>> this library may not exist since large installations of OS X are rare
>>> at best.
>>>
>>> It was basically born out of my belief that Cocoa is the best, easiest
>>> way to build good user interfaces and that it would be a shame to mar
>>> it with some terrible ORM.
>>>
>>> I hope I'm explaining myself and not just muddying the waters.
>>>
>>> Eli
>>>
>>> On Wed, May 5, 2010 at 15:25, James Foster <[hidden email]> wrote:
>>>> Hi Eli,
>>>>
>>>> I haven't looked at your application yet, but would be interested in how it overlaps with my work. See http://seaside.gemstone.com/jade for a Cocoa application that allows you to execute code in a transcript.
>>>>
>>>> James
>>>>
>>>
>>>
>>
>>
>>
>