I'm building an application that uses DifferenceEngine.php to generate
word level unified diffs. I've figured out how to do this but now need
to generate patches given the diff.
This is what I have written to generate the diff:
$orig = array('One Two Three', 'One Two Three');
$closing =
Roan Kattouw wrote:
2009/4/22 Kent Wang kw...@kwang.org:
I'm building an application that uses DifferenceEngine.php to generate
word level unified diffs. I've figured out how to do this but now need
to generate patches given the diff.
It's not in MediaWiki, and I don't know if it's in PHP,
Sergey Chernyshev sergey.chernys...@gmail.com wrote in message
news:9984a7a70903270737k8ae2e9dq9dbeb12d6dfe0...@mail.gmail.com...
There is probably a solution that can be done within the code - something
that makes all included PHP files override the version if it's later then
in
main file
On Wed, Apr 22, 2009 at 7:12 AM, Mark Clements (HappyDog)
gm...@kennel17.co.uk wrote:
Sergey Chernyshev sergey.chernys...@gmail.com wrote in message
news:9984a7a70903270737k8ae2e9dq9dbeb12d6dfe0...@mail.gmail.com...
There is probably a solution that can be done within the code - something
On 4/22/09 5:54 AM, Chad wrote:
Not sure it's worth it :-\ What's wrong with just giving version numbers
that make sense, rather than relying on the revision number which isn't
indicative of anything?
It's indicative of the running version of the code, as long as it also
tells you which
Aryeh Gregor wrote:
I'm not clear on why we don't just make the daemon synchronously
return a result the way ImageMagick effectively does. Given the level
of reuse of thumbnails, it seems unlikely that the latency is a
significant concern -- virtually no requests will ever actually wait
on
Aryeh Gregor wrote:
https://bugzilla.wikimedia.org/show_bug.cgi?id=4484
That should do what you want.
Yes, this might be the equivalent of {{substonlysubst:/substonly.
That RFE has been around for years, and I was aware of it. The problem is,
interactions between two different kinds of
On 4/17/09 6:45 PM, Marco Schuster wrote:
On Fri, Apr 17, 2009 at 11:42 PM, Brion Vibberbr...@wikimedia.org wrote:
* Background JavaScript worker threads
You mean...stuff like bots written in Javascript, using the XML API?
I could imagine also sending mails via Special:Emailuser in the
On Wed, Apr 22, 2009 at 12:18 PM, William Allen Simpson
william.allen.simp...@gmail.com wrote:
Having thought about such issues on more than one occasion, I'm proposing
clean markup that's easier and predictably parsable, and fits well with
current practices and syntax:
{{# function
There is an issue with running a foreground JS thread that is super fast and
might send a lot of request to the server. Heavy processing on the client
side would alleviate the load from the server (if possible) but it might
push another load on the server (in the presented example of sending
Many extensions are now using the Yahoo User Interface library. It would be
nice if mediawiki included it by default.
On Wed, Apr 15, 2009 at 3:05 PM, Brion Vibber br...@wikimedia.org wrote:
Just a heads-up --
Michael Dale is working on some cleanup of how the various JavaScript
bits are
Thanks for taking care of the announce mail, Roan! I spent all day
yesterday at the dentists... whee :P
I've taken the liberty of reposting it on the tech blog:
http://techblog.wikimedia.org/2009/04/google-summer-of-code-student-projects-accepted/
I'd love for us to get the students set up on
On 4/22/09 9:33 AM, Sergey Chernyshev wrote:
Exactly because this is the kind of requests we're going to get, I think it
makes sense not to have any library bundled by default, but have a
centralized handling for libraries, e.g. one extension asks for latest
jQuery and latest YUI and MW loads
On 4/22/09 9:28 AM, Brian wrote:
Many extensions are now using the Yahoo User Interface library. It would be
nice if mediawiki included it by default.
Rather than bundling multiple separate libraries we aren't going to use
in core code, I'd rather just make sure we've got a consistent
On 4/19/09 7:10 AM, Eugene wrote:
Hi everyone,
Are there any updates regarding Wikipedia's backup systems? I've
created a bug to track this at
https://bugzilla.wikimedia.org/show_bug.cgi?id=18255.
We'll be doing an audit soon to get our backup list up to date and make
sure anything that's
Yep, with jQuery in the core it's probably best to just bundle it.
There is another issue with the code loading and stuff - making JS libraries
call a callback function when they load and all the functionality to be
there instead of relying on browser to block everything until library is
loaded.
William Allen Simpson wrote:
Aryeh Gregor wrote:
https://bugzilla.wikimedia.org/show_bug.cgi?id=4484
That should do what you want.
Yes, this might be the equivalent of {{substonlysubst:/substonly.
...
Should substonly and nosubst become standard, we could use them.
NB:I'd prefer
This would be a great idea as the library is always updated and has a lot of
features for the front end.
On Wed, Apr 22, 2009 at 12:28 PM, Brian brian.min...@colorado.edu wrote:
Many extensions are now using the Yahoo User Interface library. It would be
nice if mediawiki included it by
On Wed, Apr 22, 2009 at 12:53 PM, William Allen Simpson
william.allen.simp...@gmail.com wrote:
And looking back at that RFE, which had a fairly simple patch, Brion
decided strongly inclined to WONTFIX this.
So, what do we have to do to change his mind?
Well, I already tried and he never
Aryeh Gregor wrote:
Again, personally I don't like magic symbols. Distinctive keywords
are much better for grepping/Googling/etc.
That thinking would take us back to b, bold, etc. But I'll often take
rough consensus and running code over purity At least sometime in the
past there was
I probably have an idea of how to implement this using a bot (or post-commit
hook if we want real-time data) and externals.
Essentially bot script should be checking the version of extension folder
and generate and check-in an entry in another repository in the form like
this:
No, my link is about 3 ways of loading:
1. Normal script tags (current style)
2. Asynchronous Script Loading (loading scripts without blocking, but
without waiting for onload)
3. Lazyloading (loading script onload).
Number 2 might be usable as well.
In any case changing all MW and
On Wed, Apr 22, 2009 at 12:54 AM, Marco Schuster
ma...@harddisk.is-a-geek.org wrote:
On Wed, Apr 22, 2009 at 12:22 AM, Roan Kattouw roan.katt...@gmail.comwrote:
* Zhe Wu, mentored by Aryeh Gregor (Simetrical), will be building a
thumbnailing daemon, so image manipulation won't have to happen
hmm right...
The idea of the scriptLoader is we get all our #1 included javascript in
a single request. So we don't have round trips that would benefit as
much from lazy loading so no need to rewrite stuff that is included that
way already.
I don't think we are proposing convert all scripts to
On 4/22/09 11:01 AM, Sergey Chernyshev wrote:
I probably have an idea of how to implement this using a bot (or post-commit
hook if we want real-time data) and externals.
Essentially bot script should be checking the version of extension folder
and generate and check-in an entry in another
25 matches
Mail list logo
