Lisp HUG Maillist Archive

Well, maybe not a "pretty useless toy", but "there is still wide area for improvement" :)

But, again, I insist that native code stepper would be much, much
better in architectural sence even despite less detail it would give.

_______________________________________________
Lisp Hug - the mailing list for LispWorks users
lisp-hug@lispworks.com
http://www.lispworks.com/support/lisp-hug.html


Re: Well, maybe not a "pretty useless toy", but "there is still wide area for improvement" :)

That made no sense *at all*.


On Thu, Mar 6, 2014 at 12:41 PM, Denis Budyak <budden73@gmail.com> wrote:

But, again, I insist that native code stepper would be much, much
better in architectural sence even despite less detail it would give.

_______________________________________________
Lisp Hug - the mailing list for LispWorks users
lisp-hug@lispworks.com
http://www.lispworks.com/support/lisp-hug.html


Re: Well, maybe not a "pretty useless toy", but "there is still wide area for improvement" :)

Lisp machine…

just sayin’


On Mar 6, 2014, at 6:41 AM, Denis Budyak <budden73@gmail.com> wrote:

> 
> But, again, I insist that native code stepper would be much, much
> better in architectural sence even despite less detail it would give.
> 
> _______________________________________________
> Lisp Hug - the mailing list for LispWorks users
> lisp-hug@lispworks.com
> http://www.lispworks.com/support/lisp-hug.html
> 


_______________________________________________
Lisp Hug - the mailing list for LispWorks users
lisp-hug@lispworks.com
http://www.lispworks.com/support/lisp-hug.html


Re: Well, maybe not a "pretty useless toy", but "there is still wide area for improvement" :)

On 6 Mar 2014, at 11:41, Denis Budyak <budden73@gmail.com> wrote:

> But, again, I insist that native code stepper would be much, much
> better in architectural sence even despite less detail it would give.

I think that native-code stepping is reasonably hard to do in a useful way in a language with macros.  I've never actually found stepping Lisp useful (including on LispMs).

_______________________________________________
Lisp Hug - the mailing list for LispWorks users
lisp-hug@lispworks.com
http://www.lispworks.com/support/lisp-hug.html


Re: Well, maybe not a "pretty useless toy", but "there is still wide area for improvement" :)

When you're single-stepping, it does not really matter if the code is interpreted or compiled & optimised. The moment you stop single-stepping the code, you will quite likely be able to re-compile the code that you were stepping through.


On Thu, Mar 6, 2014 at 3:00 PM, Tim Bradshaw <tfb@tfeb.org> wrote:

On 6 Mar 2014, at 11:41, Denis Budyak <budden73@gmail.com> wrote:

> But, again, I insist that native code stepper would be much, much
> better in architectural sence even despite less detail it would give.

I think that native-code stepping is reasonably hard to do in a useful way in a language with macros.  I've never actually found stepping Lisp useful (including on LispMs).

_______________________________________________
Lisp Hug - the mailing list for LispWorks users
lisp-hug@lispworks.com
http://www.lispworks.com/support/lisp-hug.html


Re: Well, maybe not a "pretty useless toy", but "there is still wide area for improvement" :)

> II think that native-code stepping is reasonably hard to do in a useful way in a language with macros.
Indeed this is hard, but there are more or less successful examples of
such implementation. E.g. #line directive in C allows to control a
stepper when code transformations are used. Some time ago I suggested
to implement similar things for Lispworks, and I even posted some
prototype code for particular cases (e.g., for iterate). Lispworks
developers promised to work on it.

> The moment you stop single-stepping the code, you will quite likely be able to re-compile the code that you were stepping through.
Is I have mentioned above, there are problems:
i) compilation context might differ in some tricky cases and there is
no predicate to check if we are in tricky case or not. So, setting a
breakpoint potentially converts function in a way which differs its
behaviour
ii) When you return from stepped function to a function which was not
compiled with stepper enabled, you're unable to step through it. I
guess there could be possible to recompile caller function just before
actual return and to redirect execution path from non-stepped function
into stepped, but this is not implemented in current version of
Lispworks stepper and I'm not sure that is easier than implement
native-code stepper.
iii) doing "restart frame stepping" works well for a code without side
effects only. Again, there is no "pure-functional-p" predicate to
check if it is safe to do restart frame.

_______________________________________________
Lisp Hug - the mailing list for LispWorks users
lisp-hug@lispworks.com
http://www.lispworks.com/support/lisp-hug.html


RE: Well, maybe not a "pretty useless toy", but "there is still wide area for improvement" :)

Bradford Miller wrote:
> Lisp machine...

> just sayin'

Yeah ... I wish I still had one :( 

Like the Symbolics 3600 I used 30 years ago.

On Mar 6, 2014, at 6:41 AM, Denis Budyak <budden73@gmail.com> wrote:
> But, again, I insist that native code stepper would be much, much  better in architectural sence even despite less detail it would give.


_______________________________________________
Lisp Hug - the mailing list for LispWorks users
lisp-hug@lispworks.com
http://www.lispworks.com/support/lisp-hug.html


Updated at: 2020-12-10 08:34 UTC