[Glass] Improved debugging of continuations from WAObjectLog

Hi guys,

I know we have tODE. Still, sometimes it's very useful to easily/quickly debug an error. Using tODE means someone needs to have a Pharo image with tODE client, tODE installed in the server, etc...  Of course, this is very much needed and worth for many developers. But sometimes, there are advanced users that would like a quick debug of the stack. Also, there might be a team where not all of them have the knowledge of GemStone...so they update the code to GemStone, they try it, and find errors.

So...for the above reasons, I tried to improve a bit the debugging of continuations from WAObjectLog. This is because I can render the component from within my webapp. This might be enough for fixing quite some bugs, and then let tODE/GemTools for the more complex bugs and for the more experienced developers.

Anyway, from what I see, WAObjectLog prints a dead string of the stack. See attached picture called "ObjectLogOld". So what I did now is to modify WAObjectLog to add one more column to the table with a "debug" link. The debug link will be present only for the object log entries that are continuations and should be able to be debugged. See attached "ObjectLogNewColumn".

Now, if I click in "debug" there, it opens a special subclass of WAGemStoneWalkback which simply has a "Full Stack" button and then below prints the stack. The printing of this stack is of course much better since I can see the state of the variables and links to seaside inspectors and friends (see file 'ObjectLogNewDebugInspectorOpened'). 

So yeah, it is a poor man debugger, but for easy bugs it may be useful for a couple of users.

If you think there could be others interested in this, I can package it (it's really little amount of code) and commit it to 'Seaside-GemStone-Tools-Production-ObjectLog'  but then I would like someone to review it at least.

Cheers, 

--

Mariano
http://marianopeck.wordpress.com

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

On Tue, Jun 2, 2015 at 8:59 PM, Dale Henrichs via Glass <[hidden email]> wrote:

This sounds like a pretty enhancement to the object log inspector! I say "ship it!"

Dale, 

Can you add me as contributor to https://github.com/GsDevKit/Seaside31  so that I can push my commits?

Thanks,

 

Dale

On 06/02/2015 04:12 PM, Mariano Martinez Peck via Glass wrote:

Hi guys,

I know we have tODE. Still, sometimes it's very useful to easily/quickly debug an error. Using tODE means someone needs to have a Pharo image with tODE client, tODE installed in the server, etc...  Of course, this is very much needed and worth for many developers. But sometimes, there are advanced users that would like a quick debug of the stack. Also, there might be a team where not all of them have the knowledge of GemStone...so they update the code to GemStone, they try it, and find errors.

So...for the above reasons, I tried to improve a bit the debugging of continuations from WAObjectLog. This is because I can render the component from within my webapp. This might be enough for fixing quite some bugs, and then let tODE/GemTools for the more complex bugs and for the more experienced developers.

Anyway, from what I see, WAObjectLog prints a dead string of the stack. See attached picture called "ObjectLogOld". So what I did now is to modify WAObjectLog to add one more column to the table with a "debug" link. The debug link will be present only for the object log entries that are continuations and should be able to be debugged. See attached "ObjectLogNewColumn".

Now, if I click in "debug" there, it opens a special subclass of WAGemStoneWalkback which simply has a "Full Stack" button and then below prints the stack. The printing of this stack is of course much better since I can see the state of the variables and links to seaside inspectors and friends (see file 'ObjectLogNewDebugInspectorOpened'). 

So yeah, it is a poor man debugger, but for easy bugs it may be useful for a couple of users.

If you think there could be others interested in this, I can package it (it's really little amount of code) and commit it to 'Seaside-GemStone-Tools-Production-ObjectLog'  but then I would like someone to review it at least.

Cheers, 

--

Mariano
http://marianopeck.wordpress.com

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

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

--

Mariano
http://marianopeck.wordpress.com

On Wed, Jun 3, 2015 at 6:35 PM, Dale Henrichs <[hidden email]> wrote:

Mariano,

I've added you as a member of the dev team, but Johan is correct that the way to go most of the time is to create a pull request from your own fork (as you've done) the travis tests are run against your fork and team members have a chance to review and comment on the changes which is a good thing!

The tests ran green for your changes and I did the merge this morning!

Thanks Dale!   Yes, I understand and makes sense. I am just a bit slow with git yet ;)

BTW...did you see my comment here https://github.com/GsDevKit/Seaside31/pull/74#event-321526451 ?

Thanks!

 

Dale

On 06/03/2015 06:18 AM, Mariano Martinez Peck wrote:

On Tue, Jun 2, 2015 at 8:59 PM, Dale Henrichs via Glass <[hidden email]> wrote:

This sounds like a pretty enhancement to the object log inspector! I say "ship it!"

Dale, 

Can you add me as contributor to https://github.com/GsDevKit/Seaside31  so that I can push my commits?

Thanks,

 

Dale

On 06/02/2015 04:12 PM, Mariano Martinez Peck via Glass wrote:

Hi guys,

I know we have tODE. Still, sometimes it's very useful to easily/quickly debug an error. Using tODE means someone needs to have a Pharo image with tODE client, tODE installed in the server, etc...  Of course, this is very much needed and worth for many developers. But sometimes, there are advanced users that would like a quick debug of the stack. Also, there might be a team where not all of them have the knowledge of GemStone...so they update the code to GemStone, they try it, and find errors.

So...for the above reasons, I tried to improve a bit the debugging of continuations from WAObjectLog. This is because I can render the component from within my webapp. This might be enough for fixing quite some bugs, and then let tODE/GemTools for the more complex bugs and for the more experienced developers.

Anyway, from what I see, WAObjectLog prints a dead string of the stack. See attached picture called "ObjectLogOld". So what I did now is to modify WAObjectLog to add one more column to the table with a "debug" link. The debug link will be present only for the object log entries that are continuations and should be able to be debugged. See attached "ObjectLogNewColumn".

Now, if I click in "debug" there, it opens a special subclass of WAGemStoneWalkback which simply has a "Full Stack" button and then below prints the stack. The printing of this stack is of course much better since I can see the state of the variables and links to seaside inspectors and friends (see file 'ObjectLogNewDebugInspectorOpened'). 

So yeah, it is a poor man debugger, but for easy bugs it may be useful for a couple of users.

If you think there could be others interested in this, I can package it (it's really little amount of code) and commit it to 'Seaside-GemStone-Tools-Production-ObjectLog'  but then I would like someone to review it at least.

Cheers, 

--

Mariano
http://marianopeck.wordpress.com

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

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

--

Mariano
http://marianopeck.wordpress.com

--

Mariano
http://marianopeck.wordpress.com

Thanks Dale. Just to know where i continue the discussion..did you get an email with my new answer?

On Thu, Jun 4, 2015 at 1:36 PM, Dale Henrichs <[hidden email]> wrote:

I hadn't seen your comment until now, and I've responded ...

Dale

On 06/03/2015 03:55 PM, Mariano Martinez Peck wrote:

On Wed, Jun 3, 2015 at 6:35 PM, Dale Henrichs <[hidden email]> wrote:

Mariano,

I've added you as a member of the dev team, but Johan is correct that the way to go most of the time is to create a pull request from your own fork (as you've done) the travis tests are run against your fork and team members have a chance to review and comment on the changes which is a good thing!

The tests ran green for your changes and I did the merge this morning!

Thanks Dale!   Yes, I understand and makes sense. I am just a bit slow with git yet ;)

BTW...did you see my comment here https://github.com/GsDevKit/Seaside31/pull/74#event-321526451 ?

Thanks!

 

Dale

On 06/03/2015 06:18 AM, Mariano Martinez Peck wrote:

On Tue, Jun 2, 2015 at 8:59 PM, Dale Henrichs via Glass <[hidden email]> wrote:

This sounds like a pretty enhancement to the object log inspector! I say "ship it!"

Dale, 

Can you add me as contributor to https://github.com/GsDevKit/Seaside31  so that I can push my commits?

Thanks,

 

Dale

On 06/02/2015 04:12 PM, Mariano Martinez Peck via Glass wrote:

Hi guys,

I know we have tODE. Still, sometimes it's very useful to easily/quickly debug an error. Using tODE means someone needs to have a Pharo image with tODE client, tODE installed in the server, etc...  Of course, this is very much needed and worth for many developers. But sometimes, there are advanced users that would like a quick debug of the stack. Also, there might be a team where not all of them have the knowledge of GemStone...so they update the code to GemStone, they try it, and find errors.

So...for the above reasons, I tried to improve a bit the debugging of continuations from WAObjectLog. This is because I can render the component from within my webapp. This might be enough for fixing quite some bugs, and then let tODE/GemTools for the more complex bugs and for the more experienced developers.

Anyway, from what I see, WAObjectLog prints a dead string of the stack. See attached picture called "ObjectLogOld". So what I did now is to modify WAObjectLog to add one more column to the table with a "debug" link. The debug link will be present only for the object log entries that are continuations and should be able to be debugged. See attached "ObjectLogNewColumn".

Now, if I click in "debug" there, it opens a special subclass of WAGemStoneWalkback which simply has a "Full Stack" button and then below prints the stack. The printing of this stack is of course much better since I can see the state of the variables and links to seaside inspectors and friends (see file 'ObjectLogNewDebugInspectorOpened'). 

So yeah, it is a poor man debugger, but for easy bugs it may be useful for a couple of users.

If you think there could be others interested in this, I can package it (it's really little amount of code) and commit it to 'Seaside-GemStone-Tools-Production-ObjectLog'  but then I would like someone to review it at least.

Cheers, 

--

Mariano
http://marianopeck.wordpress.com

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

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

--

Mariano
http://marianopeck.wordpress.com

--

Mariano
http://marianopeck.wordpress.com

--

Mariano
http://marianopeck.wordpress.com