Description of `program-sources' and accessors

Description of `program-sources' and accessors

[Diogo F. S. Ramos]

Is there a place which describes the meaning of each of element of
`program-sources' accessors?

For example:

  (source:addr (program-sources every)) => (0 "srfi/srfi-1.scm" 810 . 0)

What does each element of the improper list mean?

Also for `source:file', `source:line' and `source:column'.  The first
two are also improper lists, but the last is a list of improper lists.

Re: Description of `program-sources' and accessors

[Andy Wingo]

Hi,

On Sat 19 Apr 2014 12:07, "Diogo F. S. Ramos" <dfsr@riseup.net> writes:

> Is there a place which describes the meaning of each of element of
> `program-sources' accessors?
>
> For example:
>
>   (source:addr (program-sources every)) => (0 "srfi/srfi-1.scm" 810 . 0)
>
> What does each element of the improper list mean?
>
> Also for `source:file', `source:line' and `source:column'.  The first
> two are also improper lists, but the last is a list of improper lists.

Note that this is an interface that is very specific to Guile 2.0's
VM, and it's gnarly in many ways.  However :)  What program-sources
returns is a list of sources.  Therefore source:addr should be called on
the elements of program-sources, not on the list as a whole.

Unfortunately sources are represented in this interface as improper
lists -- source:addr is just car.  So it works on the list as a whole;
hence the confusion.  Perhaps now that this confusion is resolved, the
text in the manual will make more sense.

Regards,

Andy
-- 
http://wingolog.org/

Re: Description of `program-sources' and accessors

[Diogo F. S. Ramos]

>> Is there a place which describes the meaning of each of element of
>> `program-sources' accessors?
>
> Note that this is an interface that is very specific to Guile 2.0's
> VM, and it's gnarly in many ways.  However :)  What program-sources
> returns is a list of sources.  Therefore source:addr should be called on
> the elements of program-sources, not on the list as a whole.
>
> Unfortunately sources are represented in this interface as improper
> lists -- source:addr is just car.  So it works on the list as a whole;
> hence the confusion.  Perhaps now that this confusion is resolved, the
> text in the manual will make more sense.

Oh, I see.  Thank you.

So, what does "sources" mean?  For what I can see, each one correspond
to a line in a definition.  I can't also figure out what a `source:addr'
is, but I'm guessing it's for the VM.

I'm using this interface to know where an object has been defined.  By
your note, I get the impression that this might not be a good idea.  Am
I getting it right and if so, do you have a suggestion to achieve what
I'm trying to do using another method?

Re: Description of `program-sources' and accessors

[Andy Wingo]

On Sun 20 Apr 2014 20:09, "Diogo F. S. Ramos" <dfsr@riseup.net> writes:

>>> Is there a place which describes the meaning of each of element of
>>> `program-sources' accessors?
>>
> So, what does "sources" mean?  For what I can see, each one correspond
> to a line in a definition.  I can't also figure out what a `source:addr'
> is, but I'm guessing it's for the VM.

Sources are a way of mapping bytecode offset to source location.  The
addr indicates the byte count since the beginning of the function.
The list is sorted, so if you have adjacent S0 and S1 with addresses A0
and A1, the source information from S0 applies in the range [A0, A1).

> I'm using this interface to know where an object has been defined.

What does this mean?  (Have you seen the (system xref) facility?  It
doesn't do a good job with non-procedures, but perhaps we could change
that.)

Andy
-- 
http://wingolog.org/

Re: Description of `program-sources' and accessors

[Diogo F. S. Ramos]

>> I'm using this interface to know where an object has been defined.
>
> What does this mean?  (Have you seen the (system xref) facility?  It
> doesn't do a good job with non-procedures, but perhaps we could change
> that.)

Thank you for the reference.  `procedure-callees' and
`procedure-callers' are very useful.

For what I mean, I want to know the source file and line where an object
has been defined.  For example:

  (object-location (module-ref (current-module) 'procedure-callees)) =>
  ((file . "/path/to/module/system/xref.scm") (line . 89))

I couldn't figure out how to achieve it with (system xref) but after
your explanation, I'm using the VMs interface, hence my previous
question.

Re: Description of `program-sources' and accessors

[Andy Wingo]

On Tue 22 Apr 2014 18:43, "Diogo F. S. Ramos" <dfsr@riseup.net> writes:

>>> I'm using this interface to know where an object has been defined.
>>
>> What does this mean?  (Have you seen the (system xref) facility?  It
>> doesn't do a good job with non-procedures, but perhaps we could change
>> that.)
>
> Thank you for the reference.  `procedure-callees' and
> `procedure-callers' are very useful.
>
> For what I mean, I want to know the source file and line where an object
> has been defined.  For example:
>
>   (object-location (module-ref (current-module) 'procedure-callees)) =>
>   ((file . "/path/to/module/system/xref.scm") (line . 89))
>
> I couldn't figure out how to achieve it with (system xref) but after
> your explanation, I'm using the VMs interface, hence my previous
> question.

I see.  Indeed, you need to use (program-source proc 0) currently, for
procedures.  For non-procedure objects there's currently no way to know
where they're defined, and indeed it's tricky.  E.g.:

  (define foo '(1 2 3))
  (define bar '(1 2 3))

Since these are literals they share storage, so you can't tell whether
the value that `foo' evaluates to proceeded from the "foo" definition or
the "bar" definition.  Then there are immediates like fixnums, etc,
which obviously can't be traced to their definitions.

On the other hand it is probably possible to know where a name "foo" in
a module (bar) is defined, through VM internals.  Not currently
implemented.  But that's a mapping from fully-qualified _names_ to
locations, not values to locations.

Regards,

Andy
-- 
http://wingolog.org/

Re: Description of `program-sources' and accessors

[Diogo F. S. Ramos]

> On the other hand it is probably possible to know where a name "foo" in
> a module (bar) is defined, through VM internals.  Not currently
> implemented.  But that's a mapping from fully-qualified _names_ to
> locations, not values to locations.

I didn't think of this distinction.  For my purposes, the
fully-qualified name is indeed what I want, not the value.

Oh well.