.cel question: memory usage

[hharris]

I have recently discoverd that a lot of what I want to do (in combination with celx) is only possible using .cel scripts.

Here's my basic question: How is memory handled with repect to a celscript?

(1) Are celscripts that have completed their duration, disposed of in memory?

(2) What would happen, for example, if you created a celscript but never gave it enough celscript:ticks() to complete its duration. Since there is no dispose celscript function that I could find, do these scripts just exist in memory until the program quits?

My program "Celestia Explorer" is designed to run indefintely until the user quits. I fear an unexplained crash happening when the program runs out of memory.

Knowing the answer to these questions would help me design my program.

Thanks!

Henry

[hank]

I have recently discoverd that a lot of what I want to do (in combination with celx) is only possible using .cel scripts.

Such as?

- Hank

[hharris]

...such as orbiting a body realistically based on its mass. The .cel funciton "orbit" allows me to orbit around an axis at a specific rate. The rate my program inputs when constructing the script string is based on the body's mass which is calculated from physics derived from the type of body and its radius.

Technically, it might be possible to do this in pure celx by calculating the trajectory of the orbit and moving the spacecraft based in this trajectory, but that would involve a lengthy and complex calculation, and in addition there seemed to be information missing, such as the planet's spin axis in space, to make that a practical option.

Henry

[hank]

...such as orbiting a body realistically based on its mass. The .cel funciton "orbit" allows me to orbit around an axis at a specific rate. The rate my program inputs when constructing the script string is based on the body's mass which is calculated from physics derived from the type of body and its radius.

Technically, it might be possible to do this in pure celx by calculating the trajectory of the orbit and moving the spacecraft based in this trajectory, but that would involve a lengthy and complex calculation, and in addition there seemed to be information missing, such as the planet's spin axis in space, to make that a practical option.

It does indeed appear that CELX currently does not provide access to the Observer::orbit method. It would be interesting to see if it could be implemented effectively using what CELX does provide.

Is there anything else you need to do that requires CEL scripting?

- Hank

[cpotting]

(1) Are celscripts that have completed their duration, disposed of in memory?

I am not sure about the .cel scripts, but celx is an implementation of Lua, and upon termination of the script, all memory allocated by the Lua script should be freed. I am not sure about the any memory used by Celestia to implement Lua though.

(2) What would happen, for example, if you created a celscript but never gave it enough celscript:ticks() to complete its duration. Since there is no dispose celscript function that I could find, do these scripts just exist in memory until the program quits?

Lua will automatically perform periodic garbage collection on any variables that are no longer being referenced by the script. The memory should be released during one these cycles.

[hharris]

As far as what I need from .cel scripts is, I've only been at this a few weeks so I can't provide a detailed list, but in general I can say that .cel scripts are more fundamental and provide more detailed control, especially in the arena of vector assignments.

To me Celx and Cel are very complimentary and I couldn't do without either one. Celx provides the programing environment and Cel provides the detailed access to the code.

As I explained in another message, I don't believe it would be possible to duplicate the "orbit" function of Cel in Celx. There is just not enough access to information and control in Celx in my opinion.

I will be releasing my code in a fairly short amount of time, with documentation, and I'd appreciate any comments about efficiency or methodology then. There will probably be comments on my approach as well, since I?€™ve put some restrictions in that will probably not be to everyone?€™s taste. The intent is to create an awareness of one?€™s position and environment in space instead of the current database approach.

Henry

[hank]

As far as what I need from .cel scripts is, I've only been at this a few weeks so I can't provide a detailed list, but in general I can say that .cel scripts are more fundamental and provide more detailed control, especially in the arena of vector assignments.

To me Celx and Cel are very complimentary and I couldn't do without either one. Celx provides the programing environment and Cel provides the detailed access to the code.

As I explained in another message, I don't believe it would be possible to duplicate the "orbit" function of Cel in Celx. There is just not enough access to information and control in Celx in my opinion.

I will be releasing my code in a fairly short amount of time, with documentation, and I'd appreciate any comments about efficiency or methodology then. There will probably be comments on my approach as well, since I?€™ve put some restrictions in that will probably not be to everyone?€™s taste. The intent is to create an awareness of one?€™s position and environment in space instead of the current database approach.

My view of CEL vs. CELX is quite the opposite. CELX provides more fundamental access to the Celestia code, as well as more powerful programming capability. CEL is simpler to use for some purposes, but not generally extensible. If CEL doesn't do what you want, you have to use CELX to do it. On the other hand, if CELX doesn't do what you want (directly), you can usually write a function to do it using CELX. Most of what is provided by CEL can be implemented using CELX without much difficulty. Thus a CEL-style API could be provided as a CELX library. With this approach, CEL could also be extended by adding new functions implemented using CELX. And this could be done without rebuilding Celestia, as would be required to extend the current built-in CEL.

There are currently some gaps in CELX. For example, it doesn't allow access to the Observer::orbit method. But that would be simple to add. And even without changing the built-in code, I think it would be possible to implement the orbit method using the existing CELX access to lower-level Observer methods. It would take some work, but would only have to be done once. It's precisely this ability to extend CELX by building new functions that makes CELX so much more powerful than CEL.

- Hank

[hharris]

I didn?€™t mean to get into a ideological battle. I'm just talking pragmatically about solving problems that I have now and in passing remarking that Cel has a useful function to that end. I found it fairly easy to write a dynamic Cel script generator that easily does what was difficult or impossible, for me at least, in Celx. That?€™s all.

As I remarked earlier, I'm mainly concerned with dynamic scripts being left in memory. But from what was said, I'm assuming that Celestia's garbage collector will dispose of incomplete (in the sense of not running through its assigned duration) or unused scripts when it notes there is no longer an assignment to that script. For example if I create a script "A "and assign it to "X", when I later assign X = nil, the garbage collector will eventually notice and deallocate that memory.

Please bear in mind that I'm just talking about my needs, which are probably not mainstream as far as this forum is concerned, so take my opinion with a grain of salt.

Henry

[hank]

I didn?€™t mean to get into a ideological battle.

Me neither. This is an architectural question, not an ideological one. And it's intended as a discussion, not a debate.

I'm just talking pragmatically about solving problems that I have now and in passing remarking that Cel has a useful function to that end.

There's no reason not to use CEL if you find it useful. I'm just thinking that CEL could be implemented on top of CELX, and that this approach would have advantages. It would allow you to embed CEL commands directly in a CELX script rather than requiring a separate file, for example.

I found it fairly easy to write a dynamic Cel script generator that easily does what was difficult or impossible, for me at least, in Celx. That?€™s all.

My purpose in asking what you found difficult or impossible to do in CELX was not to question you, but in order to understand how CELX might need to be improved, either by providing convenience functions or adding new built-in functions.

As I remarked earlier, I'm mainly concerned with dynamic scripts being left in memory. But from what was said, I'm assuming that Celestia's garbage collector will dispose of incomplete (in the sense of not running through its assigned duration) or unused scripts when it notes there is no longer an assignment to that script. For example if I create a script "A "and assign it to "X", when I later assign X = nil, the garbage collector will eventually notice and deallocate that memory.

From a quick look at celx.cpp, it looks to me like CELX handles Lua garbage collection on CEL script objects properly. I don't know if there are leaks in the CEL C++ code.

Please bear in mind that I'm just talking about my needs, which are probably not mainstream as far as this forum is concerned, so take my opinion with a grain of salt.

Of course. But I'd be surprised if what you're trying to do wasn't also of interest to some other users.

- Hank

[hharris]

What you say sounds reasonable. There would be an advantage to augmenting Celx's capability and including some of the capability present in Cel. There's no particular reason that I can think of to have the current hybrid approach, except the pragmatic "Rome wasn't built in a day" reason.

I tell you what. Let me finish version 1.0 of Celestia Explorer (or under another name if that one has been taken) and after that I'll reserve some time to write up my experience that would not only include Cel capability that, in my opinion, needs to be included in Celx, but also my recommendations for future enhancements. I have a lot of ideas in that regard, including my favorite Celx topic that I've discussed elsewhere: why dynamic modeling is just as, or more important, than modeling real objects since most objects in the universe only have theoretical scientific existence and are otherwise invisible. The reason for dynamic models is, of course, the infinite variety and complexity of the universe, which is one of the reasons I find Celestia so fascinating.


Henry

[hharris]

Turns out the jokes on me. The orbit command (in .cel files) does not work for rates less than 1 degree/sec which means I can't simulate a real orbit with this command (except for orbits near very massive objects). It works fine with 1 degree/second but does nothing for .99 degrees/second. Please put that on your list of future changes. (Funny thing, though. The program acts like it's doing something because it's taking CPU time to do nothing.)

Well, let's see. I know the observer's position and the position of the center of the planet. If I go to two known positions above the equator using gotolonglat then I can calculate v3 = v2-v1 which is a vector in the plane of the equatorial orbit. Using the mass of the planet (which I already calculate), I can predict another vector for a given delta time which is in the plane of v3 but is advanced by delta t.

That method is clunky and inelegant. Does anybody have a better idea? It would help if there was some vector information about the planet available, but I don't think there is.

Henry

[hank]

Turns out the jokes on me. The orbit command (in .cel files) does not work for rates less than 1 degree/sec which means I can't simulate a real orbit with this command (except for orbits near very massive objects). It works fine with 1 degree/second but does nothing for .99 degrees/second. Please put that on your list of future changes. (Funny thing, though. The program acts like it's doing something because it's taking CPU time to do nothing.)

Did you try 0.99 degrees/second?

- Hank

[hank]

Well, let's see. I know the observer's position and the position of the center of the planet. If I go to two known positions above the equator using gotolonglat then I can calculate v3 = v2-v1 which is a vector in the plane of the equatorial orbit. Using the mass of the planet (which I already calculate), I can predict another vector for a given delta time which is in the plane of v3 but is advanced by delta t.

That method is clunky and inelegant. Does anybody have a better idea? It would help if there was some vector information about the planet available, but I don't think there is.

You may be able to get what you want using frames.

- Hank

[hharris]

Okay, that works using "orbit" directly in a .cel file. You're a genuis. The problem is, evidently, I'm using the ability of Celestia to convert numbers to text. But when I print out the string for the rate (that Celestia creates) I get something like 0.07. I would think that would work. In fact when I input 0.07 directly (in a .cel file) I get the rotation I'm looking for. But the number to text, despite what is printed out, doesn't work.

My function is:

function CreateOrbitScript(axis, rate, duration)
str = "{ "
if(axis == orb_type_equatorial ) then
axis_str = "axis [ 0 0 1 ] "
elseif(axis == orb_type_polar) then
axis_str = "axis [ 0 1 0 ] "
elseif( axis == orb_type_45deg ) then
axis_str = "axis [ 1 1 0 ] "
end
str = str .. " orbit { " .. axis_str .."rate " .. rate .. " duration " .. duration .. " }"
str = str .. " }"
celscript = celestia:createcelscript(str)
return celscript
end

Henry

[hank]

Okay, that works using "orbit" directly in a .cel file. You're a genuis. The problem is, evidently, I'm using the ability of Celestia to convert numbers to text. But when I print out the string for the rate (that Celestia creates) I get something like 0.07. I would think that would work. In fact when I input 0.07 directly (in a .cel file) I get the rotation I'm looking for. But the number to text, despite what is printed out, doesn't work.

I don't understand what you're saying. Your function seems to work for me.

- Hank

[hharris]

I'm sure it does work for you and now it works for me after I spent a couple hours testing to find out what the documentation really meant.

The documentations says call tick() repeatedly until the script if finished. That's not wrong but it doesn't explain anything and, of course, there are no examples.

This is compounded by the fact that "orbit" in Cel works differentlly, so you can't write a Cel script to help you understand the Celx code that calls the Cel function.

What the Celx documentation should have said was: "Call tick(x) for x seconds to change the position of the object to what it would have x seconds later moving at the rate given. Tick() will return false once it has completed the duration of the script."

This is an example of how the lack of clear documentation for a function can waste a lot of time for the programmer because its specfic function has architecture implications.

I suppose the writer of Celx had a good reason to disable the Cel orbit function, changing it from an internal animation function to a single frame function, which is a pity. Having the option to do both would be ideal.

With all the work it takes to explain this program to an experienced programmers like me, you'd think it would be easier for someone to just sit down and write some good docmentation for Celx. I think it would save all of us a lot of time.

Henry

[hank]

I'm sure it does work for you and now it works for me after I spent a couple hours testing to find out what the documentation really meant.

The documentations says call tick() repeatedly until the script if finished. That's not wrong but it doesn't explain anything and, of course, there are no examples.

This is compounded by the fact that "orbit" in Cel works differentlly, so you can't write a Cel script to help you understand the Celx code that calls the Cel function.

What the Celx documentation should have said was: "Call tick(x) for x seconds to change the position of the object to what it would have x seconds later moving at the rate given. Tick() will return false once it has completed the duration of the script."

This is an example of how the lack of clear documentation for a function can waste a lot of time for the programmer because its specfic function has architecture implications.

I suppose the writer of Celx had a good reason to disable the Cel orbit function, changing it from an internal animation function to a single frame function, which is a pity. Having the option to do both would be ideal.

With all the work it takes to explain this program to an experienced programmers like me, you'd think it would be easier for someone to just sit down and write some good docmentation for Celx. I think it would save all of us a lot of time.

Henry

I agree that it would be helpful if someone could sit down and write some more documentation for CELX.

The existing CELX documentation does say that? celscript:tick(dt)? executes the CEL-script as if dt seconds had passed and returns true if the script is still running. But I'd agree that an example would help.

The writer of CELX didn't disable the CEL orbit function or change it from an internal animation function to a single frame function. It's just that CEL script processing depends on tick being called repeatedly. When a CEL script is run from the Celestia application, the application event loop calls tick for the script. When a CEL script is run from a CELX script, the CELX script has to do it.

The problem is that the application, the CELX script, and the CEL script must all be running in parallel. In order for the CELX script to allow application processing to continue in parallel (for animation), it must call the wait function repeatedly to temporarily return control to the application. For a CEL script to also be run in parallel, the CELX script must call tick for it, using the time that elapsed during the wait. In other words, the CELX script must call wait to give the application its timeslice and it must call tick to give the CEL script its timeslice.

- Hank