Thank you both again for your feedback.
>> If you are in a position to draft a new or improved section for the document
Well, I'm neither a Blackbox framework nor a Component Pascal expert; all I currently do is "trial and error"; likely not a good enough qualification to contribute to documentation
>> Can you specify your question regarding your point 7?
It's mostly about that I don't understand (yet) why this assignment is supposed to be legal, and what exactly the outcome is.
>> SYSTEM.PTR is a "pointer to anything". ...
Ok, thanks, that makes sense. SYSTEM.PTR is indeed nowhere mentioned, neither in the Windows nor the Linux "Platform-specific issues".
In case you're interested, here is a link on what I'm currently working on: https://github.com/rochus-keller/BlackboxFramework.
I use the Blackbox framework code to debug and extend my Oberon+ language, parser and validator. For this purpose I also implemented a Component Pascal to Oberon+ transpiler.
Assigning values to pointers or passing pointers to VAR args
- adimetrius
- Posts: 68
- Joined: Sun Aug 04, 2019 1:02 pm
Re: Assigning values to pointers or passing pointers to VAR
Very impressive! Looks like a lot of work has been put into the project!
So, is it correct to say that due to your CP->Oberon+ transpiler it is now somewhat possible to compile CP into Lua bytecode?
So, is it correct to say that due to your CP->Oberon+ transpiler it is now somewhat possible to compile CP into Lua bytecode?
Re: Assigning values to pointers or passing pointers to VAR
Thanks. Well, I guess little work compared to the Blackbox framework, including the Linux port.
>> is it correct to say that due to your CP->Oberon+ transpiler it is now somewhat possible to compile CP into Lua bytecode?
The Oberon+ parser and validator are not yet complete (e.g. the whole generics topic is still to be implemented). But the Blackbox framework code is a great help to improve and debug my code, because as it seems it's quite difficult to find a decently large code base which makes systematic use of bound procedures. My first code generator will then likely generate Lua source and/or bytecode. Of course that doesn't mean you will then just be able to run the Blackbox framework, because there is a lot of platform-specific code dependent on the CP compiler and the OS, which would have to be migrated first. I will give this a try if it's feasible in a decent time frame. The Linux version might be easier to migrate because it has less dependencies and uses libraries available on my development system. As you can see on https://github.com/rochus-keller/BlackboxFramework I meanwhile also uploaded the transpiled and minimized Linux variant. Sice I was already successful migrating the Oberon System to LuaJIT with a Qt binding, I would go for a Qt binding also here, i.e. the result would be platform independent (if feasible at all, as I said).
>> is it correct to say that due to your CP->Oberon+ transpiler it is now somewhat possible to compile CP into Lua bytecode?
The Oberon+ parser and validator are not yet complete (e.g. the whole generics topic is still to be implemented). But the Blackbox framework code is a great help to improve and debug my code, because as it seems it's quite difficult to find a decently large code base which makes systematic use of bound procedures. My first code generator will then likely generate Lua source and/or bytecode. Of course that doesn't mean you will then just be able to run the Blackbox framework, because there is a lot of platform-specific code dependent on the CP compiler and the OS, which would have to be migrated first. I will give this a try if it's feasible in a decent time frame. The Linux version might be easier to migrate because it has less dependencies and uses libraries available on my development system. As you can see on https://github.com/rochus-keller/BlackboxFramework I meanwhile also uploaded the transpiled and minimized Linux variant. Sice I was already successful migrating the Oberon System to LuaJIT with a Qt binding, I would go for a Qt binding also here, i.e. the result would be platform independent (if feasible at all, as I said).