Wikipedia talk:Wikipedia Signpost/2013-04-22/Technology report
Discuss this story
Echo
edit"Proponents" and "detractors" carries no citation or evidence. Could they be provided? :). Okeyes (WMF) (talk) 23:17, 24 April 2013 (UTC)
- As you could probably tell from the lack of quotation, both are agglomerations from multiple sources. For example, the proponents suggestion mirrors some of the MediaWiki page and slides; the detractors section mirrors some of the many discussions on VPT about notification systems in general (though admittedly the application to Echo may be novel; it's hard to tell when you've been reading critical -- not necessarily negative -- commentary about a project for months and months like this). If you had a more specific concern, I could perhaps find a specific reference regarding that point. - Jarry1250 [Vacation needed] 22:36, 28 April 2013 (UTC)
- I'm confused. You're telling me that the detractors section is based on discussions on the village pump about the general concept of a notifications system, and therefore applies to a specific implementation? The idea that it would lead to a torrent of notifications is a potentially valid one - we had a bug on MediaWiki.org, for example, that caused that temporarily - but things like that are precisely the sort of statement that need to be specific, not general. "Notifications will make us like Facebook" is a general, conceptual concern that can plausibly (although wrongly) be applied to any implementation, including Echo. "Notifications will include tons of notifications that overwhelm everything" is something entirely dependent on the implementation. Citing generalised discussions really isn't useful in this case. Okeyes (WMF) (talk) 03:01, 29 April 2013 (UTC)
"rarely causing a stir" I remember a little bit of a stir when in the early stages there was a bug massively spamming users on mediawiki.org (Long since fixed). Bawolff (talk) 15:56, 25 April 2013 (UTC)
The score tag
editEight years seems a bit long to get it implemented.--Rockfang (talk) 14:47, 25 April 2013 (UTC)
- Well the current work that resulted in the recent deployment, was really only started in December 2011 when Graf Zahl rewrote the lillypond extension as score. (Which arguably is still a really long time) Bawolff (talk) 15:54, 25 April 2013 (UTC)
- I'm presuming it produces only single-line melodies. Is this correct? Tony (talk) 09:21, 26 April 2013 (UTC)
- We are still playing on Wikisource where it will allows us to get back to do more work on sheet music. Here is an example of some more complex coding s:Page:A Dictionary of Music and Musicians vol 1.djvu/24. — billinghurst sDrewth 12:58, 26 April 2013 (UTC)
- Thanks, billinghurst. The tenuto symbols should normally be on the notehead rather than the stem sides, I think. It's a very complex task; the simple outputs I see thus far are pretty good. Notating melodies is useful, but it won't be until more than one part can be displayed that we'll start to see the potential for many western-music articles. Even non-western music traditions often need multistave systems for the (approximate) notation of samples of ensemble music. Tony (talk) 13:59, 26 April 2013 (UTC)
- Normally, the tenuto marks would be on the notehead side, but if you look at the original source on the page billinghurst posted, you'll see that the marks are indeed all above the staff as rendered. That makes the <score> rendering faithful to the original, which is what we should be aiming for. Powers T 16:13, 26 April 2013 (UTC)
- I'd regularise rather than regenerating non-standard and problematic notation. For example, being faithful to an original doesn't involve reproducing the exact spacing between the notes—just as certain changes are permitted to quoted linguistic text by the Manual of Style. As long as the original meaning is reproduced faithfully, ease of reading is a desirable goal. Tony (talk) 10:31, 27 April 2013 (UTC)
- Well that'd be a question for Wikisource's style mavens. Powers T 13:28, 27 April 2013 (UTC)
- I'd regularise rather than regenerating non-standard and problematic notation. For example, being faithful to an original doesn't involve reproducing the exact spacing between the notes—just as certain changes are permitted to quoted linguistic text by the Manual of Style. As long as the original meaning is reproduced faithfully, ease of reading is a desirable goal. Tony (talk) 10:31, 27 April 2013 (UTC)
- Normally, the tenuto marks would be on the notehead side, but if you look at the original source on the page billinghurst posted, you'll see that the marks are indeed all above the staff as rendered. That makes the <score> rendering faithful to the original, which is what we should be aiming for. Powers T 16:13, 26 April 2013 (UTC)
- Thanks, billinghurst. The tenuto symbols should normally be on the notehead rather than the stem sides, I think. It's a very complex task; the simple outputs I see thus far are pretty good. Notating melodies is useful, but it won't be until more than one part can be displayed that we'll start to see the potential for many western-music articles. Even non-western music traditions often need multistave systems for the (approximate) notation of samples of ensemble music. Tony (talk) 13:59, 26 April 2013 (UTC)
- We are still playing on Wikisource where it will allows us to get back to do more work on sheet music. Here is an example of some more complex coding s:Page:A Dictionary of Music and Musicians vol 1.djvu/24. — billinghurst sDrewth 12:58, 26 April 2013 (UTC)
- I'm presuming it produces only single-line melodies. Is this correct? Tony (talk) 09:21, 26 April 2013 (UTC)
Lilypond
editAn example with chords and sound-file generation.
Lilypond is great! Kiefer.Wolfowitz 15:37, 26 April 2013 (UTC)
- How do you get it to play? I press the button and nothing happens. Tony (talk) 03:14, 29 April 2013 (UTC)�
- I use Firefox running on Ubuntu's GNU Linux, and I just hit the button; Wikipedia is trusted by my computer, though. With Windows, you might left-click open in a new window (and perhaps reload). Kiefer.Wolfowitz 06:44, 29 April 2013 (UTC)
- Works fine with Opera 12.15 on winxp. -Yyy (talk) 12:52, 30 April 2013 (UTC)
- Works fine with Firefox 20.0 on a Mac running 10.8.3 (Lion). -- John Broughton (♫♫) 03:24, 2 May 2013 (UTC)
Room for improvement
editIt is possible to get SVG output from Lilypond which can be animated on playback. See Animated SVG Percussion Music. Here's a nice tech post about it: [1]. See it live on http://percussion360.com/. Click the tiny "play" button. Maybe he'll open source this if we ask nicely. The thread posts are all over the place, I use Google like this to find them. I think ly2video is inferior since everything can be generated client-side, which scales better. Tell me what you think. --Ysangkok (talk) 12:56, 1 May 2013 (UTC)
- This question is better addressed to the Lilypond project, which does not yet support exporting svg files from within Lilypond, I believe. The manual suggests command line directives. (It would be better for WMF to focus on e.g. guitarists' wishes for alternative tunings and fretboard diagrams). Kiefer.Wolfowitz 13:40, 1 May 2013 (UTC)
- Exporting SVG is indeed supported, see the tech post. The problem is to make the connection between SVG shapes and notes. His solution is kind of hacky. Marrying MusicXML and SVG would be beautiful. --Ysangkok (talk) 14:35, 1 May 2013 (UTC)
- Please notice the keywords: " from within Lilypond.... The manual suggests [terminal] command-line directives". Kiefer.Wolfowitz 15:11, 1 May 2013 (UTC)
- What manual? The lilypond one? It has the SVG documented on this page. Command-line directives are passed to the lilypond binary, it does the SVG itself. --Ysangkok (talk) 17:12, 3 May 2013 (UTC)
- Please notice the keywords: " from within Lilypond.... The manual suggests [terminal] command-line directives". Kiefer.Wolfowitz 15:11, 1 May 2013 (UTC)
- Exporting SVG is indeed supported, see the tech post. The problem is to make the connection between SVG shapes and notes. His solution is kind of hacky. Marrying MusicXML and SVG would be beautiful. --Ysangkok (talk) 14:35, 1 May 2013 (UTC)
VisualEditor
editThe version of the VisualEditor report I edited said VisualEditor is in beta testing. The VisualEditor itself says that it is in alpha test, which is correct based on my experince with it (I mean that as a factual statement, not a criticism).—Finell 18:36, 25 April 2013 (UTC)
- I have yet to successfully make an edit with the Visual Editor. Powers T 16:18, 26 April 2013 (UTC)
- Most of my VisualEditor edits worked correctly. A few had weird results, such as text that disappeared. I would do more editing with VisualEditor if it were the default editor when editing just a section.—Finell 21:44, 28 April 2013 (UTC)
Perf improvements
editCould you explain the perf improvements in MariaDB, since they are not noticeable by users? What performance metrics were improved, if not for the users? (I'm not a techie, which is why I ask). 74.202.39.3 (talk) 02:11, 26 April 2013 (UTC)
- To quote the blog post "For our most common query type, 95th percentile times over an 8-hour period dropped from 56ms to 43ms and the average from 15.4ms to 12.7ms. 50th percentile times remained a bit better with the 5.1-facebook build over the sample period, 0.185ms vs. 0.194ms. Many query types were 4-15% faster with MariaDB 5.5.30 under production load, a few were 5% slower, and nothing appeared aberrant beyond those bounds." Im not an ops person, so the following is a total guess and may be totally wrong, but I would guess that db latency isnt exactly a bottleneck, so efficiency improvements are probably more long term scalability benefits rather than immediate make the site faster benefits (although they probably do make the site a bit faster). Bawolff (talk) 22:14, 27 April 2013 (UTC)
- My interpretation is the same as Bawolff's, and it's what I consequently hinted at in the report: users are unlikely to notice much of a difference, but hey, every little helps (as we say here in the UK). - Jarry1250 [Vacation needed] 22:36, 28 April 2013 (UTC)
- To quote the blog post "For our most common query type, 95th percentile times over an 8-hour period dropped from 56ms to 43ms and the average from 15.4ms to 12.7ms. 50th percentile times remained a bit better with the 5.1-facebook build over the sample period, 0.185ms vs. 0.194ms. Many query types were 4-15% faster with MariaDB 5.5.30 under production load, a few were 5% slower, and nothing appeared aberrant beyond those bounds." Im not an ops person, so the following is a total guess and may be totally wrong, but I would guess that db latency isnt exactly a bottleneck, so efficiency improvements are probably more long term scalability benefits rather than immediate make the site faster benefits (although they probably do make the site a bit faster). Bawolff (talk) 22:14, 27 April 2013 (UTC)
← Back to Technology report