#sibosdk — Public Fediverse posts
Live and recent posts from across the Fediverse tagged #sibosdk, aggregated by home.social.
-
#CTRAN update:
I've been looking at ways to neaten up the code while making it more robust and testable ("make it right").
After starting down a couple of dead ends and having a conversation with a mate, I decided to split the class parsing method (
_GetClass) into two -_BuildLocalClassand_BuildExternalClass. While there's a huge amount of crossover between Psion's local category (.CAT and .CL) files and external (.EXT) files 1 , they don't share any keywords inside their classes. Each keyword had a "if external" or "if not external" check. I never loved this, but it was the only way I could see of getting it working. Of course, the obvious solution was staring me in the face.Now the check only happens at the start of a class being parsed:
if _FileType = ooExternal then
begin
_ClassList.Add(_BuildExternalClass(tokline));
end
else begin
_ClassList.Add(_BuildLocalClass(tokline));
end;I also changed
_ClassListfrom an array to aTList, which should be a little more memory efficient when adding classes. I might do the same for elements within classes, too.These probably won't make any noticeable speed difference, but it does improve code readability and should make it easier to test.
1 : Local category files define classes for processing by CTRAN, while external category files reference and summarise pre-compiled classes.
-
Development on #CTRAN is moving into the "make it right" phase. Pulling out bits of functions, putting them into new functions, and adding tests as I go.
This is (hopefully) where I learn some good programming practices.
-
Development on #CTRAN is moving into the "make it right" phase. Pulling out bits of functions, putting them into new functions, and adding tests as I go.
This is (hopefully) where I learn some good programming practices.
-
Development on #CTRAN is moving into the "make it right" phase. Pulling out bits of functions, putting them into new functions, and adding tests as I go.
This is (hopefully) where I learn some good programming practices.
-
Development on #CTRAN is moving into the "make it right" phase. Pulling out bits of functions, putting them into new functions, and adding tests as I go.
This is (hopefully) where I learn some good programming practices.
-
Development on #CTRAN is moving into the "make it right" phase. Pulling out bits of functions, putting them into new functions, and adding tests as I go.
This is (hopefully) where I learn some good programming practices.
-
A few small tweaks to #CTRAN today.
I've started shifting small amounts of code out of the main
ctran.ppfile and into separate units. I've also started writing some proper unit tests for this code - small ones, but they're there.FPCUnit does the job, but it doesn't feel comfortable to me yet. It seems less polished than other test suites that I've seen for other languages. But it could also just be me.
FPCUnit is bundled with Free Pascal, so I want to give it a proper go before trying something else. For example, FPTest also exists, but it hasn't been updated in about 5 years.
I currently have no idea how to test a lot of other parts of the code without doing a lot of up-front work to "feed" these functions/methods with suitable data. My gut says that I need to tackle the smaller functions first. Once I can rely on them, then I can use them to test the larger ones.
I know it's progress. It just doesn't feel like much.
-
A few small tweaks to #CTRAN today.
I've started shifting small amounts of code out of the main
ctran.ppfile and into separate units. I've also started writing some proper unit tests for this code - small ones, but they're there.FPCUnit does the job, but it doesn't feel comfortable to me yet. It seems less polished than other test suites that I've seen for other languages. But it could also just be me.
FPCUnit is bundled with Free Pascal, so I want to give it a proper go before trying something else. For example, FPTest also exists, but it hasn't been updated in about 5 years.
I currently have no idea how to test a lot of other parts of the code without doing a lot of up-front work to "feed" these functions/methods with suitable data. My gut says that I need to tackle the smaller functions first. Once I can rely on them, then I can use them to test the larger ones.
I know it's progress. It just doesn't feel like much.
-
A few small tweaks to #CTRAN today.
I've started shifting small amounts of code out of the main
ctran.ppfile and into separate units. I've also started writing some proper unit tests for this code - small ones, but they're there.FPCUnit does the job, but it doesn't feel comfortable to me yet. It seems less polished than other test suites that I've seen for other languages. But it could also just be me.
FPCUnit is bundled with Free Pascal, so I want to give it a proper go before trying something else. For example, FPTest also exists, but it hasn't been updated in about 5 years.
I currently have no idea how to test a lot of other parts of the code without doing a lot of up-front work to "feed" these functions/methods with suitable data. My gut says that I need to tackle the smaller functions first. Once I can rely on them, then I can use them to test the larger ones.
I know it's progress. It just doesn't feel like much.
-
A few small tweaks to #CTRAN today.
I've started shifting small amounts of code out of the main
ctran.ppfile and into separate units. I've also started writing some proper unit tests for this code - small ones, but they're there.FPCUnit does the job, but it doesn't feel comfortable to me yet. It seems less polished than other test suites that I've seen for other languages. But it could also just be me.
FPCUnit is bundled with Free Pascal, so I want to give it a proper go before trying something else. For example, FPTest also exists, but it hasn't been updated in about 5 years.
I currently have no idea how to test a lot of other parts of the code without doing a lot of up-front work to "feed" these functions/methods with suitable data. My gut says that I need to tackle the smaller functions first. Once I can rely on them, then I can use them to test the larger ones.
I know it's progress. It just doesn't feel like much.
-
A few small tweaks to #CTRAN today.
I've started shifting small amounts of code out of the main
ctran.ppfile and into separate units. I've also started writing some proper unit tests for this code - small ones, but they're there.FPCUnit does the job, but it doesn't feel comfortable to me yet. It seems less polished than other test suites that I've seen for other languages. But it could also just be me.
FPCUnit is bundled with Free Pascal, so I want to give it a proper go before trying something else. For example, FPTest also exists, but it hasn't been updated in about 5 years.
I currently have no idea how to test a lot of other parts of the code without doing a lot of up-front work to "feed" these functions/methods with suitable data. My gut says that I need to tackle the smaller functions first. Once I can rely on them, then I can use them to test the larger ones.
I know it's progress. It just doesn't feel like much.
-
One of the best things about working on #plptools is that I get to work with developers who have far more experience in commercial software development than I do. I'm learning all the time and feel really grateful for it.*
On the flipside, it's solidified my want to work on the new #Psion #SIBOSDK by myself. I don't want collaborators for that project right now. Helpful hints and guidance is very much welcome, but I want to grow with this project in my own way. And yes, that will mean the development of the SDK will be slower. This might seem selfish in the grand scheme of FOSS development, but I know is the right thing for me right now.
* To be clear, I'm not a useless third wheel on the project. I have my things I'm good at. And I have ✨opinions✨! But still, always learning!
-
EDIT: Solved! Thank you to @penguin42 for the guidance. I now have an aarch64 VM running Debian and "host-only" networking so I can SSH in easily. My next challenge will be to do the same with Arch or Alpine, and get serial over TCP or a UNIX socket working.
#HIVEMIND: Does anyone have any tips on running ARM VMs on AMD64? Preferably both 32 and 64-bit.
I've got a few apps (#plptools, the new #SIBOSDK) that I'd like to be able to compile and test while on-the-go.
I'm guessing something like #qemu would do the job, but I don't know where to begin.
-
I've done a little more work on #ECOBJ over the past couple of weeks, but not much. Life has, unfortunately, got in the way of most of my retrocomputing fun.
But I'm pretty convinced that I could get something working by the end of the year. I should have some time over December.
It would be nice to get another SDK tool written.