Writing on eEchidna
I'm down in the common room to try to cool my head.
I was working on a bit of the system that looked like it should be done as a database. "Why are these data structures done as memory structures?"
Then my mind immediately got distracted, "well, this is a framework operating system... we could set up something so these things can run clean in memory without any indication they are getting stored."
Next my head starts going, "wait... can we set up something similar to Java Beans, where I can tell the framework operating system to store this information, regardless of it is SQLite, PostgreSQL, MySQL, Flat File or Bob's Bulliten Board Down the Street."
So I am mentally thinking of how to have each framework "drop" as I am mentally thinking of them, set up to give clues as to how to store these items.
This would simplify other parts, such as the checksum and memory management system, by having it understand what sort of information is in the data structures.
Then... I sat back... and remembered: I am writing a Framework in C... what other C Frameworks can I honestly think too much about?
Well, Android is written in/for Java/JVM. Pylons is written in Python. Catalyst is written in Perl5. Rails is written in Ruby. Mentally I am thinking about how all this is done in systems that imply some kind of Virtual Machine that is known in the state of compilation. With the actual material being run is usually some form of Clear Text information at some point. JVM Files still have a lot of clear text in their status and location.
I have to figure out some way to run a Framework system, in which the compiler most likely will not ship any symbols in the final product.
So I'm having to add an entry point that eEchidna makes use of... and a way to give clues to the eEchidna Linker Drop. Yeah... the goal of this framework is the framework handles the framework. So I need a clear system where I could drop in a new Linker to use, instead of the rest of the stuff.
I suppose I should go over the main notion of eEchidna: all items in this system are run as a Framework "drop". Each "drop" states what it defines and what functionality it needs to work. So if something says, "I require random" (in some fashion) a "drop" would state, "Oh... I can random". The end result would be that how you have something poll what is needed and what exists, itself is a framework "drop" with the metameta level being, "I need something to track what I have" being provided by an internal eEchidna object linker.
The internal eEchidna object linker uses various functions in the standard Linux Linker Library... and just creates a rather... overt system.
My goal will be to make a version that could be done in 6502c ASM and backported to the Commadore 64 and the Sinclair Spectrum ZX... with the notion of a object format with clues as to how it could be used.
That is quite a bit later in the future however.
Right now, I am having it run ontop of the Linux Kernel... for eEchidna 0 (my own personal private little play thing)... and eEchidna 1 and eEchidna 2.
I should probably explain how my current release systems are planned at happening.
eEchidna 0 is my own private play thing. This likely will not be released (or seen) by the world for the most part.
eEchidna 1 is the version that will be able to play a video game. It will be able to ship a self contained game system, that can be played on Linux, Windows and OSX. It is similar to a game engine... but it is more a framework that could work as a game engine. Eventually eEchidna 1 will be able to handle an entire Desktop Environment type system.
eEchidna 2 will be a bit more into the internals of the Linux system. The goal being to run in the spot init.d usually runs. Like loading the Linux Kernel, then directly loading eEchidna 2 into that system. This will also deviate from the standard Linux layout.
I'm just taking a break from coding. As... there is point where I am going.. and I am like, "did... did I just... zig when I zagged for coding."
I think it was mostly once I started thinking about to give clues to a memory structure system so that I could allow for storage of the memory structures with another framework drop portion and allowing a memory checking system to watch the memory for any strange issues or changes.
Yeah... for a C based Framework system... that was the point I figured it out... most people would have figured it out when they named it after the Greek Mother of all Monsters: Echidna... and not have gotten to the point where they applied a lower case e to indicate it is an electronic version of that same item... like "email"...
I was working on a bit of the system that looked like it should be done as a database. "Why are these data structures done as memory structures?"
Then my mind immediately got distracted, "well, this is a framework operating system... we could set up something so these things can run clean in memory without any indication they are getting stored."
Next my head starts going, "wait... can we set up something similar to Java Beans, where I can tell the framework operating system to store this information, regardless of it is SQLite, PostgreSQL, MySQL, Flat File or Bob's Bulliten Board Down the Street."
So I am mentally thinking of how to have each framework "drop" as I am mentally thinking of them, set up to give clues as to how to store these items.
This would simplify other parts, such as the checksum and memory management system, by having it understand what sort of information is in the data structures.
Then... I sat back... and remembered: I am writing a Framework in C... what other C Frameworks can I honestly think too much about?
Well, Android is written in/for Java/JVM. Pylons is written in Python. Catalyst is written in Perl5. Rails is written in Ruby. Mentally I am thinking about how all this is done in systems that imply some kind of Virtual Machine that is known in the state of compilation. With the actual material being run is usually some form of Clear Text information at some point. JVM Files still have a lot of clear text in their status and location.
I have to figure out some way to run a Framework system, in which the compiler most likely will not ship any symbols in the final product.
So I'm having to add an entry point that eEchidna makes use of... and a way to give clues to the eEchidna Linker Drop. Yeah... the goal of this framework is the framework handles the framework. So I need a clear system where I could drop in a new Linker to use, instead of the rest of the stuff.
I suppose I should go over the main notion of eEchidna: all items in this system are run as a Framework "drop". Each "drop" states what it defines and what functionality it needs to work. So if something says, "I require random" (in some fashion) a "drop" would state, "Oh... I can random". The end result would be that how you have something poll what is needed and what exists, itself is a framework "drop" with the metameta level being, "I need something to track what I have" being provided by an internal eEchidna object linker.
The internal eEchidna object linker uses various functions in the standard Linux Linker Library... and just creates a rather... overt system.
My goal will be to make a version that could be done in 6502c ASM and backported to the Commadore 64 and the Sinclair Spectrum ZX... with the notion of a object format with clues as to how it could be used.
That is quite a bit later in the future however.
Right now, I am having it run ontop of the Linux Kernel... for eEchidna 0 (my own personal private little play thing)... and eEchidna 1 and eEchidna 2.
I should probably explain how my current release systems are planned at happening.
eEchidna 0 is my own private play thing. This likely will not be released (or seen) by the world for the most part.
eEchidna 1 is the version that will be able to play a video game. It will be able to ship a self contained game system, that can be played on Linux, Windows and OSX. It is similar to a game engine... but it is more a framework that could work as a game engine. Eventually eEchidna 1 will be able to handle an entire Desktop Environment type system.
eEchidna 2 will be a bit more into the internals of the Linux system. The goal being to run in the spot init.d usually runs. Like loading the Linux Kernel, then directly loading eEchidna 2 into that system. This will also deviate from the standard Linux layout.
I'm just taking a break from coding. As... there is point where I am going.. and I am like, "did... did I just... zig when I zagged for coding."
I think it was mostly once I started thinking about to give clues to a memory structure system so that I could allow for storage of the memory structures with another framework drop portion and allowing a memory checking system to watch the memory for any strange issues or changes.
Yeah... for a C based Framework system... that was the point I figured it out... most people would have figured it out when they named it after the Greek Mother of all Monsters: Echidna... and not have gotten to the point where they applied a lower case e to indicate it is an electronic version of that same item... like "email"...