> --- Leopold Toetsch <[EMAIL PROTECTED]> wrote:
> > Amir Karger <[EMAIL PROTECTED]> wrote:
[fixes]
> > I'll put in these fixes.
Thanks!
> >
> > > The bad news is that when I then try to parrot it, Windows throws
> > > me an error window saying parrot died. I don't know why.
> >
> > linux SIGSEGVs. The problem is expr.pasm:419 containing a string
> > with 1024 chars in one line. This is one of the known problems of
> > imcc/parrot. There is no official limit on lines, strings or
> > identifier
> > length, while internally its assumed that there is one. This is of
> > course a bug.
[proposed long-term solutions snipped]
OK, but in the meantime, I replaced line 419 with:
set S1,
"\x00\x01\x02\x03\x04\x05\x06\x07\x08\x09\x0a\x0b\x0c\x0d\x0e\x0f\x10\x11\x12\x13\x14\x15\x16\x17\x18\x19\x1a\x1b\x1c\x1d\x1e\x1f\x20\x21\x22\x23\x24\x25\x26\x27\x28\x29\x2a\x2b\x2c\x2d\x2e\x2f\x30\x31\x32\x33\x34\x35\x36\x37\x38\x39\x3a\x3b\x3c\x3d\x3e\x3f"
set S19,
"\x40\x41\x42\x43\x44\x45\x46\x47\x48\x49\x4a\x4b\x4c\x4d\x4e\x4f\x50\x51\x52\x53\x54\x55\x56\x57\x58\x59\x5a\x5b\x5c\x5d\x5e\x5f\x60\x61\x62\x63\x64\x65\x66\x67\x68\x69\x6a\x6b\x6c\x6d\x6e\x6f\x70\x71\x72\x73\x74\x75\x76\x77\x78\x79\x7a\x7b\x7c\x7d\x7e\x7f"
concat S1, S19
set S19,
"\x80\x81\x82\x83\x84\x85\x86\x87\x88\x89\x8a\x8b\x8c\x8d\x8e\x8f\x90\x91\x92\x93\x94\x95\x96\x97\x98\x99\x9a\x9b\x9c\x9d\x9e\x9f\xa0\xa1\xa2\xa3\xa4\xa5\xa6\xa7\xa8\xa9\xaa\xab\xac\xad\xae\xaf\xb0\xb1\xb2\xb3\xb4\xb5\xb6\xb7\xb8\xb9\xba\xbb\xbc\xbd\xbe\xbf"
concat S1, S19
set S19,
"\xc0\xc1\xc2\xc3\xc4\xc5\xc6\xc7\xc8\xc9\xca\xcb\xcc\xcd\xce\xcf\xd0\xd1\xd2\xd3\xd4\xd5\xd6\xd7\xd8\xd9\xda\xdb\xdc\xdd\xde\xdf\xe0\xe1\xe2\xe3\xe4\xe5\xe6\xe7\xe8\xe9\xea\xeb\xec\xed\xee\xef\xf0\xf1\xf2\xf3\xf4\xf5\xf6\xf7\xf8\xf9\xfa\xfb\xfc\xfd\xfe\xff"
concat S1, S19
I'm sure I've broken several sacred Parrot rules by doing this, which I
hope you'll tell me about so I can learn the sacred Parrot rules. But
it
*does* compile and run this way.
I believe I've found another bug. All numerical variables have a
s/\.?0+$// performed on them whenever their value gets fetched (e.g.
when evaluating an expression including the variable name, either to do
math or to print). Note the question mark in the above s/// - that's a
bug! I believe the problem is in subroutine NTOA (alpha.pasm: 164),
which tries to do s/\.0+$//.
It seems that in the old days, variables with integer values were
stored
as 1.000, so NTOATRUNC: got written, but now the value gets truncated
somewhere along the line, so then we're trying to remove 0's at the end
and then a '.', but we end up just removing zeroes!
So I guess the fix is just to remove NTOATRUNC and NTOA_ALMOST
entirely.
If not, at the least you should jump over them if index(S0, '.') != -1.
For example, adding the following lines after line 171 of alpha.pasm
fixed the problem as far as I could see:
index I1, S0, '.'
eq -1, I1, NTOADONE
A final bug: line 820 of sampleb.bas should read "820 PRINT 355/113" :)
> > Thanks for reporting
Thanks for fixing.
-Amir
__________________________________
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com
