error disclosure

[Stefan Reinauer]

Hi there,

the error disclosure of the config tool is a little bit mystic.
Building the sandpoint configuration says the following:

Creating directory motorola_sandpoint/only
Creating motorola_sandpoint/only/static.c
Traceback (most recent call last):
  File "motorola_sandpoint/config.py", line 2732, in ?
    writecode(image)
  File "motorola_sandpoint/config.py", line 2649, in writecode
    gencode(image.getroot(), file, 1)
  File "motorola_sandpoint/config.py", line 2654, in gencode
    part.gencode(file, pass_num)
  File "motorola_sandpoint/config.py", line 804, in gencode
    file.write("struct device **last_dev_p = &%s.next;\n" %
(self.image.last_dev
ice.instance_name))
AttributeError: 'int' object has no attribute 'instance_name'

This looks like an error in the config tool, while it is a mistake in the
config file. Is there any easy way to point the user/developer to the
place in the config file that is wrong (rather than printing a python
traceback)?  This could make it a lot easier for newbies to create fresh
linuxbios ports to motherboards whose hardware is basically already
supported and it could safe the regulars quite some time comparing
config files between the ports...

Stefan

Stefan Reinauer  writes:
> Hi there,
>
> the error disclosure of the config tool is a little bit mystic.
> Building the sandpoint configuration says the following:
> This looks like an error in the config tool, while it is a mistake in the
> config file. Is there any easy way to point the user/developer to the
> place in the config file that is wrong (rather than printing a python
> traceback)?  This could make it a lot easier for newbies to create fresh
> linuxbios ports to motherboards whose hardware is basically already
> supported and it could safe the regulars quite some time comparing
> config files between the ports...

Last I looked a lot of the problem is design issues with the python parser
generator the code is using.  It does not do a very good job at remember 
making it possible to print good error messages.

The case you mention does not look like the typical failure there so it may
allow for a simple fix.

Eric

[Ronald G. Minnich]

On Wed, 1 Dec 2004, Eric W. Biederman wrote:
> Last I looked a lot of the problem is design issues with the python
> parser generator the code is using.  It does not do a very good job at
> remember making it possible to print good error messages.

yeah, that parser generator is disappointing in the error recovery.

Fixes gratefully accepted.

ron