COGs manageability grows complex as code becomes complex - ideas?
ALIBE
Posts: 299
first of all I love my Prop and the power of having COGs running stuff "independantly". ·I understand we have ::CogNew, ::CogInit, ::CogStop, ::CogID, etc that help the launch, identification, halt of cogs.·
all that is cool.
However, I am running into a couple of issues, and am hoping someone can help shed some "best practices" or a mechanism to keep track of where my cogs are and what they are doing.· Not at runtime, but, at coding time.· So, as I'm coding and wanting to use a certain cog, I can deterministically tell whether that cog is or will be available. This becomes overly complex when we all start using the "object exchange" objects when the consuming programmer may not fully understand how that object (or the nested objects) are using the cogs.
I guess my ?n is has soemone thought about an add-in to the Prop editor, that will scan thru the code and tells us which object will be utilizing cogs - sort of a COG dependency map?
Again, I'm not asking for a runtime state of COGs availability (since that can change as the code runs).· What I'm looking for is a code time COG dependency map.
not sure if anyone else had a similar need and if and how they got around to solving that issue.
thanks much
Nagi
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
"any small object, accidentally dropped, goes and hides behind a larger object."
·
ALIBE - Artificial LIfe BEing. In search of building autonoumous land robot
http://ALIBE.crosscity.com/
·
all that is cool.
However, I am running into a couple of issues, and am hoping someone can help shed some "best practices" or a mechanism to keep track of where my cogs are and what they are doing.· Not at runtime, but, at coding time.· So, as I'm coding and wanting to use a certain cog, I can deterministically tell whether that cog is or will be available. This becomes overly complex when we all start using the "object exchange" objects when the consuming programmer may not fully understand how that object (or the nested objects) are using the cogs.
I guess my ?n is has soemone thought about an add-in to the Prop editor, that will scan thru the code and tells us which object will be utilizing cogs - sort of a COG dependency map?
Again, I'm not asking for a runtime state of COGs availability (since that can change as the code runs).· What I'm looking for is a code time COG dependency map.
not sure if anyone else had a similar need and if and how they got around to solving that issue.
thanks much
Nagi
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
"any small object, accidentally dropped, goes and hides behind a larger object."
·
ALIBE - Artificial LIfe BEing. In search of building autonoumous land robot
http://ALIBE.crosscity.com/
·
Comments
Leon
Post Edited (Leon) : 4/14/2007 2:40:50 PM GMT
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
"any small object, accidentally dropped, goes and hides behind a larger object."
·
ALIBE - Artificial LIfe BEing. In search of building autonoumous land robot
http://ALIBE.crosscity.com/
·
Bada boom!
(Yes, folks. I'm here all night!)
It's really impossible for the compiler or editor to track which cogs are in use. The compiler would have to do a complete flow analysis and, even then, the compiler would not be able to determine the actual program flow, only an approximation (because it doesn't have the data to determine what branches are taken). This kind of analysis gets much worse when parallelism is present (as with multiple cogs).