Post by chriscrawford on Sept 25, 2015 10:20:06 GMT -8
10:52 AM
I have confirmed that the log data is being properly stored. However, it is being stored in a special object of Facundo's creation, a "BufferedArray". This is an extension of an AbstractList whose primary component is a list of arrays of Objects. Sheesh! Talk about general-purpose! This kind of data structure could hold almost anything. The BufferedArray is held by the TreeLogger, which in turn is extended by LogLizard... diving up and down through all these structures is too much for my age-addled brain. So it's time for a little simplification. Or, as Mr. Lenin would say, "Liquidate the BufferedArray!"
First I need to decide what kind of data structure I shall be using in the stead of this complex morass. My first inclination is to create a straightforward tree, but Facundo instead used an array. Why? I need to make certain that he was doing it merely to simplify the task of storing the data to the hard drive. Since I don't need to store data on the hard drive (I'm keeping it all in RAM), I probably don't need to use an array and can instead revert to a simple tree.
I can see the merits of an array of trees; that's the natural structure of the data that LogLizard holds. The tree of data consists of a long list of events, each of which has its own tree. However, the JTree structure assumes a simple tree as its data source, so I'm sure that Facundo had to jump through lots of hoops to get his modified array of trees to function properly in the JTree structure. Most likely he did some sort of last-minute conversion of the array of trees into one monster tree.
A word of explanation: Facundo had to satisfy a difficult specification: LogLizard had to function with an arbitrarily large data set. A user could conceivably play a storyworld for a long time, amassing a huge amount of LogLizard data, and then demand to see the results. That forced Facundo to rely on two tricks. First, he stored only a skeleton of the actual data and built a complex algorithm for filling in the flesh of the skeleton from the bones. Second, he saved big chunks of data onto the hard drive. Those were harsh specifications, and he met them brilliantly.
However, I'm not so supple a programmer. I am perfectly willing to impose harsh constraints upon the user. LogLizard will have a fixed amount of RAM allocated, and will store only as much as it can hold. If the user plays a long test storyworld and then wants to look at LogLizard, he's out of luck. That will be sufficient for Siboot. We can come up with something better if and when we build Dramagine.
Just to be safe, I decided to carry out a quick measurement. I ran the original SWAT program with a typical storyworld from those days. I played only 11 events. Then I brought up LogLizard and expanded every node, starting from the bottom. I gave up after completely expanding only six events, but the result should be good enough for purposes of estimation. I counted an average of 85 nodes per event; each node contained on average only about 40 characters of text. That means that each event will need about 3,400 bytes of storage for LogLizard. Let's pad that up to 5K per Event. A user could test a storyworld 200 events long and use up about a megabyte of RAM for LogLizard. A mere piffle! (says the man who used to program with 2K of ROM and 128 bytes of RAM). I know that a test run of a storyworld never runs as long as 200 events. Therefore, we'll be fine. If necessary, I can always assign more RAM to the program. Assuming I can figure out how to do that...
I have confirmed that the log data is being properly stored. However, it is being stored in a special object of Facundo's creation, a "BufferedArray". This is an extension of an AbstractList whose primary component is a list of arrays of Objects. Sheesh! Talk about general-purpose! This kind of data structure could hold almost anything. The BufferedArray is held by the TreeLogger, which in turn is extended by LogLizard... diving up and down through all these structures is too much for my age-addled brain. So it's time for a little simplification. Or, as Mr. Lenin would say, "Liquidate the BufferedArray!"
First I need to decide what kind of data structure I shall be using in the stead of this complex morass. My first inclination is to create a straightforward tree, but Facundo instead used an array. Why? I need to make certain that he was doing it merely to simplify the task of storing the data to the hard drive. Since I don't need to store data on the hard drive (I'm keeping it all in RAM), I probably don't need to use an array and can instead revert to a simple tree.
I can see the merits of an array of trees; that's the natural structure of the data that LogLizard holds. The tree of data consists of a long list of events, each of which has its own tree. However, the JTree structure assumes a simple tree as its data source, so I'm sure that Facundo had to jump through lots of hoops to get his modified array of trees to function properly in the JTree structure. Most likely he did some sort of last-minute conversion of the array of trees into one monster tree.
A word of explanation: Facundo had to satisfy a difficult specification: LogLizard had to function with an arbitrarily large data set. A user could conceivably play a storyworld for a long time, amassing a huge amount of LogLizard data, and then demand to see the results. That forced Facundo to rely on two tricks. First, he stored only a skeleton of the actual data and built a complex algorithm for filling in the flesh of the skeleton from the bones. Second, he saved big chunks of data onto the hard drive. Those were harsh specifications, and he met them brilliantly.
However, I'm not so supple a programmer. I am perfectly willing to impose harsh constraints upon the user. LogLizard will have a fixed amount of RAM allocated, and will store only as much as it can hold. If the user plays a long test storyworld and then wants to look at LogLizard, he's out of luck. That will be sufficient for Siboot. We can come up with something better if and when we build Dramagine.
Just to be safe, I decided to carry out a quick measurement. I ran the original SWAT program with a typical storyworld from those days. I played only 11 events. Then I brought up LogLizard and expanded every node, starting from the bottom. I gave up after completely expanding only six events, but the result should be good enough for purposes of estimation. I counted an average of 85 nodes per event; each node contained on average only about 40 characters of text. That means that each event will need about 3,400 bytes of storage for LogLizard. Let's pad that up to 5K per Event. A user could test a storyworld 200 events long and use up about a megabyte of RAM for LogLizard. A mere piffle! (says the man who used to program with 2K of ROM and 128 bytes of RAM). I know that a test run of a storyworld never runs as long as 200 events. Therefore, we'll be fine. If necessary, I can always assign more RAM to the program. Assuming I can figure out how to do that...