User talk:Bawolff

From Wikinews, the free news source you can write!
Jump to: navigation, search

Smile!

Stop hand.png
I'm somewhat busy in real life, and as a result, it may take me until the weekend to respond. Bawolff 16:24, 28 October 2009 (UTC)


note to self[edit]

Do something about the sight button for new articles.

write rss toolserver thingy and/or yell at wikinewsies who let their ts account expire.[edit]

note to self for adding to todo list.

error[edit]

User:Amgine/apcerror

Regards from portugal[edit]

Hi Bawolff how are you :) Can you please check your email? You have a msg from [1] and your expertise is welcome. Regards. Joanl

Regards from portugal[edit]

Hi Bawolff how are you :) Can you please check your email? You have a msg from [2] and your expertise is welcome. Regards. Joanl

Unreliable javascript[edit]

Hi. I've been observing a puzzle for... I think a few months now, and was just wondering if you might have any thoughts on it.

Aside: This is only indirectly related to my dialog tools, which as usual are shaping up slowly (I' trying to figure out, atm, whether it's premature for me to start building an interactive assistant for building-and-maintenance of interactive assistants). From the very first I designed the dialog tools to be as robust as possible, including especially robust against all but the most unlikely of changes to the underlying wiki platform. And so far the dialog tools haven't shown the anomaly I'm about to describe. But anything that shows instability in javascript worries me.

What I've observed is that sometimes, apparently randomly, when loading a page — on both en.wn and en.wb — some of the javascript gadgetry doesn't load. I'd first noticed this about UTCLiveClock, but then gradually became aware that when it happens it also applies to the collapsing of the legend on RecentChanges. I think I remember the problem also applying to HotCat; I really need to try to remember to notice, next time I see it happen, whether or not it also applies to the "Review progress" gadget. I'd first wondered if it had to do with UTCLiveClock being a very old gadget (or am I mistaken in believing it easily predates ResourceLoader), but I wouldn't have thought a problem with collapsing the RC legend would fit that profile. At any rate, if you've any thoughts on what sort of cause it might have and perhaps how to avoid it, I'd be most interested to hear. --Pi zero (talk) 12:05, 1 April 2016 (UTC)

Hm. When javascript fails — which happens a fair fraction of the time, these days, search-box completion is absent too. --Pi zero (talk) 11:25, 7 April 2016 (UTC)

Some observations about this, that might shed some sort of light on it.

  • On en.wb, User:JackPotte did a lot of updating of javascript on-site, and javascript now usually works there. I think it still fails some of the time, but things have gotten much better.
  • Here on en.wn, I wrapped the body of every gadget in a try block, and when that didn't eliminate the problem I wrapped try blocks around the various sections of code in Common.js, which also didn't eliminate the problem.
I've thought about a major push to eliminate some specific deprecated things from our javascript, such as importScript, but it's not clear if it's worth the effort since I've a pessimistic feeling it'd just be a huge amount of work that still wouldn't eliminate the problem. After all, the en.wn Common.js makes intensive use of importScript.
  • As of a few days ago (I think; perhaps Tuesday, if that's still when they deploy changes), javascript is much more likely to fail in my Opera browser than in my Firefox. Seems suggestive of something about the nature of the problem, though the something eludes me.

--Pi zero (talk) 14:44, 9 September 2016 (UTC)

new code gets deployed on wednessdays here (tuesday is mediawiki.org and test.wikipedia.org. Wikipedia is on thursday). Bawolff 18:22, 9 September 2016 (UTC)
Aha. I'd thought I first noticed the discrepancy more recently than a Tuesday deployment would have predicted. --Pi zero (talk) 18:56, 9 September 2016 (UTC)

Fwiw: I've replaced all the uses of importScript with mw.loader.load. Behavior might have improved slightly as a result. There are still lots of wg variable uses that should be rewritten with mw.config.get. --Pi zero (talk) 10:22, 22 September 2016 (UTC)

... and fixed all the wg* variables to use mw.config.get (except 1 2 3, which I didn't touch because the code baffled me). --Pi zero (talk) 01:24, 24 September 2016 (UTC)
My suspicion is that lots of older javascript is written with implicit assumptions about how things are scheduled relative to each other when using importScript, and the real cause of the problems is that work related to ResourceLoader has changed the overall landscape of scheduling in a way that violates the old assumptions. (Alas, I'm not familiar with whatever positive benefits may accrue from most of what the devs change, so that I tend to resent these sorts of problems as side effects of mostly-blameless devs carrying out spectacularly bad policies imposed by the WMF.) --Pi zero (talk) 15:45, 24 September 2016 (UTC)
You should generally not make assumptions about load order of different scripts. importScript is asyncronous (That's always been the case, even before RL), so timing of it can be random, and will vary depending on if the user has it cached or not. RL (and subsequent changes, especially "ResourceLoaderStorage" [aka caching scripts in LocalStorage]) changed a bunch of core scripts to be very asynchronous. In the event of caching, scripts may even load before the html of the page is fully loaded. Anyhow - If you need to use functions defined in a specific RL module, use mw.loader.using( dependency, callbackFunction ) which will call the callbackFunction only after the module is loaded. If you need access to anything from the HTML DOM, use $( callbackFunction ); which will make sure DOM is loaded before calling the callback. If for some reason you need the page entirely loaded (i.e. all images fully loaded), you can use $( document ).ready( callback );, but generally speaking images can take quite a while before fully loaded, and you almost never need them loaded before doing stuff. Bawolff 09:11, 26 September 2016 (UTC)
It's all very well to say 'don't make assumptions about load order', but I think getting things to work in practice is usually more a matter of finding a way that works (as the system behaves when you're debugging). For example, the progress-review gadget has some funky code in it for scheduling that I can't even altogether decipher but, amongst other things, seems to be checking to see if Bawolff/mwapplib2 has loaded yet and, if not, insert a one-time 0.8 second delay. With a comment I didn't understand either that mentions Google Chrome. (I actually tried to improve that code, but wasn't at all surprised when my improvement didn't work since I really didn't understand the code in the first place.)

I had a vague impression that mw.loader.using would only work with a registered module, and I was completely defeated by trying to figure out how to register a module; it sounded like something only a WMF employee was allowed to do, which would be consistent with my general impression that WMF really wants to be closed-shop. So I've never even tried to use mw.loader.using. --Pi zero (talk) 11:17, 26 September 2016 (UTC)

Yes, module registration needs MediaWiki on the server side to be involved. If you want to make your own, the only way currently (That I'm aware of) is to make a gadget. You can have hidden gadgets that don't show up in preferences by specifying a right that doesn't exist in the option field. - e.g. [ResourceLoader|rights=hidden] (You can see some examples of this on enwikipedia). Alternatively, if one doesn't want to use MediaWiki's loading and module system, one can make their own system for verifying that a dependency loaded (Somehow anyways. I have no idea how MW actually does that, but presumably one can copy whatever it does). (As for the delay in process-review. That's probably bad practice. After all, people on slow internet might have more than a 0.8 second delay. There's lots of historical javascript that doesn't exactly do the best thing). Bawolff 11:38, 26 September 2016 (UTC)
Useful info; thanks. Btw, re progress-review, there might have been a thought there that if the connection is so slow 0.8 seconds isn't enough then you probably don't want to use that gadget anyway. --Pi zero (talk) 13:05, 26 September 2016 (UTC)

User:Bawolff/mwapilib2.js[edit]

That script is old and will stop working later this year. In the worst case scenario, it would throw JavaScript errors that prevents not just itself, but even other JavaScript from working. We should fixe it or remove it. --SleaY (talk) 14:20, 12 June 2016 (UTC)

@SleaY: What is it about it, that will stop working? Also, when does "later this year" mean? I've heard a bunch of stuff will stop working but there never seem to be specifics about why. We have a very heavily automated project here and I suspect most of it depends on that library that you're saying will stop working later this year (although we do have a replacement in the works, it's just not clear if it'll be ready in time).

Btw, we already have JavaScript intermittently failing to work, and so does English Wikibooks. --Pi zero (talk) 14:42, 12 June 2016 (UTC)

i'm aware its old, i wrote it a long time ago. Im not really doing anything beyond the bare minimun of maintinance for it anymore, my interests primarily moving on to other things. What is the nature of your concern? Bawolff 17:28, 12 June 2016 (UTC)

cleanup in aisle MediaWiki:Gadget-dictionaryLookupHover.js[edit]

Mayhap a bit of time to move deprecated/unmaintained scripts to userspace to maintain the history? - Amgine | t 15:01, 21 July 2016 (UTC)

I guess maybe. Although i think there are some cross-wiki scripts that assume its at that particular location. I don't think its bothering anyone where it is. Bawolff 17:24, 21 July 2016 (UTC)