Yes, I mean - it'll probably use a heavily LCC inspired engine underneath. Although not a copy of - the plan there (as I crunch through the code) will be to look at how it's all put together, and see if I can get my head around it. I don't plan to owe LC anything for the engine as it won't be their work. The same way someone might look at a garden - appreciate it for what it is, then go and design their own.
This will also help with the Mac compiling process I'm sure. The first step is to work out the order it's doing (or trying to do) everything - then go from there.
A major piece of the puzzle fell into place this evening, as my newer mac arrived. So this means I can actually test on a newer version - something like Sonoma - and try and fix the menus in C++ while also adding any fixes along the way.
The new IDE won't be aware of revAnything or MetacardAnything - and I'm wondering just how much I try and provide a similar set of messages, or do I completely reimagine it so that it's a different animal altogether. I looked at the example Axwald pointed me towards, and the difference in the message watcher is quite drastic. (Why so many messages constantly for v9 compared to v7?) - No wonder v7 is so much more responsive.
These messages are all being fired constantly not by the engine, but by various frontscripts, backscripts and the revIDELibrary. I won't be including those (my rudimentary engine doesn't currently have any concept of frontscripts or backscripts) but I added the ability for it to save substacks of stacks yesterday. (small steps).
But then I'm only an extremely novice C++ coder, not at all up to speed like the pros. I only started learning C++ this time last year, and progress is slow because I've also got work and family commitments (blah, blah, blah - I know; boring) - but this is why I don't have as much time to spend in front of a computer as I otherwise could have, trying to backpedal and untangle things.
Having said that, I did find a real gem in that the C++ code can be cross-compiled into assembly - making the whole thing a lot faster. (I'm using the zig cross compiler for that bit, that I was going on about a long time ago). So although it's written in C++, the end result is a program/binary that is compiled in assembly - and it's fast. (The IDE can launch itself and load a stack - all in under 1 second) - but then it's a very stripped down, minimal form of itself.
I mean, we are talking going from an entire OXT Lite install which is almost 1.3GB uncompressed, down to something that's about 12MB in size. (adjust your expectations of what it's capable of relative to this)
I'm sure load time will increase as more is loaded into memory as the IDE loads. That's the bloat. Unavoidable bloat though. I don't see this being a quick process by the way, just to make that clear.
That's the long term goal - to recreate the engine, in the meantime, I'll continue tweaking OXT Lite I'm sure. Just that I hope to learn more about the inherited engine by going through this process.
Yes, I mean - it'll probably use a heavily LCC inspired engine underneath. Although not a copy of - the plan there (as I crunch through the code) will be to look at how it's all put together, and see if I can get my head around it. I don't plan to owe LC anything for the engine as it won't be their work. The same way someone might look at a garden - appreciate it for what it is, then go and design their own.
This will also help with the Mac compiling process I'm sure. The first step is to work out the order it's doing (or trying to do) everything - then go from there.
A major piece of the puzzle fell into place this evening, as my newer mac arrived. So this means I can actually test on a newer version - something like Sonoma - and try and fix the menus in C++ while also adding any fixes along the way.
The new IDE won't be aware of revAnything or MetacardAnything - and I'm wondering just how much I try and provide a similar set of messages, or do I completely reimagine it so that it's a different animal altogether. I looked at the example Axwald pointed me towards, and the difference in the message watcher is quite drastic. (Why so many messages constantly for v9 compared to v7?) - No wonder v7 is so much more responsive.
These messages are all being fired constantly not by the engine, but by various frontscripts, backscripts and the revIDELibrary. I won't be including those (my rudimentary engine doesn't currently have any concept of frontscripts or backscripts) but I added the ability for it to save substacks of stacks yesterday. (small steps). :lol:
But then I'm only an extremely novice C++ coder, not at all up to speed like the pros. I only started learning C++ this time last year, and progress is slow because I've also got work and family commitments (blah, blah, blah - I know; boring) - but this is why I don't have as much time to spend in front of a computer as I otherwise could have, trying to backpedal and untangle things.
Having said that, I did find a real gem in that the C++ code can be cross-compiled into assembly - making the whole thing a lot faster. (I'm using the zig cross compiler for that bit, that I was going on about a long time ago). So although it's written in C++, the end result is a program/binary that is compiled in assembly - and it's fast. (The IDE can launch itself and load a stack - all in under 1 second) - but then it's a very stripped down, minimal form of itself.
I mean, we are talking going from an entire OXT Lite install which is almost 1.3GB uncompressed, down to something that's about 12MB in size. (adjust your expectations of what it's capable of relative to this) :lol:
I'm sure load time will increase as more is loaded into memory as the IDE loads. That's the bloat. Unavoidable bloat though. I don't see this being a quick process by the way, just to make that clear.
That's the long term goal - to recreate the engine, in the meantime, I'll continue tweaking OXT Lite I'm sure. Just that I hope to learn more about the inherited engine by going through this process.