[Glass] Problem while loading Bootstrap for Seaside inside Gemstone

[Dale Henrichs via Glass]

On Wed, Dec 10, 2014 at 12:13 AM, draq88 via Glass <
glass at lists.gemtalksystems.com> wrote:

> Dale,
>
> I was able to load Bootstrap packages with Seaside mixing the last two
> commands you sent me. Don't know if it is correct but it works so far. I
> just wanted to let you know the progress I did. Hope it's okay and I'm not
> messing things up more haha.
>

I think that Metacello is pretty good about loading things "correctly" no
matter how many retires it takes when using the `Metacello new` form.


> Gofer new
>     package: 'GsUpgrader-Core';
>     url: 'http://ss3.gemtalksystems.com/ss/gsUpgrader';
>     load.
>   (Smalltalk at: #'GsUpgrader') upgradeGrease.
>
>    GsDeployer
>     deploy: [
>       Metacello new
>         baseline: 'Seaside3';
>         repository: 'github://GsDevKit/Seaside31:
> v3.1.3.1-gs/repository';
>         get;
>         lock.
>       Metacello new
>         configuration: 'Bootstrap';
>         repository:
> 'http://smalltalkhub.com/mc/TorstenBergmann/Bootstrap/main';
>         *onConflictUseIncoming;*
>         version: #'stable';
>         load ].
>
>
> The one thing that is strange is that, maybe because I had code in my
> project that was not compatible with gemstone's smalltalk (there were a few
> differences with the Pharo version of the project that after reviewing my
> tests I was able to fix so far), sometimes and I repeat I think due to
> programming errors, seaside/adaptors seem to crash. I am not able to access
> my app which is expected since it had errors but access to localhost:5858
> (that is where I have GsSwazooAdapter listening to) is refused. Same as if
> you tried to open an external URL and you don't have access. At least
> that's
> the impression I get. Same happened to Zinc adaptor after a few F5 pushes.
>

If you look in the log files for the  adaptors you should see stack traces
that should give you an idea about what is happening ... Also, stack traces
should be dumped to the object log as a continuation and you can debug the
continuation from the object log ... However, if the job is crashing it is
possible that the error is not being dumped to the object log and you will
have to resort to looking at the gem log ...

Swazoo and Zinc still have a couple of issues under certain error
conditions. Moving forward I recommend using Zinc.

I have been doing work recently in Zinc and I think I've made things a bit
more solid with respect to error handling and debugging, but my work isn't
quite ready for release ... I've asked a few folks to help me review the
changes ....

If you need help with the stacks in the log files, go ahead and send mail
with the log files attached or the stack in question in the body of the
email and I'll see if I can help...

Dale
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gemtalksystems.com/mailman/private/glass/attachments/20141210/6acf42d8/attachment.html>