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?)
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"
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.
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
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
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
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
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.
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.
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.
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.
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 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.
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?
Comments
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
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"
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?
No-one will give in to make a standard - Windows/DOS, *nix, Mac
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 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.
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.
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.
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.
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.
The notepad in Windows 10 actually does support LF-only files. As does any editor that one might actually want to use.
I get back to the lab.
It's working great!! on MS Windows 10. Thanks! Chip.
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).
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
So, 34 zz9... I suppose so.
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):
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.
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.
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:
ERRORLEVEL will be 0 if everything went okay, or 1 if there was an error.
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))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?