Open GoogleCodeExporter opened 8 years ago
The most common and confusing error I encounter when developing is a misspelled
name. Therefore, when this is done, my first suggested modification is to
http://code.google.com/p/python-on-a-chip/source/browse/src/vm/interp.c?spec=svn
a6e4a51472d9fc5a1d3a6f5a1867e23e4db2f394&r=50a0d809d17d12f4515ee2ac3832eab887f0a
cb0#1266 (line 1266). Change from:
PM_RAISE(retval, PM_RET_EX_NAME);
to:
PM_RAISE(retval, PM_RET_EX_NAME, "Name %s not defined.", ((pPmString_t) pobj1)->val);
A question: will the string always be null-terminated?
Original comment by bjones460@gmail.com
on 20 Oct 2010 at 3:02
General Python strings can have embedded nulls (s="see\x00here"), but Python
syntax does not allow for the direct construction of a name with an embedded
null (i.e. you can't type a variable name with a null in it). However, it is
possible to make one indirectly like this:
{{{
>>> g = globals()
>>> g["bob\x00bob"] = "billybob"
}}}
But again, there's no way to make a name out of bob\0bob:
{{{
>>> bob\0bob
File "<stdin>", line 1
bob\0bob
^
SyntaxError: unexpected character after line continuation character
}}}
Original comment by dwhall...@gmail.com
on 20 Oct 2010 at 5:13
So, printf should work to display any valid name. Per
http://code.google.com/p/python-on-a-chip/source/browse/docs/src/StringObjects.t
xt, all strings must be NULL-terminated. So, we're in good shape; I believe
this is safe.
Original comment by bjones460@gmail.com
on 20 Oct 2010 at 6:13
Original comment by dwhall...@gmail.com
on 22 Oct 2010 at 3:28
[deleted comment]
rb5f8a902b695
Put changes on a branch in order to seek help with variadic macro.
Original comment by dwhall...@gmail.com
on 3 Nov 2010 at 6:48
Changing PM_RAISE()'s condition from __DEBUG__ to HAVE_DEBUG_INFO because
__DEBUG__ is for C debugging and HAVE_DEBUG_INFO is for platforms that have the
capacity to accomodate Python debug information.
Original comment by dwhall...@gmail.com
on 5 Nov 2010 at 2:59
r16d78fb7e364
Added print-exception-message ability to: arduino_mega, desktop, mbed, mosync,
pic24 and windows platforms (all platforms that HAVE_DEBUG_INFO).
Changed PM_RAISE()'s conditional from __DEBUG__ to HAVE_DEBUG_INFO.
Had to relocate where pmfeatures.h was included in pm.h so that PM_RAISE()
macro had the HAVE_DEBUG_INFO definition available.
Original comment by dwhall...@gmail.com
on 10 Nov 2010 at 11:05
This issue was updated by revision e8f2d6c9ab.
- Decreased heap to make enough room for stack
- Added the -Wno-format-zero-length switch to all MPLAB projects
- Everything compiles, all tests pass. The switch eliminates the nuisance
warnings.
Original comment by bjones460@gmail.com
on 11 Nov 2010 at 5:48
This issue was updated by revision 7c241074af.
- Windows build tweaks: added many missing files to VS2010 project
- Changed VS2010 project to fix warning re: linker output file and project
output file different
- Tweaked declaraction in global.c to avoid warning
Original comment by bjones460@gmail.com
on 12 Nov 2010 at 4:51
Another helpful message: handle an AttributeError when a misspelled class
member / module member is referenced. For example:
import ipm
ipm.Ipm() # Should be ipm.ip()
Result:
Traceback (most recent call first):
File "main.py", line 15, in main
AttributeError detected by interp.c:1348
Looking at the code, pobj2 is a pointer to the key which wasn't found. Is there
any nice way to convert this to a string for inclusion in a helpful error
message? (E.g. the object can be a string or a boolean; in the future, perhaps
other immutable types will be supported).
Original comment by bjones460@gmail.com
on 4 Jan 2011 at 9:23
Added compiler flag to tests/system/Makefile so that tests compile.
rce9b331b623d
Original comment by dwhall...@gmail.com
on 8 May 2011 at 3:26
Added message to AttributeError
r998b52acf046
Original comment by dwhall...@gmail.com
on 8 May 2011 at 4:33
I think this is complicating things unnecessarily with the use of variadic
macros.
Since interp.c has to be modified in three specific points to accomodate for
attribute and name error strings, why not simply define a second macro
RAISE_WITHNAME() which takes the third (string*) parameter as in:
#define PM_RAISE_WITHNAME(retexn, exn, name) \
do \
{ \
retexn = (exn); \
gVmGlobal.errFileId = __FILE_ID__; \
gVmGlobal.errLineNum = (uint16_t)__LINE__; \
gVmGlobal.errName = (uint8_t*)name; \
} while (0)
After printing the standard error message, you can then test for a non NULL
pointer in plat.c such as:
/* check if additional Name string provided */
if ( gVmGlobal.errName != NULL)
{
sli_puts( gVmGlobal.errName);
sli_puts( "\n");
gVmGlobal.errName = NULL;
}
where errName is a string added to global.c
and in interp at line 1255, you can write:
PM_RAISE_WITHNAME(retval, PM_RET_EX_NAME, &(( pPmString_t)pobj1)->val);
or at 1365 :
PM_RAISE_WITHNAME(retval, PM_RET_EX_ATTR, (( pPmString_t)pobj2)->val);
Original comment by lucio.di...@googlemail.com
on 11 Jul 2013 at 1:54
Since I am applying these changes to my v10 clone the new global is actually
defined in pm.h
Original comment by lucio.di...@googlemail.com
on 11 Jul 2013 at 2:01
Original issue reported on code.google.com by
dwhall...@gmail.com
on 7 Oct 2010 at 3:42