[Glass] Is it possible to explore/inspect objects from seaside callbacks in GemTools?

[Dale Henrichs]

Mariano,  et. al.,

I've just fixed this bug[1] in the glassdbglass repository[4] and I thought
it was worth talking a bit about how I see the GLASS repo being used moving
forward.

I intend to continuously release bugfixes into the glass repository. I do
development on the dev branch until the tests are green[2] (note that the
tests cover 4 different versions of GemStone: 2.4.5.2, 3.0.1, 3.1.0.6 and
3.2) and then I do a merge onto the master branch.

The best way for you to use the glass repo is to first fork[3] the
repository to your github user account and make a local clone of the
repository. When you are at a good point to pick up the latest glass code,
you will merge the master branch on glassdb into a branch in your local
repository and verify that your application works with the new version of
glass. If it does, you can then follow your procedures for releasing the
glass code into production ... You can also make bugfixes in your local
repository and issue pull requests to the glassdb repository with those
bugfixes ... if you choose.

I know that becoming comfortable with git isn't necessarily easy, but the
"soon to be released tODE[9]" (I'm down to only 7 "must have" issues on
tode[5] and when that total reaches zero I will announce a public alpha)
has some fairly high level support for the basic git operations and I will
be added menu items/commands that should pretty much automate the process
of merging in changes from glassdb/glass to your local repository. If there
are conflicts the tODE merge tool will be opened and you will be able to
resolve the merges or abort the operation all together.

I'm about a week or so away from the public alpha (barring anymore high
priority interrupts), but I expect the early alpha users to be comfortable
with git as I won't have all of the steps automated by then...I intend to
add git-related documentation to the webEditionHome site[8] with more
detail about using git and tODE together so that folks with less experience
with git can get a hopefully gentle introduction:)

You can track tODE progress here[6] or here[7].

Dale

[1] https://github.com/glassdb/glass/issues/21
[2] https://travis-ci.org/glassdb/glass/builds/26717387
[3] https://help.github.com/articles/fork-a-repo
[4] https://github.com/glassdb/glass
[5]
https://github.com/dalehenrich/tode/issues?labels=must+have&page=1&state=open
[6] https://groups.google.com/forum/#!forum/tode_st
[7] http://forum.world.st/tODE-f3744225.html
[8] https://github.com/glassdb/webEditionHome#web-edition-home
[9]
https://github.com/dalehenrich/tode#tode-the-object-centric-development-environment-


On Wed, Dec 18, 2013 at 6:20 AM, Mariano Martinez Peck <
marianopeck at gmail.com> wrote:

>
>
>
> On Tue, Dec 17, 2013 at 7:22 PM, Dale K. Henrichs <
> dale.henrichs at gemtalksystems.com> wrote:
>
>>
>>
>> ------------------------------
>>
>> *From: *"Mariano Martinez Peck" <marianopeck at gmail.com>
>> *To: *glass at lists.gemtalksystems.com
>> *Sent: *Tuesday, December 17, 2013 11:59:09 AM
>> *Subject: *[Glass] Is it possible to explore/inspect objects from
>> seaside        callbacks in GemTools?
>>
>> .....
>>
>> Finally, and this is my real question...I have gems running seaside in
>> which I have some buttons to ease development. These buttons send #inspect
>> or #explore to some objects in seaside callbacks. When I do that (having a
>> GemTools connected to the same GemStone), I get this error:
>>
>> -----------
>>
>> Internal Server Error:
>>
>> a TransactionError occurred (error 2407), The object aSessionTemps(
>> #'GsHostRandomFile'->aGsFile,
>> #'GRGemStoneRandomProvider_MUTEX'->aTransientMutex,
>> #'SystemChangeNotifier_UniqueInstance'->aSystemChangeNotifier,
>> #'GsPackage_TransactionBoundary_Dict'->aSessionTemps(
>> #'SessionMethodChange'->1614, #'ClassChange'->6791),
>> #'Cached_Class_Organizer'->aCachingClassOrganizer,
>> #'GRGemStoneRandomProvider_GENERATOR'->aHostRandom,
>> #'GemToGemStaticException'->aGsExceptionHandler,
>> #'GsPackagePolicy_SessionMethodDictionary'->anIdentitySet( Array,
>> Association, Behavior, Boolean, Character, Class, Collection, Integer,
>> Magnitude, ObsoleteMetaclass, Number, Object, PositionableStream,
>> ReadStream, SequenceableCollection, SmallInteger, Stream, String,
>> UndefinedObject, ...), ...) may not be committed, 'instances of its class
>> are non-persistent'
>>
>> You should contact the system administrator
>>
>> -------------
>>
>>
>> So I guess this is expected right? there is no workaround?
>>
>> I'm not surprised that you are getting an error ... presumably we're
>> trying to dump the stack into the object log and it has some references to
>> the SessionTemps ... since there is no head inspect/explore aren't going to
>> bring up an inspector, however, it wouldn't be a bad idea to go ahead and
>> change inspect/explore to drop off the object into the ObjectLog ...
>>
>
> Yes, I was thinking about that too.
>
>
>> it is possible to tell if GemTools is connected, if `OBGemStonePlatform
>> canInform` answers true GemTools is running ...
>>
>>
> And do you think it is possible to avoid dumping the stack in the object
> log for the case of inspect/explore? because if true, we can check if
> GemTools is running, if true, we might be able to open a real
> inspector/explorer in GemTools and otherwise (or in addition) write the
> object to the object log?
>
> Thanks!
>
>
>
>> Dale
>>
>>
>>
>
>
> --
> Mariano
> http://marianopeck.wordpress.com
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gemtalksystems.com/mailman/private/glass/attachments/20140603/6c385f12/attachment.html>