Re: [Wikitech-l] Lua deployed to www.mediawiki.org

Hi! > As long as people in the templating community were at least consulted with, > then that's fine. I'm just saying we cannot randomly throw features onto > users without discussing it with them. Same way template editors created whatever they created without discussing with developers, ha ha

Re: [Wikitech-l] Lua deployed to www.mediawiki.org

> ...took place? I'm sure that such discussions has taken place > somewhere, because if not - that's not very mature behavior for open > source developer team. why do you have to be such an ass, by the way? Domas ___ Wikitech-l mailing list Wikitech-l@

Re: [Wikitech-l] How to write a parser

Well, the syntax is: condition = and_condition ('or' and_condition)* and_condition = relation ('and' relation)* relation = is_relation | in_relation | within_relation | 'n' is_relation = expr 'is' ('not')? value in_relation = expr ('not')? 'in' range_list within_relation = expr ('n

Re: [Wikitech-l] PHP 5.4 has been released

> > And we will not be able to use them in core for next five years > because of shared hosting compatibility. Yay! Shared hosting compatibility is for old branches ;-) Domas ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wi

Re: [Wikitech-l] Bump of minimum required PHP version to 5.3 for MediaWiki 1.20

Hi! > Agreed. Trying to push people to upgrade to 5.3 will be a colossal waste > of time. Remember the pushes for PHP5 and to get people to drop PHP4? None of that frustration was around MediaWiki development - we dropped PHP4 swiftly, and I guess only Jeffrey Merkey complained. ;-) If MediaWiki

Re: [Wikitech-l] Announcement: Terry Chay joins WMF as Director of Features Engineering

Oh my, I've been an admirer for many years ;-) Domas ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Dropping StartProfiler.php

> Good point. Rather than simply simplifying that kind of case we could add > to the $wgProfiler array a callback functionality that can return a > boolean on whether to start the profiler. Or which one to start, because, um, we start different ones. Domas ___

Re: [Wikitech-l] Dropping StartProfiler.php

> We could try to simplify those kind of common cases. Yet there are cases that are not so common - "start profiler for this page", "for this ip", "for this wiki", "for this query string", etc. Where would that belong? Domas ___ Wikitech-l mailing lis

Re: [Wikitech-l] How Does Wikimedia Succeed As A Non-Profit?

Hi! > As far as I am aware Medecins Sans Frontieres pay full whack salaries: > their doctors are not volunteers. Are you suggesting something? Heh, no, I guess my example was wrong. My point is that nonprofits have people motivated to do mission-critical things, and other stuff like 'running a

Re: [Wikitech-l] How Does Wikimedia Succeed As A Non-Profit?

Hi! > Non-profit organizations are famous for having terrible web > sites. Maybe other non-profit organizations don't conduct their business mainly via their website. Wikipedia wasn't that beautiful at some point in time either, a volunteer came and redesigned it. The way Medecins San

Re: [Wikitech-l] page view stats redux

Hi! > I had thought to do a daily update. If it turns out that hourly updates > are indeed useful, I'll set that up. I don't know of anyone else that > has a current mirror. Yeh, don't believe anything I say, wait for someone on mailing list to tell you the same to make conclusions. Domas __

Re: [Wikitech-l] wikipedia lacks a "share' button

Hi! > Gentlemen, where is the Share button? I have one in my browser, and I think thats where it belongs ;-) Domas ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Mystery of most-viewed pages on En.Wikipedia

Yo, > So I guess this was just one IP hitting the same article ~1.5 million > times per day for 3-4 days, for whatever reason. OMG, if anyone can influence quality journalism on examiner.com that easily, we definitely have to go and build proper analysis of full logs with all the shiny modern

Re: [Wikitech-l] Adding MD5 / SHA1 column to revision table

> > Ah, okay. I remember that's what happened in MyISAM but I figured > they had that fixed in InnoDB. InnoDB has optimized path for index builds, not for schema changes. Domas ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.

Re: [Wikitech-l] Adding MD5 / SHA1 column to revision table

> > * When reverting, do a select count(*) where md5=? and then do something > more advanced when more than one match is found finally "we don't need an index on it" becomes "we need an index on it", and storage efficiency becomes much more interesting (binary packing yay ;-) so, what are the

Re: [Wikitech-l] Help us document MediaWiki's history

Well played sir. :-D > > Just think how different the world might have been ;) Pity there was no Mongo at that time. Domas ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Help us document MediaWiki's history

Hi! > A cool software history project, "Architecture of Open Source > Applications," asked MediaWiki for a short history of our software. If you're soliciting feedback, you should note that putting this into an initial version of initial ideas list is somewhat odd way to attract contributions:

Re: [Wikitech-l] State of page view stats

> Downloading gigs and gigs of raw data and then processing it is generally > more impractical for end-users. You were talking about 3.7M articles. :) It is way more practical than working with pointwise APIs though :-) > Any tips? :-) My thoughts were that the schema used by the GlobalUsage >

Re: [Wikitech-l] State of page view stats

Hi! > Currently, if you want data on, for example, every article on the English > Wikipedia, you'd have to make 3.7 million individual HTTP requests to > Henrik's tool. At one per second, you're looking at over a month's worth of > continuous fetching. This is obviously not practical. Or you can

Re: [Wikitech-l] mysql_* functions and MediaWiki

> c) Both PDO and MySQLi support "prepared" statements, which could let us > introduce a form of statement cache so that if we need to execute the > same query multiple times except with different parameters, there is > less overhead involved since the statement is already prepared and just > n

Re: [Wikitech-l] Please don't commit broken code

Hi! just wanted to point out that there's open-source software for code-review that is designed for this (code reviews before commit), it supports both SVN and Git: http://phabricator.org/ Domas ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.o

Re: [Wikitech-l] ICANN expansion, relative URLs

> I suppose "in theory" having "apple" available is no worse than "apple.com" > (since you *could* have an "apple.com.mylocaldomain" already and have to > worry about which takes precedence), but in practice that sounds like a > crappy thing to do. :) Well, yes, this is exactly why you don't usual

Re: [Wikitech-l] XKCD: Extended Mind

> Well, in fact, Randall's pretty good about the details (vis 2000 people > showing up in a park in Cambridge just because he put an undesignated > time and lat/lon in a strip)... Randall: " I drew it based on an older error message where the IP was 10.0.0.243. I changed it to 242 (a) because I

Re: [Wikitech-l] XKCD: Extended Mind

> > I second Domas to check because there may be a super secret conspiracy > and the drawing may be correct. ;-) well, $wgContributionTrackingDBserver = 'db9.pmtpa.wmnet'; - though I don't see anything on profiling. *sigh* Domas ___ Wikitech-l maili

Re: [Wikitech-l] XKCD: Extended Mind

> > I would have thought the fact that it was hand drawn would have given > it away. well, it is valid DB IP, so some random extension pulling data from db9 could be likely. Worth checking anyway ;-) Domas ___ Wikitech-l mailing list Wikitech-l@lists

Re: [Wikitech-l] dns issues during downtime

> What was the problem exactly? I don't see anything about it in the > server admin log. The usual, powerdns deadlock. There're plenty of cases like that in the past. Domas ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikime

Re: [Wikitech-l] XKCD: Extended Mind

On May 25, 2011, at 9:35 AM, K. Peachey wrote: > http://xkcd.org/903/ > -Peachey that error is fake! 10.0.0.242 is internal services DNS server and is not used to serve en.wikipedia.org - dberror log does not have a single instance of it! 10.0.6.42 on the other hand the incident yesterday

Re: [Wikitech-l] dns issues during downtime

frankly, european dns server had problems we didn't really notice - until the actual maintenance. DNS should've been fully functional as it is in multiple datacenters. Domas ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wik

Re: [Wikitech-l] WYSIWYG and parser plans (was What is wrong with Wikia's WYSIWYG?)

> I've spent a lot of time profiling and optimising the parser in the > past. It's a complex process. You can't just look at one number for a > large amount of very complex text and conclude that you've found an > optimisation target. unless it is {{cite}} Cheers, Domas _

Re: [Wikitech-l] WYSIWYG and parser plans (was What is wrong with Wikia's WYSIWYG?)

Hi! > A single long line containing no markup is indeed an edge case, but it > is a good reference case since it is the input where the parser will run > at its fastest. Bubblesort will also have O(N) complexity sometimes :-) > Replacing the spaces with newlines will cause a tenfold increase in

Re: [Wikitech-l] WYSIWYG and parser plans (was What is wrong with Wikia's WYSIWYG?)

Ohi, > The time it takes to execute the code that glues together the regexps > will be insignificant compared to actually executing the regexps for any > article larger than a few hundred bytes. Well, you did an edge case - a long line. Actually, try replacing spaces with newlines, and you wil

Re: [Wikitech-l] Zend performance (Was: WYSIWYG and parser plans)

Hi! > The discussion was concerning parser performance, the discussion was concerning overall parser performance, not just edge cases. > so a profile of only parser execution would have been most relevant. Indeed, try parsing decent articles with all their template trees. > In my profiling

Re: [Wikitech-l] Zend performance (Was: WYSIWYG and parser plans)

Hi! > I'm not sure what you are profiling, Wikipedia :) > but when repeatingly requesting a > preview of an article containing 20 bytes of data consisting of the > pattern "a a a a a a " I got the below results. (The php parser doesn't > seem to depend on perl regexps.) I'm sure nothing p

Re: [Wikitech-l] Licensing (Was: WYSIWYG and parser plans)

> > Thoughts? Also, for re-licensing, what level of approval do we need? > All authors of the parser, or the current people in an svn blame? Current people are doing 'derivative work' on previous authors work. I think all are needed. Pain oh pain. Domas

Re: [Wikitech-l] Licensing (Was: WYSIWYG and parser plans)

Hi! > I was just talking about this in IRC :). We could re-license the > parser to be LGPL or BSD so that other implementations can use our > parser more freely. This is how WMF staff treats volunteers: [21:17:23] domas: and now I took your BSD idea, and didn't give you credit [21:17:38] * R

[Wikitech-l] Licensing (Was: WYSIWYG and parser plans)

> Which would also require the linking application to be GPL licensed, > which is less than ideal. Which of course allows me to fork the thread and ask why does MediaWiki have to be GPL licensed. Domas ___ Wikitech-l mailing list Wikitech-l@lists.wiki

Re: [Wikitech-l] WYSIWYG and parser plans (was What is wrong with Wikia's WYSIWYG?)

> It's slightly more difficult, but it definitely isn't any easier It is much easier to embed it in other languages, once you get shared object with Parser methods exposed ;-) Domas ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lis

[Wikitech-l] Zend performance (Was: WYSIWYG and parser plans)

> > regexps might be fast, but when you have to run hundreds of them all > over the place and do stuff in-language then the language becomes the > bottleneck. some oprofile data showsthat pcre is few percent of execution time - and there's really lots of Zend internals that stand in the way - me

Re: [Wikitech-l] facebook like box in mediawiki

> ZOMG DOMAS IS WORKING FOR TEH ALIENS!!!1!one! Careful, I can plan an Inception for you all to believe that privacy policy is bad idea, after I stop hunting dolphins in the cove, of course in my human avatar. Domas ___ Wikitech-l mailing list Wikitech

Re: [Wikitech-l] facebook like box in mediawiki

> hell, Aaron Sorkin got an Oscar for dramatizing why you *should* be > concerned about it. "Alien" and "Aliens" both won Oscars too. You *should* be concerned about aliens. Cheers, Domas ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https

Re: [Wikitech-l] HipHop

> For comparison: WYSIFTW parses [[Barak Obama]] in 3.5 sec on my iMac, > and in 4.4 sec on my MacBook (both Chrome 12). Try parsing [[Barack Obama]], 4s spent on parsing a redirect page is quite a lot (albeit it has some vandalism) OTOH, my macbook shows raw wikitext pretty much immediately. Pars

Re: [Wikitech-l] HipHop

On Mar 28, 2011, at 5:28 PM, Aryeh Gregor wrote: > ... and Facebook ignores that and adds what > it thinks would be useful? Facebook already has features Zend does not: https://github.com/facebook/hiphop-php/blob/master/doc/extension.new_functions Stuff like: * Parallel RPC - MySQL, HTTP, ..

Re: [Wikitech-l] A good question

On Mar 16, 2011, at 3:34 PM, Victor Vasiliev wrote: > Imagine a user approaches you and asks "What are significant changes > between 1.16 and 1.17?" Try marketing-l. Domas ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wiki

Re: [Wikitech-l] secure/singer proxy errors

> For now I have added a sleep() to the code to limit invalidations to > 100 pages per second per job runner process. Mass invalidations will create MJ issue in the long tail though... Need poolcounter ;-) Domas ___ Wikitech-l mailing list Wikitech-l@l

Re: [Wikitech-l] Wikimedia engineering February report

On Mar 4, 2011, at 6:36 PM, Guillaume Paumier wrote: > Hi, > > Le vendredi 04 mars 2011 à 17:25 +0100, Krinkle a écrit : >> On 4 March 2011, David Gerard wrote: >> >>> On 4 March 2011 09:58, Guillaume Paumier >>> wrote: >>> * posting a link here is a good practice that you'd like us t

Re: [Wikitech-l] Sprint to 1.17

Hi! > You might know this already, but you can download Oracle Database from > oracle.com, and use it for free for the purpose of application > development or testing. I'd think whoever cares already know about that. I don't see why WMF should be directly working on that though ;-) Domas

Re: [Wikitech-l] Using MySQL as a NoSQL

Hi! > I was assuming usage of pfsockopen(), of course. Though protocol is slightly cheaper, you still have to do TCP handshake :) Domas ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Using MySQL as a NoSQL

Hi! > I suppose it's possible in theory, but in any case, it's not what > they're doing. They *are* going through MySQL, via the HandlerSocket > plugin. After reading the code I can sure correct myself - they are calling into some of MySQL things (e.g. for table open), but everything else is ta

Re: [Wikitech-l] Using MySQL as a NoSQL

Hi! > It seems from my tinkering that MySQL query cache handling is > circumvented via HandlerSocket. On busy systems (I assume we talk about busy systems, as discussion is about HS) query cache is usually eliminated anyway. Either by compiling it out, or by patching the code not to use qcache

Re: [Wikitech-l] Using MySQL as a NoSQL

Hi! > This could also reduce memory usage by not using memcached (as often) > which, I understand, is a bigger problem. No it is not. First of all, our memcached and database access times not that far away - 0.7 vs 1.3 ms (again, memcached is static response time, whereas database average i

Re: [Wikitech-l] Using MySQL as a NoSQL

Hi! A: > It's easy to get fast results if you don't care about your reads being > atomic (*), and I find it hard to believe they've managed to get > atomic reads without going through MySQL. MySQL upper layers know nothing much about transactions, it is all engine-specific - BEGIN and COMMIT pro

Re: [Wikitech-l] Using MySQL as a NoSQL

Hi! > I have recently encountered this text in which the author claims very > high MySQL speedups for simple queries It is not that he speeds up simple queries (you'd notice that maybe if you used infiniband, and even then it wouldn't matter much :) He just avoided hitting some expensive critic

Re: [Wikitech-l] Convention for logged vs not-logged page requests

Hi! > will still return the same results, wouldn't it make more sense to > teach the stat's logger to ignore both?  Or is there a reason that we > actually want to track one and not the other? Pretty URLs are for being pretty URLs (e.g. in your address bar). That leads to very easy assumption, th

Re: [Wikitech-l] Collaboration between staff and volunteers: a two-way street

... > +4,294,967,295 see what you did to poor Roan, in this "always be positive" environment this is the only way he can write -1. Domas ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] [Announce]: Mark Bergsma promotion to Operations Engineer Programs Manager

Hi! > Erik gave an overview of how EPMs work a few days ago: > http://article.gmane.org/gmane.science.linguistics.wikipedia.technical/49532 What I learned is that most important information should be put under most obscure subject lines, so that only people who really really care would read tha

Re: [Wikitech-l] [Announce]: Mark Bergsma promotion to Operations Engineer Programs Manager

Hello, > Please join me in congratulating Mark Bergsma on his promotion last week > to Operations EPM. Congratulations with a long title (whatever it means, Enterprise? Executive? Project Manager?) What is the rationale for another Director of Operations? What will he direct? What is the futu

[Wikitech-l] On decentralized discussions

> Why decentralized discussions even more? And is there a reason you > always seem to spilt your replies to the thread into new treads/topics > instead of just replying to the original one? Innovation, maybe? Domas ___ Wikitech-l mailing list Wikitec

Re: [Wikitech-l] Community vs. centralized development

Hi! > I created a yahoo group Why not Facebook Page?!!? Domas ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Community vs. centralized development

Hi! > ... there would now be open source hardware Do you need open source "Enter" key? Domas ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Community vs. centralized development

Hi! > Back in 2006 I wanted to make search better, and if then it > wasn't for Tim Starling to give me shell access and a couple of test > servers to play with, I think we would not have the new search, or at > least not developed by me. I probably have similar story to share :) Unfortunatel

Re: [Wikitech-l] Wikimedia logging infrastructure

> Without having looked at any code, can't the threads just add data to > a semaphore linked list (fast), and a single separate thread writes > the stuff to disk occasionally? Isn't that the usual error that threaded software developers do: 1. get all threads depend on single mutex 2. watch them

Re: [Wikitech-l] Wikimedia logging infrastructure

Hi! > Sure. Make each thread call accept and let the kernel give incoming > sockets to one of them. There you have the listener done :) > Solaris used to need an explicit locking, but it is now fixed there, too. Heh, I somewhat ignored this way - yeah, it would work just fine - one can do per-fi

Re: [Wikitech-l] wikipedia is one of the slower sites on the web

Hi! <3 enthusiasm :) > 1) > This is not a website "http://en.wikipedia.org";, is a redirection to this: > http://en.wikipedia.org/wiki/Main_Page > Can't "http://en.wikipedia.org/wiki/Main_Page"; be served from > "http://en.wikipedia.org";? Our major entrance is not via main page usually, so this

Re: [Wikitech-l] Wikimedia logging infrastructure

Hi! > Going multithread is really easy for a socket listener. Really? :) > However, not so > much in the LogProcessors. If they are shared accross threads, you may > end up with all threads blocked in the fwrite and if they aren't shared, > the files may easily corrupt (depends on what you are

Re: [Wikitech-l] Wikimedia logging infrastructure

Hi! > multiple collectors with distinct log pipes setup. E.g. one machine for > the sampled logging, and another, independent machine to do all the > special purpose log streams. I do like more efficient software solutions > rather than throwing more iron at the problem, though. :) Frankly, we cou

Re: [Wikitech-l] Developing true WISIWYG editor for media wiki

> Unless you use hip-hop to do PHP->C++, then alchemy for C++ -> Flash... > A really crazy idea :) crazy uneducated idea :) Domas ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] New table: globaltemplatelinks

Hi! > Can you please read it and give your opinion? Great job on indexing, man, I see you cover pretty much every use case! Domas ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] wikipedia is one of the slower sites on the web

Hi! > Couldn't you just tag every internal link with > a separate class for the length of the target article, Great idea, how come noone ever came up with this, I even have a stylesheet ready, here it is (do note, even it looks big in text, gzip gets it down to 10% so we can support this kind o

Re: [Wikitech-l] wikipedia is one of the slower sites on the web

> The first load of the homepage can be slow: > http://zerror.com/unorganized/wika/lader1.png > http://en.wikipedia.org/wiki/Main_Page > (I need a bigger monitor, the escalator don't fit on my screen) well, no wonder that first page load is sluggish, with 12 style sheets, and 12 javascript files

Re: [Wikitech-l] wikipedia is one of the slower sites on the web

> That's what he did. Read the query. ;-) thats what happens when email gets ahead of coffee. Domas ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] wikipedia is one of the slower sites on the web

Hi! > I.e., only about a quarter of users have been ported to > user_properties. Why wasn't a conversion script run here? In theory if all properties are at defaults, user shouldn't be there. The actual check should be against the blob field. Domas _

Re: [Wikitech-l] Caching, was: Re: wikipedia is one of the slower sites on the web

Hi! Do note, once you log out, you still have a cookie that prohibits edge caching, I think ;-) > My browser, while reloading, Don't hit "reload" button, thats what it does - reloads all assets. > bits.wikimedia.org then again and then again here and there needed > time to reload a simp

[Wikitech-l] Caching, was: Re: wikipedia is one of the slower sites on the web

Hi! >> That's pretty much the purpose of the caching servers. > > Yes, but I presume that a big advantage could come from having a > simplified, unique, js-free version of the pages online, completely devoid > of "user preferences" to avoid any need to parse it again when uploaded by > differen

Re: [Wikitech-l] wikipedia is one of the slower sites on the web

> This is probably a bad thing. I'd think that most of the settings > that fragment the parser cache should be implementable in a > post-processing stage, which should be more than fast enough to run on > parser cache hits as well as misses. But we don't have such a thing. some of which can be e

Re: [Wikitech-l] wikipedia is one of the slower sites on the web

> Could you please elaborate on that? Thanks. we don't have large blinking red lights when people deviate with their parser cache settings - that makes them miss the cache and each pageview is slow. Domas ___ Wikitech-l mailing list Wikitech-l@lists.w

Re: [Wikitech-l] collab.wikimedia db error in many tools

Hello, > collab.wikimedia db error in many tools. > like luxo's tool, vvv;s sulutil. Thats so sad. It is really depressing, that even after I explained you on IRC (when you were reporting toolserver issue on #wikimedia-tech) that private wikis are not supposed to be exposed to toolserver users,

Re: [Wikitech-l] Architectural revisions to improve category sorting

Hi! > No doubt Domas will complain anyway, but without developers adding new > features, I figure his volunteer DBA work would get very boring. I don't complain about well designed features, especially if they don't scan millions of rows to return 0 ;-) Domas ___

Re: [Wikitech-l] developer

Hi! > It's for Wikimedia operations as well as MediaWiki development. The > latter tends to take up much more of the list traffic in practice, > though. Indeed, staff-ization of WMF made more and more of communications internal, for better or worse. Domas __

Re: [Wikitech-l] Adding fields to the interwiki table

> You're right. But centralizing this sort of thing makes long term > planning for that sort of thing easier. And by putting it in core you > get more eyes on it and hopefully more people caring :) Well, it doesn't matter where these things are, in core, or externally - in both cases people ignore

Re: [Wikitech-l] Adding fields to the interwiki table

Hi! I somewhat didn't jump here, as we simply don't use interwiki table on WMF sites, so the topic was out of interest. :) > It seems to me that if we want to modify the core to support interwiki > integration, there are any number of core tables that could benefit from DB > name fields. I perso

Re: [Wikitech-l] On proper sorting using CLDR

> > That could even be done internally. Indeed, for some languages sortkeys can be implicitly populated with certain rules applied on text. Unfortunately that would target category sorting only, and not other lists ( pagelinks, templatelinks, users, etc ;) Oh well. This is a difficult topic :)

[Wikitech-l] On proper sorting using CLDR (was: varchar(255) binary in tables.sql)

Hi! > Yes it is a technical pain in the arse.The question is one of primacy. Is it > more important to provide service or are technical considerations of the > most importance. Yes, we discussed this in the past and we did not agree > then and we do not agree now. Well, I agree that it might be g

Re: [Wikitech-l] varchar(255) binary in tables.sql

Hello, On Jun 8, 2010, at 11:22 PM, Gerard Meijssen wrote: > The difference is that is actually does sort according to the CLDR.. It > would be really nice if we did that. It does not, it sorts according to the partial UCA implementation. We have discussed CLDR in the past - it is a huge colle

Re: [Wikitech-l] Fixme, please fix me!

> That isn't a good thing. Why not? ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] wikistats earlier files

Hi! > I have uploaded them to the Internet Archive. > The oldest one is > http://www.archive.org/details/wikipedia_visitor_stats_200712 Lars, thanks - awesome job. Did you get any automated way to do it? Maybe we could just send to archive.org directly? Domas ___

Re: [Wikitech-l] WMF decommissions servers

Hi, > No. There are far more articles created every day than are deleted. > These servers have just been replaced by newer models. The total > number of servers keeps increasing, but there are always going to be > old servers that aren't worth the costs to keep running. at least the crazy growth

Re: [Wikitech-l] modernizing mediawiki

Hi! > A lot of the replies were helpful, in particular Ryan Lane and Yaron's > replies. Also made a quick reply to Domas. Replies are good! > Overall it's awesome no doubt (otherwise I wouldn't have used it in the first > place), but a few of the practices (i.e. editing localsettings file thro

Re: [Wikitech-l] hiphop progress

Jared, > assert(hash('adler32', 'foo', true) === mhash(MHASH_ADLER32, 'foo')); Thanks! Would get to that eventually, I guess. Still, there's xdiff and few other things. Domas ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wik

Re: [Wikitech-l] modernizing mediawiki

Hi! > The Wikimedia Foundation makes millions more than Wordpress, but the > Foundation is running a top 5 website. wordpress.com is in top20 too :) Domas ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/

Re: [Wikitech-l] modernizing mediawiki

Hi! > I hope I am emailing this to the right group. My concern was about mediawiki > and it's limitations, as well as it's outdated methods. As someone wo runs a > wiki, I've gone through a lot of frustrations. Very sad to hear that! > Mediawiki makes millions more than Wordpress does too Hah

Re: [Wikitech-l] hiphop progress

Howdy, > Looks like a loot of fun :-) Fun enough to have my evenings and weekends on it :) > this smell like something that can benefict from metadata. > /* [return integer] */ function getApparatusId($obj){ > //body > } Indeed - type hints can be quite useful, though hiphop is smart enough

[Wikitech-l] hiphop progress

Howdy, > Most of the code in MediaWiki works just fine with it (since most of > it is mundane) but things like dynamically including certain files, > declaring classes, eval() and so on are all out. There're two types of includes in MediaWiki, ones I fixed for AutoLoader and ones I didn't - HPHP

Re: [Wikitech-l] hiphop! :)

> > Nevertheless - a process isn't the same process when it's going at 10x > the speed. This'll be interesting. not 10x. I did concurrent benchmarks for API requests (e.g. opensearch) on modern boxes, and saw: HipHop: Requests per second:1975.39 [#/sec] (mean) Zend: Requests per second:

Re: [Wikitech-l] hiphop! :)

Hi! > For those of us not familiar with MediaWiki benchmarking, what kind of > times were you getting without hiphop? Zend: > Domas, how much hacking did you have to do to MediaWiki to get it to > compile in Hiphop? Lots. I'm trying to get basic functionality/prototypes work. Some changes had

[Wikitech-l] hiphop! :)

r...@flack:/hiphop/web/phase3/includes# ab -n 100 -c 1 'http://dom.as:8085/phase3/api.php?action=query&prop=info&titles=Main%20Page' This is ApacheBench, Version 2.3 <$Revision: 655654 $> Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/ Licensed to The Apache Software Fou

Re: [Wikitech-l] User-Agent:

> is false. (As near as I can tell, the header is required only > for those requests that include an "action=" modifier.) wrong. "all uncached or uncacheable requests" would probably be more true version of it :) Domas ___ Wikitech-l mailing list Wik

Re: [Wikitech-l] User-Agent:

> > It showed that there was quite a bit of bathwater thrown out. And at least > one very large baby (Google translation), which was temporarily > resurrected. We still don't know how many other, smaller, babies were > thrown out, and likely never will. I'm pretty sure, that at least 99.9% of t

Re: [Wikitech-l] User-Agent:

Hi! > 1) Only if you've already identified the spammer through some other process > (otherwise, you don't even know if they're using automated software). You probably don't get scale of wikipedia or scale of the behavior we had to deal with, if you think that it isn't possible to notice behavior

Re: [Wikitech-l] User-Agent:

Robert, > The current English error message text that I see from Python reads: our error message system became overkill, with all those nice designs and multiple languages. in certain cases serving that message too certain requests caused gigabits of bandwidth. it is also not practical to updat

Re: [Wikitech-l] User-Agent:

Anthony, >> Yes, we will ban all IPs participating in this. > Guess it's just a matter of time until *reading* Wikipedia is unavailable to > large portions of the world. Your insight is entirely bogus here. > And "Mozilla/4.0 (compatible; MSIE 7.0; Windows NT >

  1   2   3   >