On Jeudi 5 Septembre 2002 17:08, Dan Sugalski wrote :
> At 3:04 PM +0000 9/5/02, Leon Brocard (via RT) wrote:
> >I realise that proper Unicode support is coming, but it may be a while
> >to get here. We currently have ord() and it makes sense to have a
> >chr() as well, so that's what my patch provides. Please apply, thanks ;-)
> Done.
I wanted to use the chr instruction in my Befunge interpreter. I modified it
to take this new instruction into account, instead of Clinton Pierce's hack
(check BASIC)... But it did not work properly. I was rather puzzled, so I
came back with my original version (rsync the whole parrot), and tried to
"make test" in the languages/Befunge-93 directory: I got the same buggy
behavior!
Taking a look in more depth, I found _where_ the bug lies in my Befunge
interpreter, but can't understand _why_ there's such a bug.
Here's the buggy code. I added the print (and end) statements in order to
understand what's going on (at the moment of execution, S0 should be the
string "v").
IO_PUSH_CHAR:
pushi
ord I10, S0
print "\n===\n>"
print S0
print "<\n>"
print I10
print "<\n===\n"
end
And I get:
===
>v<
>60<
===
which is obviously a bug...
In fact, I tried to change S0, and whatever S0 value is (I tried with several
values: "<", ">", "A", "0", " "), I always get a 60 as its ordinal value...
When I check the length of S0:
length I12, S0
print I12
print "\n"
I get:
1
(which is correct - remember, S0 eq "v")
I also tried the three-args form of ord():
ord I10, S0, 0
but get the same result...
The strange thing is that when I run in a standalone test.pasm the buggy code:
set S0, "v"
ord I10, S0
print "\n===\n>"
print S0
print "<\n>"
print I10
print "<\n===\n"
end
then it works nice:
====
>v<
>118<
====
Does anybody have an explanation? When I sent the patch with the Befunge-93
interpreter, it was working well. (promise! :-) )
Who broke my interpreter?
J�r�me
--
[EMAIL PROTECTED]
