User:Callahanp
About Me
Hello, my name is Patrick Callahan. People call me Pat. I have a website, and you've found it.
I've been a programmer since I was a teenager. I'm 74 years old and retired now. I have signed the Agile Manifesto.
Programming was a fun job. We couldn't believe we got paid to have so much fun.
My current expertise primarily lies in databases, bash scripting, and traditional procedural programming in various languages.
C++ is a work in progress. I took a course in 1993, but never used it professionally.
I like gardening with my wife of 33 years, Ann. We have a daughter who has given us three very active grandchildren, who will visit us next week for four days. Did I say I kept busy? We reside in the state of Massachusetts in the United States.
I hope to make regular code contributions to FlightGear. I want to gain the skills to address some FlightGear issues as they come up and participate in the discussions and programming for the various [FlightGear Epics |https://gitlab.com/groups/flightgear/-/epics?sort=created_date&state=opened&first_page_size=100]
You are about to read a very personal document. I make statements there that I have not yet validated by discussing these ideas directly with others and trying to put them into practice. Go easy on me. Criticize my ideas, not me. I think this is ok, as the material is buried in a personal web page on a wiki.
FlightGear Development:
I'm motivated to learn enough C++, Nasal, and whatever else it takes to start regularly contributing to the Flightgear Codebase.
Someone with practical experience writing, maintaining, and fixing problems in C++ can easily begin contributing to FlightGear's codebase. They may find a few fine points, such as the internal scripting language and the property tree, but they should be able to navigate with little assistance. That's not me. I don't have the practical experience, and my C++ experience consists mostly of a one-semester class. Not only that, the class was in the previous century. Move semantics? What's That!?
You get the idea: "Nice goal, Pat. Good luck with that. You do realize you are 75 years old, don't you?" Heedless, I press on.
It should be obvious to all that this endeavour requires a lot of work, and anyone undertaking it is going to need help at various points. It's easy to get stuck on specific points, and stuck in ways that you don't know which question to ask first, and where to ask it. You, kind reader, may be able to help.
Flightgear - Study Group
I'm continuing to think about the idea of organizing and participating in a study group for flightgear coding, I want to consider current work on Flightgear proceeding on Gitlab as fodder for study.
The study group idea was prompted by my thinking about the codebase itself and why I found it so difficult to understand. I'm sure others have at least some of the same challenges if they share my goal of becoming a regular flightgear contributor. If so, we are likely to find common ground in meeting those challenges.
These points are personal challenges in learning how FlightGear works, writing code and documentation, and debugging.
- Object-oriented programming - Don't get me started. Based on secondary sources, I agree with Alan Kay's thoughts on messaging as the most important aspect of "object" thinking, which most of us seem to overlook.[1] Alan appears to live nearby. Maybe I'll get up the nerve to ask him personally. Finally, I am pretty sure I am not "a can of Coke[2]."
- C++, when I learned C++, the STL was new. New as in "Do you need a container? Please feel free to write an implementation as homework". There has been significant progress since then, but I never actually wrote any C++ professionally, so I'm catching up on the changes in C++98, 03, 11, 14, 17, and 20.
- Specific Aircraft simulations are implemented mostly in XML, AC files, and Nasal, not in C++.
- Nasal is an interpreted language with separate class structures, memory allocation, and symbol tables, inaccessible to debuggers.
- The property tree is a global data store used for most intercommunication between subsystems, but it has no concept of messaging or data flow management. Everything is done with callbacks on individual properties. It's like watching an ant colony.
None of the above should be taken as a suggestion that FlightGear development take any specific direction in the future. That will come from me only after I've become a regular and significant contributor of C++, Nasal, and FlightGear data. Nor should it be taken as criticism of what has been done so far in the 28-year history of the project.
Getting an Giving Help
I want to request assistance in the appropriate forums, having exhausted all possible avenues to explore answers before seeking help. At the same time I want to help others with any code problems they are struggling with.
I like helping other people. It's the best way to make friends.
I want you to know that I sometimes help people by listening to them describe a problem, and suggesting a route to finding some small tidbit of information that makes the problem easier to think about. It doesn't always happen, or even often, but when it does, the result seems very satisfying to both parties.
There are other times when just having me listen attentively to an explanation of a problem is sufficient for the teller to grasp a solution. I don't have to say a word, but they already have the answer. Helpful, no? This has happened to me on numerous occasions, more so than me making helpful comments. Perhaps my asking for a description of the problem and any naive questions I ask about it are enough to get things moving.
If you're stuck on a point and want my help, please don't hesitate to ask me personally on any forum where you encounter me. You can find me on Discord as callahanp, on IRC as pac1 (early internet username formed from my initials)
Teamwork:
I'm a believer in teamwork and would love working closely in real-time with others on specific programming problems. I hope we can create opportunities for that. I also believe that the only learning environment is not limited to a formal course, which includes lectures, readings, homework, quizzes, tests, and final grades. Grown-ups use study groups, working groups, collaborators, publications, conferences, and prior work. And they take formal courses from time to time.
Pair programming
I find pair programming an attractive idea and wonder how it works in practice. What is the result of practicing pair programming with programmers of similar skills? What happens when an expert programmer pairs with an inexperienced one?
I find that most are resistant to participating in pair programming, and I wonder why.
We're taught in academic settings to program by ourselves and hand in ou submissions for review as "homework", but we continue that pattern in our work mainly out of inertia and lack of proper training. There's no reason to continue that pattern outside of a classroom as our only or even as main way of working together.
Understanding FlightGear's Large & Complex Codebase
The problem with FlightGear is its size, complexity, and the lack of a detailed guide to exploring that complexity. Several factors contribute to that complexity. Understanding FlightGear requires knowledge of many application domains, C++, an internal scripting language, a global data store, application features driven by XML or scripts, network protocols and data formats, some custom, some obscure, and from the era of mainframe computers.
I'll examine each of these complexity realms with a view to providing a guideline for new FlightGear developers, me for instance, a path to follow leading to regular contributions to the FlightGear in C++, Nasal, and XML and other data formats.
C++
First, the application uses C++. As a complex and evolving language, C++ has a reputation for being complex. It's not just the language, its the fragmentation of code into small tidbits, widely scattered in individual files covering supposedly just one aspect of what needs to be done. I don't really know if the structure of C++ code as objects is more efficient than a C++ program done using solid structured programming, but I know which is easier think about and to work on.
Flight Simulation does a lot of different things
Second, Flight Simulation involves numerous application domains. Among them are aerodynamics, graphics, geography, geodesy, environment, navigation, networks, audio, video, and human languages. FlightGear addresses all of them and more. Each of these domains has its own view of the world, and many of them are modelled as C++ classes. Full understanding comes from knowing the C++ code, the terminology of the domain, and the way the code's authors chose to structure things as objects and methods.
Nasal and the Property Tree
Next, in addition to the complexity introduced by C++ and the application domains, there's Nasal. Finally, to tie it all together, loosely, the property tree. a global object, with individual data items of a key-value store actually stored in a tree because they are conceptually related. The property tree introduced complexity because items in it are not "owned", they're simply created at some point, in either C++, XML processing, or Nasal, and used wherever the data item is "needed". Connecting the dots through all the code based on identifying individual properties is not all that easy.
Where should I start? C++, Nasal or XML)
It's not clear from existing documentation the central role of Nasal scripting and the Property Tree are in the simulation. It's not just C++, Nasal, and the interface between them, understood as computer languages. Knowing the languages and interfaces themselves is vital, but even more important is understanding how scripting is used in FlightGear to create the simulation. If you are struggling as a newcomer to understand FlightGear's C++ code, understanding Nasal's role in driving parts of the simulation and the way it interacts with C++ code is probably one of the first things to do. It's what I'll be doing next.
FlightGear's DataFlow Diagram
There isn't one. Or rather, there is one, but it's virtual in the sense that no one used it as a design document; rather, it is constructible as a mental model from the observable workings of flightgear itself.`
Part of understanding any body of code is to be able to identify how data flows through the application. Dataflows are usually represented as arrows of various widths. The arrows are messages flowing between parts of an application. The larger the arrow, the more data items in that data flow. Knowing what is in each of those flows is important to understanding how the application works.
In FlightGear's C++ code, there are, of course, classes and objects that represent some dataflows. There's a problem, though. Many of the classes are about processing data into ad-hoc structures within the property tree. How can we define a data flow for these ad-hoc structures? (Note: need a way to describe two dataflows. The one that creates the infrastructure as properties in the tree, and a second one implied by the existence of the property.)
There is no C++ class for an Altimeter or a Heading Indicator. Instead, these are represented by a set of properties and data loaded via XML and other formats. The numerical data, stored in the property tree has a path indicating that the properties underneath a node are for the altimeter or the heading indicator. The actual paths in this case are /instrumentation/altimeter and /instrumentation/heading-indicator. Each node in the tree can have properties as child nodes, as well as child nodes that contain additional properties, such as /instrumentation/heading-indicator/gyro. Usually, only the lear nodes of th e tree
Properties are created on the fly, once the property tree's root node is instantiated. Properties are specified in XML data, created by a Nasal script, or by C++ code. The actual property mechanism is implemented in a C++ class.
After they are created, properties are used as needed from Nasal scripts and C++ code, and finally destroyed by a destructor in C++. However, none of that is traceable as a data flow. IDEs are great at connecting elements of code to their definitions and usage, but when we use a data store like the property tree, the connection can't be found by the IDE. These data flows through the property tree mechanisms are a real part of the FlightGear Application, but we have no easy way to visualise them. Any visualization is mentally constructed over time by developers' experiences, as they examine and step through code.