Debugging stand-alone applications

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

Debugging stand-alone applications

Holger Freyther
Hi Paolo,

I wonder if there could be an easy way from within smalltalk to invoke the
various scripts (profile, remote, convert,package) from within the other.

E.g. I would like to profile a run of (gst-sunit or gst-package), I would like
to debug a crash inside the gst-remote. Right now my option will be to
manipulate the Smalltalk args and then FileIn the various scripts.

is there a better way?

_______________________________________________
help-smalltalk mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/help-smalltalk
Reply | Threaded
Open this post in threaded view
|

Re: Debugging stand-alone applications

Paolo Bonzini-2
On 04/01/2011 11:28 AM, Holger Hans Peter Freyther wrote:

> Hi Paolo,
>
> I wonder if there could be an easy way from within smalltalk to invoke the
> various scripts (profile, remote, convert,package) from within the other.
>
> E.g. I would like to profile a run of (gst-sunit or gst-package), I would like
> to debug a crash inside the gst-remote. Right now my option will be to
> manipulate the Smalltalk args and then FileIn the various scripts.
>
> is there a better way?

You can load the MiniDebugger into your image (gst -SK
examples/MiniDebugger.st), and pass -I to the gst-* executables.

Paolo

_______________________________________________
help-smalltalk mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/help-smalltalk
Reply | Threaded
Open this post in threaded view
|

Re: Debugging stand-alone applications

Holger Freyther
On 04/01/2011 11:30 AM, Paolo Bonzini wrote:

>
> You can load the MiniDebugger into your image (gst -SK
> examples/MiniDebugger.st), and pass -I to the gst-* executables.

True. is the mini debugger capable of suspending all processes and activating
itself? I figured out that the only weird part about gst-remote is the change
of Compilers (#Compiler package).

So right now I know:

- PackageLoader fileInPackage: #Compiler; fileInPackage: #Sockets will fail.
- PackageLoader fileInPackage: #Compiler; fileInPackage: #Grease will use all
  memory and unless you have a infinite turing tape abort the VM. :)

I will look into the second issue, maybe by monday.

holger

_______________________________________________
help-smalltalk mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/help-smalltalk
Reply | Threaded
Open this post in threaded view
|

Re: Debugging stand-alone applications

Holger Freyther
On 04/01/2011 11:35 AM, Holger Hans Peter Freyther wrote:

>

Core/Text/GRInflector.st

is the file that fails to parse, I will debug it.

_______________________________________________
help-smalltalk mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/help-smalltalk
Reply | Threaded
Open this post in threaded view
|

Re: Debugging stand-alone applications

Stephen-71
Hmmm, did you mean this to be a reply to the GST 4.1 post of Paolo?

Core/Text/GRIn.st?

>
> Core/Text/GRInflector.st
>
> is the file that fails to parse, I will debug it.
>



_______________________________________________
help-smalltalk mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/help-smalltalk
Reply | Threaded
Open this post in threaded view
|

Re: Debugging stand-alone applications

Holger Freyther
On 04/01/2011 10:34 PM, Stephen wrote:
> Hmmm, did you mean this to be a reply to the GST 4.1 post of Paolo?
>
> Core/Text/GRIn.st?
>

Hey,

no it is not a joke. The file exists[1] and the Parser/Compiler written in
Smalltalk goes into a infinite loop and consumes all the memory on the way
(all that the VM can allocate).

I will create a test case for it.


https://github.com/NicolasPetton/Grease/commits/master/Core/Text/GRInflector.st

_______________________________________________
help-smalltalk mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/help-smalltalk