Mac OS X and GemStone users

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

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

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

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

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