Shop OBEX P1 Docs P2 Docs Learn Events
Request to add Chr function to debug statement — Parallax Forums

Request to add Chr function to debug statement

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

«1

Comments

  • Try debug(64,65)
    @A

    those are the ascii codes

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

  • @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

  • @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 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

  • @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.

  • @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

  • 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.

  • cgraceycgracey Posts: 14,133
    edited 2022-12-17 06:55

    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.

  • 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.

  • 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

  • @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

  • @"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

  • @"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_TonyB_ Posts: 2,144
    edited 2022-12-17 18:21

    @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 ... ?

  • cgraceycgracey Posts: 14,133

    @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.

  • cgraceycgracey Posts: 14,133

    @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.

  • @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!

  • 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

  • @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.

  • . . . 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

  • 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

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

    Mike

  • 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

  • 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.

  • 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

  • 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

  • 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

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

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

    \\ Backslash

  • 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.

Sign In or Register to comment.