Smalltalk › Gemtalk › GLASS

[Glass] callbackMarker not found in Seaside stack

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

35 messages Options

otto

Re: [Glass] callbackMarker not found in Seaside stack

Hi,

Pardon the delay on the response here. We decided to simplify the flow of screens here to avoid the problem, in the light of a possibly complex way that we're implementing the requirement and a pressing client.

But we'd like to explore this a bit more to see if we can find this because it may be a problem elsewhere in our system or for someone else.

Firstly, we are using https://github.com/glassdb/Seaside30. The comment says Seaside 3.0.7.1. I don't know how to figure out what version of seaside this is besides trusting the comment. Looking at logs when loading from scratch does not tell me much. How will I go about figuring out the version that we've got loaded? From Johan's recent mail, I take it that https://github.com/glassdb/Seaside31 could be good to upgrade to.

To get back to the problem, I think the continuation was created with

Scriptaculous >> lightbox: aComponent

^ self wait: [ :cc |

self

show: aComponent

onAnswer: cc

delegation: (SULightbox new

delegate: aComponent;

yourself).

WARenderNotification signal ]

Yes, we still have some Scriptaculous bits to get rid of, so if this is the problem, the time is now.

What do you think? Is this it?

Thanks

Otto

On Tue, May 20, 2014 at 3:05 AM, Dale Henrichs <[hidden email]> wrote:

Otto,

Another possibility ... although I don't know if this kind of thing would be possible but here goes nothing ...

If the callback that we're looking at with the broken stack was created during WADispatchCallback>>evaluateWithArgument: or WAMultiSelectTag>>triggerCallback and inform: answer was run in WACallbackRegistry>>handle:, then the call back would have been created with one less frame on the stack (no do: frame) ... and that would provide us with a nice off by one error ...

some logging in the methods WADispatchCallback>>evaluateWithArgument: and WAMultiSelectTag>>triggerCallback, where you record the oop of theWACallback instance and logging in WACallbackRegistry>>handle: recording the oops of WACallbacks run should rule this hare-brained idea out or rule it right into play:) ...

Dale

On Mon, May 19, 2014 at 5:41 PM, Dale Henrichs <[hidden email]> wrote:

Otto,

I haven't been able to reproduce the bad error yet and I think that the corruption is being caused by the previous callback in the set ... the stack is corrupt at the point you try to create the continuation for the inform: in the validation block ...

setting breakpoints in the WACallback>>evaluateWithFieldValues: will catch the first callback in this sequence .. check to see if the stack looks corrupt in the first call, then continue and see if the stack looks corrupt before executing the code for the second callback ... if we can isolate the transition from good stack to bad stack, we'll be on our way to a solution...

I'm a bit suspicious of Magritte in the mix and the#reset message ... if the structure of objects have been changed between the time the continuation is created and the time it gets used, there might be trouble ... but I'm only grasping at straws at this point in time ... BTW, what version of Seaside and Magritte are you using?

If Pieter's case is simpler, we might be able to figure it out easier ... I'd like to see the two addForm: methods:) Just in case something jumps out at me...

Dale

On Mon, May 19, 2014 at 2:48 PM, Dale Henrichs <[hidden email]> wrote:

Otto,

Given an instance of WACallback, you can determine the source code of the method where the callback is defined by looking at the `block` instance variable og a WACallBack instance ... then in 3.1:

block _method sourceString.    "source"
block _method inClass              "class"
block _method _lineDeltaForBlock    "line number in source (ignoring selector)"

This can be done from a debugger (topaz) when error occurs ... navigate up the stack to the WACallback>>evaluateWithFieldValues: frame... get the oop of the _method (use `display oops`) and then sued the `send` command to send the three different messages:

send @34379893 sourceString

... still digging ...

Dale

On Mon, May 19, 2014 at 10:55 AM, Otto Behrens <[hidden email]> wrote:

Thank you, Dale. I'm finally at home :)

On Monday, May 19, 2014, Dale Henrichs <[hidden email]> wrote:

Otto,

Thanks!

I'm finally in the office ) and will spend some time today getting myself grounded in continuations again ... then I should have a better idea how to proceed ...

Dale

On Mon, May 19, 2014 at 9:47 AM, Otto Behrens <[hidden email]> wrote:

> perhaps capturing the stack at the point the continue is created will give
> us clues ...

Attached are some stacks that I hacked in by calling the following
method where we create them:

WAPartialContinuation >> printStack
| stream |
stream := GsFile openWriteOnServer: '/tmp/stack_', self asOop printString.
[ stream nextPutAll: partial printString ] ensure: [ stream close ]

It does not tell me much at the moment. But perhaps you can see
something. Or perhaps you have a better printing method that I can
call?

Thanks
Otto

_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass

otto

Re: [Glass] callbackMarker not found in Seaside stack

Hi,

A weirdness we had in our system was that the accessor called by a Magritte description raised an Error. This code is called in a callback of a button:

[

aComponent

call:

(MatchInvestmentPage new

instruction: self;

yourself).

aComponent reset ]

on: Error

do: [ :err |

aComponent inform: err messageText.

aComponent answer ]

It tries to handle the error raised by "aComponent reset". The MatchInvestmentPage component changes the state of the model of aComponent (a magritte container component). The "aComponent reset" causes a magritte MADescription (displaying a fairly simple amount field) to call an accessor on the model, which raises the error.

We now removed this error handler and check for the error condition elsewhere.

A broader question here is whether magritte descriptions should handle exceptions when reading from the model (Object >> readUsing: which calls #read: on).

Our understanding is that reading via accessors (MAAccessor descendants) should not handle exceptions and a fallback (outer) handler should handle it, because this is really unexpected. Is this right? Does anyone know what the best way is to handle this situation?

Does it make sense to handle exceptions at the description level and display a message to the user (on the field itself)? Not sure that it does, but perhaps someone have better ideas here.

Thanks

Otto

PS. Does anyone have suggestions on nicer dialogs (the inform: call here) that perhaps uses JQuery or another mechanism?

On Wed, May 21, 2014 at 10:45 AM, Otto Behrens <[hidden email]> wrote:

Hi,

Pardon the delay on the response here. We decided to simplify the flow of screens here to avoid the problem, in the light of a possibly complex way that we're implementing the requirement and a pressing client.

But we'd like to explore this a bit more to see if we can find this because it may be a problem elsewhere in our system or for someone else.

Firstly, we are using https://github.com/glassdb/Seaside30. The comment says Seaside 3.0.7.1. I don't know how to figure out what version of seaside this is besides trusting the comment. Looking at logs when loading from scratch does not tell me much. How will I go about figuring out the version that we've got loaded? From Johan's recent mail, I take it that https://github.com/glassdb/Seaside31 could be good to upgrade to.

To get back to the problem, I think the continuation was created with

Scriptaculous >> lightbox: aComponent
^ self wait: [ :cc |
self

show: aComponent
onAnswer: cc
delegation: (SULightbox new

delegate: aComponent;
yourself).
WARenderNotification signal ]

Yes, we still have some Scriptaculous bits to get rid of, so if this is the problem, the time is now.

What do you think? Is this it?

Thanks
Otto

On Tue, May 20, 2014 at 3:05 AM, Dale Henrichs <[hidden email]> wrote:

Otto,

Another possibility ... although I don't know if this kind of thing would be possible but here goes nothing ...

If the callback that we're looking at with the broken stack was created during WADispatchCallback>>evaluateWithArgument: or WAMultiSelectTag>>triggerCallback and inform: answer was run in WACallbackRegistry>>handle:, then the call back would have been created with one less frame on the stack (no do: frame) ... and that would provide us with a nice off by one error ...

some logging in the methods WADispatchCallback>>evaluateWithArgument: and WAMultiSelectTag>>triggerCallback, where you record the oop of theWACallback instance and logging in WACallbackRegistry>>handle: recording the oops of WACallbacks run should rule this hare-brained idea out or rule it right into play:) ...

Dale

On Mon, May 19, 2014 at 5:41 PM, Dale Henrichs <[hidden email]> wrote:

Otto,

I haven't been able to reproduce the bad error yet and I think that the corruption is being caused by the previous callback in the set ... the stack is corrupt at the point you try to create the continuation for the inform: in the validation block ...

setting breakpoints in the WACallback>>evaluateWithFieldValues: will catch the first callback in this sequence .. check to see if the stack looks corrupt in the first call, then continue and see if the stack looks corrupt before executing the code for the second callback ... if we can isolate the transition from good stack to bad stack, we'll be on our way to a solution...

I'm a bit suspicious of Magritte in the mix and the#reset message ... if the structure of objects have been changed between the time the continuation is created and the time it gets used, there might be trouble ... but I'm only grasping at straws at this point in time ... BTW, what version of Seaside and Magritte are you using?

If Pieter's case is simpler, we might be able to figure it out easier ... I'd like to see the two addForm: methods:) Just in case something jumps out at me...

Dale

On Mon, May 19, 2014 at 2:48 PM, Dale Henrichs <[hidden email]> wrote:

Otto,

Given an instance of WACallback, you can determine the source code of the method where the callback is defined by looking at the `block` instance variable og a WACallBack instance ... then in 3.1:

block _method sourceString.    "source"
block _method inClass              "class"
block _method _lineDeltaForBlock    "line number in source (ignoring selector)"

This can be done from a debugger (topaz) when error occurs ... navigate up the stack to the WACallback>>evaluateWithFieldValues: frame... get the oop of the _method (use `display oops`) and then sued the `send` command to send the three different messages:

send @34379893 sourceString

... still digging ...

Dale

On Mon, May 19, 2014 at 10:55 AM, Otto Behrens <[hidden email]> wrote:

Thank you, Dale. I'm finally at home :)

On Monday, May 19, 2014, Dale Henrichs <[hidden email]> wrote:

Otto,

Thanks!

I'm finally in the office ) and will spend some time today getting myself grounded in continuations again ... then I should have a better idea how to proceed ...

Dale

On Mon, May 19, 2014 at 9:47 AM, Otto Behrens <[hidden email]> wrote:

> perhaps capturing the stack at the point the continue is created will give
> us clues ...

Attached are some stacks that I hacked in by calling the following
method where we create them:

WAPartialContinuation >> printStack
| stream |
stream := GsFile openWriteOnServer: '/tmp/stack_', self asOop printString.
[ stream nextPutAll: partial printString ] ensure: [ stream close ]

It does not tell me much at the moment. But perhaps you can see
something. Or perhaps you have a better printing method that I can
call?

Thanks
Otto

_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass

Dale Henrichs-3

Re: [Glass] callbackMarker not found in Seaside stack

In reply to this post by otto

On Wed, May 21, 2014 at 1:45 AM, Otto Behrens <[hidden email]> wrote:

Hi,

Pardon the delay on the response here. We decided to simplify the flow of screens here to avoid the problem, in the light of a possibly complex way that we're implementing the requirement and a pressing client.

That's okay, I put the time to good use:)

But we'd like to explore this a bit more to see if we can find this because it may be a problem elsewhere in our system or for someone else.

Firstly, we are using https://github.com/glassdb/Seaside30. The comment says Seaside 3.0.7.1. I don't know how to figure out what version of seaside this is besides trusting the comment.

Trust the comment. There are later versions of 3.0 on smalltalk hub ... 3.0.9.1 is probably the latest version available that passes tests in GemStone...

Looking at logs when loading from scratch does not tell me much. How will I go about figuring out the version that we've got loaded?

The best way that I know of is to record the SHA of the commit when you do the load. I have made extensions to Metacello that record the SHA when you do the load (part of the registration).

tODE has a `project list` that displays the SHA from the metacello registration. tODE also "monitors" the local git repo for changes to the SHA and displays this skew in the `project list` ... from the `project list` you can access the commit log (which has the SHA of each commit) and from the commit log you can do diffs between the selected commit and the image ...

This typs of problem is exactly why I am pushing to get tODE released ...

From Johan's recent mail, I take it that https://github.com/glassdb/Seaside31 could be good to upgrade to.

To get back to the problem, I think the continuation was created with

Scriptaculous >> lightbox: aComponent
^ self wait: [ :cc |
self

show: aComponent
onAnswer: cc
delegation: (SULightbox new

delegate: aComponent;
yourself).
WARenderNotification signal ]

Yes, we still have some Scriptaculous bits to get rid of, so if this is the problem, the time is now.

What do you think? Is this it?

The way to tell is to monitor the stack as the calls are being made to evaluateWithArgument:...you can automate things by using the object log to record the source/class/lineno of the callback block and the location of the evaluateWithArgument: call ... when you hit the error, peek at the last entry in the object log.

When I'm doing this kind of work, I nuke the object log before each test run so I have fewer entries to look at ...

Thanks
Otto

On Tue, May 20, 2014 at 3:05 AM, Dale Henrichs <[hidden email]> wrote:

Otto,

Another possibility ... although I don't know if this kind of thing would be possible but here goes nothing ...

If the callback that we're looking at with the broken stack was created during WADispatchCallback>>evaluateWithArgument: or WAMultiSelectTag>>triggerCallback and inform: answer was run in WACallbackRegistry>>handle:, then the call back would have been created with one less frame on the stack (no do: frame) ... and that would provide us with a nice off by one error ...

some logging in the methods WADispatchCallback>>evaluateWithArgument: and WAMultiSelectTag>>triggerCallback, where you record the oop of theWACallback instance and logging in WACallbackRegistry>>handle: recording the oops of WACallbacks run should rule this hare-brained idea out or rule it right into play:) ...

Dale

On Mon, May 19, 2014 at 5:41 PM, Dale Henrichs <[hidden email]> wrote:

Otto,

I haven't been able to reproduce the bad error yet and I think that the corruption is being caused by the previous callback in the set ... the stack is corrupt at the point you try to create the continuation for the inform: in the validation block ...

setting breakpoints in the WACallback>>evaluateWithFieldValues: will catch the first callback in this sequence .. check to see if the stack looks corrupt in the first call, then continue and see if the stack looks corrupt before executing the code for the second callback ... if we can isolate the transition from good stack to bad stack, we'll be on our way to a solution...

I'm a bit suspicious of Magritte in the mix and the#reset message ... if the structure of objects have been changed between the time the continuation is created and the time it gets used, there might be trouble ... but I'm only grasping at straws at this point in time ... BTW, what version of Seaside and Magritte are you using?

If Pieter's case is simpler, we might be able to figure it out easier ... I'd like to see the two addForm: methods:) Just in case something jumps out at me...

Dale

On Mon, May 19, 2014 at 2:48 PM, Dale Henrichs <[hidden email]> wrote:

Otto,

Given an instance of WACallback, you can determine the source code of the method where the callback is defined by looking at the `block` instance variable og a WACallBack instance ... then in 3.1:

block _method sourceString.    "source"
block _method inClass              "class"
block _method _lineDeltaForBlock    "line number in source (ignoring selector)"

This can be done from a debugger (topaz) when error occurs ... navigate up the stack to the WACallback>>evaluateWithFieldValues: frame... get the oop of the _method (use `display oops`) and then sued the `send` command to send the three different messages:

send @34379893 sourceString

... still digging ...

Dale

On Mon, May 19, 2014 at 10:55 AM, Otto Behrens <[hidden email]> wrote:

Thank you, Dale. I'm finally at home :)

On Monday, May 19, 2014, Dale Henrichs <[hidden email]> wrote:

Otto,

Thanks!

I'm finally in the office ) and will spend some time today getting myself grounded in continuations again ... then I should have a better idea how to proceed ...

Dale

On Mon, May 19, 2014 at 9:47 AM, Otto Behrens <[hidden email]> wrote:

> perhaps capturing the stack at the point the continue is created will give
> us clues ...

Attached are some stacks that I hacked in by calling the following
method where we create them:

WAPartialContinuation >> printStack
| stream |
stream := GsFile openWriteOnServer: '/tmp/stack_', self asOop printString.
[ stream nextPutAll: partial printString ] ensure: [ stream close ]

It does not tell me much at the moment. But perhaps you can see
something. Or perhaps you have a better printing method that I can
call?

Thanks
Otto

_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass

Johan Brichau-3

Re: [Glass] callbackMarker not found in Seaside stack

On 21 May 2014, at 15:32, Dale Henrichs <[hidden email]> wrote:

> Trust the comment. There are later versions of 3.0 on smalltalk hub ... 3.0.9.1 is probably the latest version available that passes tests in GemStone...

Actually, that should be 3.0.10
Using it in production... :-)

Johan
_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass

Dale Henrichs-3

Re: [Glass] callbackMarker not found in Seaside stack

haha,take a look at the comment:)

Dale

On Wed, May 21, 2014 at 10:41 AM, Johan Brichau <[hidden email]> wrote:

On 21 May 2014, at 15:32, Dale Henrichs <[hidden email]> wrote:

> Trust the comment. There are later versions of 3.0 on smalltalk hub ... 3.0.9.1 is probably the latest version available that passes tests in GemStone...

Actually, that should be 3.0.10
Using it in production... :-)

Johan

_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass

Johan Brichau-3

Re: [Glass] callbackMarker not found in Seaside stack

ow wait.

I meant that for the version on Smalltalk hub / seaside.gemstone.com monticello

I have no idea what version is in that github repo.

Johan

On 21 May 2014, at 19:47, Dale Henrichs <[hidden email]> wrote:

> haha,take a look at the comment:)
>
> Dale
>
>
> On Wed, May 21, 2014 at 10:41 AM, Johan Brichau <[hidden email]> wrote:
>
> On 21 May 2014, at 15:32, Dale Henrichs <[hidden email]> wrote:
>
> > Trust the comment. There are later versions of 3.0 on smalltalk hub ... 3.0.9.1 is probably the latest version available that passes tests in GemStone...
>
> Actually, that should be 3.0.10
> Using it in production... :-)
>
> Johan
>

_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass

Johan Brichau-3

Re: [Glass] callbackMarker not found in Seaside stack

Sorry about that, I misread the email.

johan

On 21 May 2014, at 19:49, Johan Brichau <[hidden email]> wrote:

> ow wait.
>
> I meant that for the version on Smalltalk hub / seaside.gemstone.com monticello
>
> I have no idea what version is in that github repo.
>
> Johan
>
> On 21 May 2014, at 19:47, Dale Henrichs <[hidden email]> wrote:
>
>> haha,take a look at the comment:)
>>
>> Dale
>>
>>
>> On Wed, May 21, 2014 at 10:41 AM, Johan Brichau <[hidden email]> wrote:
>>
>> On 21 May 2014, at 15:32, Dale Henrichs <[hidden email]> wrote:
>>
>>> Trust the comment. There are later versions of 3.0 on smalltalk hub ... 3.0.9.1 is probably the latest version available that passes tests in GemStone...
>>
>> Actually, that should be 3.0.10
>> Using it in production... :-)
>>
>> Johan
>>
>

_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass

Dale Henrichs-3

Re: [Glass] callbackMarker not found in Seaside stack

In reply to this post by Johan Brichau-3

Then 3.0.7.1 ... I looked at the commit history and things were not changed much after the initial creation of the repository ...

It's good to know that you are using 3.0.10 in production ... the configuration should be updated to reflect this (3.0.10 blessed as released and release3 pointing to 3.0.10 for GemStone 3.1 (and 2.4?)) then I will work to get 3.0.10 passing tests for GemStone 3.2 ...

Dale

On Wed, May 21, 2014 at 10:49 AM, Johan Brichau <[hidden email]> wrote:

ow wait.

I meant that for the version on Smalltalk hub / seaside.gemstone.com monticello

I have no idea what version is in that github repo.

Johan

On 21 May 2014, at 19:47, Dale Henrichs <[hidden email]> wrote:

> haha,take a look at the comment:)
>
> Dale
>
>
> On Wed, May 21, 2014 at 10:41 AM, Johan Brichau <[hidden email]> wrote:
>
> On 21 May 2014, at 15:32, Dale Henrichs <[hidden email]> wrote:
>
> > Trust the comment. There are later versions of 3.0 on smalltalk hub ... 3.0.9.1 is probably the latest version available that passes tests in GemStone...
>
> Actually, that should be 3.0.10
> Using it in production... :-)
>
> Johan
>

_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass

Dale Henrichs-3

Re: [Glass] callbackMarker not found in Seaside stack

In reply to this post by Johan Brichau-3

No problem, man! At the end of the day, we've got more (and better) information:)

On Wed, May 21, 2014 at 10:50 AM, Johan Brichau <[hidden email]> wrote:

Sorry about that, I misread the email.

johan

On 21 May 2014, at 19:49, Johan Brichau <[hidden email]> wrote:

> ow wait.
>
> I meant that for the version on Smalltalk hub / seaside.gemstone.com monticello
>
> I have no idea what version is in that github repo.
>
> Johan
>
> On 21 May 2014, at 19:47, Dale Henrichs <[hidden email]> wrote:
>
>> haha,take a look at the comment:)
>>
>> Dale
>>
>>
>> On Wed, May 21, 2014 at 10:41 AM, Johan Brichau <[hidden email]> wrote:
>>
>> On 21 May 2014, at 15:32, Dale Henrichs <[hidden email]> wrote:
>>
>>> Trust the comment. There are later versions of 3.0 on smalltalk hub ... 3.0.9.1 is probably the latest version available that passes tests in GemStone...
>>
>> Actually, that should be 3.0.10
>> Using it in production... :-)
>>
>> Johan
>>
>

_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass

Johan Brichau-3

Re: [Glass] callbackMarker not found in Seaside stack

In reply to this post by Dale Henrichs-3

On 21 May 2014, at 19:54, Dale Henrichs <[hidden email]> wrote:

> It's good to know that you are using 3.0.10 in production ... the configuration should be updated to reflect this (3.0.10 blessed as released and release3 pointing to 3.0.10 for GemStone 3.1 (and 2.4?)) then I will work to get 3.0.10 passing tests for GemStone 3.2 ...

Don't confuse between Seaside 3.0.x and Seaside 3.1.x !

#release3 correctly points to 3.1.0 (soon that will be 3.1.1)

I'm running 3.0.10 in production because we have not moved to Seaside 3.1 yet!
But I made 3.1.1 work for Gemstone 3.1

In the end, I'm not sure of these #release3 #release31 #release30 tags are not making it all more confusing.

Johan
_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass

Dale Henrichs-3

Re: [Glass] callbackMarker not found in Seaside stack

I'm just trying to fill out the matrix for GemStone3.2 ... I prefer to support "older versions" on newer versions of GemStone (to a certain extent) so that folks can move forward on GemStone without being forced to change to a different version of Seaside ...

I'm under the impression that moving from Seaside3.0 to Seaside3.1 is not a simple task, while getting Seaside3.0.10 running on GemStone3.2 is a simple task ...

I am probably the one that is confused... I read the blessing in the versions and when I saw development, I didn't read any further:)

Dale

On Thu, May 22, 2014 at 8:14 AM, Johan Brichau <[hidden email]> wrote:

On 21 May 2014, at 19:54, Dale Henrichs <[hidden email]> wrote:

> It's good to know that you are using 3.0.10 in production ... the configuration should be updated to reflect this (3.0.10 blessed as released and release3 pointing to 3.0.10 for GemStone 3.1 (and 2.4?)) then I will work to get 3.0.10 passing tests for GemStone 3.2 ...

Don't confuse between Seaside 3.0.x and Seaside 3.1.x !

#release3 correctly points to 3.1.0 (soon that will be 3.1.1)

I'm running 3.0.10 in production because we have not moved to Seaside 3.1 yet!
But I made 3.1.1 work for Gemstone 3.1

In the end, I'm not sure of these #release3 #release31 #release30 tags are not making it all more confusing.

Johan

_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass

Johan Brichau-3

Re: [Glass] callbackMarker not found in Seaside stack

On 22 May 2014, at 17:34, Dale Henrichs <[hidden email]> wrote:

> I'm under the impression that moving from Seaside3.0 to Seaside3.1 is not a simple task, while getting Seaside3.0.10 running on GemStone3.2 is a simple task ...

Right, I fully agree with that.

Johan
_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass

otto

Re: [Glass] callbackMarker not found in Seaside stack

>> I'm under the impression that moving from Seaside3.0 to Seaside3.1 is not a simple task, while getting Seaside3.0.10 running on GemStone3.2 is a simple task ...
>
> Right, I fully agree with that.

What makes this a big change? I'd like to consider the upgrade, but
you're making it a daunting task now :-)
_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass

Johan Brichau-3

Re: [Glass] callbackMarker not found in Seaside stack

On 28 May 2014, at 13:15, Otto Behrens <[hidden email]> wrote:

>>> I'm under the impression that moving from Seaside3.0 to Seaside3.1 is not a simple task, while getting Seaside3.0.10 running on GemStone3.2 is a simple task ...
>>
>> Right, I fully agree with that.
>
> What makes this a big change? I'd like to consider the upgrade, but
> you're making it a daunting task now :-)

WOOPS
I quoted the wrong sentence. Let me correct that.

I wanted to say I agree with the following sentence:

> I prefer to support "older versions" on newer versions of GemStone (to a certain extent) so that folks can move forward on GemStone without being forced to change to a different version of Seaside ...

Upgrading from 3.0 to 3.1 is not a difficult task at all actually.
It depends a bit on what you are using/extending, so see the change logs [1][2]

Sorry for that!

Johan

[1] https://code.google.com/p/seaside/wiki/Seaside310Changelog
[2] https://code.google.com/p/seaside/wiki/Seaside311Changelog
_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass

otto

Re: [Glass] callbackMarker not found in Seaside stack

Thanks

On Wed, May 28, 2014 at 1:20 PM, Johan Brichau <[hidden email]> wrote:

>
> On 28 May 2014, at 13:15, Otto Behrens <[hidden email]> wrote:
>
>>>> I'm under the impression that moving from Seaside3.0 to Seaside3.1 is not a simple task, while getting Seaside3.0.10 running on GemStone3.2 is a simple task ...
>>>
>>> Right, I fully agree with that.
>>
>> What makes this a big change? I'd like to consider the upgrade, but
>> you're making it a daunting task now :-)
>
> WOOPS
> I quoted the wrong sentence. Let me correct that.
>
> I wanted to say I agree with the following sentence:
>
>> I prefer to support "older versions" on newer versions of GemStone (to a certain extent) so that folks can move forward on GemStone without being forced to change to a different version of Seaside ...
>
> Upgrading from 3.0 to 3.1 is not a difficult task at all actually.
> It depends a bit on what you are using/extending, so see the change logs [1][2]
>
> Sorry for that!
>
> Johan
>
> [1] https://code.google.com/p/seaside/wiki/Seaside310Changelog
> [2] https://code.google.com/p/seaside/wiki/Seaside311Changelog

_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass