Request to add Chr function to debug statement

jay_harlow · 2022-12-14 22:34

Can a chr function be added to the debug statement?

``` debug(IF(TRACE_wifi_rx), "fds.rxtime(1000) ", lstr(@ch, 1), sdec(ch), chr(ch))

Instead of lstr(@ch, 1) or sdec(ch) one could use chr(status) which would output the character

``` fds.rxtime(1000) ch = S

Optionally if the underlying value is -1, it would not format the character, output -1 instead

Thanks
Jay

Simonius · 2022-12-14 22:59

Try debug(64,65)
@A

those are the ascii codes

ersmith · 2022-12-15 00:11

In other words, instead of writing chr(S) you can just write S and get the same result.

jay_harlow · 2022-12-15 00:11

@Simonius said:
Try debug(64,65)
@A

those are the ascii codes

Nice workaround

however, you lose all the formatting,

  debug(chr(ch1), chr(ch2))
  debug("oh1 = ",ch1, ", ch2 = ", ch2)

It's a little cleaner than my work around,

  debug(lstr(@ch1, 1),lstr(@ch2, 1),)

I still lilke the chr method the best so far.

Jay

jay_harlow · 2022-12-15 00:21

@ersmith said:
In other words, instead of writing chr(S) you can just write S and get the same result.

I in favor of writing "chr(variable)" and get "variable = S" as the result; assuming variable contains 83

Jay

jay_harlow · 2022-12-15 00:36

@jay_harlow said:
Optionally if the underlying value is -1, it would not format the character, output -1 instead

To expand on this, all control characters ( -1 to 31) should be mapped to a token 13 to NL for example.

Jay

rogloh · 2022-12-15 00:45

@jay_harlow said:
To expand on this, all control characters ( -1 to 31) should be mapped to a token 13 to NL for example.

If you want to able to issue specific characters for formatting with DEBUG I think you'd probably want to be able to issue characters 0-31 as well (to control different serial terminals etc), rather than have them all sending NL. Although this presupposes the DEBUG output can be directed to other applications and not just sent to PNut/PropTool for processing. I think there are ways that Wuerfel_21/ersmith already do that, at least with FlexSpin.

jay_harlow · 2022-12-15 01:10

@rogloh said:

@jay_harlow said:
To expand on this, all control characters ( -1 to 31) should be mapped to a token 13 to NL for example.

If you want to able to issue specific characters for formatting with DEBUG I think you'd probably want to be able to issue characters 0-31 as well (to control different serial terminals etc), rather than have them all sending NL. Although this presupposes the DEBUG output can be directed to other applications and not just sent to PNut/PropTool for processing. I think there are ways that Wuerfel_21/ersmith already do that, at least with FlexSpin.

Both formats should be allowed, 2 CHR functions, or 1 CHR function with a parameter

Jay

ersmith · 2022-12-15 01:52

The other thing is that introducing more reserved words (like CHR) will break existing programs, and that particular sequence of characters is probably used a lot. There are already work-arounds and ways to achieve this, so I don't think it's worth it myself.

cgracey · 2022-12-17 06:49

I think it would be nice to have:

ASCI(AsciiChr)
LOGT(TrueFalse)
LOGF(FalseTrue)

Someone else had asked for logical TRUE/FALSE debug output formats, as well.

Just need some ugly four-letter names for them that are unlikely to create conflicts.

rogloh · 2022-12-17 07:26

CHAR and BOOL would be nice. Would people name their functions or variables these names? I guess "char" might be used, I tend to use c or ch for that.

Phil Pilgrim (PhiPi) · 2022-12-17 07:36

One solution to the naming dilemma is to use sigils. For example, $chr would not conflict with chr. Okay, let the howls of derision begin. I said it was a solution. I didn't say it was a great solution. But it works for Perl and other languages.

-Phil

jay_harlow · 2022-12-17 14:24

@cgracey said:
I think it would be nice to have:

ASCI(AsciiChr)
LOGT(TrueFalse)
LOGF(FalseTrue)

Someone else had asked for logical TRUE/FALSE debug output formats, as well.

Just need some ugly four-letter names for them that are unlikely to create conflicts.

have you considered contextual keywords https://learn.microsoft.com/en-us/dotnet/csharp/language-reference/keywords/#contextual-keywords

chr is only reserved within a debug statement.

Jay

jay_harlow · 2022-12-17 15:00

@"Phil Pilgrim (PhiPi)" said:
One solution to the naming dilemma is to use sigils. For example, $chr would not conflict with chr. Okay, let the howls of derision begin. I said it was a solution. I didn't say it was a great solution. But it works for Perl and other languages.

-Pi

I use that in c#, default is a reserved word @default is not

https://learn.microsoft.com/en-us/dotnet/csharp/language-reference/keywords/

Jay

ersmith · 2022-12-17 17:17

@"Phil Pilgrim (PhiPi)" said:
One solution to the naming dilemma is to use sigils. For example, $chr would not conflict with chr. Okay, let the howls of derision begin. I said it was a solution. I didn't say it was a great solution. But it works for Perl and other languages.

Actually I think it's a great solution, Phil! $ wouldn't work because $c is a hex constant, but % would. % followed by a digit is a binary number, but % followed by a letter could introduce a special reserved keyword. So we could have %hex, %dec, %chr, and so on. Names starting with % would be reserved only for the compiler's use, and user variable could not start with that character. @cgracey, what do you think?

TonyB_ · 2022-12-17 18:19

@ersmith said:

@"Phil Pilgrim (PhiPi)" said:
One solution to the naming dilemma is to use sigils. For example, $chr would not conflict with chr. Okay, let the howls of derision begin. I said it was a solution. I didn't say it was a great solution. But it works for Perl and other languages.

Actually I think it's a great solution, Phil! $ wouldn't work because $c is a hex constant, but % would. % followed by a digit is a binary number, but % followed by a letter could introduce a special reserved keyword. So we could have %hex, %dec, %chr, and so on. Names starting with % would be reserved only for the compiler's use, and user variable could not start with that character. @cgracey, what do you think?

Could % on its own at the end of a line signify "continue parsing" instead of the { CR/LF } nonsense or ... ?

cgracey · 2022-12-17 20:44

@TonyB_ said:

@ersmith said:

@"Phil Pilgrim (PhiPi)" said:
One solution to the naming dilemma is to use sigils. For example, $chr would not conflict with chr. Okay, let the howls of derision begin. I said it was a solution. I didn't say it was a great solution. But it works for Perl and other languages.

Actually I think it's a great solution, Phil! $ wouldn't work because $c is a hex constant, but % would. % followed by a digit is a binary number, but % followed by a letter could introduce a special reserved keyword. So we could have %hex, %dec, %chr, and so on. Names starting with % would be reserved only for the compiler's use, and user variable could not start with that character. @cgracey, what do you think?

Could % on its own at the end of a line signify "continue parsing" instead of the { CR/LF } nonsense or ... ?

It could, yes.

cgracey · 2022-12-17 20:45

@ersmith said:

@"Phil Pilgrim (PhiPi)" said:
One solution to the naming dilemma is to use sigils. For example, $chr would not conflict with chr. Okay, let the howls of derision begin. I said it was a solution. I didn't say it was a great solution. But it works for Perl and other languages.

Actually I think it's a great solution, Phil! $ wouldn't work because $c is a hex constant, but % would. % followed by a digit is a binary number, but % followed by a letter could introduce a special reserved keyword. So we could have %hex, %dec, %chr, and so on. Names starting with % would be reserved only for the compiler's use, and user variable could not start with that character. @cgracey, what do you think?

I think it's a great idea.

ersmith · 2022-12-17 21:08

@TonyB_ said:

@ersmith said:

@"Phil Pilgrim (PhiPi)" said:
One solution to the naming dilemma is to use sigils. For example, $chr would not conflict with chr. Okay, let the howls of derision begin. I said it was a solution. I didn't say it was a great solution. But it works for Perl and other languages.

Actually I think it's a great solution, Phil! $ wouldn't work because $c is a hex constant, but % would. % followed by a digit is a binary number, but % followed by a letter could introduce a special reserved keyword. So we could have %hex, %dec, %chr, and so on. Names starting with % would be reserved only for the compiler's use, and user variable could not start with that character. @cgracey, what do you think?

Could % on its own at the end of a line signify "continue parsing" instead of the { CR/LF } nonsense or ... ?

Yet another way to continue lines? Seems like overkill, really, since there are already two of them!

Phil Pilgrim (PhiPi) · 2022-12-17 21:14

In addition to the fact that it's already built in to the language, one nice thing about { CR/LF } is that you can comment a long statement piece-by-piece, as illustrated in an earlier post.

-Phil

TonyB_ · 2022-12-17 22:21

@ersmith said:

@TonyB_ said:

@ersmith said:

@"Phil Pilgrim (PhiPi)" said:
One solution to the naming dilemma is to use sigils. For example, $chr would not conflict with chr. Okay, let the howls of derision begin. I said it was a solution. I didn't say it was a great solution. But it works for Perl and other languages.

Actually I think it's a great solution, Phil! $ wouldn't work because $c is a hex constant, but % would. % followed by a digit is a binary number, but % followed by a letter could introduce a special reserved keyword. So we could have %hex, %dec, %chr, and so on. Names starting with % would be reserved only for the compiler's use, and user variable could not start with that character. @cgracey, what do you think?

Could % on its own at the end of a line signify "continue parsing" instead of the { CR/LF } nonsense or ... ?

Yet another way to continue lines? Seems like overkill, really, since there are already two of them!

There may be two already but neither is excellent, one has been around for a very short time and the other is in my opinion plain daft.

% is superior to both because (a) it is a single char, (b) it is only on the line to be continued, (c) it is a sensible and logical use of the proposed new reserved symbol and (d) it is a good visual representation of the action involved.

Phil Pilgrim (PhiPi) · 2022-12-17 23:19

. . . instead of the { CR/LF } nonsense

. . . and the other is in my opinion plain daft.

"Nonsense" and "daft" are rather emotional reactions to a reasonable paradigm that already works -- and has for years. Perhaps you can explicate its logical disadvantages compared to other solutions.

Thanks,
-Phil

Phil Pilgrim (PhiPi) · 2022-12-17 23:51

How about this to keep everyone happy? Let the user define macros:

MAC

  "..." = "}\r\n{"

Yes, it's about time to introduce the escape character \ into string expressions, too!

Or, better yet, if context is important, define macros using regular expressions:

MAC

  s/\.\.\..*\r\n/\}\r\n\{/

recognizes ... only at the end of a line.

-Phil

msrobots · 2022-12-18 05:40

Macros is a cool idea, but PLEASE no regular expressions.

Mike

Phil Pilgrim (PhiPi) · 2022-12-18 07:40

Macros is a cool idea, but PLEASE no regular expressions.

I'm always mystified by people's aversion to REs. They can be as simple as you want them to be, but extremely powerful when you need that power. It's totally up to the user which level of complexity to choose.

-Phil

VonSzarvas · 2022-12-18 10:18

Macros seem like a relatively simple addition; essentially a pre-process find/replace operation.

Regex would require a signifcant development "tangent" and no doubt introduce never-ending edge cases that would fuel ongoing distraction and displeasure. That seems like a feature only justifiable alongside a substantial product order if not coming from a community initiative.

Phil Pilgrim (PhiPi) · 2022-12-18 19:33

I agree that adding a regex engine to the compiler from scratch would be nearly insurmountable. But there are plenty of high-level languages that already have those engines built-in. So do the macro expansions in a high-level preprocessor before handing the converted code off to the compiler.

-Phil

msrobots · 2022-12-19 04:13

Lets get

IFDEF and friends go into PropTool/Pnut first.

Absolutely needed.

SECTION

MAC
    "..." = "}\r\n{"

with simple text replacement is a wonderful idea and easy to put into all spin parser.

So @cgracey PLEASE add #IFDEF & friends and MACros, PLEASE. II am sure @ersmith has no problems adding MACros to FlexProp

Enjoy!

Mike

Phil Pilgrim (PhiPi) · 2022-12-19 07:59

So @cgracey PLEASE add #IFDEF & friends and MACros, PLEASE. II am sure @ersmith has no problems adding MACros to FlexProp

No, this stuff does not belong in Chip's 386 assembly-language compiler. It belongs in a preprocessor that someone other than Chip can write using a high-level language.

That said, I do think escaped string characters belong in the compiler, viz.:

ser.str(string("Results for \"My Study\" follow on the next lines:\r\r"))

rather than the more awkward

ser.str(string("Results for ", 34, "My Study", 34, " follow on the next lines:", 13, 13))

Here are some of them:

\r Carriage return
\n New line
\t Tab
\" Double quote
\ Backslash

-Phil

Electrodude · 2022-12-19 17:44

@"Phil Pilgrim (PhiPi)" said:
\ Backslash

The forum markup ate one of your backslashes. I think you meant:

\\ Backslash

ersmith · 2022-12-19 17:56

We're really starting to wander away from the original request with more an more elaborate things. Maybe we should go back to basics -- the OP would like to add some new debug types, other posters worried about conflicts with existing code, @"Phil Pilgrim (PhiPi)" made a great suggestion that some reserved words could start with a special character like %. Let's maybe start with that.

Request to add Chr function to debug statement

Comments

IFDEF and friends go into PropTool/Pnut first.