ℙ𝕖𝕡 🙴 ℕ𝕠𝕞

You cannot be serious! John McEnroe, tennis player, said to umpire

known bugs in the ℙ𝕖𝕡 ℕ𝕠𝕞 system

A document listing the bugs that I know about in the ℙ𝕖𝕡 / ℕ𝕠𝕞 system. This will include bugs in the pep interpreter and also translation scripts.

Unfortunately, since I have been working on this system by myself and sometimes take big breaks from it, there will be a number of bugs in the c pep interpreter and the translation scripts. Also, there are example scripts in the /eg/ example folder. You can look at the STATUS heading in most scripts to see if the script is in a working state.

But in general the system seems to work pretty well. If you get a segmentation fault in the pep interpreter, it means there is something wrong with the script (not clearing the workspace and the parse stack gets too big etc).

♛

• since I haven't tested this system of ms windows I haven't put much thought into line-endings: so basically I assume that text lines are ended with \n which is not true. To overcome this the read() method in the translation scripts should translated strange line endings to \n
• I have done minimal testing of unicode input into the example and translation scripts.

general bugs

• there is still (2025) no way to change the escape character that is used by the commands escape and unescape and also by the until command ( until will read past an escaped end delimiter). I should add an echar command which will do this.

ℙ𝕖𝕡 interpreter

• not sure if the stack and unstack commands actually update the tape pointer. But they do in the translation scripts because I implement stack and unstack as a while pop() or while push() loop which is simple and good.
• I got a 'executing undefined instruction' recently when writing the /eg/brainfork.c.pss script: not sure why, but that should never happen with a compiled script.
• ms windows line ending \r\n ? should be dealt with.
• you have to have a parse> label in a script, which seems silly but maybe not a bug.
• For historical reasons the pep interpreter tool (which is written the c language uses 'byte' characters. So basically input-streams or files may not work probably with nom scripts when they are interpreted with

   pep -f script.pss input.txt
  

• when I wrote "#* disable:" in a nom script the interpreter thought that disable was a command even though it is in a multiline comment.
• The 'D' abbreviation for replace does not work because 'D' is not a valid command letter in bumble.sf.net/books/pars/compile.pss . Compile.pss probably should be rewritten with a new grammar.
• classes like [.-] parse as ranges (i.e [a-z] ) not as lists
• a big stack will cause a segfault in the c pep machine.

translation scripts

• the old style translation scripts (translate.<lang>.pss) don’t read unicode grapheme clusters. At best they just read code points. Usually in a language parser you would want to get the whole grapheme cluster with each read command
• the old translation scripts don’t allow parse> labels in funny spots See the /tr/nom.todart.pss grammar for a solution.
• mar 2025: the PERL translation script has several bugs
• the python translator wasn't translating eg/text.tohtml.pss properly.
• Untested file reading code in /tr/nom.todart.pss probably doesn't work.

hopefully solved bugs

in the interpreter:

• didn't count escape chars when doing escape, unescape? see the dart code for this.