Re : [Help-smalltalk] Having a bytcode loader

[Mathieu Suen]

Ok So I did try to profile with the ProfileTools package.


Here is the code to generate a grind file:

Eval [
     | file 
result |
     PackageLoader fileInPackage: 'ProfileTools'.
     
result := CallGraphProfiler profile: [PackageLoader fileInPackage: 
'Seaside'].
     file := FileStream open: 'grind.out' mode: 
FileStream write.
     file nextPutAll: result printString.
     
file close.
]

But I soon as I try to read it with KCachegrind 
it fail to open the grind.out file.
Is there some missing header or 
something else to append to the file?


Thanks

--Mathieu suen




----- Message d'origine ----
De : Paolo Bonzini <address@hidden>
À : Mathieu Suen <address@hidden>
Cc : address@hidden
Envoyé le : Jeu 27 mai 2010, 12h 22min 34s
Objet : Re: [Help-smalltalk] Having a bytcode loader

On 05/27/2010 11:52 AM, Mathieu Suen wrote:
> Hi,
> 
> I have a little bit of free time so I decided to try implementing a
> bytecode loader and dumper. So I have a couple of question on what
> would be the right interface. And how people want this kind of
> feature.
> 
> First do we wanted inside the *.st file or have it like in elisp a
> kind of *.stc file?

I think a *.stc file like Python and elisp would be better.  The right 
interface IMO would be:

1) a gst-compile script to compile a .st file to .stc.  This could reuse some 
of the infrastructure in gst-convert.

2) gst-package would check if a .stc file is present every time a .st file is 
put in an archive, and put the .stc file too.

3) Similarly, the PackageLoader would check if a .stc file is present and "file 
it in" too.  I'm not sure whether the same file in primitive would be used for 
filein, or a different one.

> I part from that I have look at the ObjectDumper class. I wonder if
> that could help for building the bytcode dumper.

Maybe.  However, first of all I'd start by profiling a large filein (Seaside) 
and see whether time is spent in Smalltalk or C code.

Paolo