Smalltalk › Frameworks & Tools › Seaside › Seaside General

The session in the debugger

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

21 messages Options

Philippe Marschall

The session in the debugger

Hi

One of the most annoying things about Seaside for me is that you can't
access the session in the debugger. Often when debugging code that
needs to access some session data I find myself writing code like
this:

aBuggedMethod
"some code"
session := self session.
self halt.
"more code"

and then restarting the method. I am sick of it. This just sucks. So
recently I meant someone with too much time who would like to make a
valuable contribution to Seaside. I told him about this and he said he
would do it if I find at least 5 people to whom it is important.

Personally I don't care how ugly the solution is as long as Seaside
still works. It doesn't have to be a general solutions. It can be a
very evil changeset that causes famine, plague, small pocks and
shortens life by 10 years. That desperately I want it.

If you feel the same way raise your hand now.

Cheers
Philippe
_______________________________________________
Seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

Boris Popov, DeepCove Labs (SNN)

Re: The session in the debugger

Re: [Seaside] The session in the debugger

I wouldn't mind being able to step over session as well.

Cheers!

-Boris
(Sent from a BlackBerry)

----- Original Message -----
From: [hidden email] <[hidden email]>
To: The Squeak Enterprise Aubergines Server - general discussion. <[hidden email]>
Sent: Sun Feb 04 10:19:00 2007
Subject: [Seaside] The session in the debugger

Hi

One of the most annoying things about Seaside for me is that you can't
access the session in the debugger. Often when debugging code that
needs to access some session data I find myself writing code like
this:

aBuggedMethod
    "some code"
    session := self session.
    self halt.
    "more code"

and then restarting the method. I am sick of it. This just sucks. So
recently I meant someone with too much time who would like to make a
valuable contribution to Seaside. I told him about this and he said he
would do it if I find at least 5 people to whom it is important.

Personally I don't care how ugly the solution is as long as Seaside
still works. It doesn't have to be a general solutions. It can be a
very evil changeset that causes famine, plague, small pocks and
shortens life by 10 years. That desperately I want it.

If you feel the same way raise your hand now.

Cheers
Philippe
_______________________________________________
Seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

_______________________________________________
Seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

Yann Monclair-2

Re: The session in the debugger

In reply to this post by Philippe Marschall

+1

This would be great

Yann

Philippe Marschall wrote:

> Hi
>
> One of the most annoying things about Seaside for me is that you can't
> access the session in the debugger. Often when debugging code that
> needs to access some session data I find myself writing code like
> this:
>
> aBuggedMethod
> "some code"
> session := self session.
> self halt.
> "more code"
>
> and then restarting the method. I am sick of it. This just sucks. So
> recently I meant someone with too much time who would like to make a
> valuable contribution to Seaside. I told him about this and he said he
> would do it if I find at least 5 people to whom it is important.
>
> Personally I don't care how ugly the solution is as long as Seaside
> still works. It doesn't have to be a general solutions. It can be a
> very evil changeset that causes famine, plague, small pocks and
> shortens life by 10 years. That desperately I want it.
>
> If you feel the same way raise your hand now.
>
> Cheers
> Philippe
> _______________________________________________
> Seaside mailing list
> [hidden email]
> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

_______________________________________________
Seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

Michel Bany-3

Re: The session in the debugger

In reply to this post by Philippe Marschall

Philippe Marschall a écrit :

In the VisualWorks version of Seaside, I patched the VisualWorks
debugger so that
the current session object is always available in the debugger if there
is one.
See the lower right panes in this picture
ftp://ftp.bany.fr/seaside/Session.gif
The code for this is in package Seaside-VW-Debugging.
Maybe that can be ported to Squeak.
HTH
Michel.

> Cheers
> Philippe
> _______________________________________________
> Seaside mailing list
> [hidden email]
> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
> ---------------------------------------------------------------------------------------
>
> Orange vous informe que cet e-mail a ete controle par l'anti-virus
> mail. Aucun virus connu a ce jour par nos services n'a ete detecte.
>
>
>

_______________________________________________
Seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

Boris Popov, DeepCove Labs (SNN)

Re: The session in the debugger

In reply to this post by Philippe Marschall

Re: [Seaside] The session in the debugger

But you still can't step through code though or swipe and do-it, which would be nice, don't you think? Not a show stopper though that's for sure.

Cheers!

-Boris
(Sent from a BlackBerry)

----- Original Message -----
From: [hidden email] <[hidden email]>
To: The Squeak Enterprise Aubergines Server - general discussion. <[hidden email]>
Sent: Sun Feb 04 10:36:00 2007
Subject: Re: [Seaside] The session in the debugger

Philippe Marschall a écrit :
> Hi
>
> One of the most annoying things about Seaside for me is that you can't
> access the session in the debugger. Often when debugging code that
> needs to access some session data I find myself writing code like
> this:
>
> aBuggedMethod
>    "some code"
>    session := self session.
>    self halt.
>    "more code"
>
> and then restarting the method. I am sick of it. This just sucks. So
> recently I meant someone with too much time who would like to make a
> valuable contribution to Seaside. I told him about this and he said he
> would do it if I find at least 5 people to whom it is important.
>
> Personally I don't care how ugly the solution is as long as Seaside
> still works. It doesn't have to be a general solutions. It can be a
> very evil changeset that causes famine, plague, small pocks and
> shortens life by 10 years. That desperately I want it.
>
> If you feel the same way raise your hand now.
>
In the VisualWorks version of Seaside, I patched the VisualWorks
debugger so that
the current session object is always available in the debugger if there
is one.
See the lower right panes in this picture
ftp://ftp.bany.fr/seaside/Session.gif
The code for this is in package Seaside-VW-Debugging.
Maybe that can be ported to Squeak.
HTH
Michel.

> Cheers
> Philippe
> _______________________________________________
> Seaside mailing list
> [hidden email]
> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
> ---------------------------------------------------------------------------------------
>
> Orange vous informe que cet e-mail a ete controle par l'anti-virus
> mail. Aucun virus connu a ce jour par nos services n'a ete detecte.
>
>
>
_______________________________________________
Seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

_______________________________________________
Seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

Michel Bany-3

Re: The session in the debugger

In reply to this post by Boris Popov, DeepCove Labs (SNN)

Boris Popov a écrit :
>
> I wouldn't mind being able to step over session as well.
>
Boris,
My debugger patches also provide for stepping over "self session".
So I do not quite understand what you mean. Can you clarify.
Michel.

_______________________________________________
Seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

Boris Popov, DeepCove Labs (SNN)

Re: The session in the debugger

In reply to this post by Philippe Marschall

Re: [Seaside] The session in the debugger

Oh? My bad, maybe I haven't tried it recently, ill get back to you once confirmed.

Cheers!

-Boris
(Sent from a BlackBerry)

----- Original Message -----
From: [hidden email] <[hidden email]>
To: The Squeak Enterprise Aubergines Server - general discussion. <[hidden email]>
Sent: Sun Feb 04 10:40:58 2007
Subject: Re: [Seaside] The session in the debugger

Boris Popov a écrit :
>
> I wouldn't mind being able to step over session as well.
>
Boris,
My debugger patches also provide for stepping over "self session".
So I do not quite understand what you mean. Can you clarify.
Michel.

_______________________________________________
Seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

_______________________________________________
Seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

Klaus D. Witzel

Re: The session in the debugger

In reply to this post by Philippe Marschall

On Sun, 04 Feb 2007 19:19:00 +0100, Philippe Marschall wrote:

Counting someone at our table in Bern plus /my, you've found five people :)

Attached is a .cs which shows (self session) in the debugger (same place
as in Michel's VW solution) only if (aContext receiver respondsTo:
#session). #session seems not to be implemented in the stock image. When
the session item is selected it can be inspected but update with #accept
does not update.

> Personally I don't care how ugly the solution is as long as Seaside
> still works. It doesn't have to be a general solutions. It can be a
> very evil changeset that causes famine, plague, small pocks and
> shortens life by 10 years. That desperately I want it.

Tested it on 3.7/8/9, let me know how it works.

If someone needs the name emphasized in the debugger, please post how
you'd like to have it.

/Klaus

> If you feel the same way raise your hand now.
>
> Cheers
> Philippe
_______________________________________________
Seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

DebugSessionVariable-kwl.1.cs (3K) Download Attachment

Ron Teitelbaum

RE: The session in the debugger

In reply to this post by Philippe Marschall

+1 I hit that all the time.

Better yet it would be great to have a direct connection between the
instance of Component/application and the session that created it. I
implemented a stack that keeps track of which application I'm currently in
just to do this!

In case the question of why comes up. I added an automatic object
registration. Each application responds to handlesCommit. When an object
is created it automatically finds the application in the stack that is
currently handling the commit and registers itself in a dirtySet.

Ron

> -----Original Message-----
> From: [hidden email] [mailto:seaside-
> [hidden email]] On Behalf Of Philippe Marschall
> Sent: Sunday, February 04, 2007 1:19 PM
> To: The Squeak Enterprise Aubergines Server - general discussion.
> Subject: [Seaside] The session in the debugger
>
> Hi
>
> One of the most annoying things about Seaside for me is that you can't
> access the session in the debugger. Often when debugging code that
> needs to access some session data I find myself writing code like
> this:
>
> aBuggedMethod
> "some code"
> session := self session.
> self halt.
> "more code"
>
> and then restarting the method. I am sick of it. This just sucks. So
> recently I meant someone with too much time who would like to make a
> valuable contribution to Seaside. I told him about this and he said he
> would do it if I find at least 5 people to whom it is important.
>
> Personally I don't care how ugly the solution is as long as Seaside
> still works. It doesn't have to be a general solutions. It can be a
> very evil changeset that causes famine, plague, small pocks and
> shortens life by 10 years. That desperately I want it.
>
> If you feel the same way raise your hand now.
>
> Cheers
> Philippe
> _______________________________________________
> Seaside mailing list
> [hidden email]
> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

_______________________________________________
Seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

Philippe Marschall

Re: Re: The session in the debugger

In reply to this post by Klaus D. Witzel

2007/2/4, Klaus D. Witzel <[hidden email]>:

> On Sun, 04 Feb 2007 19:19:00 +0100, Philippe Marschall wrote:
> > Hi
> >
> > One of the most annoying things about Seaside for me is that you can't
> > access the session in the debugger. Often when debugging code that
> > needs to access some session data I find myself writing code like
> > this:
> >
> > aBuggedMethod
> > "some code"
> > session := self session.
> > self halt.
> > "more code"
> >
> > and then restarting the method. I am sick of it. This just sucks. So
> > recently I meant someone with too much time who would like to make a
> > valuable contribution to Seaside. I told him about this and he said he
> > would do it if I find at least 5 people to whom it is important.
>
> Counting someone at our table in Bern plus /my, you've found five people :)
>
> Attached is a .cs which shows (self session) in the debugger (same place
> as in Michel's VW solution) only if (aContext receiver respondsTo:
> #session). #session seems not to be implemented in the stock image. When
> the session item is selected it can be inspected but update with #accept
> does not update.
>
> > Personally I don't care how ugly the solution is as long as Seaside
> > still works. It doesn't have to be a general solutions. It can be a
> > very evil changeset that causes famine, plague, small pocks and
> > shortens life by 10 years. That desperately I want it.
>
> Tested it on 3.7/8/9, let me know how it works.

Yes there is a session variable in the debugger but it is nil. That is
not what I meant. What I want is being able to do:

self session

in the debugger and it returns the session instead of nil.

Sorry for not being more clear.

Philippe

> If someone needs the name emphasized in the debugger, please post how
> you'd like to have it.
>
> /Klaus
>
> > If you feel the same way raise your hand now.
> >
> > Cheers
> > Philippe
>
> _______________________________________________
> Seaside mailing list
> [hidden email]
> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
>
>
>
>

_______________________________________________
Seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

Klaus D. Witzel

Re: Re: The session in the debugger

On Mon, 05 Feb 2007 10:10:00 +0100, Philippe Marschall wrote:

> 2007/2/4, Klaus D. Witzel:
>> On Sun, 04 Feb 2007 19:19:00 +0100, Philippe Marschall wrote:
>> > Hi
>> >
>> > One of the most annoying things about Seaside for me is that you can't
>> > access the session in the debugger. Often when debugging code that
>> > needs to access some session data I find myself writing code like
>> > this:
>> >
>> > aBuggedMethod
>> > "some code"
>> > session := self session.
>> > self halt.
>> > "more code"
>> >
>> > and then restarting the method. I am sick of it. This just sucks. So
>> > recently I meant someone with too much time who would like to make a
>> > valuable contribution to Seaside. I told him about this and he said he
>> > would do it if I find at least 5 people to whom it is important.
>>
>> Counting someone at our table in Bern plus /my, you've found five
>> people :)
>>
>> Attached is a .cs which shows (self session) in the debugger (same place
>> as in Michel's VW solution) only if (aContext receiver respondsTo:
>> #session). #session seems not to be implemented in the stock image. When
>> the session item is selected it can be inspected but update with #accept
>> does not update.
>>
>> > Personally I don't care how ugly the solution is as long as Seaside
>> > still works. It doesn't have to be a general solutions. It can be a
>> > very evil changeset that causes famine, plague, small pocks and
>> > shortens life by 10 years. That desperately I want it.
>>
>> Tested it on 3.7/8/9, let me know how it works.
>
> Yes there is a session variable in the debugger but it is nil. That is
> not what I meant. What I want is being able to do:
>
> self session
>
> in the debugger and it returns the session instead of nil.

The debugger sends (aContext receiver) session, which is all it can. Of
course the debugger's stack is not the same as aContext's stack, this can
be the cause of nil.

> Sorry for not being more clear.

NP. Does (self session) in the debugger's left pane (where the ivars are)
return the object that you want? If not so, then I'll have to dig deeper
and find where the stack is switched or else manually traverse aContext
sender, or so.

Anyways I'll try to reproduce this with the most recent Seaside-dev image.
Which method in that image would be best for provoking this situation? TIA.

/Klaus

> Philippe
>
>> If someone needs the name emphasized in the debugger, please post how
>> you'd like to have it.
>>
>> /Klaus
>>
>> > If you feel the same way raise your hand now.
>> >
>> > Cheers
>> > Philippe
>>
>> _______________________________________________
>> Seaside mailing list
>> [hidden email]
>> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
>>
>>
>>
>>

_______________________________________________
Seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

Michel Bany

Re: Re: Re: The session in the debugger

>> Yes there is a session variable in the debugger but it is nil.
>> That is
>> not what I meant. What I want is being able to do:
>>
>> self session
>>
>> in the debugger and it returns the session instead of nil.
>
> The debugger sends (aContext receiver) session, which is all it
> can. Of course the debugger's stack is not the same as aContext's
> stack, this can be the cause of nil.

FWIW, the VW implementation traverses the context stack until it
finds a context
where the method is WADynamicVariable>>use:during: The session object
is the
first argument of the method (in VW it is localAt: 1). With this
technique you see the
session object in debugger's right panes for all stack frames that
are above
#use:during: not only for those stack frames where the receiver is a
WAComponent
instance.
Cheers,
Michel.

>
>> Sorry for not being more clear.
>
> NP. Does (self session) in the debugger's left pane (where the
> ivars are) return the object that you want? If not so, then I'll
> have to dig deeper and find where the stack is switched or else
> manually traverse aContext sender, or so.
>
> Anyways I'll try to reproduce this with the most recent Seaside-dev
> image. Which method in that image would be best for provoking this
> situation? TIA.
>

_______________________________________________
Seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

Philippe Marschall

Re: Re: Re: The session in the debugger

In reply to this post by Klaus D. Witzel

2007/2/5, Klaus D. Witzel <[hidden email]>:

> On Mon, 05 Feb 2007 10:10:00 +0100, Philippe Marschall wrote:
> > 2007/2/4, Klaus D. Witzel:
> >> On Sun, 04 Feb 2007 19:19:00 +0100, Philippe Marschall wrote:
> >> > Hi
> >> >
> >> > One of the most annoying things about Seaside for me is that you can't
> >> > access the session in the debugger. Often when debugging code that
> >> > needs to access some session data I find myself writing code like
> >> > this:
> >> >
> >> > aBuggedMethod
> >> > "some code"
> >> > session := self session.
> >> > self halt.
> >> > "more code"
> >> >
> >> > and then restarting the method. I am sick of it. This just sucks. So
> >> > recently I meant someone with too much time who would like to make a
> >> > valuable contribution to Seaside. I told him about this and he said he
> >> > would do it if I find at least 5 people to whom it is important.
> >>
> >> Counting someone at our table in Bern plus /my, you've found five
> >> people :)
> >>
> >> Attached is a .cs which shows (self session) in the debugger (same place
> >> as in Michel's VW solution) only if (aContext receiver respondsTo:
> >> #session). #session seems not to be implemented in the stock image. When
> >> the session item is selected it can be inspected but update with #accept
> >> does not update.
> >>
> >> > Personally I don't care how ugly the solution is as long as Seaside
> >> > still works. It doesn't have to be a general solutions. It can be a
> >> > very evil changeset that causes famine, plague, small pocks and
> >> > shortens life by 10 years. That desperately I want it.
> >>
> >> Tested it on 3.7/8/9, let me know how it works.
> >
> > Yes there is a session variable in the debugger but it is nil. That is
> > not what I meant. What I want is being able to do:
> >
> > self session
> >
> > in the debugger and it returns the session instead of nil.
>
> The debugger sends (aContext receiver) session, which is all it can. Of
> course the debugger's stack is not the same as aContext's stack, this can
> be the cause of nil.
>
> > Sorry for not being more clear.
>
> NP. Does (self session) in the debugger's left pane (where the ivars are)
> return the object that you want?

No

> If not so, then I'll have to dig deeper
> and find where the stack is switched or else manually traverse aContext
> sender, or so.
>
> Anyways I'll try to reproduce this with the most recent Seaside-dev image.
> Which method in that image would be best for provoking this situation? TIA.

A simple example would be to change #increase in the WACounter to:

increase
1 / 0.
count := count + 1

Which will get you a walback. Click on debug. In the debuger evalutate
code like:

self session useSessionCookie

Philippe

> /Klaus
>
> > Philippe
> >
> >> If someone needs the name emphasized in the debugger, please post how
> >> you'd like to have it.
> >>
> >> /Klaus
> >>
> >> > If you feel the same way raise your hand now.
> >> >
> >> > Cheers
> >> > Philippe
> >>
> >> _______________________________________________
> >> Seaside mailing list
> >> [hidden email]
> >> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
> >>
> >>
> >>
> >>
>
>
> _______________________________________________
> Seaside mailing list
> [hidden email]
> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
>

_______________________________________________
Seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

Sebastian Sastre-2

RE: The session in the debugger (online?)

In reply to this post by Philippe Marschall

I don't know if I'm going too far but asking doesn't hurts so.. What about
making the debugger to be online like the class browser reached by the
halos?

I'm pretty sure that for customers it makes no difference but for developers
that will rocks !

cheers,

Sebastian Sastre

-----Mensaje original-----
De: [hidden email]
[mailto:[hidden email]] En nombre de Philippe
Marschall
Enviado el: Domingo, 04 de Febrero de 2007 16:19
Para: The Squeak Enterprise Aubergines Server - general discussion.
Asunto: [Seaside] The session in the debugger

Hi

One of the most annoying things about Seaside for me is that you can't
access the session in the debugger. Often when debugging code that needs to
access some session data I find myself writing code like
this:

aBuggedMethod
"some code"
session := self session.
self halt.
"more code"

and then restarting the method. I am sick of it. This just sucks. So
recently I meant someone with too much time who would like to make a
valuable contribution to Seaside. I told him about this and he said he would
do it if I find at least 5 people to whom it is important.

Personally I don't care how ugly the solution is as long as Seaside still
works. It doesn't have to be a general solutions. It can be a very evil
changeset that causes famine, plague, small pocks and shortens life by 10
years. That desperately I want it.

If you feel the same way raise your hand now.

Cheers
Philippe
_______________________________________________
Seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

_______________________________________________
Seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

Boris Popov, DeepCove Labs (SNN)

RE: The session in the debugger (online?)

Would you really find that useful? Debugger in VisualWorks is greatly
integrated with the tools, having a simplified version online would
literally see zero use there, not sure about Squeak.

Cheers,

-Boris

--
+1.604.689.0322
DeepCove Labs Ltd.
4th floor 595 Howe Street
Vancouver, Canada V6C 2T5
http://tinyurl.com/r7uw4

[hidden email]

CONFIDENTIALITY NOTICE

This email is intended only for the persons named in the message
header. Unless otherwise indicated, it contains information that is
private and confidential. If you have received it in error, please
notify the sender and delete the entire message including any
attachments.

Thank you.

-----Original Message-----
From: [hidden email]
[mailto:[hidden email]] On Behalf Of
Sebastian Sastre
Sent: Monday, February 05, 2007 2:06 PM
To: 'The Squeak Enterprise Aubergines Server - general discussion.'
Subject: RE: [Seaside] The session in the debugger (online?)

I don't know if I'm going too far but asking doesn't hurts so.. What
about
making the debugger to be online like the class browser reached by the
halos?

I'm pretty sure that for customers it makes no difference but for
developers
that will rocks !

cheers,

Sebastian Sastre

-----Mensaje original-----
De: [hidden email]
[mailto:[hidden email]] En nombre de
Philippe
Marschall
Enviado el: Domingo, 04 de Febrero de 2007 16:19
Para: The Squeak Enterprise Aubergines Server - general discussion.
Asunto: [Seaside] The session in the debugger

Hi

One of the most annoying things about Seaside for me is that you can't
access the session in the debugger. Often when debugging code that needs
to
access some session data I find myself writing code like
this:

aBuggedMethod
"some code"
session := self session.
self halt.
"more code"

and then restarting the method. I am sick of it. This just sucks. So
recently I meant someone with too much time who would like to make a
valuable contribution to Seaside. I told him about this and he said he
would
do it if I find at least 5 people to whom it is important.

Personally I don't care how ugly the solution is as long as Seaside
still
works. It doesn't have to be a general solutions. It can be a very evil
changeset that causes famine, plague, small pocks and shortens life by
10
years. That desperately I want it.

If you feel the same way raise your hand now.

Cheers
Philippe
_______________________________________________
Seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

_______________________________________________
Seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
_______________________________________________
Seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

Sebastian Sastre-2

RE: The session in the debugger (online?)

Dear Boris,

well, besides the idea is in the same "path" than the online class
browser, certainly it would be.

One scenario I can imagine could be a presentation or a demo of a
prototype app where "what is supoused not to happen happens" and your server
is not in the next room. If you, for any reason, don't have a local version
of the app it could be a real lifeboat.

And that os not coupled with any ST platform.

Cheers,

Sebastian Sastre

-----Mensaje original-----
De: [hidden email]
[mailto:[hidden email]] En nombre de Boris Popov
Enviado el: Lunes, 05 de Febrero de 2007 20:36
Para: The Squeak Enterprise Aubergines Server - general discussion.
Asunto: RE: [Seaside] The session in the debugger (online?)

Would you really find that useful? Debugger in VisualWorks is greatly
integrated with the tools, having a simplified version online would
literally see zero use there, not sure about Squeak.

Cheers,

-Boris

--
+1.604.689.0322
DeepCove Labs Ltd.
4th floor 595 Howe Street
Vancouver, Canada V6C 2T5
http://tinyurl.com/r7uw4

[hidden email]

CONFIDENTIALITY NOTICE

This email is intended only for the persons named in the message header.
Unless otherwise indicated, it contains information that is private and
confidential. If you have received it in error, please notify the sender and
delete the entire message including any attachments.

Thank you.

-----Original Message-----
From: [hidden email]
[mailto:[hidden email]] On Behalf Of Sebastian
Sastre
Sent: Monday, February 05, 2007 2:06 PM
To: 'The Squeak Enterprise Aubergines Server - general discussion.'
Subject: RE: [Seaside] The session in the debugger (online?)

I don't know if I'm going too far but asking doesn't hurts so.. What about
making the debugger to be online like the class browser reached by the
halos?

I'm pretty sure that for customers it makes no difference but for developers
that will rocks !

cheers,

Sebastian Sastre

-----Mensaje original-----
De: [hidden email]
[mailto:[hidden email]] En nombre de Philippe
Marschall Enviado el: Domingo, 04 de Febrero de 2007 16:19
Para: The Squeak Enterprise Aubergines Server - general discussion.
Asunto: [Seaside] The session in the debugger

Hi

One of the most annoying things about Seaside for me is that you can't
access the session in the debugger. Often when debugging code that needs to
access some session data I find myself writing code like
this:

aBuggedMethod
"some code"
session := self session.
self halt.
"more code"

and then restarting the method. I am sick of it. This just sucks. So
recently I meant someone with too much time who would like to make a
valuable contribution to Seaside. I told him about this and he said he would
do it if I find at least 5 people to whom it is important.

Personally I don't care how ugly the solution is as long as Seaside still
works. It doesn't have to be a general solutions. It can be a very evil
changeset that causes famine, plague, small pocks and shortens life by 10
years. That desperately I want it.

If you feel the same way raise your hand now.

Cheers
Philippe
_______________________________________________
Seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

_______________________________________________
Seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
_______________________________________________
Seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

_______________________________________________
Seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

Klaus D. Witzel

Re: The session in the debugger

In reply to this post by Philippe Marschall

Stack search now added and (surprise! :) now it shows seaside's session in
the debugger (labelled aSession class name).

/Klaus

On Mon, 05 Feb 2007 17:31:23 +0100, Philippe Marschall wrote:

> 2007/2/5, Klaus D. Witzel <[hidden email]>:
>> On Mon, 05 Feb 2007 10:10:00 +0100, Philippe Marschall wrote:
>> > 2007/2/4, Klaus D. Witzel:
>> >> On Sun, 04 Feb 2007 19:19:00 +0100, Philippe Marschall wrote:
>> >> > Hi
>> >> >
>> >> > One of the most annoying things about Seaside for me is that you
>> can't
>> >> > access the session in the debugger. Often when debugging code that
>> >> > needs to access some session data I find myself writing code like
>> >> > this:
>> >> >
>> >> > aBuggedMethod
>> >> > "some code"
>> >> > session := self session.
>> >> > self halt.
>> >> > "more code"
>> >> >
>> >> > and then restarting the method. I am sick of it. This just sucks.
>> So
>> >> > recently I meant someone with too much time who would like to make
>> a
>> >> > valuable contribution to Seaside. I told him about this and he
>> said he
>> >> > would do it if I find at least 5 people to whom it is important.
>> >>
>> >> Counting someone at our table in Bern plus /my, you've found five
>> >> people :)
>> >>
>> >> Attached is a .cs which shows (self session) in the debugger (same
>> place
>> >> as in Michel's VW solution) only if (aContext receiver respondsTo:
>> >> #session). #session seems not to be implemented in the stock image.
>> When
>> >> the session item is selected it can be inspected but update with
>> #accept
>> >> does not update.
>> >>
>> >> > Personally I don't care how ugly the solution is as long as Seaside
>> >> > still works. It doesn't have to be a general solutions. It can be a
>> >> > very evil changeset that causes famine, plague, small pocks and
>> >> > shortens life by 10 years. That desperately I want it.
>> >>
>> >> Tested it on 3.7/8/9, let me know how it works.
>> >
>> > Yes there is a session variable in the debugger but it is nil. That is
>> > not what I meant. What I want is being able to do:
>> >
>> > self session
>> >
>> > in the debugger and it returns the session instead of nil.
>>
>> The debugger sends (aContext receiver) session, which is all it can. Of
>> course the debugger's stack is not the same as aContext's stack, this
>> can
>> be the cause of nil.
>>
>> > Sorry for not being more clear.
>>
>> NP. Does (self session) in the debugger's left pane (where the ivars
>> are)
>> return the object that you want?
>
> No
>
>> If not so, then I'll have to dig deeper
>> and find where the stack is switched or else manually traverse aContext
>> sender, or so.
>>
>> Anyways I'll try to reproduce this with the most recent Seaside-dev
>> image.
>> Which method in that image would be best for provoking this situation?
>> TIA.
>
> A simple example would be to change #increase in the WACounter to:
>
> increase
> 1 / 0.
> count := count + 1
>
> Which will get you a walback. Click on debug. In the debuger evalutate
> code like:
>
> self session useSessionCookie
>
> Philippe
>
>> /Klaus
>>
>> > Philippe
>> >
>> >> If someone needs the name emphasized in the debugger, please post how
>> >> you'd like to have it.
>> >>
>> >> /Klaus
>> >>
>> >> > If you feel the same way raise your hand now.
>> >> >
>> >> > Cheers
>> >> > Philippe
>> >>
>> >> _______________________________________________
>> >> Seaside mailing list
>> >> [hidden email]
>> >> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
>> >>
>> >>
>> >>
>> >>
>>
>>
>> _______________________________________________
>> Seaside mailing list
>> [hidden email]
>> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
>>

_______________________________________________
Seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

DebugSessionVariable-kwl.2.cs (4K) Download Attachment

Lukas Renggli

Re: Re: The session in the debugger

> Stack search now added and (surprise! :) now it shows seaside's session in
> the debugger (labelled aSession class name).

I don't think this is quite what we want: We would like to be able to
select any part of the code in the code pane and evaluate it. This
code might directly or indirectly do a stack-lookup for dynamic
variables such as (but not limited to) the current session. This does
not work right now, as a doIt is not executed in the context of the
debugger.

Now this is a little bit tricky. When processing a doIt the execution
stack in the debugger should be chained with the one from the doIt,
but otherwise not touched or unwound. I already do chain two execution
stacks with Continuation>>#invoke:, but in the debugger this seems to
be slightly more tricky ...

Cheers,
Lukas

--
Lukas Renggli
http://www.lukas-renggli.ch
_______________________________________________
Seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

Klaus D. Witzel

Re: The session in the debugger

Hi Lukas,

on Wed, 07 Feb 2007 22:26:14 +0100, you wrote:

>> Stack search now added and (surprise! :) now it shows seaside's session
>> in
>> the debugger (labelled aSession class name).
>
> I don't think this is quite what we want:

No nitpicking: this thread is about The session in the debugger :)

> We would like to be able to
> select any part of the code in the code pane and evaluate it.

Sure, can be done ;-)

> This
> code might directly or indirectly do a stack-lookup for dynamic
> variables such as (but not limited to) the current session.

It seems that "stack-lookup for dynamic variables" is not implemented with
the debugging situation in mind but, see below.

> This does
> not work right now, as a doIt is not executed in the context of the
> debugger.

You perhaps mean, "is only executed in the context which belongs to the
debugger and not in the context of the debugee".

> Now this is a little bit tricky. When processing a doIt the execution
> stack in the debugger should be chained with the one from the doIt,
> but otherwise not touched or unwound. I already do chain two execution
> stacks with Continuation>>#invoke:, but in the debugger this seems to
> be slightly more tricky ...

Sure (tricky). In anticipation or this complaint (it's an old one, the
problem exists since debugger is forked into a new process, isolated from
the debuggee), I've reported, many many femtoseconds ago

- http://bugs.impara.de/view.php?id=5957

Sorry for no better news. Ad hoc I see no easy way for debugger (which
delegates to #evaluate: and friends) to solve the possible problems
(unwind, exception, process termination) which can occur when evaluating
in the context of the debuggee's stack (and perhaps its process).

/Klaus

> Cheers,
> Lukas
>

_______________________________________________
Seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

Klaus D. Witzel

Re: The session in the debugger

In reply to this post by Lukas Renggli

Seasiders,

have a look at the two new changesets which I added to

- http://bugs.impara.de/view.php?id=5957

DoItWithContextVariable-kwl.1.cs resolves accessing the context of the
debuggee, as discussed with Lukas.

WADynamicVariable-kwl.1.cs uses (DoItWithContextVariable raiseSignal) just
for accessing the context of the debuggee (if it needs so).

Please test evaluation of (self session) from the context pane of the
debugger, also other dynamic variables if you have some.

Thank you Lukas for participating in the solution. I think that the above,
since it is implemented by WADynamicVariable just when it searches for
itself on the stack, does not impose any problem on any other exception
handling, unwind or process manipulation.

/Klaus

P.S. No other change set is needed.

On Wed, 07 Feb 2007 22:26:14 +0100, Lukas Renggli wrote:

>> Stack search now added and (surprise! :) now it shows seaside's session
>> in
>> the debugger (labelled aSession class name).
>
> I don't think this is quite what we want: We would like to be able to
> select any part of the code in the code pane and evaluate it. This
> code might directly or indirectly do a stack-lookup for dynamic
> variables such as (but not limited to) the current session. This does
> not work right now, as a doIt is not executed in the context of the
> debugger.
>
> Now this is a little bit tricky. When processing a doIt the execution
> stack in the debugger should be chained with the one from the doIt,
> but otherwise not touched or unwound. I already do chain two execution
> stacks with Continuation>>#invoke:, but in the debugger this seems to
> be slightly more tricky ...
>
> Cheers,
> Lukas
>

_______________________________________________
Seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside