FlightGear wiki - User contributions [en]

Howto talk:Coding a simple Nasal Framework

2014-07-24T20:40:55Z

Adrian:

== Todo: Considerations for creating Canvas Widgets ==

* benefits of creating widgets
* supporting multiple instances
* creating multiple windows of a widget
* creating a window/dialog with multiple widgets (tabs?)
* all Canvas-based instruments/MFDs should support GUI-based viewing, without requiring a cockpit/aircraft-even if it's just for testing/development purposes (profiling)
* every widget must support rendering to a customizable context/canvas, so that recursion is fully supported, i.e. dialogs showing instruments with GUI elements

--[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 14:25, 29 June 2014 (UTC)

:: I feel that the whole subject of creating a Nasal framework could become an exercise in futility, and should even be discouraged in favour of writing code within the core framework. Nasal simply does not have the suitable debugging tools which could make it a big winner. A large piece of code could easily become unmaintainable in case the original developer left. Case in point: local weather.
::[[User:Adrian|Adrian]] ([[User talk:Adrian|talk]])

::: I guess it's a matter of having to make concessions - in an ideal world, you'd be correct obviously. But given the state of affairs, manpower is not where core development is - but where fgdata contributions happen. The degree of Canvas-based developments and related novelties has meanwhile exceeded any related core developments (except for Canvas itself), including stuff like the hard-coded [[Map]] dialog, wxradar, agradar, groundradar, kln89 etc - and that was foreseeable even within a few months after the most basic drawing primitives were added and supported.

::: But what's been happening is a lot of unprecedented "glass" development in various areas, that was basically completely chaotic, disorganized - without any collaboration and coordination taking place. The few cases where this was not the case, we spent a ton of time doing behind-the-scenes networking. But otherwise, we're seeing a number of efforts, with very desirable features, being developed by people who have no clue/interest about collaborating properly, in order not to write redundant -and usually even incompatible/conflicting- code.

::: However, I am not sure if you've even played with Canvas recently, or if you're aware of the underlying C++ code, and the deprecated code that is made obsolete by Canvas.
::: But it is obvious that without any further involvement/direction from our side, all this fgdata development is going to continue obviously, without any significant degree of collaboration/coordination going on.
::: So coming up with '''frameworks''' in scripting space is the only sane, and scaleable, way to deal with this - absent some major change in the FlightGear development philosophy.

::: Also, what you say is not quite spot-on when it comes to "the core framework" though: What we'll certainly need to explore increasingly is extending the Canvas system itself through extended/added elements and primitives - and that's been happening already, Tom has added a huge number of novelties recently - but we cannot be expected to port all existing code that's being written by dozens of aircraft developers and other Canvas adopters.

::: Thus, localizing and encapsulating functionality in terms of having dedicated frameworks is the right thing to do - because it allows us to define boundaries, while phasing out/re-implementing more native hooks over time, i.e. more optimized code.
::: But as long as people come up with their own code doing all sorts of things in a heavily redundant fashion, they cannot benefit from such optimizations automatically, because all THEIR existing code will need to be manually ported - which is exactly the whole point of having a framework-centric development model.
::: If you've been following my Canvas related postings on the forum, you may have seen that I started exploring re-implementing '''certain''' parts of [[MapStructure]] in C++ space, which is kinda promising - and all code/aircraft/dialogs using the MapStructure '''framework''' (such as Gijs' ND) will automatically benefit from those changes if they're merged, because the key functionality is well-encapsulated there.
::: Which also kinda challenges your whole point about maintenance issues, because frameworks are typically just 500-1000 lines, while separating front-end and back-en code.

::: Like Thorsten suggested himself, LW is far from being a good example here - despite your point being totally valid (I kept saying that for years ...), but the main challenge there is not "framework-centric" development, but the whole development methodology adopted there - Thorsten recently mentioned that he thinks it could be re-architected within 4-6 weeks by a team of skilled Nasal coders - so we've had the same discussion behind the scenes. But Thorsten also said that the main issue is that he wasn't familiar with certain programming techniques when he started LW, so it very much "evolved" over time, and wasn't refactored in any major way - and Thorsten kept saying that "it works", so there's not much motivation to do something about it, which I kinda share - I am also more interested in other things, despite having tried cleaning up a few things there a while ago.

::: Overall, when it comes to major Nasal-based contributions like [[Advanced Weather]] (or [[Bombable]]) the main challenge is not the implementation language, but rather the underlying expertise, i.e. maths, physics, AI, combat etc - the language part is trivial, and good and maintainable Nasal code can definitely be written, just look at any code committed by AndersG, TheTom or Philosopher - the real challenge is that there's no major barrier to entry when it comes to writing Nasal code, and we're seeing a lot of mediocre code committed, often in terms of performance - but almost certainly in structural terms, i.e. stuff like code organization/reuse and refactoring/generalization. Which kinda comes with the territory, i.e. $FG_ROOT/Nasal not being reviewed/maintained any longer. Nasal is not the reason for this, it's just making the underlying problem more prominent, because we 1) have a lot of fgdata-level coding going on and 2) because we're not reviewing/refactoring stuff properly.

::: Like I said, the core Canvas system will certainly be extended and refined over time, but there's no sane way for us to deal with existing code, unless people adopt a framework-centric development model that would allow us to encapsulate and localize functionality - once that is the case, refining frameworks, re-implementing them and even phasing them out is straightforward - but as long as people continue with the current "method", we'll end up with a huge mess with Nasal code using different parts of the Canvas system is hugely inconsistent ways, without having anybody willing to do the ugly refactoring/porting work to use more recent Canvas APIs. And frankly, I am not going to volunteer cleaning up all that mess - it's like ThorstenB once said about [[Advanced Weather]]: it's simply too much to handle for a single person. Then again, we cannot expect non-coders to adopt and honor important concepts like "code reuse", "constant refactoring" and "encapsulation" without also providing working examples. As could be seen in the last few days, doing that actually scales very well - just look at all of omega95's recent postings in the canvas forum.

::: Extending the Canvas system is happening, and will continue to happen, but it's a process that will take months, and probably even years - until then, it makes sense to encapsulate common functionality in terms of frameworks, and use that come up with requirements for the Canvas system itself. Otherwise, we'd need a time machine ...

::: Now, debugging and profiling Nasal code is a different issue - and one that's being worked on, Philosopher has created several very promising patches, some of which we've been running to test/profile and debug code - none of this has been merged yet, but it's on the way.--[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 20:00, 24 July 2014 (UTC)

:: I certainly don't disagree that recent Canvas efforts have become a lot more organised and this has affected the quality of the code in a good way, but the fact still remains that there are too few useful tools to aid Nasal development, while there certainly are a ton for C++ frameworks. Also, while C++ is less forgiving than Nasal, it is also easier to maintain and debug using established techniques. I feel that the project would benefit a lot by encouraging existing contributors to move up to the core code base and have access to a plethora of data that otherwise would be wrapped in layers which don't contribute much to speed and ease of debugging. Of course, Nasal has an important place, but I think developing a large platform strictly within Nasal means asking for trouble in the future.
:: [[User:Adrian|Adrian]] ([[User talk:Adrian|talk]]) 20:40, 24 July 2014 (UTC)

Howto talk:Coding a simple Nasal Framework

2014-07-24T18:55:52Z

Adrian:

User talk:Hooray/SandBox/FlightGear Performance and Run-Time Footprint Debate

2014-07-09T22:05:11Z

Adrian: /* MEANING & PURPOSE ???????? */

==MEANING & PURPOSE ????????==

What's the meaning, and purpose of this page? Personal issues should be dealt in private and not brought in public, even more so not on a wiki, which is supposed to be neutral and informative.

This new exercise in futility is just the latest in a long run of late from a couple of contributors to the wiki, could we please just stop this now????

Op-eds and debates have their place on blogs, and other such personal channels, not on (official) wikis which are supposed to supplement documentation, and carry the clout of apparently being an 'official statement' from the project.

[[User:I4dnf|I4dnf]] ([[User talk:I4dnf|talk]]) 11:14, 9 July 2014 (UTC)

: It does make a lot of sense to present, and summarize, the main arguments and issues that were raised by several contributors. As you may have noticed, compared to the original thread, this is already somewhat "redacted", i.e. minus several emotional statements and tirades. Thus, the purpose is quite simply to get to the meat of the discussion, i.e. the main issues and the suggestions presented by several people, so that people can make up their own mind without having to waste 30 minutes going through pointless debates. This being -quite obviously- a collection of quotes, it is far from appearing "official".
: If any points made here seem "authoritative" it's just because of the exact people who made them, i.e. Thorsten's rendering/GLSL/effects statements obviously carry more weight than mine for example. We've had other heated debates about FlightGear issues, no matter if it's lack of usability, lack of a good GUI, lack of a 2D rendering API, lack of combat support etc - in varying forms, many of these were addressed over time, in response to debates like these.
: You don't have to agree here obviously - but frankly, I also don't agree with things you have done and said in the past, as you know. Like Thorsten so eloquently stated on the forum: We all have different ways of dealing with such situations. The wiki has proven to be a fairly usable platform to present such issues in a less emotional fashion. It is for a reason that we've started locking emotional threads after posting a link to a wiki article presenting the main issues (e.g. [[FlightGear_and_old_Hardware]]): it helps us waste less time. As for your suggestion to deal with personal issues privately: I couldn't agree more with you (and would have loved to see you applying the same standards to your own disagreements with fellow contributors!), but this is '''not''' an attempt to continue the original debate or just make my own point here, it's a summary of all the main arguments and proposals. Those among us who're interested in understanding and fixing such issues, and prevent such debates, actually require some way to gather, evaluate & analyze '''all''' standpoints. This has worked well enough for other heated debates, so I don't see why it shouldn't work this time. --[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 14:35, 9 July 2014 (UTC)

:: First of all let's get things straight: I have never redacted or quoted someone out of context, I have never presented my personal opinions as the "project's official stance". I have merely used my right given by the EU law, on my work, so please spear me the "you've done same/worse" discourse, as that's not going to stick.
:: Btw, no, bullying other people and shutting their mouth under the guise of "project stance" does not mean the debate was solved. It just means that your louder shouts and your abuse of clout has subdued their comments. Censoring the forums and selectively deleting disgruntled posts and/or locking threads and using the ban-hammer threat doesn't mean that either.
:: I'm merely saying that I think personal opinions should be clearly marked as such (no, looking at the history of edits on one page doesn't mean that it's marked as personal opinion), and that I think they have no place on the wiki in the first place. And that I think you're abusing these quotes to paint an image that suits, at most, your personal idea of this project and its development (like it happened in all those other cases that worked oh so well).
:: [[User:I4dnf|I4dnf]] ([[User talk:I4dnf|talk]]) 15:14, 9 July 2014 (UTC)

::: There's no "out-of-context" quoting taking place here, if surrounding context is omitted, the corresponding header makes the point pretty obvious. Besides, that's exactly the point of quoting people, while still linking back to the original posting/discussion: so that statements can be looked up and checked.

::: I've never said that you've done "something worse" - I just said that your applying good standards, but apparently not in the scope of your own work, contributions and discussions/disagreements.
::: And not sure what you are referring to WRT to "EU law". The GPL, and the FSF, are pretty clear about "retracting" contributions-once you release work under the GPL, you are granting others all the freedoms that you are taking by "reserving the right" to retract your work at any later time. See the FSF/GPL FAQs. Their point is quite specifically that individuals acting that way are harming the project, which is exactly which more established projects like the kernel or gcc, require people to sign contracts to prevent such havoc from happening.

::: I totally agree with your point on censorship, but people aren't being censored, it's just that debates that would otherwise need moderation (which IS taking up time) are reviewed and locked if necessary, while providing a less heated platform (i.e. the wiki) to present different views.
::: Personal opinions are what they're, and they can be easily identified as such by looking at the link, which is part of each quote. The edit history doesn't contain any such information obviously.

::: There's no "abusive quoting" taking place, it's a summary of points raised by fellow users and contributors-not even very selective, I added quite a lot of stuff that I disagree/d with personally.
::: But then again, I also once disagreed with the idea to implement a weather system in scripting space, or to implement a 2D rendering API on top of the property tree, or to add scripted AI. And I once ripped out Nasal and replaced it with a different scripting engine - that was several years ago, these days, it is obvious that I was wrong in many of these instances-and I've tried to support several of such efforts/occasions, despite my original reluctance/disagreement.

::: Which kinda goes to show, that the wiki, and summarized discussions there, does work exceptionally well - in fact, much better so than the majority of heated debates on the devel list or the forum. You may not agree with me, or the discussions and features I was involved in, but there clearly is a benefit here. The good thing about contributing to a project like this one is that people don't necessarily have to agree to still collaborate, or even just contribute to an unrelated area.

::: At the end of the day, it really doesn't matter. However, people who are using their track record of participation and contributions as leverage to "veto" and make their points, and threaten to possibly pull certain contributions, is '''always''' going to be harmful and cause havoc. It is with great relief that I find this an uncommon behavior among people involved in more critical parts of the project, like the core code, or we would really be in a pathetic situation.

::: Don't get me wrong: I disagreed with Thorsten on several counts, but that's been previously the case already, and while it may take a while for the dust to settle, I have no doubt that we'll collaborate again, and probably exchange lots of messages behind the scenes.

::: Case in point, we've gone through this at least a dozen times before and just went on a few weeks later, so I have no reason to believe that this will be any different. I have the utmost of respect for Thorsten, not just for his work, but also for him as an individual, because he's really trying to improve things on a "meta" level, not just in terms of "features" but also project coordination and collaboration-often enough acting as an interface between core developers, contributors and end-users. Obviously, this can be very daunting and frustrating. But no matter how strongly the two of us may have agreed on technical terms, he's never refused to answer any questions that I've had, and neither have I. --[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 16:14, 9 July 2014 (UTC)

:::: First of all, I don't see the reason to duplicate forum posts here, when a simple link might be enough.

:::: Second, whatever interpretation of GPL you choose, it doesn't supersede the copyright law. While GPL is just a license, the author of whatever work is involved still has the ultimate right to change the license or stop distributing his own work. I also might say that GPL is not the best license for works other than code, since there are various licenses better suited to artistic contributions. Don't know why Flighgear chose GPL for other works than code. As a Flightgear contributor, I see the subject of the IAR80 as a non-issue. I4dnf can do anything with his contribution, even if it's unorthodox by our standards.

:::: [[User:Adrian|Adrian]] ([[User talk:Adrian|talk]]) 20:39, 9 July 2014 (UTC)

:: 1) it's so that people don't have to go through dozens (or even hundreds) of postings/tirades to find the main points made by fellow contributors, as previously stated.
:: 2) I am not a lawyer, and even if you and I were both lawyers, our "opinions" would be irrelevant still. Which is why I kept referring to the FSF/GPL FAQs explicitly, which supports the main statement here, but which also states pretty clearly why the FSF expects written statements from its contributors (e.g. GCC) [http://www.gnu.org/licenses/gpl-faq.html#CanDeveloperThirdParty] [http://www.cnet.com/news/revoking-open-source/].
:: 3) There's no point in debating this here and now-no matter the outcome, it won't have '''any''' effect whatsoever, for the simple reason that 1) FlightGear traditionally doesn't consult lawyers or pursue such debates, and 2) that FlightGear as such is '''not''' a legal entity at all - we've seen good contributions removed for questionable reasons before - and probably will see that happen again. This was never a matter of 'copyright' or a developer deciding to stop distributing his own work, it was exactly about asking for previously GPL'ed contributions to be revoked by others, which isn't just implicit right like "copyright". Please refer to the FSF/GPL FAQs for details though-they're available in a plethora of languages. --[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 20:57, 9 July 2014 (UTC)

::: You might be confusing the GPL issue with the bit about the FSF requiring people to surrender copyright to them, in order to defend in court. Either way, copyright is recognised in almost every country, while GPL may not have stood a trial. Hence my statements above. I don't think we need to discuss this further here, but references to the IAR will bring this up inevitably ;-)

::: [[User:Adrian|Adrian]] ([[User talk:Adrian|talk]]) 22:05, 9 July 2014 (UTC)

2013-09-03T19:13:27Z

Adrian:

File:Qfgradio3.png

2013-09-03T19:12:33Z

Adrian: with APRS stations DE

== Summary ==
with APRS stations DE
== Licensing ==
{{self|cc-by-sa-3.0}}