FlightGear wiki talk:Instant-Refs: Difference between revisions

From FlightGear wiki
Jump to navigation Jump to search
(→‎Issues: regarding messages chopped by regexes - found what's wrong, no easy fix)
Line 70: Line 70:


=== too greedy non-greedy regexes ===
=== too greedy non-greedy regexes ===
The problem described in the previous section regarding regexes that eat up half messages seems to be related to my  [http://blog.liip.ch/archive/2009/07/24/the-greedyness-of-non-greedy-regular-expressions.html misunderstanding of the non-greediness]. So, I managed to fix it for this one case, but this means that using .*? to match everything until you meet the following character (as I currently do pretty much everywhere) is dangerous and prone to failure. Any occurrence of that should be changed as I did in [http://wiki.flightgear.org/index.php?title=FlightGear_wiki:Instant-Cquotes&oldid=72839 this edit] and that's clearly cumbersome, not to say that it can't be straightforwardly done everywhere: for example, say you have <tt><nowiki><a href="http://www.link.org" ... someprop="a > c" ... ></nowiki></tt>. If I want to mach anything after the href up to the closing &gt;, I'd have to use <tt><nowiki>[^>]*</nowiki></tt>, but that would match only up to a greather than b, so I'd have to check that it's not inside parenthesis... Well, I guess this is getting too complicated for handling it [http://blog.codinghorror.com/parsing-html-the-cthulhu-way/ the Chtulu way].
The problem described in the previous section regarding regexes that eat up half messages seems to be related to my  [http://blog.liip.ch/archive/2009/07/24/the-greedyness-of-non-greedy-regular-expressions.html misunderstanding of the non-greediness]. So, I managed to fix it for this one case, but this means that using .*? to match everything until you meet the following character (as I currently do pretty much everywhere) is dangerous and prone to failure. Any occurrence of that should be changed as I did in [http://wiki.flightgear.org/index.php?title=FlightGear_wiki:Instant-Cquotes&oldid=72839 this edit] and that's clearly cumbersome, not to say that it can still be incorrect: say I have
<nowiki><a someprop="href" href="http://www.link.org" ... ></nowiki>
If I want to mach anything between a and href, I use <tt><nowiki>[^(?:href)]*</nowiki></tt>, but that would match only up to the text inside someprop, so I'd have to check that it's not inside doublequotes... Well, I guess this is getting too complicated for handling it [http://blog.codinghorror.com/parsing-html-the-cthulhu-way/ the Chtulu way].


So my approach would be: fix this whenever the problem comes up, but don't overdo because we're already moving in dangerous ground.
So my approach would be: fix this whenever the problem comes up, but don't overdo because we're already moving in dangerous ground. Or, rewrite it all using ''only'' xpaths *sobs*.
--[[User:Bigstones|Bigstones]] ([[User talk:Bigstones|talk]]) 16:49, 17 June 2014 (UTC)
--[[User:Bigstones|Bigstones]] ([[User talk:Bigstones|talk]]) 16:49, 17 June 2014 (UTC)



Revision as of 17:04, 17 June 2014

more sources

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

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)

Automatic update of script and old quotes

Thanks for the heads-up. Now, that makes me wonder if I can adapt the script to automatically parse existing wiki articles and update cquotes there automatically by re-opening the URL and re-running the extraction logic :) BTW: That reminds me: I was going to investigate adopting the downloadURL attribute[1] so that scripts can auto-update --Hooray (talk) 22:51, 11 June 2014 (UTC)

selection/clipboard buffer or alert() limits ?

There seems to be a minor glitch when selecting large text blobs, at some point the text gets truncated. I assume it's some browser-specific limit that is applied here, or maybe it's just the alert() dialog? To work around that, we would either need to use a different "OUTPUT" method, or maybe just use a for() loop to show multiple alert() dialogs for each part of the blob. It's not a major issue, but it's also easy to miss - still need to investigate where the real culprit is. --Hooray (talk) 14:11, 12 June 2014 (UTC)

I would argue that's a feature :D Yes, there should be an alert. I was also thinking, will it be possible to hook up the ctrl-c event and output directly to the clipboard? EDIT: no... it would be a security issue.
--Bigstones (talk) 22:02, 13 June 2014 (UTC)
right, there are several potential security issues involved here-but we can circumvent several SOP restrictions easily because using "TamperMonkey" we can directly hook into the HTML code of the document. According to SO the real issue here is probably a size restriction of the alert() message box. So we could either show multiple alerts or simply use a different output method, i.e. by showing a new form/popup, or even by directly writing to a wiki form. It's not a big issue, but I'll see what we can do about it.--Hooray (talk) 23:16, 13 June 2014 (UTC)

Issues

phpBB code snippets not displayed using syntaxhighlight

Cquote1.png What you can do for input and output properties representig periodic values (like heading) is to normalize them into a given range:
<periodic>
     <min>-180</min>
     <max>180</max>
</periodic>

will transform a value of -190 to +170 for example. But that's probably not what you asked for.


Cquote2.png

recognizing wiki images

I just tested the script using one of my recent forum postings:

Cquote1.png
RevHardt wrote in http://wiki.flightgear.org/MapStructure ... map_dialog
(see the linked image)

You can basically create arbitrary layers, even for custom objects/positions:
(see the linked image)

The same method can be used for creating a "live" radar display:
http://wiki.flightgear.org/Canvas_Radar
(see the linked image)

But maps and layers can be fairly sophisticated, too - all 100% scripted:
http://wiki.flightgear.org/FlightGear_N ... Map_dialog
(see the linked image)

As long as you use the MapStructure framework, all layers can be easily used in dialogs AND instruments

Coding-wise, there isn't too much involved these days, all the details are covered in the MapStructure
— Hooray (Sat Jun 14). Re: Get objects to show up on Map/Radar.
Cquote2.png

I am thinking of fixing the conversion and maybe even use the thumbnail preview (or gallery) so that we can "transform" text into image descriptions --Hooray (talk) 16:45, 14 June 2014 (UTC)

Uhm, I could swear I tested the quote conversion... but I guess not on a quoting with author (the <cite>RevHardt... part.)
Wiki images: that's something I didn't even consider indeed, and that should go together with an exception rule in the a2wikilink() function to avoid links to wiki image pages (File:blabla) to become a shown image in here (probably not many link those page... I did, and it led to that funny behaviour in fact). Yeah, that's definitely more correct.
One more thing on the text for converted internal wikilinks: I chose to preserve the "user" text, it may look ugly sometimes but one never knows if it's an automatic link (like above) or a link embedded in the text, in which case one has to preserve it.
(Be sure to have the latest version, because I see it's using cquote and the last thing I did was fixing that)
--Bigstones (talk) 17:37, 14 June 2014 (UTC)
I changed how (links to) wiki images are handled, although I'm not sure at all now if that's what you meant!... I changed how pipes and equals are escaped because escaping pipes would mess up the wikilinks and the templates. I also took into account the "cite" tag in the forum quotes, but I tried again on your example above and it seems to work unless I include in the selection also the first link. That seems to break the regex.
--Bigstones (talk) 21:35, 14 June 2014 (UTC)
Debugging shows that it's the a2wikilink regex that's being too greedy. It eats up all the text from the link in the "cite" tag down to the first link. I haven't spent much on it but I'll leave this for another time...
--Bigstones (talk) 21:51, 14 June 2014 (UTC)
Never mind, this is pretty cool now and works well enough for our needs. We can basically "announce" news on the forum/devel list now, and easily duplicate stuff on the wiki (newsletter/changelog) with zero effort. Regarding preserved user text, I actually agree with you - and I also tend to agree that we shouldn't try too hard to also convert those links to internal wiki links if it complicates the script too much. I think we can clean up this page a bit and removed obsolete/outdated stuff. I have roughly half a dozen of minor changes here to generalize the thing a bit more, but I still need to integrate them properly, and update things to work with your latest changes. Thanks again, this has really become a very useful tool meanwhile, largely thanks to your work - I think, there's very little remaining in terms of code that you haven't touched, so all the credit should really go to you here, very good job! ;-) --Hooray (talk) 21:58, 14 June 2014 (UTC)


Regarding the URL text, I think at least for the forum we can default to the internal wiki link whenever the URL is a wiki link that contains "...", because then it's simply an automatically shortened URL and linking to just [[FOO]] would make more make sense than having something http://wiki.flightgear.org/FOO ? --Hooray (talk) 11:32, 15 June 2014 (UTC)

too greedy non-greedy regexes

The problem described in the previous section regarding regexes that eat up half messages seems to be related to my misunderstanding of the non-greediness. So, I managed to fix it for this one case, but this means that using .*? to match everything until you meet the following character (as I currently do pretty much everywhere) is dangerous and prone to failure. Any occurrence of that should be changed as I did in this edit and that's clearly cumbersome, not to say that it can still be incorrect: say I have <a someprop="href" href="http://www.link.org" ... > If I want to mach anything between a and href, I use [^(?:href)]*, but that would match only up to the text inside someprop, so I'd have to check that it's not inside doublequotes... Well, I guess this is getting too complicated for handling it the Chtulu way.

So my approach would be: fix this whenever the problem comes up, but don't overdo because we're already moving in dangerous ground. Or, rewrite it all using only xpaths *sobs*. --Bigstones (talk) 16:49, 17 June 2014 (UTC)

regex vectors

When testing things I realized that you are right: there are some scenarios where the regex may fail depending on how "complete" the selection is, because we obviously have hard-coded assumptions here. I'll see if it's feasible to also support vectors for regexes to extract the corresponding fields and try each regex in order to get a certain field, or if that doesn't make any sense... But quoting with/without author (anonymous quote) would be a valid test case here.--Hooray (talk) 16:46, 16 June 2014 (UTC)

Probably going to look into this sooner or later because this could be a simple solution to also support PM quoting - without having to parse the actual URL, we'd just try different regexes in order and use the one that succeeds. --Hooray (talk) 16:46, 16 June 2014 (UTC)

Syntaxhighlighting

Need to investigate what needs to be updated to support quoting code sections, as per [2] --Hooray (talk) 22:33, 14 June 2014 (UTC)

Misc notes

Detecting failed XPaths

you've got a point, we should probably check if xpath/regexes succeed or fail, and show a warning so that we know that the scripts needs to be updated because some xpath/regex may have changed.

Paragraphs / br (trailing slash)

There are some minor issues now, i.e. newline2br will no longer contain the trailing forward slash, so there's probably some JavaScript/regex oddity involved here, maybe slashes just need to be escaped. Will be testing the code with a few different forum postings and check the resulting cquote

Done Done. That's because newline2br wasn't used at all in html mode. I added addNewlines which puts newlines after br's and list related tags, if there are more newlines to be added that should be the place.
--Bigstones (talk) 14:03, 17 June 2014 (UTC)

support/ignore highlighted keywords/smilies

see Understanding Forward Compatibility for examples

Done Done. However, before resorting to simply using the alt text, I tried by matching on the image name, so I had a series of replace() and tested it here. It worked, but if I selected a larger extent of text, again one of the regexes would go crazy and eat up half the message. That's clearly the same that's happening above, I'd really love to understand what's happening there. I tried using a new variable instead of reassigning to the same, but it changed nothing (I expected that.)
--Bigstones (talk) 15:13, 17 June 2014 (UTC)