I don't want to maintain this

I don't want to maintain this

[Bruce Korb]

Hi all,

The following function is disliked by me and disliked by Guile 1.7.
It is a PITA to maintain, but it is compulsory until there is equivalent
functionality available.  It is crucially important that error messages
point to the source file where the problem lies.

More and more installations seem to have 1.7, but I still deal with 1.4.
So, I use stuff like SCM_ROCHARS, except that it has been completely
removed from the interface leaving me with hard errors.  I've spent a
day and a half trying to fix this stuff and it is very resistant to
being fixed.

Grumble, grumble.  Anyway, this belongs in your code.  We argued about this
before and someone said, "well, you could do it in any of several ways,
so we won't do it at all."  This function is entirely equivalent to
"scm_c_eval_string" except that error results show file name and line 
number.  This is "The Right Way" for the interface and "The Wrong Way"
for me.  Can you please add this (or something similar) to your interface
and reinstate SCM_ROCHARS et al. please?  Thank you.

Regards, Bruce

SCM
ag_scm_c_eval_string_from_file_line( tCC* pzExpr, tCC* pzFile, int line )
{
    SCM port;

    if (OPT_VALUE_TRACE >= TRACE_EVERYTHING) {
        fprintf( pfTrace, "eval from file %s line %d:\n%s\n", pzFile, line,
                 pzExpr );
    }

    {
        tSCC zEx[] = "eval-string-from-file-line";
        SCM  expr  = scm_makfrom0str( pzExpr );
        port = scm_mkstrport( SCM_INUM0, expr, SCM_OPN | SCM_RDNG, zEx );
    }

    {
        static SCM file = SCM_UNDEFINED;
        scm_t_port* pt;

        if (  (file == SCM_UNDEFINED)
           || (strcmp( SCM_CHARS( file ), pzFile ) != 0) )
            file = scm_makfrom0str( pzFile );

        pt = SCM_PTAB_ENTRY(port);
        pt->line_number = line - 1;
        pt->file_name   = file;
    }

    {
        SCM ans = SCM_UNSPECIFIED;

        /* Read expressions from that port; ignore the values.  */
        for (;;) {
            SCM form = scm_read( port );
            if (SCM_EOF_OBJECT_P( form ))
                break;
            ans = scm_primitive_eval_x( form );
        }

        return ans;
    }
}

P.S.  Speaking of error messages:

$ autogen --trace=every --trace-out=trace.log -L../autoopts opts.def
ERROR: In procedure inexact?:
ERROR: Wrong type argument in position 1: #<unspecified>

Some deprecated features have been used.  Set the environment
variable GUILE_WARN_DEPRECATED to "detailed" and rerun the
program to get more information.  Set it to "no" to suppress
this message.
Scheme evaluation error.  AutoGen ABEND-ing in template
        options on line 86

============== trace.log ====================
== See the entry for "options line 86", below.
== "suffix", "count", "dne" and "exist?" are all functions legally defined
== and this all works with Guile 1.6. If I *ONLY* had a clue about what
== was being said above ``In procedure inexact?:'' and
== ``#<unspecified>''.  It is just so nebulous.
==
eval from file options line 19:
(define have-cb-procs     (make-hash-table 31))
eval from file options line 20:
(define is-ext-cb-proc    (make-hash-table 31))
eval from file options line 21:
(define cb-proc-name      (make-hash-table 31))
eval from file options line 22:
(define test-proc-name    (make-hash-table 31))
eval from file options line 23:
(define disable-name      (make-hash-table 31))
eval from file options line 24:
(define disable-prefix    (make-hash-table 31))
eval from file options line 25:
(define ifdef-ed          (make-hash-table 31))
eval from file options line 26:
(define extract-fmt       "\n/* extracted from %s near line %d */\n")
eval from file options line 28:
(setenv "SHELL" "/bin/sh")
Starting h template
EXPR       ( B) in options at line 78
eval from file options line 78:
(dne " *  " "/*  ")
Text       (11) in options at line 78
CASE       ( 1) in options at line 82
eval from file options line 82:
(suffix)
CASE string `h' COMPARE_FULL matched `h'
EXPR       ( B) in options at line 86
eval from file options line 86:
(if (not (exist? "flag.name"))
      (error "No options have been defined" ))

  (if (> (count "flag") 100)
      (error (sprintf "%d options are too many - limit of 100"
                  (count "flag")) ))
eval from file autogen.c line 213:
(if (> (string-length shell-cleanup) 0)    (shell shell-cleanup) )


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

I don't want to maintain this

[Bruce Korb]

Hi all,

The following function is disliked by me and disliked by Guile 1.7.
It is a PITA to maintain, but it is compulsory until there is equivalent
functionality available.  It is crucially important that error messages
point to the source file where the problem lies.

More and more installations seem to have 1.7, but I still deal with 1.4.
So, I use stuff like SCM_ROCHARS, except that it has been completely
removed from the interface leaving me with hard errors.  I've spent a
day and a half trying to fix this stuff and it is very resistant to
being fixed.

Grumble, grumble.  Anyway, this belongs in your code.  We argued about this
before and someone said, "well, you could do it in any of several ways,
so we won't do it at all."  This function is entirely equivalent to
"scm_c_eval_string" except that error results show file name and line 
number.  This is "The Right Way" for the interface and "The Wrong Way"
for me.  Can you please add this (or something similar) to your interface
and reinstate SCM_ROCHARS et al. please?  Thank you.

Regards, Bruce

SCM
ag_scm_c_eval_string_from_file_line( tCC* pzExpr, tCC* pzFile, int line )
{
    SCM port;

    if (OPT_VALUE_TRACE >= TRACE_EVERYTHING) {
        fprintf( pfTrace, "eval from file %s line %d:\n%s\n", pzFile, line,
                 pzExpr );
    }

    {
        tSCC zEx[] = "eval-string-from-file-line";
        SCM  expr  = scm_makfrom0str( pzExpr );
        port = scm_mkstrport( SCM_INUM0, expr, SCM_OPN | SCM_RDNG, zEx );
    }

    {
        static SCM file = SCM_UNDEFINED;
        scm_t_port* pt;

        if (  (file == SCM_UNDEFINED)
           || (strcmp( SCM_CHARS( file ), pzFile ) != 0) )
            file = scm_makfrom0str( pzFile );

        pt = SCM_PTAB_ENTRY(port);
        pt->line_number = line - 1;
        pt->file_name   = file;
    }

    {
        SCM ans = SCM_UNSPECIFIED;

        /* Read expressions from that port; ignore the values.  */
        for (;;) {
            SCM form = scm_read( port );
            if (SCM_EOF_OBJECT_P( form ))
                break;
            ans = scm_primitive_eval_x( form );
        }

        return ans;
    }
}

P.S.  Speaking of error messages:

$ autogen --trace=every --trace-out=trace.log -L../autoopts opts.def
ERROR: In procedure inexact?:
ERROR: Wrong type argument in position 1: #<unspecified>

Some deprecated features have been used.  Set the environment
variable GUILE_WARN_DEPRECATED to "detailed" and rerun the
program to get more information.  Set it to "no" to suppress
this message.
Scheme evaluation error.  AutoGen ABEND-ing in template
        options on line 86

============== trace.log ====================
== See the entry for "options line 86", below.
== "suffix", "count", "dne" and "exist?" are all functions legally defined
== and this all works with Guile 1.6. If I *ONLY* had a clue about what
== was being said above ``In procedure inexact?:'' and
== ``#<unspecified>''.  It is just so nebulous.
==
eval from file options line 19:
(define have-cb-procs     (make-hash-table 31))
eval from file options line 20:
(define is-ext-cb-proc    (make-hash-table 31))
eval from file options line 21:
(define cb-proc-name      (make-hash-table 31))
eval from file options line 22:
(define test-proc-name    (make-hash-table 31))
eval from file options line 23:
(define disable-name      (make-hash-table 31))
eval from file options line 24:
(define disable-prefix    (make-hash-table 31))
eval from file options line 25:
(define ifdef-ed          (make-hash-table 31))
eval from file options line 26:
(define extract-fmt       "\n/* extracted from %s near line %d */\n")
eval from file options line 28:
(setenv "SHELL" "/bin/sh")
Starting h template
EXPR       ( B) in options at line 78
eval from file options line 78:
(dne " *  " "/*  ")
Text       (11) in options at line 78
CASE       ( 1) in options at line 82
eval from file options line 82:
(suffix)
CASE string `h' COMPARE_FULL matched `h'
EXPR       ( B) in options at line 86
eval from file options line 86:
(if (not (exist? "flag.name"))
      (error "No options have been defined" ))

  (if (> (count "flag") 100)
      (error (sprintf "%d options are too many - limit of 100"
                  (count "flag")) ))
eval from file autogen.c line 213:
(if (> (string-length shell-cleanup) 0)    (shell shell-cleanup) )


-------------------------------------------------------


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

Re: I don't want to maintain this

[Ludovic Courtès]

Hi,

Bruce Korb <bruce.korb@gmail.com> writes:

> Grumble, grumble.  Anyway, this belongs in your code.  We argued about this
> before and someone said, "well, you could do it in any of several ways,
> so we won't do it at all."  This function is entirely equivalent to
> "scm_c_eval_string" except that error results show file name and line 
> number.

Sorry if I'm just re-stating what you were already answered: Can't you
implement this as a small Scheme procedure?  Something along the lines
of:

  (read-enable 'positions)

  (define (eval-from-file file)
    (with-input-from-file file
      (lambda ()
        (let loop ((sexp (read))
                   (result #f))
          (if (eof-object? sexp)
              result
              (begin
                (format #t "evaluating `~a' from ~a:~a:~a~%"
                        sexp (port-filename (current-input-port))
                        (source-property sexp 'line)
                        (source-property sexp 'column))
                (loop (read) (primitive-eval sexp))))))))

This would certainly be easier for you to maintain.

Thanks,
Ludovic.


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

Re: I don't want to maintain this

[Bruce Korb]

On Tuesday 29 November 2005 12:16 am, Ludovic Courtès wrote:
> Hi,
> 
> Bruce Korb <bruce.korb@gmail.com> writes:
> 
> > Grumble, grumble.  Anyway, this belongs in your code.  We argued about this
> > before and someone said, "well, you could do it in any of several ways,
> > so we won't do it at all."  This function is entirely equivalent to
> > "scm_c_eval_string" except that error results show file name and line 
> > number.
> 
> Sorry if I'm just re-stating what you were already answered: Can't you
> implement this as a small Scheme procedure?  Something along the lines
> of:

Hi Ludovic,

*I* certainly cannot.  And I do not understand the usage of the "file"
argument.  What I am doing is extracting Scheme code from an encompassing
template and handing it off for evaluation.  My program is reading the
file, not Guile.  When I hand off the the string for evaluation, I hand
it to that ugly thing that I do not want to maintain.  I do this in
exactly the same way as one would with scm_c_eval_string, except I have
the additional parameters file name and line number.  Perhaps I could
wrap my strings in something like this:

char* fmt =
"(read-enable 'positions)
(format #t \"evaluating `~a' from ~a:~a:~a~%%\"
            sexp (port-filename (current-input-port))
           (source-property sexp \"%s\")
           (source-property sexp %d))
(begin
   %s
)";

and use it thus:

   sprintf( buf, fmt, filename, linenum, script );
   result = scm_c_eval_string( buf );

Would that work?

Your help is _surely_  appreciated!!  Thank you.

Kind regards, Bruce


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

Re: I don't want to maintain this

[Ludovic Courtès]

Hi Bruce,

Bruce Korb <bruce.korb@gmail.com> writes:

> *I* certainly cannot.

Do you mean that you don't *want* to, or that this is not possible?

The point is that writing Scheme code will always be easier than writing
C code, and maintaining it will be even more easier.

> And I do not understand the usage of the "file"
> argument.  What I am doing is extracting Scheme code from an encompassing
> template and handing it off for evaluation.  My program is reading the
> file, not Guile.  When I hand off the the string for evaluation, I hand
> it to that ugly thing that I do not want to maintain.  I do this in
> exactly the same way as one would with scm_c_eval_string, except I have
> the additional parameters file name and line number.  Perhaps I could
> wrap my strings in something like this:
>
> char* fmt =
> "(read-enable 'positions)
> (format #t \"evaluating `~a' from ~a:~a:~a~%%\"
>             sexp (port-filename (current-input-port))
>            (source-property sexp \"%s\")
>            (source-property sexp %d))
> (begin
>    %s
> )";
>
> and use it thus:
>
>    sprintf( buf, fmt, filename, linenum, script );
>    result = scm_c_eval_string( buf );
>
> Would that work?

That might work, but that's "ugly".  Are you evaluating reading a file
and evaluating it from C code?

Even if this is the case, nothing prevents you from writing your own
read/eval function in Scheme (along the lines of what I posted earlier)
and using it from C:

  eval_proc = scm_c_eval_string ("eval-from-file");
  result = scm_call_1 (eval_proc, scm_from_locale_string ("the-file.scm"));

Hope this helps,
Ludovic.


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

Re: I don't want to maintain this

[Bruce Korb]

On Wednesday 30 November 2005 12:39 am, Ludovic Courtès wrote:
> Hi Bruce,
> 
> Bruce Korb <bruce.korb@gmail.com> writes:
> 
> > *I* certainly cannot.
> 
> Do you mean that you don't *want* to, or that this is not possible?

Well, okay, I don't find the stuff obvious.  With effort, I'm sure
I could puzzle it out.  I have never found Lisp to be inherently
"obvious".

> > char* fmt =
> > "(read-enable 'positions)
> > (format #t \"evaluating `~a' from ~a:~a:~a~%%\"
> >             sexp (port-filename (current-input-port))
> >            (source-property sexp \"%s\")
> >            (source-property sexp %d))
> > (begin
> >    %s
> > )";
> >
> > and use it thus:
> >
> >    sprintf( buf, fmt, filename, linenum, script );
> >    result = scm_c_eval_string( buf );
> >
> > Would that work?
> 
> That might work, but that's "ugly".  Are you evaluating reading a file
> and evaluating it from C code?

I extract the scheme code from a file.  Now, I have a string in memory
and I want it eval-ed.  If I was reading your suggestion correctly,
I would need to write that string to a real file.  I want to avoid
that.  I want to hand that string, from memory, to Guile and tell
Guile, "This string came from file XXX on line NNN."  (That is what
the ag_scm_c_eval_string_from_file_line() does.)

> Even if this is the case, nothing prevents you from writing your own
> read/eval function in Scheme (along the lines of what I posted earlier)
> and using it from C:
> 
>   eval_proc = scm_c_eval_string ("eval-from-file");
>   result = scm_call_1 (eval_proc, scm_from_locale_string ("the-file.scm"));

Or this?

   SCM body = scm_from_locale_string (extracted_text);
   SCM file = scm_from_locale_string (current_input_file);
   SCM line = scm_from_<integer?> (line_num);
   return scm_call_3 (eval_proc, body, file, line);

Obviously, ``eval-from-file'' has to be reformulated to eval "body" instead of
reading input from a file and it must set the file name and line number
from the passed in arguments, but something like this ought to be workable,
yes?  Sorry for being dense, but just how to formulate the "eval-from-xxx" thing
isn't real obvious to me.  Thank you for your help & patience.  Regards, Bruce


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

Re: I don't want to maintain this

[Ludovic Courtès]

Bruce Korb <bruce.korb@gmail.com> writes:

> Well, okay, I don't find the stuff obvious.  With effort, I'm sure
> I could puzzle it out.  I have never found Lisp to be inherently
> "obvious".

Oh, but things are different here: this is Scheme!  ;-)

Just out of curiosity: why are you writing Scheme if you don't like it?

> I extract the scheme code from a file.  Now, I have a string in memory
> and I want it eval-ed.  If I was reading your suggestion correctly,
> I would need to write that string to a real file.  I want to avoid
> that.  I want to hand that string, from memory, to Guile and tell
> Guile, "This string came from file XXX on line NNN."  (That is what
> the ag_scm_c_eval_string_from_file_line() does.)

While you're at reading Scheme code from a file, why not use Scheme
construct (be it from Scheme of C code) whose purpose are exactly that?
Consider the following excerpt:

  (with-input-from-file "chbouib.scm"
    read)

This will read a single balanced expression (S-exp) from "chbouib.scm"
and return it[0].  Additionally, Guile does something interesting: it
attaches to that returned S-exp information about its original location.
IOW, you can then use the source property API[1] with that S-exp to know
where it came from (file name, line number, etc.).

It seems to be exactly the kind of feature you are looking for, isn't
it?  What you are describing (reading a file into memory, asking Guile
to evaluate its content as a string, adding location information to it)
is just what Guile's `read' already does.

Thanks,
Ludovic.

[0] http://www.gnu.org/software/guile/docs/guile-ref/Scheme-Read.html#Scheme%20Read
[1] http://www.gnu.org/software/guile/docs/guile-ref/Procedure-Properties.html#Procedure%20Properties


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

Re: I don't want to maintain this

[Bruce Korb]

On Wednesday 30 November 2005 05:46 am, Ludovic Courtès wrote:
> Bruce Korb <bruce.korb@gmail.com> writes:
> 
> > Well, okay, I don't find the stuff obvious.  With effort, I'm sure
> > I could puzzle it out.  I have never found Lisp to be inherently
> > "obvious".
> 
> Oh, but things are different here: this is Scheme!  ;-)

Oh.  That's right!  It is _so_ different.  ;)

> Just out of curiosity: why are you writing Scheme if you don't like it?

I needed an extension language for my templates.  The Scheme/Guile/Lisp
code is embedded in my template and when my interpreter stumbles into
it, it collects the text and says, "here!  You deal with this". (i.e.
it calls some variation on scm_c_eval_string()).

> While you're at reading Scheme code from a file, why not use Scheme
> construct (be it from Scheme of C code) whose purpose are exactly that?
> Consider the following excerpt:
> 
>   (with-input-from-file "chbouib.scm"
>     read)

Because the file is mostly *NOT* scheme.  There is just some
embedded scheme phrases.  I mmap the text (private and read/write)
and parse its components.  The Scheme pieces get passed to Guile.
I know the file name and line number where these pieces come from.
I want Guile error messages to reflect the file/line where these
things live.  :)

Thanks again - Bruce


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

Getting source location information

[Ludovic Courtès]

Bruce Korb <bruce.korb@gmail.com> writes:

> Because the file is mostly *NOT* scheme.

I did say that you could use "Scheme constructs", "be it from Scheme
o[r] C code".  In other words, you can either write `(read)' in a piece
of Scheme code, or call `scm_read ()' from your C code: both are
strictly equivalent (well, almost).

The point is: do not rewrite what already exists because *this* is hard
to maintain.

Actually, what you want is `primitive-load' + `read' (which handles
piggy-backing of source location information as I said).  It is true,
however, that `primitive-load' (or, rather, `open-input-file') is not
guaranteed to use `mmap ()' the way you do it currently[*].  So if you
do want to make sure that the input file is `mmap'd the way you like,
then you may want to write your own variant of `primitive-load' (see
`libguile/load.c').

In any case, I can hardly imagine how Guile itself could be more helpful
than this.  ;-)

Thanks,
Ludovic.


[*] Actually, Guile currently does not use `mmap ()' at all.  Perhaps
    file ports should be revised to take advantage of this where
    available.


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

Re: Getting source location information

[Bruce Korb]

On Wednesday 30 November 2005 06:44 am, Ludovic Courtès wrote:
> Bruce Korb <bruce.korb@gmail.com> writes:
> 
> > Because the file is mostly *NOT* scheme.
> 
> I did say that you could use "Scheme constructs", "be it from Scheme
> o[r] C code".  In other words, you can either write `(read)' in a piece
> of Scheme code, or call `scm_read ()' from your C code: both are
> strictly equivalent (well, almost).
> 
> The point is: do not rewrite what already exists because *this* is hard
> to maintain.
> 
> Actually, what you want is `primitive-load' + `read' (which handles
> piggy-backing of source location information as I said).  It is true,
> however, that `primitive-load' (or, rather, `open-input-file') is not
> guaranteed to use `mmap ()' the way you do it currently[*].  So if you
> do want to make sure that the input file is `mmap'd the way you like,
> then you may want to write your own variant of `primitive-load' (see
> `libguile/load.c').
> 
> In any case, I can hardly imagine how Guile itself could be more helpful
> than this.  ;-)

Hi,

I am completely certain that this makes sense to you.  To me, it does
not.  If I call ``scm_read(port)'' I have to attach the input file
as a port.  That read function reads an s-expr.  How can that work if
the non-Scheme text in the file is not an s-expr?  I don't see another
function for getting text from a port.  Am I missing something?
Especially troubling is the phrase, "Any whitespace before the
next token is discarded."  I do not want tokenized input.  I want raw
text.  I have my own methods for determining when something needs
a Scheme evaluation.  I will certainly have a more authoritative idea
about what is discardable white space and what is not.  Here, take
a look at an example template file:

  http://autogen.sourceforge.net/doc/autogen_3.html#SEC3

It is about halfway down, after the phrase "It looks something like this".
Oh, here it is anyway, but there is some discussion describing it on
that page:

   [+ AutoGen5 template h c +]
   [+ CASE (suffix) +][+
      ==  h  +]
   typedef enum {[+
      FOR list "," +]
           IDX_[+ (string-upcase! (get "list_element")) +][+
      ENDFOR list +] }  list_enum;

   extern const char* az_name_list[ [+ (count "list") +] ];
   [+

      ==  c  +]
   #include "list.h"
   const char* az_name_list[] = {[+
     FOR list "," +]
           "[+list_info+]"[+
     ENDFOR list +] };[+

   ESAC +]

That example text contains 3 scheme phrases to be evaluated by Guile:

  (suffix)
  (string-upcase! (get "list_element"))
  (count "list")

"get", "count" and "suffix" are my own functions defined in other ways.
The file name should be "list.tpl" in all cases and the line numbers
be 2, 6 and 9 respectively.  Everything else is handled by my program.
So, I can hardly imagine how Guile would be able to do what you say it
can.  Likely, I am just missing something, but nevertheless, it is
escaping me.  BTW, the expression on line 6 gets evaluated three times.
Each time, ``(get "list_element")'' returns a different value.  Likewise,
``(suffix)'' is evaluated twice and returns "h" the first time and "c"
the second time.

Sorry to be such a bother.  Thanks - Bruce


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

Re: Getting source location information

[Ludovic Courtès]

Bruce Korb <bruce.korb@gmail.com> writes:

> That read function reads an s-expr.  How can that work if
> the non-Scheme text in the file is not an s-expr?  I don't see another
> function for getting text from a port.  Am I missing something?
> Especially troubling is the phrase, "Any whitespace before the
> next token is discarded."  I do not want tokenized input.  I want raw
> text.  I have my own methods for determining when something needs
> a Scheme evaluation.

That the input file does not contain only Scheme source wasn't clear to
me.  Then, in fact, it would make sense to use `scm_c_eval_string ()',
provided your tool is able to determine the boundaries of the Scheme
expression (if it's not, you'd better use `scm_read ()').

After the `scm_c_eval_string ()', you can `printf ()' whatever location
information you want.  If you want to use source locations in a
Guile-friendly way (so that Guile can, for instance, display location
information in backtraces), then you may want to use
`scm_set_source_property_x (sexp, key, datum)' (where KEY may be one of
SCM_SYM_FILENAME, SCM_SYM_LINE, SCM_SYM_COLUMN) which is defined in
`srcprop.h'.

But again, this is a problem (and a solution) relevant to your tool, not
to Guile in general.

Thanks,
Ludovic.


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

Re: Getting source location information

[Bruce Korb]

On Wednesday 30 November 2005 08:04 am, Ludovic Courtès wrote:
*Thank you*, Ludvic!  Now we're getting some where.  :-D

> That the input file does not contain only Scheme source wasn't clear to
> me.

  What I am doing is extracting Scheme code from an encompassing
  template and handing it off for evaluation.

When I said that, I was meaning to say that the file was
not pure scheme code.

> Then, in fact, it would make sense to use `scm_c_eval_string ()', 
> provided your tool is able to determine the boundaries of the Scheme
> expression (if it's not, you'd better use `scm_read ()').

It is easily done.

> If you want to use source locations in a
> Guile-friendly way (so that Guile can, for instance, display location
> information in backtraces),

*YES* !!!

> then you may want to use 
> `scm_set_source_property_x (sexp, key, datum)' (where KEY may be one of
> SCM_SYM_FILENAME, SCM_SYM_LINE, SCM_SYM_COLUMN) which is defined in
> `srcprop.h'.

So, again, I need clarity.  Are you saying this:

  SCM res;
  SCM code = scm_from_locale_string (extracted_text);
  SCM file = scm_from_locale_string (file_name);
  SCM line = scm_from_int (line);
  scm_set_source_property_x (code, SCM_SYM_FILENAME, file);
  scm_set_source_property_x (code, SCM_SYM_LINE, line);
  res = scm_primitive_eval (code)

> But again, this is a problem (and a solution) relevant to your tool, not
> to Guile in general.

Well, actually, I disagree.  If any application wants to cope with
embedded Guile extensions in their input files, they either have to
solve this problem or else give up on being able to have Guile error
messages reference the source location.  My guess is is that other
folks just invoke scm_c_eval_string() and don't sweat the message
locations.  That is what I first did.  Then, I learned that getting
location information was possible.  However, the only way I could do
it was by writing a piece of obnoxious code that delved deep into the
bowels of Guile.  That was wrong, but more important than not having
file and line information.  Now, the 1.7 implementation has invalidated
portions of the non-deprecated 1.6 interface that I have been using.
I am forced to rewrite a lot of stuff as a consequence.  Here I am. :)

Thanks again for all your help.  Regards, Bruce


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

Re: Getting source location information

[Ludovic Courtès]

Bruce Korb <bruce.korb@gmail.com> writes:

> *Thank you*, Ludvic!  Now we're getting some where.  :-D

Cool. ;-)

> So, again, I need clarity.  Are you saying this:

First, the `scm_sym_*' things should be lower-case (I was using the GNU
notation for function arguments).

It's more complicated than that in fact.  Source properties must be
attached to S-exps (in fact, pairs), not to the source string.  And
source properties are actually attached by `scm_read ()' and the
function it calls.

So I guess we're almost screwed because `scm_read ()' gets location info
from the port it's reading from.  So if you provide it with a string port,
that will not work.

I can't think of a hack to work around that, so we might even be screwed
for good (well, the hack you originally posted does the job but with a
very coarse grain).  Now you just have to hope that a Guile developer
will read this message and post a bright solution.

> Well, actually, I disagree.  If any application wants to cope with
> embedded Guile extensions in their input files

You may agree that this is not a very common case.  :-)

> Now, the 1.7 implementation has invalidated
> portions of the non-deprecated 1.6 interface that I have been using.

Well, *this* is arguably problematic.

Hope this helps,
Ludo'.


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

Re: Getting source location information

[Rob Browning]

ludovic.courtes@laas.fr (Ludovic Courtès) writes:

> If you want to use source locations in a Guile-friendly way (so that
> Guile can, for instance, display location information in
> backtraces), then you may want to use `scm_set_source_property_x
> (sexp, key, datum)' (where KEY may be one of SCM_SYM_FILENAME,
> SCM_SYM_LINE, SCM_SYM_COLUMN) which is defined in `srcprop.h'.

I think this is probably more along the lines of what he wants, but is
the above going to work correctly if there are multiple lines of
Scheme code?  For example:

   [This is an example ]
   (do-something (foo) (bar))
   (let ((baz bax))
     (do-something-else baz)
     (more-stuff baz)
     (and-even-more baz))
   [ ...with several lines of embedded Scheme code. ]

If I'm guesssing correctly about how scm_set_source_property_x works
(I haven't used it), then it seems like it might be a lot of work to
turn the above lines of Scheme code into a properly filename, line
(and column?) annotated set of forms.

If so, then I wondered if it might be possible to just implement the
function mentioned originally
i.e. ag_scm_c_eval_string_from_file_line, and here's what I came up
with.  Note that I have no idea if this will actually work; I haven't
tested it, and I don't know the semantics of the port related
filename, line, and column bits offhand.

  (define (eval-port port)
    ;; See strports.c inner_eval_string for similar code.
    (let loop ((next-form (read port))
               (any-read? #f)
               (result #f))
      (if (eof-object? next-form)
          (if any-read? result)
          (loop (read port)
                #t
                (primitive-eval next-form)))))

  (define (eval-string-from-file str filename line column)
    (call-with-input-string str
        (lambda (port)
          (set-port-filename! port filename)
          (set-port-line! port line)
          (set-port-column! port column)
          (eval-port port))))

-- 
Rob Browning
rlb @defaultvalue.org and @debian.org; previously @cs.utexas.edu
GPG starting 2002-11-03 = 14DD 432F AE39 534D B592  F9A0 25C8 D377 8C7E 73A4


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

Re: Getting source location information

[Bruce Korb]

On Wednesday 30 November 2005 11:00 am, Rob Browning wrote:
> If so, then I wondered if it might be possible to just implement the
> function mentioned originally
> i.e. ag_scm_c_eval_string_from_file_line, and here's what I came up
> with.  Note that I have no idea if this will actually work; I haven't
> tested it, and I don't know the semantics of the port related
> filename, line, and column bits offhand.
> 
>   (define (eval-port port)
>     ;; See strports.c inner_eval_string for similar code.
>     (let loop ((next-form (read port))
>                (any-read? #f)
>                (result #f))
>       (if (eof-object? next-form)
>           (if any-read? result)
>           (loop (read port)
>                 #t
>                 (primitive-eval next-form)))))
> 
>   (define (eval-string-from-file str filename line column)
>     (call-with-input-string str
>         (lambda (port)
>           (set-port-filename! port filename)
>           (set-port-line! port line)
>           (set-port-column! port column)
>           (eval-port port))))

With the final piece being the C code:

   SCM proc = scm_c_eval_string ("eval-string-from-file");
   SCM str  = scm_from_locale_string (scheme_text);
   SCM file = scm_from_locale_string (file_name);
   SCM line = scm_from_int (line_no);
   SCM res  = scm_call_3 (proc, str, file, line);
   //  Let's forget columns -- we don't have scm_call_4.

Actually, I might as well create the port in C and invoke "eval-port" directly.
I could easily set the column number, too.  (If I were tracking it.)

I'll give this a spin and let you know if it works shortly
(a day or two).  Thank you.  (I still think adding it to libguile
would not hurt.)

Regards, Bruce


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

Re: Getting source location information

[Rob Browning]

Bruce Korb <bruce.korb@gmail.com> writes:

> With the final piece being the C code:
>
>    SCM proc = scm_c_eval_string ("eval-string-from-file");

This is probably fine, but you might also want to try the
scm_c_module_lookup function(s).  They should be a little bit more
efficient:

     SCM proc = scm_variable_ref(scm_c_lookup("eval-string-from-file"));

There's also a SCM_VARIABLE_REF macro.

>    SCM res  = scm_call_3 (proc, str, file, line);
>    //  Let's forget columns -- we don't have scm_call_4.

Actually it looks like there is a scm_call_4.

> I'll give this a spin and let you know if it works shortly
> (a day or two).  Thank you.  (I still think adding it to libguile
> would not hurt.)

It could be worth adding something like this to Guile, but I'd need to
think a bit more about what might be most generally useful.

-- 
Rob Browning
rlb @defaultvalue.org and @debian.org; previously @cs.utexas.edu
GPG starting 2002-11-03 = 14DD 432F AE39 534D B592  F9A0 25C8 D377 8C7E 73A4


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

Re: Getting source location information

[Bruce Korb]

On Wednesday 30 November 2005 02:35 pm, Rob Browning wrote:

> >    SCM res  = scm_call_3 (proc, str, file, line);
> >    //  Let's forget columns -- we don't have scm_call_4.
> 
> Actually it looks like there is a scm_call_4.

OK.  Let's put it in the doc then, too.  :-)

> > I'll give this a spin and let you know if it works shortly
> > (a day or two).  Thank you.  (I still think adding it to libguile
> > would not hurt.)
> 
> It could be worth adding something like this to Guile, but I'd need to
> think a bit more about what might be most generally useful.

That would be great!  Thank you.  Regards, Bruce


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

Re: Getting source location information

[Han-Wen Nienhuys]

Bruce Korb wrote:
> Hi,
> 
> I am completely certain that this makes sense to you.  To me, it does
> not.  If I call ``scm_read(port)'' I have to attach the input file
> as a port.  That read function reads an s-expr.  How can that work if
> the non-Scheme text in the file is not an s-expr?  I don't see another

What we do in LilyPond is to do scm_seek() to  the start of the s-expr. 
Then scm_read() reads exactly one s-expr, and scm_ftell() shows us where 
we can continue reading non-Scheme stuff. The port is a string-port, 
which is easy enough, as we read the input file in a big string anyway.

-- 
  Han-Wen Nienhuys - hanwen@xs4all.nl - http://www.xs4all.nl/~hanwen



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

Re: I don't want to maintain this

[Kevin Ryde]

Bruce Korb <bruce.korb@gmail.com> writes:
>
>         port = scm_mkstrport( SCM_INUM0, expr, SCM_OPN | SCM_RDNG, zEx );

scm_open_input_string is probably easier.

>         pt->line_number = line - 1;
>         pt->file_name   = file;

Maybe scm_set_port_line_x and scm_set_port_filename_x instead of
mucking about with the ptab structure.

Apart from that a string port sounds good to me (without actually
trying it :-).


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

Re: I don't want to maintain this

[Kevin Ryde]

Bruce Korb <bruce.korb@gmail.com> writes:
>
> ERROR: Wrong type argument in position 1: #<unspecified>

Ah, I see 1.7 now throws an error for a non-number argument to
inexact?, where 1.6 would accept anything.

Looks like a deliberate change "2003-11-19 Marius Vollmer", maybe he
can say what motivated it.


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

Re: Getting source location information

[Ludovic Courtès]

Hi,

ludovic.courtes@laas.fr (Ludovic Courtès) writes:

> So I guess we're almost screwed because `scm_read ()' gets location info
> from the port it's reading from.  So if you provide it with a string port,
> that will not work.

Well, `set-port-filename!', `set-port-line!', etc. which Rob pointed out
_are_ indeed the right solution to get `scm_read ()' get the right
source location information...

Thanks,
Ludovic.


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

Re: I don't want to maintain this

[Marius Vollmer]

Kevin Ryde <user42@zip.com.au> writes:

> Bruce Korb <bruce.korb@gmail.com> writes:
>>
>> ERROR: Wrong type argument in position 1: #<unspecified>
>
> Ah, I see 1.7 now throws an error for a non-number argument to
> inexact?, where 1.6 would accept anything.
>
> Looks like a deliberate change "2003-11-19 Marius Vollmer", maybe he
> can say what motivated it.

The 1.7 behavior is what R5RS specifies.

-- 
GPG: D5D4E405 - 2F9B BCCC 8527 692A 04E3  331E FAF8 226A D5D4 E405


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

Re: Getting source location information

[Kevin Ryde]

Bruce Korb <bruce.korb@gmail.com> writes:
>
> OK.  Let's put it in the doc then, too.  :-)

I added it.


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