FlightGear wiki talk:Instant-Refs

regex / sourceforge

You're right - I just checked out the sourceforge archives, there's just a single tag that contains author/date, so regex seems like the right solution here - xpath alone won't get us very far. However, we can also just split the string using From:, < and - as delimiters to get substrings for author/date. But supporting regex seems like a good idea and should be straightforward to generalize as part of the CONFIG hash, maybe in addition to XPath expressions.--Hooray (talk) 16:12, 31 May 2014 (UTC)

RX suffix

That's kinda neat - "eval-metaprogramming", I guess - took me a few seconds to understand how this works behind the scenes. If it works this way, it's good, but I'd probably just use a nested hash, e.g. something like:

var CONFIG = {
"sourceforge.net": { 
        author: { xpath: "../../../tr/td/div/small/text()", regex:"/^From:\s(.*)</" },
        title:  { xpath: "../../../tr/td/div/div/b/a/text()", regex: "/(.*)/" },
        date:   { xpath: "../../../tr/td/div/small/text()", regex: "/(\d\d\d\d.\d\d.\d\d)/" },
        url:    { xpath: "../../../tr/td/div/div/b/a/@href", regex: "/(.*)/" }
    },
};

basically, each entry would consist of a single hash that contains two lookup-expressions, the xpath to get to the element itself, and the regex to do additional filtering. Otherwise, it's looking pretty good to me. That should be fairly future-proof and extensible then. We could in fact even add additional keys, for example one for post-processing all data, i.e. for cleaning up/escaping/transforming parsed data, or even just trimming. I really like the fact that you introduced a few tiny helper functions and that you didn't bloat the whole thing, but also that you extended the existing config hash! Overall, this is pretty cool and could save us quite some time when adding quotes to articles, and also save us from having to re-write useful postings. Thank you! --Hooray (talk) 16:23, 31 May 2014 (UTC)

Thanks for the "neat", I appreciate your diplomacy towards what looks like a hack to me. I don't know JS and don't know how I could transform those repeated calls to extractInfo() into a loop. That'd be looping through the members (properties?) of profile, which I'm doing now by "calling them by name". And also, extractInfo() should return a structure. I'm pretty sure one can treat an object like an array, but I fear there could be hidden traps.

EDIT: actually the little helper function were there already, and the regex idea was in a TODO comment. No wonder you appreciate it :D

--Bigstones (talk) 18:27, 31 May 2014 (UTC)

Nope, it's not a hack at all - but you are doing the equivalent of using Albert Einstein to remodel your kitchen ;-) I'll see what I can do to integrate your changes and simplify things a bit.--Hooray (talk) 19:47, 31 May 2014 (UTC)

extractInfo loop

I would probably just change the extraInfo() function to return a hash with url, author, message, date etc. all set. That way, you only need to make a single call and call directly use the return value to build the template .--Hooray (talk) 20:22, 31 May 2014 (UTC)

prepend field

I would rename this to transform and turn it into a function, that accepts a single string argument and which returns the transformed data - that way, we cannot just "prepend" stuff, but do pretty much anything. --Hooray (talk) 22:24, 31 May 2014 (UTC)

I'm happy the way it is actually. The "prepend" was particularly needed for urls, or I wouldn't even have put it, but as far as possible I think it's better to keep CONFIG separated from any code. Anyway that's easy to be changed. The hardest part was figuring out that in the regex's I had to use real spaces instead of \s. Also, it didn't like \d for the date digits.

--Bigstones (talk) 23:47, 31 May 2014 (UTC)

more sources

at some point, we may also want to add support for other sources, such as:

• the issue tracker: http://code.google.com/p/flightgear-bugs/
• gitorious commit logs http://gitorious.org/fg/
• http://www.mail-archive.com/flightgear-devel@flightgear.org/ (until 2005)
• http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/maillist.html (until 10/2013)

that should cover all important sources. And it would allow us to also use the same script to help populate FlightGear Newsletter & changelogs, but also Release plan/Lessons learned. So this could be a real time-saver. --Hooray (talk) 14:40, 1 June 2014 (UTC)

retained formatting

The whole transform/post-process idea may not be that far-fetched, I just added quite a few cquotes to the Canvas EFB Framework article thanks to your work. But I had to exclude some passages, because they contained phpBB/forum formatting, such as bulletin lists or URLs for example. Having an optional post-processing callback would allow us to also parse and transform such mark-up, we could even turn links linking to the wiki (http://wiki.flightgear.org/FOO) into internal wiki links ([[FOO]]) automatically. We could even rewrite forum postings containing wiki images or youtube videos that way. (paragraphs are currently also not retained, but could be easily supported by replacing CR/LF with <br/>) --Hooray (talk) 15:39, 1 June 2014 (UTC)

I'll take a look at these, paragraphs are easy indeed. But I suspect that copying the HTML content of a selection for retaining formatting and links would be a bit harder, any idea?

--Bigstones (talk) 19:53, 2 June 2014 (UTC)

I don't think we need to copy the HTML content[1] - For starters, just looking for CR/LF and turning it into <br/> should suffice - as long as there's support for a single "post_process(blob)" callback, most things could be implemented. Regarding other formatting, such as links, we could probably simply use the xpath of the selected text portion and look for any child elements [2][3][4], e.g. <a href=""></a> - but even that may be more low-level than needed - for instance, the phpBB/forum markup uses dedicated CSS classes that we can look up via XPath queries, such as postlink (right click on any link in a forum posting and use "inspect element" to see for yourself). Likewise, bulletin lists only use <ul> <li>...</li> </ul>. Looking for images doesn't make too much sense unless those are wiki-based, otherwise we cannot embed them directly. Youtube videos are a different beast, those can be directly turned into {{#ev:youtube|VIDEO_ID}} markup - either through youtube.com URLs, or embedded videos (div id=video, iframe). Looks like a nice little challenge, let me know if you don't make any progress, I can probably help with it in a few days--Hooray (talk) 20:18, 2 June 2014 (UTC)

Newlines are now <br/>, but I had to remove nowiki() from text. However this is temporary, it makes no sense to process text out of extractInfo() and it makes it unconfigurable. I'll continue working on it when I'm done with the weather article.

--Bigstones (talk) 20:52, 2 June 2014 (UTC)

example

A basic functioning gauge has the following parts. 1. 3D model which is made up of a handful of 3D objects (bezel, face, pointer(s)...) and a texture. Now it could be even easier to make new gauges if there were a standard library of 3D "instrument parts" (IE. a selection of bezels, knobs, pointers...) but these are very simple 3D objects and anyone who even tried a little bit can put together this part of a gauge. The hardest part is the texture for the face which is probably 70% to 80% of the total effort to create a typical gauge and almost every new gauge will need a new texture. No coding at all in this part. 2. XML to setup the animation for the gauge pointer(s) and to interface the gauge to the property tree. For many gauges this XML is very simple and this is a pure exercise in configuration and is exactly the type of activity that a "modder" would be expected to do. I don't consider this to be coding but others may not agree. 3. In a small number of cases the property tree will not have the data needed to drive the gauge animation directly. In JSBSim, in many cases, it is possible to create FDM functions for this and again since it is XML it is more of a configuration activity than a coding activity. But in a subset of these cases it may be necessary to write some Nasal code to get the data needed into the property tree. For YASim aircraft writing Nasal for gauges is probably more common than for JSBSim aircraft. Overall perhaps 4% or 5% of new gauges will require actual "coding" skill but in most cases these will be a relatively trivial coding task. — hvengel (Fri May 30). Re: Does FlightGear has Multiplayer Combat mode?.

We have many people here who have extensive coding skills that are heavily involved in FG activities that don't need those skills. For example, I do a lot of aircraft work (3D modeling, FDM...) because I enjoy it even though, in my professional life for the last 25 years, I have worked as a software engineer. I do FG stuff for pleasure and although I do enjoy programming I get about as much of that "fun" as I need at work. So my FG activities are to do something different for fun although on occasion I will do some non-trivial coding that is FG related like the computing gunsight stuff I did earlier this year. Which gets us back to coding and "gauges". The computing gunsight code was needed to implement what amounts to a very complex "gauge" (IE. a lead computing gunsight) for my aircraft project. This is a clear case where significant coding skills were needed to implement a "gauge". Any framework that would have allowed a "modder" to create this device seems li...modder" can now create new very sophisticated gunsights with no coding beyond the XML that needed to do the interfacing and animation. The animation work will be nontrivial so this will definitely require a skilled "modder". Since we have a large number of aircraft that should have computing gunsights that are currently missing this functionality (probably because creating a good lead computer is difficult) this should allow for this situation to be corrected over time by the "modders" with very little needs for the involvement of the coders. What I am getting at this for typical gauges "modders" can and are creating these all the time and it is only very complex highly specialized gauges that require actual coding skills to implement. — hvengel (Fri May 30). Re: Does FlightGear has Multiplayer Combat mode?.

testing CR/LF conversion

I do agree that an inaccurate rating could motivate that original author to correct and maintain the rating. I also don't have an issue with users stepping up to rate aircraft that are currently unrated or that have clearly wrongs ratings. Most of the unrated aircraft in git will likely be Alpha and Beta level and as I pointed out not very much aircraft specific knowledge or detailed flight testing is needed to rate this class of aircraft. Alpha and Beta class aircraft are particularly well suited to being rated by someone other than the developer. But as you move up to more advanced aircraft the amount of aircraft specific knowledge needed to properly rate the aircraft goes up exponentially and at the highest levels (aircraft with 4 or 5 level FDMs and systems) a person starting from scratch to gather the materials/data needed to do the evaluation and learn enough about the aircraft and then run tests to confirm the FD... aircraft to be rated if the author wants it on the download page. B. Gives aircraft devs a simple why to keep aircraft that are still in too early of a development state off the download page by either not having a rating section or by commenting it out. The current aircraft inventory has many aircraft that are not ready for even basic testing by users that should not be on the download page at all and I think many aircraft devs would take advantage of this. 2. The other way to deal with the dead line thing is to set all of the ratings for unrated aircraft to 0 when the dead line is reached and if the authors don't like it they can update the ratings for their aircraft. — hvengel (Thu May 29). Re: Aircraft Rating System.