Guile top-level functions

Guile top-level functions

[Mike Gran]

Out of curiosity, I generated a plot of the initialization of Guile's
top-level functions.  It shows the order in which the functions are
defined and how long the whole process takes on a pitiable 8-year old
AIX.  Here is a plot of the default system loading no SRFIs.

http://www.lonelycactus.com/pics/guile_1.6.5_boot.png

There are some time discontinuities.  Those may be when my hacked plot
prints are being flushed to disk.  Dunno for sure.

I had thought it would be neat to color code them by module.  Is there
a way from the C API to find out the filename and line number of a SCM
procedure?

-- Mike Gran


		
__________________________________ 
Do you Yahoo!? 
Yahoo! Mail - now with 250MB free storage. Learn more.
http://info.mail.yahoo.com/mail_250


_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-user

Re: Guile top-level functions

[Kevin Ryde]

Mike Gran <spk121@yahoo.com> writes:
>
> There are some time discontinuities.  Those may be when my hacked plot
> prints are being flushed to disk.  Dunno for sure.

GC, or if this is the cvs then maybe the new automatic rehashing.

> I had thought it would be neat to color code them by module.  Is there
> a way from the C API to find out the filename and line number of a SCM
> procedure?

I was wanting that the other day too, from the procedure would be
good, from the module variable would be even better.  The reader gets
the information, but is it thrown away?


_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-user

Re: Guile top-level functions

[Neil Jerram]

Kevin Ryde wrote:
> Mike Gran <spk121@yahoo.com> writes:
> 
>>I had thought it would be neat to color code them by module.  Is there
>>a way from the C API to find out the filename and line number of a SCM
>>procedure?
> 
> 
> I was wanting that the other day too, from the procedure would be
> good, from the module variable would be even better.  The reader gets
> the information, but is it thrown away?

Not if you set the 'positions read option, i.e.

(read-enable 'positions)

Then source location information is saved in a weak hash table 
(scm_source_whash, I think) indexed by each read pair.  Given a read 
expression X, you can get its filename, line and column from

(source-property X 'filename)
(source-property X 'line)
(source-property X 'column)

I'm now sure, though, how to access this for a given procedure; I 
suspect there are two problems:

- procedure-source may return a new unmemoized copy of the procedure's 
source, not the original source, and without source properties attached

- it may be impossible to enable the 'positions option early enough in 
boot-9.scm to catch everything that you want to catch.

I hope this is some help, though.

	Neil


_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-user

Re: Guile top-level functions

[Kevin Ryde]

Neil Jerram <neil@ossau.uklinux.net> writes:
>
> - procedure-source may return a new unmemoized copy of the procedure's 
> source, not the original source, and without source properties attached

Yep, or does it drops off the lambda and formals from the list, thus
losing the source position info (that being on the start of the list
only)?

	(read-enable 'positions)
	(define (x) (display 'hello))
	(source-properties (procedure-source x))
	=> ()

Another use for positions on procedures I mentioned another time was
to show that info in a backtrace.  When you just see "<procedure #f>"
it's a bit of a guessing game to tell where the offending bit actually
came from.

All this would be for under --debug only, it wouldn't need to bloat
normal operation.


_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-user

Re: Guile top-level functions

[Neil Jerram]

Kevin Ryde wrote:
> Neil Jerram <neil@ossau.uklinux.net> writes:
> 
>>- procedure-source may return a new unmemoized copy of the procedure's 
>>source, not the original source, and without source properties attached
> 
> 
> Yep, or does it drops off the lambda and formals from the list, thus
> losing the source position info (that being on the start of the list
> only)?
> 
> 	(read-enable 'positions)
> 	(define (x) (display 'hello))
> 	(source-properties (procedure-source x))
> 	=> ()
> 
> Another use for positions on procedures I mentioned another time was
> to show that info in a backtrace.  When you just see "<procedure #f>"
> it's a bit of a guessing game to tell where the offending bit actually
> came from.

Except that normally the backtrace info already has it right.  For 
example, with this typed into the REPL -

guile> (define (x) (ddd))
guile> (x)

- my soon-to-be-released debugger shows the stack at the error as:

=> st (ddd)
    s  [x]
       [primitive-eval (x)]

The `s' here shows that there are source properties for the frame on 
that line, calculated as:

(if (frame-procedure? frame)
     (or (frame-source frame)
         (let ((proc (frame-procedure frame)))
           (and proc
                (procedure? proc)
                (procedure-source proc))))
     (frame-source frame))

So it looks like frame-source is getting at the info somehow - we just 
need to investigate how.

(I'll do that tomorrow evening if no one else beats me to it.)

	Neil


_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-user

Re: Guile top-level functions

[Kevin Ryde]

Neil Jerram <neil@ossau.uklinux.net> writes:
>
> guile> (define (x) (ddd))
> guile> (x)

Actually I was thinking of something like

	(define callback noop)
	...
	(set! callback (lambda () (display 'hello)))
	...
	(callback)

when the callback is made you'd like to know where that anonymous
procedure came from.

I've been hitting this lately in guile-gtk signal callbacks.  The
calls are all made from the main loop, so the location of the call
doesn't help, you'd like to know the location of the procedure's
creation.


_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-user

Re: Guile top-level functions

[Neil Jerram]

Kevin Ryde wrote:
> 
> Actually I was thinking of something like
> 
> 	(define callback noop)
> 	...
> 	(set! callback (lambda () (display 'hello)))
> 	...
> 	(callback)
> 
> when the callback is made you'd like to know where that anonymous
> procedure came from.

Well:

guile> (source-properties (caddr (procedure-source callback)))
((breakpoint . #f) (line . 1) (column . 26) (filename . "standard input"))

But this assumes that the first form in the body is a pair (or more 
generally, if tweaked, that the body contains _some_ pair), and I agree 
that if would be nicer for the result of (procedure-source ...) to have 
the source properties directly.

	Neil


_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-user

Re: Guile top-level functions

[Kevin Ryde]

Neil Jerram <neil@ossau.uklinux.net> writes:
>
> guile> (source-properties (caddr (procedure-source callback)))
> ((breakpoint . #f) (line . 1) (column . 26) (filename . "standard input"))

Sweet.  I've already got my own backtrace, so I can plug that in
easily.  I'll use it for my lint program too I think.

Doesn't work in the cvs head though, it seems.  Unmemoizing like you
said before maybe.


_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-user