Free Flight, Free Speech

What's wrong with those guys?
It is like an stomping feet party back there!
(maybe a Flamenco Dance's Party?)

Anyhow.
This scheme

abassign wrote:

Seems rather err to me.

The problem is again, I am not a developer, and reading thru lines of never documented sourcecode is for me an effort in futility. Maybe I'm better off trying to read Homer's The Odyssey in original ancient Greek scripts.
But I could hope that a software developer, such as abbassign himself can get some of the answers to his own questions by sniffing directly "the mountains of papers" that conform the core-code

Maybe, just a pointer to the proper directions:
The simgear core code, at
simgear/simgear/nasal

https://sourceforge.net/p/flightgear/si ... ear/nasal/

That code implements nasal functionality.

I looked at that thing really over-the-shoulder.
This is my conclussion.

Nasal interacts directly at the c++ level of the code. (just as a python interpreter could have)
and the c++ code is in charge of the rest of the operation.

There is a "ghost" (such called) that exposes C++ objects back to nasal as well.
The pertinent code is in simgear/simgear/nasal/cppbind/Ghost.*

So it looks to me, that in FG Nasal scheme is like follows

NASAL <-> C++ <-> Generic Interface

Thus, without the first interaction, NASAL is not dealing directly with the xml parser, nor with the "core" (in abassign diagram) -- which I don't understand what he meant by "core" at the top level there, either.
The important thing also being that parsing the xml is done directly at the C++ level

https://sourceforge.net/p/flightgear/si ... mgear/xml/
simgear/simgear/xml/XMLStaticParser.hxx

So,

NASAL <-> C++ <-> XML <-> Generic Interface

(which what we are calling interface here, will include among others the rendering machine)

So, in this context, NASAL is serving no other purpose that to expose the c++ code into "scripting" realm. That is, allows coding capabilities outside of the core, and without the need of recompiling.

Therefore, if all that is the case, there would be no problem (at all) to expose such code (even possibly using the same Ghost objects) to additional scripting languagues

https://docs.python.org/2/extending/embedding.html

Basically

Nasal <-> C++ |
Python <-> C++ |
Perl <-> C++ | <-> XML <-> Generic Interface
Lua <-> C ++ |
etc <-> C++ |

Well, i gave that source a glance, but i am not going to plough through that without any guidance. Where are the design documents? You know, the sorts of functional an technical.

The wiki does not seem to contain any design documentation either. There i find only chit-chat copied from the forum and the mailing lists.

If there are no design documents, someone who knows the source should reverse engineer the documents now. Specifically about the embedded scripting design, and even more specific about how nasal is implemented in that context. Abassign is asking about the design.

Kind regards, Vincent

Where are the design documents?

If you find these, let me know

Don't forget there's the extended xml...

Where does the flight model coding sit in this, be it jsbsim or YAsim?

Also a round of applause for spotting the runaround technique Hooray uses all too often

Hooray wrote in Sun Oct 09, 2016 4:44 pm:
The first step of loading an aircraft is loading its -set.xml file, which is then processed and turned into a property tree data structure, which is then processed by various parts of the initialization sequence to actually "build" an aircraft and load its resources (3D model, textures, nasal, bindings etc).

Abassign wrote
I love to have fun, but not in these things, if information is missing ... missing, if the information is buried under mountains of papers ... are buried in mountains of papers. My question is perfectly logical, is not a game, what you do when you talk like that to whoever asks you a specific question on a specific question, if you know then answer or do not know well, as they say IBM ... "I'm going at informing." But to answer so, as you have answered the question, not deliberately saying absolutely nothing, is proof that you are a person absolutely arrogant. I do not like the arrogant, so avoids responding if your spirit wants to answer with this nonsense, totally different from my question.

Very true... abassign... very true.

Yeah, thanks for nothing Hooray.

https://forum.flightgear.org/viewtopic.php?f=30&t=30626&p=296463#p296463

I went through all the documents mentioned, and they tell me all the stuff i do not and want to know. They are not design documents on interfacing something with fg.

- The first document describes property tree. Nice to know, but it does not tell me about whether that is all the binding i need for a scripting language.

- The others are about how to use nasal. Totally irrelevant. Yet again spent time on nothing.

- The last one is about nasal internals. Also totally irrelevant. Lost time again.

The crucial part is missing: How is nasal as a whole hung into the fg C core? By what api? Is this the only way to hang a scripting language into fg, or are there other api's usable? What are the preferred api for hanging a scripting language in fg? Where is the api documentation? Or is there no api interface and is nasal entangled spaghetti with fg C core?

Or is a standard embedding of a scripting language into C sufficient for fg to understand it?

https://docs.python.org/2/extending/embedding.html

I highly doubt it. So where is the embedding documentation? The embedding design of nasal would be nice for starters.

Kind regards, Vincent

I do hope that i am premature in saying this. You fg guys have managed within days to piss off 2 people who could have become good assets to fg, Beaver and Abassign. Congratulations with working yourselves into oblivion. In this manner the pool of contributors will soon dry out.

Kind regards, vincent

On what planet have you been hiding the last 20 years Bugman?

@Abassign: Do you know that the core developers rarely, and for many never, visit this forum? Did you know that in most open source software, that the design documents are the technical discussions in the mailing list archives? Are you subscribed to the FlightGear development mailing list? And did you know that established codebases are absolutely always more difficult to work with compared to writing new code, in all software projects, open or closed?

https://forum.flightgear.org/viewtopic.php?f=30&t=30626&p=296487#p296487

All open source projects i know of have decent documentation of the internals, often accompanied by nice graphs of module interaction, and finer class interaction. Some even demand a design document for minor bug fixes.

But you prefer to pompously refer people to the mailing lists, so they can enjoy your worthless chit-chat over there.

There is good reason why flightgear fails to recruit new core developers of any quality above minor bug fixes, Bugman.
- nasal: not maintained
- yasim: not maintained
- what else: not maintained

Just go on like this, and you will find yourself the sole developer minor bug fixer over there soon.

Kind regards, Vincent

Maybe for a clear answer, you need to start with a clear question

Regards,
Edward

Palm to face...

Guys I understand there was never an intention to fork FG however building up a group of interested parties on this forum might be the way forward...

Otherwise FG and us run the risk of losing young bright people capable of making a difference as they slip away in disbelief.