Shop OBEX P1 Docs P2 Docs Learn Events
PNut/Spin2 Latest Version (v44 -Data Structures Added, New Methods for Memory Testing/Manipulation) - Page 29 — Parallax Forums

PNut/Spin2 Latest Version (v44 -Data Structures Added, New Methods for Memory Testing/Manipulation)

1262729313263

Comments

  • If you open the file with WordPad, and then do a "save as" to the same file name, it will add the CR's to it so PNut can handle it.
  • I've almost always had this problem (no CRs) as a macOS user, when using PNut & Propeller Tools in a WIN10 VM. Whenever, I've downloaded files from git on the macOS side, then tried to read them on the WIN 10 side, it has happened. So, I'm used to opening the files with an editor in macOS first, copying the text and pasting back in PNut or Propeller Tool (yuck).

    I kind of remember that someone here on the forum had a script to ad the CRs (was it a Perl or Pyrthon script?)


    dgately

  • @Dave Hein
    If you open the file with WordPad, and then do a "save as" to the same file name, it will add the CR's to it so PNut can handle it.


    I already tried that but for me when I reopened it in Pnut, it looked normal . However, when you compile it , everything goes back to one line and it's doesn't complie.

    You still get a error mesage
    " No PUB method found"
  • cgraceycgracey Posts: 14,131
    I'm working on this right now. I meant to take care of this a few months ago, but I got distracted.

    So, considering UNIX, Mac's, and PC's, is this rule set comprehensive? (see below)

    13,10 -> 13,10 (PC, no change)
    13,<>10 -> 13,10 (Mac?)
    <>13,10 -> 13,10 (Linux?)

    This would mean that files always wind up PC-style, with both 13 and 10.

    Would it be better to preserve what is found, so that the file is still native to the platform?
  • Cluso99Cluso99 Posts: 18,066
    edited 2020-08-27 23:20
    cgracey wrote: »
    I'm working on this right now. I meant to take care of this a few months ago, but I got distracted.

    So, considering UNIX, Mac's, and PC's, is this rule set comprehensive? (see below)

    13,10 -> 13,10 (PC, no change)
    13,<>10 -> 13,10 (Mac?)
    <>13,10 -> 13,10 (Linux?)

    This would mean that files always wind up PC-style, with both 13 and 10.

    Would it be better to preserve what is found, so that the file is still native to the platform?
    Don't know the answer. You would think 40+ years on it would be sorted, but no!
    No-one will give in to make a standard - Windows/DOS, *nix, Mac
  • Dave HeinDave Hein Posts: 6,347
    edited 2020-08-27 23:51
    Chip, the way I handle it in my programs is that I will strip off the CRLF characters at the end of a line as I read them in. I store each line internally as a NULL terminated string without the CR or LF at the end. When you write the file out you could preserve the format that it had when you opened it. For new files you could default to the native format -- CRLF for a Windows, and just LF for Linux. I don't really know what the Mac uses.
  • Cluso99Cluso99 Posts: 18,066
    Confirmed the problem with pnut is the missing CR. The file is terminated in LF only.
  • cgraceycgracey Posts: 14,131
    Dave Hein wrote: »
    Chip, the way I handle it in my programs is that I will strip off the CRLF characters at the end of a line as I read them in. I store each line internally as a NULL terminated string without the CR or LF at the end. When you write the file out you could preserve the format that it had when you opened it. For new files you could default to the native format -- CRLF for a Windows, and just LF for Linux. I don't really know what the Mac uses.

    Good idea. That's what I'll do for now - preserve the format on saving, but convert it to an internal standard on loading. Internally, I just have CR at line ends and a $00 at the file end.
  • ASCII character 10
    ASCII character 10 is also called a Line Feed or LF . On a UNIX based operating system such as Linux or Mac it is all you typically use to delineate a line in a file. The ASCII character code 13 is called a Carriage Return or CR

    https://www.google.com/search?q=ascii+charcter+for+line+feed&oq=ascii+charcter+for+line+feed&aqs=chrome..69i57.6943j0j15&sourceid=chrome&ie=UTF-8



    Here is how the different platforms end lines in ASCII files.

    Windows - Lines end with both a <CR> followed by a <LF> character
    Linux - Lines end with only a <LF> character
    Macintosh (Mac OSX) - Lines end with only a <LF> character
    Macintosh (old) - Lines end with only a <CR> character

    https://confluence.qps.nl/fledermaus7/questions-answers/other/differences-in-end-of-line-characters-mac-windows-and-linux
  • cgraceycgracey Posts: 14,131
    ASCII character 10
    ASCII character 10 is also called a Line Feed or LF . On a UNIX based operating system such as Linux or Mac it is all you typically use to delineate a line in a file. The ASCII character code 13 is called a Carriage Return or CR

    https://www.google.com/search?q=ascii+charcter+for+line+feed&oq=ascii+charcter+for+line+feed&aqs=chrome..69i57.6943j0j15&sourceid=chrome&ie=UTF-8



    Here is how the different platforms end lines in ASCII files.

    Windows - Lines end with both a <CR> followed by a <LF> character
    Linux - Lines end with only a <LF> character
    Macintosh (Mac OSX) - Lines end with only a <LF> character
    Macintosh (old) - Lines end with only a <CR> character

    https://confluence.qps.nl/fledermaus7/questions-answers/other/differences-in-end-of-line-characters-mac-windows-and-linux

    I've got them all covered now.
  • This should be great. PNut messing up source file upon reads/writes was a real problem with shared folders between MACs and PCs, so your internal format handling seems like the best way to go Chip. The conversion algorithm you suggested above looks right. The MAC nowadays is the same as UNIX (LF only).

    I sort of hope the same applies to the official PropTool in the end (perhaps it already supports that) because I've been wondering whether to release my source in Unix or Windows format, and I'd prefer to keep it as is without the CRs, just the LF's so I don't have to convert each time things change. Not sure how well Windows supports viewing the Unix text files these days, but hopefully it should be better than it used to be given they want to try to support some more Unix tools etc.
  • cgraceycgracey Posts: 14,131
    edited 2020-08-28 02:42
    New version at the top of this thread loads and saves all three text-file formats:

    1) PC, where new line is CR+LF
    2) Linux, where new line is LF
    3) Mac, where new line is CR

    File format is preserved from loading to saving.
  • cgraceycgracey Posts: 14,131
    rogloh wrote: »
    This should be great. PNut messing up source file upon reads/writes was a real problem with shared folders between MACs and PCs, so your internal format handling seems like the best way to go Chip. The conversion algorithm you suggested above looks right. The MAC nowadays is the same as UNIX (LF only).

    I sort of hope the same applies to the official PropTool in the end (perhaps it already supports that) because I've been wondering whether to release my source in Unix or Windows format, and I'd prefer to keep it as is without the CRs, just the LF's so I don't have to convert each time things change. Not sure how well Windows supports viewing the Unix text files these days, but hopefully it should be better than it used to be given they want to try to support some more Unix tools etc.

    The only built-in Windows app that seems to load LF-only files is WordPad, which is really awkward. I wish things were more sensible, because I would be happy to go with LF-only.
  • evanhevanh Posts: 15,091
    ...
    2) Unix (Linux/OS X), where new line is LF
    3) Pre-OS X Mac (20+ years back), where new line is CR

    PS: The Amiga also used LF.
  • cgracey wrote: »
    rogloh wrote: »
    This should be great. PNut messing up source file upon reads/writes was a real problem with shared folders between MACs and PCs, so your internal format handling seems like the best way to go Chip. The conversion algorithm you suggested above looks right. The MAC nowadays is the same as UNIX (LF only).

    I sort of hope the same applies to the official PropTool in the end (perhaps it already supports that) because I've been wondering whether to release my source in Unix or Windows format, and I'd prefer to keep it as is without the CRs, just the LF's so I don't have to convert each time things change. Not sure how well Windows supports viewing the Unix text files these days, but hopefully it should be better than it used to be given they want to try to support some more Unix tools etc.

    The only built-in Windows app that seems to load LF-only files is WordPad, which is really awkward. I wish things were more sensible, because I would be happy to go with LF-only.

    The notepad in Windows 10 actually does support LF-only files. As does any editor that one might actually want to use.
  • Dave HeinDave Hein Posts: 6,347
    edited 2020-08-28 10:16
    The fix in notepad is a fairly recent thing. According to the Wikipedia page on notepad they fixed this 2 years ago.
    Historically, Notepad did not treat newlines in Unix- or classic Mac OS-style text files correctly. However, on 8th May 2018, Microsoft announced that they had fixed this issue.
    It only took them a few decades to do it.
  • cgraceycgracey Posts: 14,131
    edited 2020-08-28 21:19
    So, has anybody tried v34y, yet, and confirmed that loading and saving works with the various formats?
  • need two days before
    I get back to the lab.
  • @cgracey
    So, has anybody tried v34y, yet, and confirmed that loading and saving works with the various formats?

    It's working great!! on MS Windows 10. Thanks! Chip. :)

  • Cluso99Cluso99 Posts: 18,066
    W10 Pro

    After unzipping, creating a shortcut on the taskbar, then clicked to run - came up with a warning from Windows Defender about unsigned? program and wanted to remove it. I answered run anyway. It ran, compiled, loaded and executed just fine with a simple P2 test program :)

    Note that pnut34x did not cause a Defender issue. It just ran fine out of the box (same method as I used with pnut34y).
  • I have a request.

    After we get version 34z, can the next version please be 34 zz9 ? And perhaps release it as an Alpha version?

    This would make a lot of HitchHiker's Guide to the Galaxy fans happy

    Thanks
  • cgraceycgracey Posts: 14,131
    Thanks for trying it, Guys.

    So, 34 zz9... I suppose so.
  • cgraceycgracey Posts: 14,131
    edited 2020-08-29 02:26
    I've finally got the FFT debug display working.

    This code:
    PUB go() | i, f[5]
    
      ' Set up FFT
      debug("`fft f pos 100 600 size 600 500 samples 1024 1024 0 49 linesize 1 dotsize 3 textsize 12")
      debug("`f 'FFT1' 0 1000 70 10 15")
      debug("`f 'FFT2' 0 1000 70 110 15")
      debug("`f 'FFT3' 0 1000 70 210 15")
      debug("`f 'FFT4' 0 1000 70 310 15")
      debug("`f 'FFTX' 0 1000 70 410 15")
    
      ' Set up scope
      debug("`scope s pos 100 600 size 600 500 samples 1024 linesize 1 textsize 12")
      debug("`s 'Sine1' -1000 1000 70 10 15")
      debug("`s 'Sine2' -1000 1000 70 110 15")
      debug("`s 'Sine3' -1000 1000 70 210 15")
      debug("`s 'Sine4' -1000 1000 70 310 15")
      debug("`s 'SineX' -1000 1000 70 410 15")
    
      ' Generate waveforms
      repeat i from 0 to 1023
        f[0],_ := polxy(1000, i * $03000000)
        f[1],_ := polxy(1000, i * $05000000)
        f[2],_ := polxy(1000, i * $07000000)
        f[3],_ := polxy(1000, i * $09000000)
        f[4]   := f[0] + f[1] + f[2] + f[3]
        debug("`f ", sdec_long_array_(@f, 5))
        debug("`s ", sdec_long_array_(@f, 5))
        waitms(20)
    

    Makes this (we are looking at FFT bins 0..49):

    FFT.png

    Note how all powers are 1:1 with input amplitudes. Magnification is Power(2,n) and n=0, after the 'FFT' labels.

    Next, I want to make a rolling spectrograph display and then I'll document all this and output a new version of PNut which has all this in it.
    622 x 1150 - 24K
    FFT.png 24.4K
  • RaymanRayman Posts: 13,767
    Does PNut still run from command line?
    If so, seem to have forgotten how to do it...
    Are there instructions somewhere?
  • cgraceycgracey Posts: 14,131
    Rayman wrote: »
    Does PNut still run from command line?
    If so, seem to have forgotten how to do it...
    Are there instructions somewhere?

    In the Spin documentation, linked to at the top of this thread, command-line operation is covered.
  • RaymanRayman Posts: 13,767
    Found it, thanks. It would be useful to have some kind of output on whether compilation was successful or not (at least).
  • cgraceycgracey Posts: 14,131
    Rayman wrote: »
    Found it, thanks. It would be useful to have some kind of output on whether compilation was successful or not (at least).

    I think I did implement ERRORLEVEL. You can check ERRORLEVEL in a batch file after compilation.
  • cgraceycgracey Posts: 14,131
    edited 2020-08-29 20:34
    cgracey wrote: »
    Rayman wrote: »
    Found it, thanks. It would be useful to have some kind of output on whether compilation was successful or not (at least).

    I think I did implement ERRORLEVEL. You can check ERRORLEVEL in a batch file after compilation.

    I just verified this. You need to make a batch file that looks something like this:
    pnut untitled -c
    echo %ERRORLEVEL%
    

    ERRORLEVEL will be 0 if everything went okay, or 1 if there was an error.
  • cgraceycgracey Posts: 14,131
    I found some ways to make the graphical debug windows run a lot faster, by adding a RATE parameter which updates the window's graphics on every Nth datum received, and also by polling for received data differently. Ultimately, I need to get the data reception into its own Windows thread, so that nothing can clobber it.


    PUB go() | i, j, w[5]
    
      ' Set up FFT
      debug("`fft f pos 0 0 size 600 600 samples 1024 0 127 rate 70 linesize 1 dotsize 3 textsize 12")
      debug("`f 'FFT1' 0 1000 70 10 15")
      debug("`f 'FFT2' 0 1000 70 110 15")
      debug("`f 'FFT3' 0 1000 70 210 15")
      debug("`f 'FFT4' 0 1000 70 310 15")
      debug("`f 'FFTX' 0 1000 70 410 15")
    
      ' Set up scope
      debug("`scope s pos 623 0 size 600 600 samples 300 rate 70 linesize 1 textsize 12")
      debug("`s 'Sine1' -1000 1000 70 10 15")
      debug("`s 'Sine2' -1000 1000 70 110 15")
      debug("`s 'Sine3' -1000 1000 70 210 15")
      debug("`s 'Sine4' -1000 1000 70 310 15")
      debug("`s 'WaveX' -1000 1000 70 410 15", dly(100))
    
      ' Generate waveforms
      j~
      repeat i from 0 to 1024 * 80 - 1
        j += $800
        w[0],_ := polxy(1000, i * ($04000000 + j*4))
        w[1],_ := polxy(1000, i * ($07000000 + j*3))
        w[2],_ := polxy(1000, i * ($0A000000 + j*2))
        w[3],_ := polxy(1000, i * ($0D000000 + j*1))
        w[4]   := w[0] + w[1] + w[2] + w[3]
        debug("`f ", sdec_long_array_(@w, 5))
        debug("`s ", sdec_long_array_(@w, 5))
    
  • Nice work - The new PNut Ver.34y works great and no sign of any nasty code virus.

    Stepping back and reviewing: - What is the preferred installation of Ver.34y ? - Either in the Windows/../Program Files(86)/Parallax - or - any sub-directory you want? I am currently using the Documents directory and everything seems fine.

    Secondly - Running PNut Ver.34y directly gives no screen color formatting, just a text screen. I use add-in 2.2.0.0 Alpha for full editing capability. Everything appears to work nicely.

    Given all of that - How do I know that 2.2.0.0 Alpha is picking up and running PNut Ver.34y ??? Is there any printable version function I can use to be absolutely sure?
Sign In or Register to comment.