ABSTRACT CLASSES WORK!

It's only for .C and .G (header) files and it's hacky as hell, but it works exactly like #Psion's #CTRAN.

It's taken me probably two years to mentally be in a position to get this working. I always knew the solution was simple, but I just couldn't work it out. But once I'd written a test file with two abstract classes it became really obvious. I had to back myself out of a couple of coding corners to get it to work, which is no bad thing.

I can see that I'll need to do a lot more tidying here. I'm calculating a few things on the fly multiple times, sometimes just to get a count of the methods that need to be generate. I'll either need to modify my existing DependencyList dictionary to add more information, or create a new one with just the method details.

Next I need to do the TASM file generation (.ASM and .ING files), and check that there's nothing that needs doing with the skeleton class file generation.

https://codeberg.org/thelastpsion/ctran/commit/f782e2025b133aa835e22a8116de93245789ee5b

#SIBOSDK

#HiveMind: Is the opposite of an "abstract class" a "concrete class"?

When building code for a class, #CTRAN needs to be able to find the next ancestor that isn't abstract. I'm trying to think of a good name for the function, e.g. GetConcreteAncestor() or GetNonAbstractAncestor().

#OO #OOP #AskFedi

#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 - _BuildLocalClass and _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:

I also changed _ClassList from an array to a TList, 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.

#Psion #SIBOSDK

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.

#SIBOSDK

A few small tweaks to #CTRAN today.

I've started shifting small amounts of code out of the main ctran.pp file 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.

#SIBOSDK

I think I'm using the term "metaclass" incorrectly in #CTRAN.

Is there a term for squashing all of a class's ancestors together as if they were just one parent class or superclass?

#OO #OOP

Current main projects:

• #ecobj: Another piece of the #Psion SIBO SDK rewrite puzzle. ECOBJ.EXE takes an Intel OMF file (.OBJ) for a class and moves the class descriptor data into the code segment. I think I might be able to get this working by the end of the year.
• Get my website running #GoHugo (this is almost done!).
• #CTRAN: Still haven't started writing unit tests. Also, complete a full write-up of what it took to get the thing working.
• Research into compilers: I'm nowhere near ready to start yet, but I'm learning as much as I can.

Upcoming projects:

• #siboimg: Rewrite in Pascal, and add the ability to create and modify FEFS images.
• #plptools: I'd like to see two-way transfer working for EPOC16 -- I'm sure I'll need the help of the rest of the maintainers to get this working. I can't do much with the #HaikuOS port until the USB serial drivers are "fixed" (hardware flow control added) -- I don't think I have the skills for this, so it'll have to wait until some kind soul has the time to work on it.
• #PsiDrive: Add a ~17V boost converter to allow writing to Flash SSDs.
• NAS/home server: Rebuild or replacement of DEATH, my Microserver gen8. It's been over 18 months since DEATH's RAID died. It's lead me to thinking that maybe I don't need the sort of server I thought I need. TBD.

Maybe next year, maybe not:

• New Psion SSD with RP2350: I doubt I'll get anything made, but I'd like to experiment to see what can be done with the protocol.
• Rewrite the rest of the SIBO C SDK tools.
• Compiler: Recreation of the JPI/Clarion TopSpeed C compiler, targeting the SIBO/EPOC16 platform (8086 and V30). I was hoping to get going with this around July this year, but it just didn't happen. This is my Everest. I know I'm not ready yet. I need to train for it.
• Vine: New word processor for EPOC16. Trying to start this project in 2023 lead me to rewriting the SDK, so we're quite some way away from getting this done.
• Research into Objective-C: Not Foundation, just the syntax. For compiler shenanigans.

I've really struggled to get going with projects this year. That's fine, these things happen. But I'd like to find better ways to cope next year so that I can make a little more progress.