more debugging info needed.

more debugging info needed.

[Paul Emsley]

Hi Guilers,

I'd like more more debugging info, I currently get something like:

Exception: (wrong-type-arg #f Wrong type (expecting ~A): ~S (pair D) (D))

I have
(turn-on-debugging)

in my begin.grg file.

I'd like to see the line number too.  Is that possible?

Thanks,

Paul.

Re: more debugging info needed.

[Neil Jerram]

Paul Emsley <paul.emsley@bioch.ox.ac.uk> writes:

> Hi Guilers,
>
> I'd like more more debugging info, I currently get something like:
>
> Exception: (wrong-type-arg #f Wrong type (expecting ~A): ~S (pair D) (D))
>
> I have
> (turn-on-debugging)
>
> in my begin.grg file.
>
> I'd like to see the line number too.  Is that possible?

Hi Paul,

`(turn-on-debugging)' is the right first step.  It makes sure that
debugging information (file names and line numbers) is available
internally, associated with the code that Guile has read in.

In addition, you need to

- capture the stack at the point where that exception occurs - using
  `catch', `lazy-catch' or `with-throw-handler'

- print out the captured stack, probably at the same place that you
  currently print the above exception args.

This is covered in detail in the `Debug on Error' node of the manual.
Please take a look at that and then let us know if you have further
questions.

Regards,
        Neil

Re: more debugging info needed.

[Paul Emsley]

Neil Jerram wrote:
> Paul Emsley <paul.emsley@bioch.ox.ac.uk> writes:
> 
>> Hi Guilers,
>>
>> I'd like more more debugging info, I currently get something like:
>>
>> Exception: (wrong-type-arg #f Wrong type (expecting ~A): ~S (pair D) (D))
>>
>> I have
>> (turn-on-debugging)
>>
>> in my begin.grg file.
>>
>> I'd like to see the line number too.  Is that possible?
> 
> Hi Paul,
> 
> `(turn-on-debugging)' is the right first step.  It makes sure that
> debugging information (file names and line numbers) is available
> internally, associated with the code that Guile has read in.
> 
> In addition, you need to
> 
> - capture the stack at the point where that exception occurs - using
>   `catch', `lazy-catch' or `with-throw-handler'
> 
> - print out the captured stack, probably at the same place that you
>   currently print the above exception args.
> 
> This is covered in detail in the `Debug on Error' node of the manual.
> Please take a look at that and then let us know if you have further
> questions.

Hi Neil.

Thanks.

I did read the manual.  Still I have the same problem, but now it seems 
clearer to me that I can't catch anything because Greg eats it first.

I will read some more...

Paul.

Re: more debugging info needed.

[Neil Jerram]

Paul Emsley <paul.emsley@bioch.ox.ac.uk> writes:

> I did read the manual.  Still I have the same problem, but now it
> seems clearer to me that I can't catch anything because Greg eats it
> first.

Greg has the unfortunate characteristic of being ungooglable... so I
can't immediately tell if it's something that might accept a patch.
Do you have a URL for it?

Regards,
        Neil

Re: more debugging info needed.

[Paul Emsley]

Neil Jerram wrote:
> Paul Emsley <paul.emsley@bioch.ox.ac.uk> writes:
> 
>> I did read the manual.  Still I have the same problem, but now it
>> seems clearer to me that I can't catch anything because Greg eats it
>> first.
> 
> Greg has the unfortunate characteristic of being ungooglable... so I
> can't immediately tell if it's something that might accept a patch.
> Do you have a URL for it?
>

Yes, it's a terrible name.  Maintainer is unresponsive also.

However, Greg is great.

This is Greg's Home:
http://home.gna.org/greg/

I made some fixes that didn't make it into stable release, I get the 
fixed up Greg from here:

http://www.ysbl.york.ac.uk/~emsley/software/extras/greg-2.0.0-pe.tar.gz

Paul.

Greg testing framework

[Ludovic Courtès]

Hi,

Paul Emsley <paul.emsley@bioch.ox.ac.uk> writes:

> However, Greg is great.
>
> This is Greg's Home:
> http://home.gna.org/greg/
>
> I made some fixes that didn't make it into stable release, I get the
> fixed up Greg from here:
>
> http://www.ysbl.york.ac.uk/~emsley/software/extras/greg-2.0.0-pe.tar.gz

What's the maintainance status?  It it sill used in GNUstep or other
projects?  It looks much nicer than DejaGNU...

Thanks,
Ludo'.

Re: Greg testing framework

[Paul Emsley]

Ludovic Courtès wrote:
> Hi,
>
> Paul Emsley <paul.emsley@bioch.ox.ac.uk> writes:
>
>   
>> However, Greg is great.
>>
>> This is Greg's Home:
>> http://home.gna.org/greg/
>>
>> I made some fixes that didn't make it into stable release, I get the
>> fixed up Greg from here:
>>
>> http://www.ysbl.york.ac.uk/~emsley/software/extras/greg-2.0.0-pe.tar.gz
>>     
>
> What's the maintainance status?  It it sill used in GNUstep or other
> projects?  It looks much nicer than DejaGNU...
>   

I'm afraid that I can't be of much help - I don't know in what way 
GNUstep uses Greg (however, I use it almost every day).  **Maurizio 
Boriani is the maintainer (his email address is in the README file), but 
he **does not correspond with me.

As for DejaGNU vs Greg... tcl vs guile?  Night and day... no contest!

Paul.

Re: Greg testing framework

[Linas Vepstas]

2009/2/3 Paul Emsley <paul.emsley@bioch.ox.ac.uk>:
> Ludovic Courtès wrote:
>> Paul Emsley <paul.emsley@bioch.ox.ac.uk> writes:
>>> However, Greg is great.
>>>
>>> This is Greg's Home:
>>> http://home.gna.org/greg/
>>>
>>> I made some fixes that didn't make it into stable release, I get the
>>> fixed up Greg from here:
>>>
>>> http://www.ysbl.york.ac.uk/~emsley/software/extras/greg-2.0.0-pe.tar.gz
>>>
>>
>> What's the maintainance status?  It it sill used in GNUstep or other
>> projects?  It looks much nicer than DejaGNU...
>
> I'm afraid that I can't be of much help - I don't know in what way GNUstep
> uses Greg (however, I use it almost every day).  **Maurizio Boriani is the
> maintainer (his email address is in the README file), but he **does not
> correspond with me.
>
> As for DejaGNU vs Greg... tcl vs guile?  Night and day... no contest!

Maurizio Boriani seems to have vanished somewhere.
I took over maintenance for guile-dbi from him just late
last year; I never received a response from him in
3-4 months of trying.

I eventually convinced the gna.org people to grant me
write access to the guile-dbi project, but that also was
not easy to do -- They did not respond on thier 'normal'
channels, I had to file a server bug or something else
strange like that, to get their attention.

The right thing to do would be to register with gna.org,
and try to get them to add you as a project maintainer
for greg, and push your updates there.

--linas

Re: more debugging info needed.

[Neil Jerram]

Paul Emsley <paul.emsley@bioch.ox.ac.uk> writes:

> This is Greg's Home:
> http://home.gna.org/greg/

Thanks.

> I made some fixes that didn't make it into stable release, I get the
> fixed up Greg from here:
>
> http://www.ysbl.york.ac.uk/~emsley/software/extras/greg-2.0.0-pe.tar.gz

OK, so basically you want to modify each occurrence of the (catch ...)
pattern in ice-9/greg.scm:

- Before each (catch ...), add `(set! stack-saved? #f)'

- To each (catch ...) add a fourth parameter `lazy-handler-dispatch'

- In the handler code of each (catch ...), add something like
  `(display-backtrace (fluid-ref the-last-stack) (current-error-port)
  #f #f '())' to print out the back trace.

That's a bit messy because it reuses some of the boot-9.scm code which
is really intended for the Guile REPL.  To do something neater, you
could copy just the bits of lazy-handler-dispatch that you really
need.

Regards,
        Neil