Wikipedia:Reference desk/Archives/Computing/2014 November 18
Computing desk | ||
---|---|---|
< November 17 | << Oct | November | Dec >> | November 19 > |
Welcome to the Wikipedia Computing Reference Desk Archives |
---|
The page you are currently viewing is an archive page. While you can leave answers for any questions shown below, please ask new questions on one of the current reference desk pages. |
November 18
editChanging MediaWiki's version control mechanism.
edit(This is not a question about Wikipedia!)
I'm looking for a plugin/extension or perhaps an outright modification that would allow me to use an alternative version control system to MediaWiki's "history".
Specifically, I want to be able to change the way that 'diff' is done - but I'd also like to use something more like GitHub.
Googling for this is near-impossble because all you get is protracted debates amongst the MediaWiki developers about which version control system they should use for the software behind MediaWiki and it's extensions. I'm interested in versioning the content stored INSIDE MediaWiki.
If there isn't a plugin - I'd be interested in any tips about where to find all this stuff in the MediaWiki source code so I can attempt a "Do It Yourself" approach.
TIA SteveBaker (talk) 17:12, 18 November 2014 (UTC)
- (edit conflict) You're talking about the backing store, i.e., the database. In Manual:Installing_MediaWiki#Create_a_database a standard MediaWiki installation, that database is usually MySQL or PostgreSQL, or something equally suitable for SQL data archival. You're talking about retrieving the content out of, say, a git or subversion repository: that would not work out of the box. MediaWiki expects to speak SQL to its backing store. You would need something - either a modification of the MediaWiki PHP source, or some "interposer" program that pretends to speak SQL while actually committing the data to, say, a subversion server. Nimur (talk) 17:30, 18 November 2014 (UTC)
- Have you looked through mw:Manual:Extensions you might find something there. I suspect that changing the way a diff is done would be relatively easy, changing how revisions are manage is a much more complex task involving changing the database tables used. Perhaps mw:Extension:Diff, mw:Visual_Diff mw:Extension:Wikidiff2 mw:Extension:Wikidiff.--Salix alba (talk): 17:28, 18 November 2014 (UTC)
- @Nimur: I confess to being not super-familiar with SQL either (although I have a sense that I'm about to become that!)...so am I right in saying that SQL has some kind of native revision history - and MediaWiki is just using it? Or is it a case of MediaWiki creating a sequence of time-stamped data records which it's using to create a revision history that just happens to be stored by SQL?
- MediaWiki creates a sequence of time-stamped data records. See: Database Access in the MediaWiki manual, and tables.sql, the code that defines the database layout of a clean MediaWiki installation. Each historical revision of a Wiki page on MediaWiki is an instance of a revision (i.e., a "row" in the revision table); that revision has pointers to the historical textual content (e.g., the rev_text_id, and so on). Nimur (talk) 22:19, 18 November 2014 (UTC)
- @Salix: Thanks for the "diff" stuff - I think that'll answer that part of my question once I get a chance to wade through it all! SteveBaker (talk) 18:39, 18 November 2014 (UTC)
- @Nimur: I confess to being not super-familiar with SQL either (although I have a sense that I'm about to become that!)...so am I right in saying that SQL has some kind of native revision history - and MediaWiki is just using it? Or is it a case of MediaWiki creating a sequence of time-stamped data records which it's using to create a revision history that just happens to be stored by SQL?
Trying to understand Python syntax
editThis is related to this question. In File:Poisson_pmf.svg there is a line: "a = plt.plot(X, P, 'o', color=col[L])". why does it perform an action (plotting the stuff), and get assigned to a variable? I'd expect the method call only to be assigned to the variable 'a' (and do nothing yet, just hold the object). However, "a = plt.plot" and "plt.plot" have the same effect (on the plot, I see that later they need the 'a' for the legend). I just don't get that you don't have to write two independent lines. First, "plt.plot(X, P, 'o', color=col[L])" and then "a = plt.plot(X, P, 'o', color=col[L])".--Senteni (talk) 17:29, 18 November 2014 (UTC)
- First, I've taken the liberty of fixing your wiki-links.
- To directly answer your question: these two lines are actually creating two different plot objects. It is perfectly legal in Python (and almost all other programming languages) for a function to do something and also to return a value. In this case, the return-value of the plot function is an object pointer to an object that stores information about the plot.
- Nimur (talk) 17:33, 18 November 2014 (UTC)
- Ok, but what if you wanted to store a function to a variable, not run it and get the return value? Would that be possible and meaningful?
- You can take a function and some parameters and glue them together into another function, a reference to which you can store in a variable and then subsequently call (typicaly then supplying the remaining paramters you didn't do when you glued up the partial). The documentation for functools.partial gives an example here. -- Finlay McWalterᚠTalk 17:52, 18 November 2014 (UTC)
- In Python (and many more modern languages with functional features) you can refer to a function (
a = plt.plot
) or call it and use the return value (a = plt.plot(...)
- note the parenthesis with (elided) parameters here). And you can make ad-hoc functions, too:a = lambda x:x+10
will assign a function of one variable to a (and that function will return its argument plus 10 if called). --Stephan Schulz (talk) 18:03, 18 November 2014 (UTC)
- In Python (and many more modern languages with functional features) you can refer to a function (
- You can take a function and some parameters and glue them together into another function, a reference to which you can store in a variable and then subsequently call (typicaly then supplying the remaining paramters you didn't do when you glued up the partial). The documentation for functools.partial gives an example here. -- Finlay McWalterᚠTalk 17:52, 18 November 2014 (UTC)
- Hmm, but matplotlib plot calls are methods on the plt object (they mutate its state), they're not pure functions. I think taking a partial of a method may essentially unbind it (lose its association with the plt object) so that's probably not what you want to do. -- Finlay McWalterᚠTalk 18:07, 18 November 2014 (UTC)
- I would need to think about this. But what you certainly can do is use a lambda again:
a = lambda x:plt.plot(x)
(substitute parameters as needed ;-). --Stephan Schulz (talk) 19:08, 18 November 2014 (UTC)
- I would need to think about this. But what you certainly can do is use a lambda again:
- Hmm, but matplotlib plot calls are methods on the plt object (they mutate its state), they're not pure functions. I think taking a partial of a method may essentially unbind it (lose its association with the plt object) so that's probably not what you want to do. -- Finlay McWalterᚠTalk 18:07, 18 November 2014 (UTC)
- In contrast to some other languages,
plt.plot
behaves sensibly in Python. If you assignplt.plot
tof
thenf(*args)
is equivalent toplt.plot(*args)
. Ifplot
is defined inCls
thenplt.plot
is equivalent topartial(Cls.plot, plt)
, andpartial(plt.plot, arg)
is equivalent topartial(Cls.plot, plt, arg)
and so on. -- BenRG (talk) 19:17, 18 November 2014 (UTC)
- In contrast to some other languages,