@ersmith said:
Thank you @pedward . The RPM build support will be in the 6.2.0 release.
Do you see value in a Flatpak build? I haven't built Flatpak yet, but it does seem like the most agnostic way of supporting all distros.
I doubt the number of Linux users of flexprop, total, is much more than a dozen or so, hence I suspect the market for a flatpak build would be very limited. But I'm open to having my mind changed.
Yeah, tbh flexprop looks kinda bare bones. Having the toolchain packaged in one place is the bigger benefit I get. A CI pipeline should be able to build these, but it will need some changes to be automated.
Either the version can be maintained statically or it could be derived from the git tag hash.
For static:
Move the version to a .spec.version file
Run spectool to fetch the sources
Launch rpmbuild with --define="version=$(cat flexprop.spec.version)"
Add a way to do a version bump.
For git hash:
Execute rpmbuild with --define="version=$(git rev-parse --short HEAD)"
Fedora uses hashes often in their production builds for packages they don't directly maintain.
It would be nice if we could have the vscode extension add some additional actions to the tabbed menubar, like what gitlens does. Then have the equivalent "compile and run", "compile and flash", etc. Then we'd package the various binaries for different platforms in the extension.
Not trying to poo-poo, but realizing you're right about the low adoption among Linux users. I remember SimpleIDE looked pretty nice, I just don't know what happened to it.
@ersmith said:
Thank you @pedward . The RPM build support will be in the 6.2.0 release.
Do you see value in a Flatpak build? I haven't built Flatpak yet, but it does seem like the most agnostic way of supporting all distros.
I doubt the number of Linux users of flexprop, total, is much more than a dozen or so, hence I suspect the market for a flatpak build would be very limited. But I'm open to having my mind changed.
+1 - I use flexprop on "all". Windows everyday, but for a robot development, there is a Pi with flexprop installed, where the robot is developed. And rpm format has limited use on Pi as it its OS is debian based. No problem now, I know how to compile
The workhorse is spin2cpp/flexptools, so any IDE that can call them properly will do
As one of the dozen or so.. (Also use on windows..)
Flatpack would be useful to avoid the little bit of dependency heck (Does not quite qualify as hell) on an initial install. Now I wrote an update script that I run before doing anything big.. I learned this entire Linux install process specifically to use FlexProp on Linux. It might be off-putting for a new Propeller/Linux user.
Maybe an install script for the major distros would be helpful? (especally RasPi/Debian)
I guess what I am saying is that maybe there would be many more (Linux) users, maybe more users overall, if a flatpack or script was available.
BTW, I LIKE 'barebones'.. Hate it when full-featured suites stick me with stuff I don't want/understand.
I'd prefer a packaging format that will give you the CLI tools (flexspin, loadp2, etc) on PATH. Flatpak can't really do that. Though ideally they'd be available as a standalone package to begin with.
Relatedly, such a package would ideally also set up bash autocompletion for the CLI tools. for example complete -f -X '!*.@(binary|bix|BIX|biy|BIY)' loadp2 will make loadp2 autocomplete with .binary/.bix/.biy files only, which is very useful for avoiding the thing where you accidentally upload the source file to the chip. This can be made more complex to account for options as well, but even this simple setup is really nice.
@Wuerfel_21 said:
I'd prefer a packaging format that will give you the CLI tools (flexspin, loadp2, etc) on PATH. Flatpak can't really do that. Though ideally they'd be available as a standalone package to begin with.
Relatedly, such a package would ideally also set up bash autocompletion for the CLI tools. for example complete -f -X '!*.@(binary|bix|BIX|biy|BIY)' loadp2 will make loadp2 autocomplete with .binary/.bix/.biy files only, which is very useful for avoiding the thing where you accidentally upload the source file to the chip. This can be made more complex to account for options as well, but even this simple setup is really nice.
This also would be useful on Windows. It is enough to unpack the zip and use on Windows, but the path has to be set manually if needed. Another Windows related problem is a config file and include path. The simplest way I do "installation" of flexprop is download, unzip, make a shortcut, delete the previous one, and then I got flexprop 6.1.5 but it includes from (for example) 6.1.4.
What I'm hearing is that people want "native" packages for Linux distros so they "just work"?
I did actually start the RPM with deploying the normal binaries in the system path, but flexprop TCL code makes assumptions and detects paths based on the location of the executable. It will need some updating to properly detect the tcl file locations and not assume everything is in a monolithic tree.
I got past the application detection (and checked in some changes in my tree), but then it started probing for the binaries in relative locations, so I just gave up on that route and installed it in /opt.
If you download the flexspin/flexc CI builds right now, it will not work fully unless you move the EXEs into a "bin" subdirectory because it can't find the include directory otherwise.
(Also, the CI builds are currently windows only... might look into making linux builds available, ideally fully static executables to sidestep glibc-related stupidity)
The Flexprop's LFN file system escapes to short file names when there are Polish characters in the file name. When there are French characters, (J.M.Jarre music) it works (it displays improper characters but that is the font definition problem). Is there a simple way to repair this?
So VFAT predates Unicode and the long filenames are stored in a legacy codepage. Which one? F uck you, you get to guess. Windows will use the legacy codepage corresponding to your system locale. By default flexspin assumes codepage 850. you can -DFF_CODE_PAGE=852 which I think should select the codepage that has polish characters. Though I'm not 100% on why a codepage mismatch there would cause it to reject the LFN entirely instead of just giving you mojibake. Note that by default no attempt is made to convert the filenames to your runtime codepage (there is FF_LFN_UNICODE but you can't define it on the command line right now and it would add a lot of bloat). And of course, this is an unsolvable problem in the general case because each codepage contains a different assortment of characters (eg. CP852 does not contain characters needed for spanish. And if you used CP 932 to store filenames of japanese music, that has no extended latin at all (and also no backslash)). In theory nothing stops you from using UTF8 LFNs, but this is non-standard. And also rendering full unicode is unnecessarily complex.
It seems -DFF_CODE_PAGE=852 repaired the problem with Polish titles, while reintroduced it for French ones.
That seems to be problem with UTF<->ASCII translation, when one ASCII character code goes to several different UTF16 characters according to the code page used and that seems to be unsolvable at all, as the system cannot guess to which UTF16 character it should translate that particular ASCII
The possible workaround for a player is to use short file names for the file system access, while retrieve and translate UTF16 filename for displaying in the player itself. Something I did in a P1 player: I added LFN read function to KyeFAT so I can read and display the LFN while open a file according to its shortened name
I just looked it up and apparently the LFNs are UTF16. I was pretty sure they weren't. But the short names have the aformentioned encoding issue and the API somehow has to present both through the same interface. Headache inducing.
Try going to include/fliesys/fatfs/ffconf.h and set FF_LFN_UNICODE at line 143 to 2. That should give you UTF-8 for everything and might be the least gormless way of doing things. Will submit PR to let that be set from the build command.
I downloaded github artifacts to try this, but meanwhile I encountered another glitch in Basic...
This:
union eresult
dim iresult as integer
dim uresult as ulong
dim lresult as longint
dim ulresult as ulongint
dim fresult as double
dim sresult as string
end union
class expr_result
dim aresult as eresult
dim result_type as ubyte
end class
function do_plus(t1 as expr_result ,t2 as expr_result) as expr_result
'todo the real function that adds t1 to t2 according to its type
t1.aresult_type=1
t1.aresult.iresult=5
return t1
end function
gives this result:
"C:/Users/Piotr/Downloads/flexprop-6.1.5/flexprop/bin/flexspin" -2 --tabs=8 -D_BAUD=230400 -O1 --charset=utf8 -I "C:/Users/Piotr/Downloads/flexprop-6.1.5/flexprop/include" "D:/Programowanie/P2-retromachine-1/Propeller/P2P16/test4.bas" -DFF_USE_LFN -DFF_CODE_PAGE=852
Propeller Spin/PASM Compiler 'FlexSpin' (c) 2011-2023 Total Spectrum Software Inc. and contributors
Version 6.2.0-beta-HEAD-v6.1.7-4-g66375e01 Compiled on: Jun 16 2023
test4.bas
D:/Programowanie/P2-retromachine-1/Propeller/P2P16/test4.bas:11: error: Internal error, Taking size of an object with pending variables
D:/Programowanie/P2-retromachine-1/Propeller/P2P16/test4.bas:11: error: Internal error, Taking size of an object with pending variables
child process exited abnormally
Finished at Fri Jun 16 16:38:25 2023
.. and WOW!!!! The player code that works with 6.1.6 now gives this: (now I can't use let more than one time in the function)
Reverting while I can !!!!
"C:/Users/Piotr/Downloads/flexprop-6.1.5/flexprop/bin/flexspin" -2 --tabs=8 -D_BAUD=230400 -O1 --charset=utf8 -I "C:/Users/Piotr/Downloads/flexprop-6.1.5/flexprop/include" "D:/Programowanie/P2-retromachine-1/Propeller/P2P16/player34.bas" -DFF_USE_LFN -DFF_CODE_PAGE=852
Propeller Spin/PASM Compiler 'FlexSpin' (c) 2011-2023 Total Spectrum Software Inc. and contributors
Version 6.2.0-beta-HEAD-v6.1.7-4-g66375e01 Compiled on: Jun 16 2023
D:/Programowanie/P2-retromachine-1/Propeller/P2P16/hg008.spin2:356: warning: used spaces for indentation (previous lines used tabs)
D:/Programowanie/P2-retromachine-1/Propeller/P2P16/hg008.spin2:924: warning: used spaces for indentation (previous lines used tabs)
D:/Programowanie/P2-retromachine-1/Propeller/P2P16/mp3.c:3896: warning: Non-const member variable samplerateTab cannot be initialized at compile time; assuming variable is shared
D:/Programowanie/P2-retromachine-1/Propeller/P2P16/mp3.c:3907: warning: Non-const member variable bitrateTab cannot be initialized at compile time; assuming variable is shared
D:/Programowanie/P2-retromachine-1/Propeller/P2P16/mp3.c:3931: warning: Non-const member variable samplesPerFrameTab cannot be initialized at compile time; assuming variable is shared
D:/Programowanie/P2-retromachine-1/Propeller/P2P16/mp3.c:3943: warning: Non-const member variable sideBytesTab cannot be initialized at compile time; assuming variable is shared
D:/Programowanie/P2-retromachine-1/Propeller/P2P16/mp3.c:3953: warning: Non-const member variable slotTab cannot be initialized at compile time; assuming variable is shared
D:/Programowanie/P2-retromachine-1/Propeller/P2P16/mp3.c:3978: warning: Non-const member variable sfBandTable cannot be initialized at compile time; assuming variable is shared
D:/Programowanie/P2-retromachine-1/Propeller/P2P16/mp3.c:5038: warning: Non-const member variable imdctWin cannot be initialized at compile time; assuming variable is shared
D:/Programowanie/P2-retromachine-1/Propeller/P2P16/mp3.c:5095: warning: Non-const member variable ISFMpeg1 cannot be initialized at compile time; assuming variable is shared
D:/Programowanie/P2-retromachine-1/Propeller/P2P16/mp3.c:5117: warning: Non-const member variable ISFMpeg2 cannot be initialized at compile time; assuming variable is shared
D:/Programowanie/P2-retromachine-1/Propeller/P2P16/mp3.c:5149: warning: Non-const member variable ISFIIP cannot be initialized at compile time; assuming variable is shared
D:/Programowanie/P2-retromachine-1/Propeller/P2P16/mp3.c:5160: warning: Non-const member variable csa cannot be initialized at compile time; assuming variable is shared
D:/Programowanie/P2-retromachine-1/Propeller/P2P16/player34.bas:187: error: duplicate definition for r
D:/Programowanie/P2-retromachine-1/Propeller/P2P16/player34.bas:159: note: ... previous definition is here
D:/Programowanie/P2-retromachine-1/Propeller/P2P16/player34.bas:344: error: duplicate definition for delta
D:/Programowanie/P2-retromachine-1/Propeller/P2P16/player34.bas:328: note: ... previous definition is here
D:/Programowanie/P2-retromachine-1/Propeller/P2P16/player34.bas:376: error: duplicate definition for rpt
D:/Programowanie/P2-retromachine-1/Propeller/P2P16/player34.bas:375: note: ... previous definition is here
D:/Programowanie/P2-retromachine-1/Propeller/P2P16/player34.bas:945: error: duplicate definition for bdiv
D:/Programowanie/P2-retromachine-1/Propeller/P2P16/player34.bas:945: note: ... previous definition is here
D:/Programowanie/P2-retromachine-1/Propeller/P2P16/player34.bas:946: error: duplicate definition for bdiv
D:/Programowanie/P2-retromachine-1/Propeller/P2P16/player34.bas:945: note: ... previous definition is here
D:/Programowanie/P2-retromachine-1/Propeller/P2P16/player34.bas:947: error: duplicate definition for bdiv
D:/Programowanie/P2-retromachine-1/Propeller/P2P16/player34.bas:945: note: ... previous definition is here
D:/Programowanie/P2-retromachine-1/Propeller/P2P16/player34.bas:998: error: duplicate definition for add
D:/Programowanie/P2-retromachine-1/Propeller/P2P16/player34.bas:997: note: ... previous definition is here
D:/Programowanie/P2-retromachine-1/Propeller/P2P16/player34.bas:999: error: duplicate definition for add
D:/Programowanie/P2-retromachine-1/Propeller/P2P16/player34.bas:997: note: ... previous definition is here
D:/Programowanie/P2-retromachine-1/Propeller/P2P16/player34.bas:1028: error: duplicate definition for qq3
D:/Programowanie/P2-retromachine-1/Propeller/P2P16/player34.bas:1027: note: ... previous definition is here
D:/Programowanie/P2-retromachine-1/Propeller/P2P16/player34.bas:1029: error: duplicate definition for qq3
D:/Programowanie/P2-retromachine-1/Propeller/P2P16/player34.bas:1027: note: ... previous definition is here
D:/Programowanie/P2-retromachine-1/Propeller/P2P16/player34.bas:1030: error: duplicate definition for qq3
D:/Programowanie/P2-retromachine-1/Propeller/P2P16/player34.bas:1027: note: ... previous definition is here
D:/Programowanie/P2-retromachine-1/Propeller/P2P16/player34.bas:1031: error: duplicate definition for qq3
D:/Programowanie/P2-retromachine-1/Propeller/P2P16/player34.bas:1027: note: ... previous definition is here
D:/Programowanie/P2-retromachine-1/Propeller/P2P16/player34.bas:1032: error: duplicate definition for qq3
D:/Programowanie/P2-retromachine-1/Propeller/P2P16/player34.bas:1027: note: ... previous definition is here
D:/Programowanie/P2-retromachine-1/Propeller/P2P16/player34.bas:1085: error: duplicate definition for newcnt
D:/Programowanie/P2-retromachine-1/Propeller/P2P16/player34.bas:177: note: ... previous definition is here
D:/Programowanie/P2-retromachine-1/Propeller/P2P16/player34.bas:1437: error: duplicate definition for oldcpl
D:/Programowanie/P2-retromachine-1/Propeller/P2P16/player34.bas:1383: note: ... previous definition is here
D:/Programowanie/P2-retromachine-1/Propeller/P2P16/player34.bas:1437: error: duplicate definition for oldcpl1
D:/Programowanie/P2-retromachine-1/Propeller/P2P16/player34.bas:1383: note: ... previous definition is here
D:/Programowanie/P2-retromachine-1/Propeller/P2P16/player34.bas:1437: error: duplicate definition for oldbufptr
D:/Programowanie/P2-retromachine-1/Propeller/P2P16/player34.bas:1383: note: ... previous definition is here
D:/Programowanie/P2-retromachine-1/Propeller/P2P16/player34.bas:1509: error: duplicate definition for err
D:/Programowanie/P2-retromachine-1/Propeller/P2P16/player34.bas:185: note: ... previous definition is here
D:/Programowanie/P2-retromachine-1/Propeller/P2P16/player34.bas:1510: error: duplicate definition for err
D:/Programowanie/P2-retromachine-1/Propeller/P2P16/player34.bas:185: note: ... previous definition is here
D:/Programowanie/P2-retromachine-1/Propeller/P2P16/player34.bas:1511: error: duplicate definition for err
D:/Programowanie/P2-retromachine-1/Propeller/P2P16/player34.bas:185: note: ... previous definition is here
D:/Programowanie/P2-retromachine-1/Propeller/P2P16/player34.bas:1512: error: duplicate definition for err
D:/Programowanie/P2-retromachine-1/Propeller/P2P16/player34.bas:185: note: ... previous definition is here
D:/Programowanie/P2-retromachine-1/Propeller/P2P16/player34.bas:1513: error: duplicate definition for err
D:/Programowanie/P2-retromachine-1/Propeller/P2P16/player34.bas:185: note: ... previous definition is here
D:/Programowanie/P2-retromachine-1/Propeller/P2P16/player34.bas:1514: error: duplicate definition for err
D:/Programowanie/P2-retromachine-1/Propeller/P2P16/player34.bas:185: note: ... previous definition is here
D:/Programowanie/P2-retromachine-1/Propeller/P2P16/player34.bas:1515: error: duplicate definition for err
D:/Programowanie/P2-retromachine-1/Propeller/P2P16/player34.bas:185: note: ... previous definition is here
D:/Programowanie/P2-retromachine-1/Propeller/P2P16/player34.bas:1516: error: duplicate definition for err
D:/Programowanie/P2-retromachine-1/Propeller/P2P16/player34.bas:185: note: ... previous definition is here
D:/Programowanie/P2-retromachine-1/Propeller/P2P16/player34.bas:1797: error: duplicate definition for l
D:/Programowanie/P2-retromachine-1/Propeller/P2P16/player34.bas:160: note: ... previous definition is here
D:/Programowanie/P2-retromachine-1/Propeller/P2P16/player34.bas:1844: error: duplicate definition for r
D:/Programowanie/P2-retromachine-1/Propeller/P2P16/player34.bas:159: note: ... previous definition is here
D:/Programowanie/P2-retromachine-1/Propeller/P2P16/player34.bas:1845: error: duplicate definition for r
D:/Programowanie/P2-retromachine-1/Propeller/P2P16/player34.bas:159: note: ... previous definition is here
D:/Programowanie/P2-rplayer34.bas
|-hg008.spin2
|-|-psram.spin2
|-|-|-psram16drv.spin2
|-usbnew.spin2
|-trackerplayer.spin2
|-audio093b-8-sc.spin2
|-sidcog8.spin2
|-psram.spin2
|-spccog.spin2
|-a6502-1.spin2
|-mp3.c
etromachine-1/Propeller/P2P16/player34.bas:1908: error: duplicate definition for samplerate
D:/Programowanie/P2-retromachine-1/Propeller/P2P16/player34.bas:171: note: ... previous definition is here
D:/Programowanie/P2-retromachine-1/Propeller/P2P16/player34.bas:1916: error: duplicate definition for tag$
D:/Programowanie/P2-retromachine-1/Propeller/P2P16/player34.bas:1909: note: ... previous definition is here
D:/Programowanie/P2-retromachine-1/Propeller/P2P16/player34.bas:1943: error: duplicate definition for bitrate
D:/Programowanie/P2-retromachine-1/Propeller/P2P16/player34.bas:1907: note: ... previous definition is here
D:/Programowanie/P2-retromachine-1/Propeller/P2P16/player34.bas:1944: error: duplicate definition for samplerate
D:/Programowanie/P2-retromachine-1/Propeller/P2P16/player34.bas:171: note: ... previous definition is here
D:/Programowanie/P2-retromachine-1/Propeller/P2P16/player34.bas:1997: error: duplicate definition for offset1
D:/Programowanie/P2-retromachine-1/Propeller/P2P16/player34.bas:1993: note: ... previous definition is here
child process exited abnormally
Finished at Fri Jun 16 16:40:31 2023
Reverted to Version 6.1.6-HEAD-v6.1.6 Compiled on: Jun 6 2023 - the player compiles now. I have to switch the computer off now, to do : find the commit that breaks the player...
This works: Version 6.2.0-beta-v6.1.6-4-g56e394de Compiled on: Jun 6 2023
This doesn't: Version 6.1.7 Compiled on: Jun 14 2023 (330)
Bad: Version 6.2.0-beta-v6.1.6-10-g175f7378 Compiled on: Jun 10 2023 (328)
Bad: Version 6.2.0-beta-v6.1.6-5-gd6460875 Compiled on: Jun 9 2023 (326)
last good: Version 6.2.0-beta-v6.1.6-4-g56e394de Compiled on: Jun 6 2023 (325 in Github's actions)
@Wuerfel_21 said:
I just looked it up and apparently the LFNs are UTF16. I was pretty sure they weren't. But the short names have the aformentioned encoding issue and the API somehow has to present both through the same interface. Headache inducing.
Try going to include/fliesys/fatfs/ffconf.h and set FF_LFN_UNICODE at line 143 to 2. That should give you UTF-8 for everything and might be the least gormless way of doing things. Will submit PR to let that be set from the build command.
That works. Of course I now have to implement a proper utf8 displaying in the player, but now all LFNs are LFNs and they can be opened too.
@pik33 said:
Of course I now have to implement a proper utf8 displaying in the player
"Proper" is not happening Unless you want to fill up your PSRAM with font data and then figure out the true form of the eldritch entities known as "grapheme clusters". And then figure out just why no one ever invented a non-cursive arabic script, for that would've probably been easier than implementing the whacky letter joining logic required.
@pik33 said:
Of course I now have to implement a proper utf8 displaying in the player
"Proper" is not happening Unless you want to fill up your PSRAM with font data and then figure out the true form of the eldritch entities known as "grapheme clusters". And then figure out just why no one ever invented a non-cursive arabic script, for that would've probably been easier than implementing the whacky letter joining logic required.
Proper means to display one character and not two, and then it would be good if this character is what it should be. I can't read Arabic or Japanese... but I can read Russian and I have mp3 files with Russian names while I have no Russian font definitions...(yet?)
I saw new commits on spin2cpp github that implements utf8 and repairs 'let' in Basic. The only problem left is this Internal error, Taking size of an object with pending variables. The strange thing is - the bigger program using this class/union combination compiles without this error and there are warnings instead: warning: Internal assert failure: func numresults inconsistent for function do_plus
MAybe that was not a good idea to put an union inside a class.
@pik33 said:
Of course I now have to implement a proper utf8 displaying in the player
"Proper" is not happening Unless you want to fill up your PSRAM with font data and then figure out the true form of the eldritch entities known as "grapheme clusters". And then figure out just why no one ever invented a non-cursive arabic script, for that would've probably been easier than implementing the whacky letter joining logic required.
Proper means to display one character and not two, and then it would be good if this character is what it should be. I can't read Arabic or Japanese... but I can read Russian and I have mp3 files with Russian names while I have no Russian font definitions...(yet?)
I saw new commits on spin2cpp github that implements utf8 and repairs 'let' in Basic. The only problem left is this Internal error, Taking size of an object with pending variables. The strange thing is - the bigger program using this class/union combination compiles without this error and there are warnings instead: warning: Internal assert failure: func numresults inconsistent for function do_plus
MAybe that was not a good idea to put an union inside a class.
Are you able to share the code that's producing the error? The example you posted earlier is somewhat incomplete, and the error goes away as soon as any variable of type expr_result is declared (although having the error at all is a little strange, I'll try to track it down).
Also, for the specific example you posted earlier (doing arithmetic on different types of objects) you might be able to use generic types in a function instead of a union, something like:
any(T) function do_plus(x as T, y as T) as T
return x + y
end function
print do_plus(1, 2)
print do_plus(1.5, 2.0)
print do_plus("hello, ", "world")
While working on an expression evaluator I had this union only (no problems) but then I decided to add an expression type information so I made a class. Then I got a bunch of these warnings, so I decided to simplify this as much as posiible, and got this error.
@pik33 said:
Proper means to display one character and not two, and then it would be good if this character is what it should be. I can't read Arabic or Japanese... but I can read Russian and I have mp3 files with Russian names while I have no Russian font definitions...(yet?)
I was just having a jape
But that exactly is where the specter of the grapheme cluster comes to haunt you. Normally Ä is U+E4, but you can also have Ä, which is a two-codepoint grapheme cluster of U+41 (the regular A) and U+308 (funny codepoint that adds dots to any character). In practice the latter is exceedingly rare though.
Guess how many codepoints and bytes 👩🏽❤️💋👨🏽 has (if it even renders correctly on your PC).
(Yes, they effectively re-invented backspace composition. Incredible)
Guess how many codepoints and bytes 👩🏽❤️💋👨🏽 has (if it even renders correctly on your PC).
That's abusing a font definition These were supposed to be characters, something you can write your language with, and now they are jpg replacement. The next step will be adding "animate" to Unicode as U+something, so we will have an equivalent of animated gif
I downloaded newest spin2cpp, strange warnings/errors disappeared so I can continue writing the interpreter.
I am having a segmentation violation when trying to return more than 8 values from a method using method pointers. I created an issue in github with more details. https://github.com/totalspectrum/flexprop/issues/75
FWIW, it compiles ok in Propeller Tool and Spin Tools.
@ersmith Tried modifying your simple serial to use rx&tx pins as constants instead of variables.
Works in PropTool but gives garbage in FlexProp. Any idea how this can be?
@Rayman said:
@ersmith Tried modifying your simple serial to use rx&tx pins as constants instead of variables.
Works in PropTool but gives garbage in FlexProp. Any idea how this can be?
That garbage is every second letter of original string. Something is wrong with txflush(): adding waitms(1) gives the proper output.
Is Spin's pinr a proper way to read a busy flag? It should be, in asm, rdpin with wc set.
As a delay restores the proper function, PropTool may work OK even with improper txflush() as its bytecode is slower than the compiled Flexprop's code
@pik33 said:
That garbage is every second letter of original string. Something is wrong with txflush(): replacing it with waitms(1) gives the proper output.
Using -O0 works ... and -2nu also separately works ... --fcache=0 does not work ...
Comments
Do you see value in a Flatpak build? I haven't built Flatpak yet, but it does seem like the most agnostic way of supporting all distros.
I doubt the number of Linux users of flexprop, total, is much more than a dozen or so, hence I suspect the market for a flatpak build would be very limited. But I'm open to having my mind changed.
Yeah, tbh flexprop looks kinda bare bones. Having the toolchain packaged in one place is the bigger benefit I get. A CI pipeline should be able to build these, but it will need some changes to be automated.
Either the version can be maintained statically or it could be derived from the git tag hash.
For static:
--define="version=$(cat flexprop.spec.version)"For git hash:
--define="version=$(git rev-parse --short HEAD)"Fedora uses hashes often in their production builds for packages they don't directly maintain.
It would be nice if we could have the vscode extension add some additional actions to the tabbed menubar, like what gitlens does. Then have the equivalent "compile and run", "compile and flash", etc. Then we'd package the various binaries for different platforms in the extension.
Not trying to poo-poo, but realizing you're right about the low adoption among Linux users. I remember SimpleIDE looked pretty nice, I just don't know what happened to it.
+1 - I use flexprop on "all". Windows everyday, but for a robot development, there is a Pi with flexprop installed, where the robot is developed. And rpm format has limited use on Pi as it its OS is debian based. No problem now, I know how to compile
The workhorse is spin2cpp/flexptools, so any IDE that can call them properly will do
As one of the dozen or so.. (Also use on windows..)
Flatpack would be useful to avoid the little bit of dependency heck (Does not quite qualify as hell) on an initial install. Now I wrote an update script that I run before doing anything big.. I learned this entire Linux install process specifically to use FlexProp on Linux. It might be off-putting for a new Propeller/Linux user.
Maybe an install script for the major distros would be helpful? (especally RasPi/Debian)
I guess what I am saying is that maybe there would be many more (Linux) users, maybe more users overall, if a flatpack or script was available.
BTW, I LIKE 'barebones'.. Hate it when full-featured suites stick me with stuff I don't want/understand.
I'd prefer a packaging format that will give you the CLI tools (flexspin, loadp2, etc) on PATH. Flatpak can't really do that. Though ideally they'd be available as a standalone package to begin with.
Relatedly, such a package would ideally also set up bash autocompletion for the CLI tools. for example
complete -f -X '!*.@(binary|bix|BIX|biy|BIY)' loadp2will make loadp2 autocomplete with .binary/.bix/.biy files only, which is very useful for avoiding the thing where you accidentally upload the source file to the chip. This can be made more complex to account for options as well, but even this simple setup is really nice.This also would be useful on Windows. It is enough to unpack the zip and use on Windows, but the path has to be set manually if needed. Another Windows related problem is a config file and include path. The simplest way I do "installation" of flexprop is download, unzip, make a shortcut, delete the previous one, and then I got flexprop 6.1.5 but it includes from (for example) 6.1.4.
What I'm hearing is that people want "native" packages for Linux distros so they "just work"?
I did actually start the RPM with deploying the normal binaries in the system path, but flexprop TCL code makes assumptions and detects paths based on the location of the executable. It will need some updating to properly detect the tcl file locations and not assume everything is in a monolithic tree.
I got past the application detection (and checked in some changes in my tree), but then it started probing for the binaries in relative locations, so I just gave up on that route and installed it in /opt.
Yea there's some issues like that.
If you download the flexspin/flexc CI builds right now, it will not work fully unless you move the EXEs into a "bin" subdirectory because it can't find the include directory otherwise.
(Also, the CI builds are currently windows only... might look into making linux builds available, ideally fully static executables to sidestep glibc-related stupidity)
PR submitted that makes spin2cpp/flexspin/flexcc CI builds work out of the box and also adds the aforementioned linux-musl builds: https://github.com/totalspectrum/spin2cpp/pull/390
The Flexprop's LFN file system escapes to short file names when there are Polish characters in the file name. When there are French characters, (J.M.Jarre music) it works (it displays improper characters but that is the font definition problem). Is there a simple way to repair this?
tl;dr: non-ASCII filenames were a mistake
So VFAT predates Unicode and the long filenames are stored in a legacy codepage. Which one? F uck you, you get to guess. Windows will use the legacy codepage corresponding to your system locale. By default flexspin assumes codepage 850. you can
-DFF_CODE_PAGE=852which I think should select the codepage that has polish characters. Though I'm not 100% on why a codepage mismatch there would cause it to reject the LFN entirely instead of just giving you mojibake. Note that by default no attempt is made to convert the filenames to your runtime codepage (there isFF_LFN_UNICODEbut you can't define it on the command line right now and it would add a lot of bloat). And of course, this is an unsolvable problem in the general case because each codepage contains a different assortment of characters (eg. CP852 does not contain characters needed for spanish. And if you used CP 932 to store filenames of japanese music, that has no extended latin at all (and also no backslash)). In theory nothing stops you from using UTF8 LFNs, but this is non-standard. And also rendering full unicode is unnecessarily complex.It seems -DFF_CODE_PAGE=852 repaired the problem with Polish titles, while reintroduced it for French ones.
That seems to be problem with UTF<->ASCII translation, when one ASCII character code goes to several different UTF16 characters according to the code page used and that seems to be unsolvable at all, as the system cannot guess to which UTF16 character it should translate that particular ASCII
The possible workaround for a player is to use short file names for the file system access, while retrieve and translate UTF16 filename for displaying in the player itself. Something I did in a P1 player: I added LFN read function to KyeFAT so I can read and display the LFN while open a file according to its shortened name
I just looked it up and apparently the LFNs are UTF16. I was pretty sure they weren't. But the short names have the aformentioned encoding issue and the API somehow has to present both through the same interface. Headache inducing.
Try going to
include/fliesys/fatfs/ffconf.hand setFF_LFN_UNICODEat line 143 to 2. That should give you UTF-8 for everything and might be the least gormless way of doing things. Will submit PR to let that be set from the build command.I downloaded github artifacts to try this, but meanwhile I encountered another glitch in Basic...
This:
gives this result:
.. and WOW!!!! The player code that works with 6.1.6 now gives this: (now I can't use let more than one time in the function)
Reverting while I can !!!!
Reverted to Version 6.1.6-HEAD-v6.1.6 Compiled on: Jun 6 2023 - the player compiles now. I have to switch the computer off now, to do : find the commit that breaks the player...
This works: Version 6.2.0-beta-v6.1.6-4-g56e394de Compiled on: Jun 6 2023
This doesn't: Version 6.1.7 Compiled on: Jun 14 2023 (330)
Bad: Version 6.2.0-beta-v6.1.6-10-g175f7378 Compiled on: Jun 10 2023 (328)
Bad: Version 6.2.0-beta-v6.1.6-5-gd6460875 Compiled on: Jun 9 2023 (326)
last good: Version 6.2.0-beta-v6.1.6-4-g56e394de Compiled on: Jun 6 2023 (325 in Github's actions)
That works. Of course I now have to implement a proper utf8 displaying in the player, but now all LFNs are LFNs and they can be opened too.
"Proper" is not happening
Unless you want to fill up your PSRAM with font data and then figure out the true form of the eldritch entities known as "grapheme clusters". And then figure out just why no one ever invented a non-cursive arabic script, for that would've probably been easier than implementing the whacky letter joining logic required.
Proper means to display one character and not two, and then it would be good if this character is what it should be. I can't read Arabic or Japanese... but I can read Russian and I have mp3 files with Russian names while I have no Russian font definitions...(yet?)
I saw new commits on spin2cpp github that implements utf8 and repairs 'let' in Basic. The only problem left is this
Internal error, Taking size of an object with pending variables. The strange thing is - the bigger program using this class/union combination compiles without this error and there are warnings instead:warning: Internal assert failure: func numresults inconsistent for function do_plusMAybe that was not a good idea to put an union inside a class.
Are you able to share the code that's producing the error? The example you posted earlier is somewhat incomplete, and the error goes away as soon as any variable of type expr_result is declared (although having the error at all is a little strange, I'll try to track it down).
Also, for the specific example you posted earlier (doing arithmetic on different types of objects) you might be able to use generic types in a function instead of a union, something like:
any(T) function do_plus(x as T, y as T) as T return x + y end function print do_plus(1, 2) print do_plus(1.5, 2.0) print do_plus("hello, ", "world")This is the mess that may be a retromachine style Basic interpreter in the future: https://gitlab.com/pik33/P2-retromachine/-/tree/main/Propeller/Basic - the file is https://gitlab.com/pik33/P2-retromachine/-/blob/main/Propeller/Basic/basic003.bas
While working on an expression evaluator I had this union only (no problems) but then I decided to add an expression type information so I made a class. Then I got a bunch of these warnings, so I decided to simplify this as much as posiible, and got this error.
I was just having a jape
But that exactly is where the specter of the grapheme cluster comes to haunt you. Normally Ä is U+E4, but you can also have Ä, which is a two-codepoint grapheme cluster of U+41 (the regular A) and U+308 (funny codepoint that adds dots to any character). In practice the latter is exceedingly rare though.
Guess how many codepoints and bytes 👩🏽❤️💋👨🏽 has (if it even renders correctly on your PC).
(Yes, they effectively re-invented backspace composition. Incredible)
That's abusing a font definition
These were supposed to be characters, something you can write your language with, and now they are jpg replacement. The next step will be adding "animate" to Unicode as U+something, so we will have an equivalent of animated gif 
I downloaded newest spin2cpp, strange warnings/errors disappeared so I can continue writing the interpreter.
@ersmith
I am having a segmentation violation when trying to return more than 8 values from a method using method pointers. I created an issue in github with more details. https://github.com/totalspectrum/flexprop/issues/75
FWIW, it compiles ok in Propeller Tool and Spin Tools.
@ersmith Tried modifying your simple serial to use rx&tx pins as constants instead of variables.
Works in PropTool but gives garbage in FlexProp. Any idea how this can be?
That garbage is every second letter of original string. Something is wrong with txflush(): adding waitms(1) gives the proper output.
Is Spin's pinr a proper way to read a busy flag? It should be, in asm, rdpin with wc set.
As a delay restores the proper function, PropTool may work OK even with improper txflush() as its bytecode is slower than the compiled Flexprop's code
It's strange... Works when tx_pin and rx_pin are variables, like in the original.
Guess I'll just do that for now until sorted...
Using -O0 works ... and -2nu also separately works ... --fcache=0 does not work ...
Another quirk is that this works in Prop Tool, but not FlexProp
Did this by accident. Guess I forgot that you can leave off the "long" prefix in Spin2...