[Wikitech-l] 中絶薬RU486,即日発送ヤマトで一日か二日で届ける

[wikitech-l]

メーカ定価：23800円　当店4000円割引します、　お買徳：19800円
☆二種類を使いペニス増大効果100％
☆勃起難しく、より頑丈で、より強力な
☆射精のコントロールがより快適に、楽しく、任意の操作です
☆より強い性的快感、欲望とオーガズム二重刺激
☆以上の射精量は、量と精子の質を向上させる 
新豪華ProExtender?ペニス増大キット   http://www.chinaokjapan.com/list_7929.asp   
メイルエッジ BASIC  お買徳：18000円  http://www.jpyebay.com/List_7900.asp  
 新ジェスエクステンダーＤＸキット お買徳：17800円 
☆グローバルな販売タイトル、レコード190カ国、販売レコードの9200受益者
☆勃起硬度、性的快感、精液の質、セックス時間、男性も魅力を高めるために
☆12の特許は、ヨーロッパの健康証明書は、世界保健協会の男性をお勧めします
☆陰茎の機能不全と弯曲の根本的な改善を
☆副作用なし☆安全性は、成長を支えて、トップ29の先進国は、医療の専門家が同意尊重
☆世界初の、20年の臨床試験で、すべての陰茎の拡大製品の効果を最も重要
http://ejapanes.com/list_4566.asp 6800円 VigRx Oil(ビグレックス オイル) 30ml/1瓶
http://ejapanes.com/List_7274.asp 　1880円 ドイツGOOZ14000 ドーズスプレー(赤)45mL 

激┃　　安┃　　卸┃　　特┃　　　価┃ 
━┛　　━┛　　━┛　　━┛　　　━┛ 
http://ejapanes.com/list_4205.asp 1990円 蟻力神 イーリーシン2錠入×5箱
http://ejapanes.com/List_7901.asp 2100円 勃大精生男根増大カプセル2錠×3箱（6錠入り） 
http://ejapanes.com/list_4909.asp 8800円 中絶薬RU486(北京紫竹)のru486 販売,安心輸入、
RU486,即日発送ヤマトで一日か二日で届ける
http://ejapanes.com/List_6786.asp 1950円 FITXスーパー脂肪解消カプセル１箱60錠（第4世代）
http://ejapanes.com/List_6863.asp 1000円 終極痩身カプセル10錠/箱
http://ejapanes.com/list_4839.asp 6980円ペニス貞操帯ＣＢ4000(男性専用！)Ｂｉｇサイズ
E-mailでご注文の場合は商品番号、商品名称、購入数量、お名前、ご住所、電話番号、
メールアドレスなどを明記の上ご注文くださいhttp://ejapanes.com/shopping.asp へ送信してください。
 
悦可亭 - 長期経口避妊薬（ピル１ヶ月避妊）  http://japanjpy.com/YueKeTing.htm 
北京紫竹 RU486四点システムとは http://jpyjapan.com/ru486_NewIndex.htm
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] Doxygen tags - a proposal

[Ori Livneh]

Earlier this evening I found myself gawking at a strange confusion of
letters and symbols that had appeared in my editor. What are these symbols,
and where do they come from? What secret geometry governs their
arrangement? Just what is this, anyway? I sat and stared, perplexed. The
symbols stared back.

Soon my eyes adjusted to the strange contours of the glyphs, and I began to
perceive a kind of rhythm or a structure to their ordering. Finally, I lit
upon this enchanted hieroglyph:

@file

Of course! That's what this is -- a file! I wept with joy, and my heart
soared with gratitude for this humble Doxygen tag, without which the
ontology of our source code would be occult and irretrievable.

But soon my rapture gave way to creeping doubts: could we not, after all,
do better?

I went to the drawing board. After several iterations (all agile,
naturally), I came up with two tags that I think are very fine and that I'd
like to see us adopt. Consider them:

@tag

This tag denotes a Doxygen tag. Like '@file', it answers the question,
"What is this?". Answer: it is a Doxygen tag. It is not a banana. A car
part, neither. If you thought it was a ceiling fan or a Python decorator,
you were wrong -- dead wrong. Because it is a Doxygen tag.

@comment

This tag denotes a comment. It precisely identifies the purpose and
discourse of the text which surrounds it. It tells you, "There is wisdom
here. Stay a while and listen."

Here is a sample file header, demonstrating proper usage of these tags:

/**
 * Example
 * This file represents an example.
 *
 * @file
 * @ingroup examples
 * @comment
 * @tag
 */

The syntax is economical and expressive; the meaning eloquent and germane.

What do you think? Don't worry about the HTML representation for now -- we
can worry about those later.

---
Ori Livneh
o...@wikimedia.org
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Doxygen tags - a proposal

[Daniel Friesen]

On Sat, 08 Jun 2013 00:42:40 -0700, Ori Livneh  wrote:


/**
 * Example
 * This file represents an example.
 *
 * @file
 * @ingroup examples
 * @comment
 * @tag
 */


Uhh, what extra meaning are @comment and @tag supposed to suggest?

@file already indicates that this comment block defines metadata and  
details about the whole file.




---
Ori Livneh
o...@wikimedia.org


--
~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://danielfriesen.name/]


___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] migrating hooks doc to doxygen?

[S Page]

This is great. I think building HTML from source files is the way to go for
dry reference material like this.

You need links both ways so people know the other format is available.  The
hooks.txt should say "The documentation at
https://doc.wikimedia.org/mw-hooks/hooks_mainpage.htmlis regularly
generated from the master branch of the gerrit repository."

If mediawiki.org's extension template linked "hooks in use" to this doc
instead of mediawiki.org/Hooks:xyz pages then we could retire the latter
pages and have less stuff to maintain.
Except...

* It's sometimes useful that the Hooks pages are searchable along with the
rest of the documentation on mediawiki.org.

* The mw.org hooks pages have additional information. E.g. comparing
https://doc.wikimedia.org/mw-hooks/page_hooks_list.html#UserCreateForm and
http://www.mediawiki.org/wiki/Manual:Hooks/UserCreateForm , the mw.org page
has
** version = 1.6.0
** source = SpecialUserlogin.php
** These categorize it as [Hooks added in MediaWiki 1.6.0]
and [MediaWiki hooks included in SpecialUserlogin.php]

If we add this information to hooks.txt maybe there's a way doxygen can
show the information and produce tables similar to the categories.

- The hooks are documented in a separate file (still docs/hooks.txt),
> when we might want to have the doc near the wfRunHooks() call.
>

Hmm. On the one hand if they're all in one place it's easier to do
cargo-cult pattern matching when adding new hook documentation.  But if the
doc is in the PHP near the wfRunHooks call it's more likely people will
update it when making changes.

Now that we have mw.hook() in JavaScript we have a second universe of hooks
to think about :)

-- 
=S Page  software engineer on Editor Engagement Experiments
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Doxygen tags - a proposal

[S Page]

Perhaps Ori is pointing out that doxygen (and jsduck) require needless
verbiage. The tools aren't smart enough to infer obvious information from
source on their own (or maybe they are but you're not sure and you see
other comments using these symbols so you copy and paste), so you wind up
repeating information in "doc generation syntax".

And to what end?  I view doxygen as an external test that we're being
consistent in comments (quick, is it @param String $mystr  or @param $myStr
{string}  ?) but I never actually refer to the generated output. Does
anyone? Until someone builds a browser bridge that automatically scrolls
the right HTML into view as you move around in your editor and
automatically regenerates the HTML as you type, I don't see my habits
changing.

If web search engines could understand the generated documentation and
ranked it higher in search results it would be more useful and used more.
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] [tool labs] central logging service

[Petr Bena]

Hi,

per https://bugzilla.wikimedia.org/show_bug.cgi?id=48846 we are
setting up a logging service for tools and bots, so that every tool or
bot can easily log to a central logging base which in future should
support some nice web-based gui with log filtering (eventually some
3rd notifications, like e-mails (sms) / irc pings) and so on.

The website of this project is here: http://tools.wmflabs.org/logs/

I haven't got much feedback so far so I would appreciate some, in this
moment we are in phase where we are discussing the best options how to
design this feature.

Some people believe that it would be best to use some already existing
logging service such as facebook's scribe, I /think/ that despite the
already made and working solution might be a good idea, on other hand
these usually were designed for another purpose than what we need and
thus it's quite complicated to set them up for our needs. Having said
that I started working on simple, but powerful logging daemon which
should do precisely what we need (and which can be infinitely extended
for our purposes) - but of course we can set up multiple solutions and
let tool operators pick what they prefer most.

If it's simpler for a tool / bot operator to intergrate with syslog,
then why we shouldn't have it as well? But I must admit I found it
quite complicated to make rsyslog behave as we need (I believe it's
not even possible for it to match all out potential needs)

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] migrating hooks doc to doxygen?

[Daniel Friesen]

On Sat, 08 Jun 2013 01:09:26 -0700, S Page  wrote:


If mediawiki.org's extension template linked "hooks in use" to this doc
instead of mediawiki.org/Hooks:xyz pages then we could retire the latter
pages and have less stuff to maintain.


MediaWiki.org doesn't have //mediawiki.org/Hooks:xyz pages, it has  
//mediawiki.org/wiki/Manual:Hooks/xyz... ;) but I wouldn't be opposed to  
creating a dedicated /mediawiki.org/wiki/Hook:xyz namespace.



Except...

* It's sometimes useful that the Hooks pages are searchable along with  
the

rest of the documentation on mediawiki.org.

* The mw.org hooks pages have additional information. E.g. comparing
https://doc.wikimedia.org/mw-hooks/page_hooks_list.html#UserCreateForm  
and
http://www.mediawiki.org/wiki/Manual:Hooks/UserCreateForm , the mw.org  
page

has
** version = 1.6.0
** source = SpecialUserlogin.php
** These categorize it as [Hooks added in MediaWiki 1.6.0]
and [MediaWiki hooks included in SpecialUserlogin.php]

If we add this information to hooks.txt maybe there's a way doxygen can
show the information and produce tables similar to the categories.


There are other things the hooks pages have that hooks.txt doesn't and may  
never:
* Some of them have extra documentation and more details than what we can  
simply fit into hooks.txt:  
https://www.mediawiki.org/wiki/Manual:Hooks/PersonalUrls
* Hooks pages document all hooks past and present with information on when  
hooks are removed and references to their replacements. Auto-generated  
hooks documentation however generally just makes said hook documentation  
disappear when we naturally remove it from the software.



To be clear I'm not really in favor of moving more things to our doxygen  
setup. Quite frankly I haven't met a single person who's said they  
actually used the Doxygen documentation. Most new devs likely don't even  
know it exists. And I'd bet many core devs are just like me and instead of  
opening up Doxygen we just quickly open the relevant php file and read the  
documentation comment raw.


I find the Doxygen documentation to be hard to navigate, slow, and  
extremely disorganized.
I also do not expect the visual disconnect of leaving the MediaWiki.org  
site and the MW UI and then landing on Doxygen's own custom style will be  
helpful at all to the user.
The search bar is so recluse-ly tucked away that I've never attempted  
using it. And as expected typing "User" into it wasn't very helpful at all.


The hooks pages on the other hand. Even I've used once or twice. And I'll  
admit I've had to fix some and felt others needed work. But automating  
away from them is probably the wrong way to do things.


Frankly I think we should try automating stuff towards our wiki rather  
than using it as a way to take stuff out. Find ways to integrate this data  
automatically into parts of the wiki. Bots if you ABSOLUTELY need to. But  
preferably instead extensions and Lua stuff. Things that provide the data  
in ways they can be incorporated into wiki pages. Keep wiki pages up to  
date. Show full UIs, etc... on special pages and dedicated namespaces. And  
ideally, be integrated right into the search.


Speaking of search there's something that's been bothering be for awhile.  
The Extension:, Skin:, and API: namespaces aren't part of our default  
search namespaces. A chunk of information about the stuff people come to  
the wiki for isn't even easily searchable.




- The hooks are documented in a separate file (still docs/hooks.txt),

when we might want to have the doc near the wfRunHooks() call.



Hmm. On the one hand if they're all in one place it's easier to do
cargo-cult pattern matching when adding new hook documentation.  But if  
the

doc is in the PHP near the wfRunHooks call it's more likely people will
update it when making changes.


Hooks can be run from more than one location. I know the skin system has a  
few of those and I wouldn't be surprised if this was true of other parts  
of core and extensions even too.
They are also run inline where a lot of other code is going on. Breaking  
that complicated method flow with a huge hook documentation comment really  
doesn't sound like a good idea.


So I don't think inline hook documentation is a good idea, it's best to  
stick with a common location.



--
~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://danielfriesen.name/]


___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] [tool labs] central logging service

[Petr Bena]

Using this service is as easy as typing

pyhon bot.py | /shared/logeater mybot

given that a bot is sending out log to stdout it will be stored at
http://tools.wmflabs.org/logs/data/mybot


The service of course support many other ways to store logs, but this
is a simplest example I can think of :)

On Sat, Jun 8, 2013 at 10:44 AM, Petr Bena  wrote:
> Hi,
>
> per https://bugzilla.wikimedia.org/show_bug.cgi?id=48846 we are
> setting up a logging service for tools and bots, so that every tool or
> bot can easily log to a central logging base which in future should
> support some nice web-based gui with log filtering (eventually some
> 3rd notifications, like e-mails (sms) / irc pings) and so on.
>
> The website of this project is here: http://tools.wmflabs.org/logs/
>
> I haven't got much feedback so far so I would appreciate some, in this
> moment we are in phase where we are discussing the best options how to
> design this feature.
>
> Some people believe that it would be best to use some already existing
> logging service such as facebook's scribe, I /think/ that despite the
> already made and working solution might be a good idea, on other hand
> these usually were designed for another purpose than what we need and
> thus it's quite complicated to set them up for our needs. Having said
> that I started working on simple, but powerful logging daemon which
> should do precisely what we need (and which can be infinitely extended
> for our purposes) - but of course we can set up multiple solutions and
> let tool operators pick what they prefer most.
>
> If it's simpler for a tool / bot operator to intergrate with syslog,
> then why we shouldn't have it as well? But I must admit I found it
> quite complicated to make rsyslog behave as we need (I believe it's
> not even possible for it to match all out potential needs)

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] [tool labs] central logging service

[Ori Livneh]

On Sat, Jun 8, 2013 at 1:44 AM, Petr Bena  wrote:

> Hi,
>
> per https://bugzilla.wikimedia.org/show_bug.cgi?id=48846 we are
> setting up a logging service for tools and bots, so that every tool or
> bot can easily log to a central logging base which in future should
> support some nice web-based gui with log filtering (eventually some
> 3rd notifications, like e-mails (sms) / irc pings) and so on.
>
> The website of this project is here: http://tools.wmflabs.org/logs/
>
> I haven't got much feedback so far so I would appreciate some, in this
> moment we are in phase where we are discussing the best options how to
> design this feature.
>

What does the 's' prefix mean?

What is the expected character encoding of messages?

How is malformed input handled? What happens if I log this message: "s test
0 hi\ns fake_tool 0 evil_message\n"?

If I don't terminate my message with a newline, does my message swallow the
next one to come along?

How would you go about adding a field, if you discovered you needed one?
Would clients using the old format break?

How reliable does the service need to be? What is the cost of an outage? Is
it OK for the service to be down for a few hours?



>
> Some people believe that it would be best to use some already existing
> logging service such as facebook's scribe, I /think/ that despite the
> already made and working solution might be a good idea, on other hand
> these usually were designed for another purpose than what we need and
> thus it's quite complicated to set them up for our needs. Having said
> that I started working on simple, but powerful logging daemon which
> should do precisely what we need (and which can be infinitely extended
> for our purposes) - but of course we can set up multiple solutions and
> let tool operators pick what they prefer most.
>

I think your intuitions are good. Everyone has their favorite message
queue, but most are quite complex. "Simple" and "adequate" are the virtues
you should optimize for.

Get input from some early adopters of your service, then iterate. Let
people know that the service is experimental for now, so that you have
plenty of room to change the protocol if you need to. If you find yourself
adding feature after feature, stop, and reconsider existing solutions.


> If it's simpler for a tool / bot operator to intergrate with syslog,
> then why we shouldn't have it as well? But I must admit I found it
> quite complicated to make rsyslog behave as we need (I believe it's
> not even possible for it to match all out potential needs)
>
> ___
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] [tool labs] central logging service

[Petr Bena]

Replies bellow

On Sat, Jun 8, 2013 at 11:58 AM, Ori Livneh  wrote:
> On Sat, Jun 8, 2013 at 1:44 AM, Petr Bena  wrote:
>
>> Hi,
>>
>> per https://bugzilla.wikimedia.org/show_bug.cgi?id=48846 we are
>> setting up a logging service for tools and bots, so that every tool or
>> bot can easily log to a central logging base which in future should
>> support some nice web-based gui with log filtering (eventually some
>> 3rd notifications, like e-mails (sms) / irc pings) and so on.
>>
>> The website of this project is here: http://tools.wmflabs.org/logs/
>>
>> I haven't got much feedback so far so I would appreciate some, in this
>> moment we are in phase where we are discussing the best options how to
>> design this feature.
>>
>
> What does the 's' prefix mean?
>

it is shortcut for "store"

you can either type

s ...
or
store ...

it will do same, or you can use "n" (noreply) that will do same as s
or store but will send no reply on success

> What is the expected character encoding of messages?
>

You got me. I have no idea, either mono is smart enough to find out or
it's uses some standard encoding by default, like utf-8 or unicode? I
will find out. Google doesn't bring clear answer.

> How is malformed input handled? What happens if I log this message: "s test
> 0 hi\ns fake_tool 0 evil_message\n"?
>

malformed (invalid) input gets response ERROR: 

malformed (malicious) input is something I am still thinking of, I
don't expect many users to intentionally break logs of others, but I
am thinking of implementing optional authentication. If tool requested
to use authentication (it would subscribe / register a folder somehow)
it could for example get a temporary token that would stored somewhere
like /data/project/logs/tokens/tool and which would be readable only
by tool account.

This token would be updated periodically for security reasons and tool
would be required to provide it together with log message in order to
write to its folder.

But this is something I am still designing and I want to keep it
opt-in as it complicate stuff and many users will likely not require
it. Also we are getting far beyond possibilities of rsyslog now
(another reason why using own daemon could be better).

> If I don't terminate my message with a newline, does my message swallow the
> next one to come along?
>

I forgot to mention newline isn't required in UDP connection. You can
send multiple log lines using newline or just 1 line and it will be
parsed.

If you terminate TCP connection before writing newline (which means -
buffer is finished, store it - to daemon), it will be likely dropped
(you won't get the STORED response either).

> How would you go about adding a field, if you discovered you needed one?
> Would clients using the old format break?
>

What kind of field do you mean?

> How reliable does the service need to be? What is the cost of an outage? Is
> it OK for the service to be down for a few hours
>

It's not OK for it to be down for few hours, however the clients
should be able to recognize the server is down if they are using tcp
(because they won't be able to connect).

The wrapper script I made now (logeater) should be optimized to
recognize this as well and keep retrying until successful or
something. Outage is always a problem for any kind of logger.

>
>
>>
>> Some people believe that it would be best to use some already existing
>> logging service such as facebook's scribe, I /think/ that despite the
>> already made and working solution might be a good idea, on other hand
>> these usually were designed for another purpose than what we need and
>> thus it's quite complicated to set them up for our needs. Having said
>> that I started working on simple, but powerful logging daemon which
>> should do precisely what we need (and which can be infinitely extended
>> for our purposes) - but of course we can set up multiple solutions and
>> let tool operators pick what they prefer most.
>>
>
> I think your intuitions are good. Everyone has their favorite message
> queue, but most are quite complex. "Simple" and "adequate" are the virtues
> you should optimize for.
>
> Get input from some early adopters of your service, then iterate. Let
> people know that the service is experimental for now, so that you have
> plenty of room to change the protocol if you need to. If you find yourself
> adding feature after feature, stop, and reconsider existing solutions.
>
>
>> If it's simpler for a tool / bot operator to intergrate with syslog,
>> then why we shouldn't have it as well? But I must admit I found it
>> quite complicated to make rsyslog behave as we need (I believe it's
>> not even possible for it to match all out potential needs)
>>
>> ___
>> Wikitech-l mailing list
>> Wikitech-l@lists.wikimedia.org
>> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
> ___
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> ht

Re: [Wikitech-l] 中絶薬RU486,即日発送ヤマトで一日か二日で届ける

[Yusuke Matsubara]

To anyone wondering, this is simply a spam written in Japanese and can
be safely ignored/deleted.

-Yusuke / [[User:Whym]]

2013/6/8  :
> メーカ定価：23800円　当店4000円割引します、　お買徳：19800円
> ☆二種類を使いペニス増大効果100％
> ☆勃起難しく、より頑丈で、より強力な
> ☆射精のコントロールがより快適に、楽しく、任意の操作です
> ☆より強い性的快感、欲望とオーガズム二重刺激
> ☆以上の射精量は、量と精子の質を向上させる
> 新豪華ProExtender?ペニス増大キット   http://www.chinaokjapan.com/list_7929.asp
> メイルエッジ BASIC  お買徳：18000円  http://www.jpyebay.com/List_7900.asp
>  新ジェスエクステンダーＤＸキット お買徳：17800円
> ☆グローバルな販売タイトル、レコード190カ国、販売レコードの9200受益者
> ☆勃起硬度、性的快感、精液の質、セックス時間、男性も魅力を高めるために
> ☆12の特許は、ヨーロッパの健康証明書は、世界保健協会の男性をお勧めします
> ☆陰茎の機能不全と弯曲の根本的な改善を
> ☆副作用なし☆安全性は、成長を支えて、トップ29の先進国は、医療の専門家が同意尊重
> ☆世界初の、20年の臨床試験で、すべての陰茎の拡大製品の効果を最も重要
> http://ejapanes.com/list_4566.asp 6800円 VigRx Oil(ビグレックス オイル) 30ml/1瓶
> http://ejapanes.com/List_7274.asp　 1880円 ドイツGOOZ14000 ドーズスプレー(赤)45mL
>
> 激┃　　安┃　　卸┃　　特┃　　　価┃
> ━┛　　━┛　　━┛　　━┛　　　━┛
> http://ejapanes.com/list_4205.asp 1990円 蟻力神 イーリーシン2錠入×5箱
> http://ejapanes.com/List_7901.asp 2100円 勃大精生男根増大カプセル2錠×3箱（6錠入り）
> http://ejapanes.com/list_4909.asp 8800円 中絶薬RU486(北京紫竹)のru486 販売,安心輸入、
> RU486,即日発送ヤマトで一日か二日で届ける
> http://ejapanes.com/List_6786.asp 1950円 FITXスーパー脂肪解消カプセル１箱60錠（第4世代）
> http://ejapanes.com/List_6863.asp 1000円 終極痩身カプセル10錠/箱
> http://ejapanes.com/list_4839.asp 6980円ペニス貞操帯ＣＢ4000(男性専用！)Ｂｉｇサイズ
> E-mailでご注文の場合は商品番号、商品名称、購入数量、お名前、ご住所、電話番号、
> メールアドレスなどを明記の上ご注文くださいhttp://ejapanes.com/shopping.asp へ送信してください。
>
> 悦可亭 - 長期経口避妊薬（ピル１ヶ月避妊）  http://japanjpy.com/YueKeTing.htm
> 北京紫竹 RU486四点システムとは http://jpyjapan.com/ru486_NewIndex.htm
> ___
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] migrating hooks doc to doxygen?

[Raylton P. Sousa]

I've used (and use) doxygen+txt+mediawiki and was very helpful(still
include myself in new dev).

But, on the other hand, in the hooks (without doxygen), I always had
trouble knowing when and where it is loaded. And it is always hard to
figure out which one to use.

Probably a newbie problem, but since we are talking about this. I decided
to say.


2013/6/8 Daniel Friesen 

> On Sat, 08 Jun 2013 01:09:26 -0700, S Page  wrote:
>
>  If mediawiki.org's extension template linked "hooks in use" to this doc
>> instead of mediawiki.org/Hooks:xyz pages then we could retire the latter
>> pages and have less stuff to maintain.
>>
>
> MediaWiki.org doesn't have //mediawiki.org/Hooks:xyz pages, it has //
> mediawiki.org/wiki/Manual:**Hooks/xyz...
> ;) but I wouldn't be opposed to creating a dedicated /
> mediawiki.org/wiki/Hook:xyz namespace.
>
>
>  Except...
>>
>> * It's sometimes useful that the Hooks pages are searchable along with the
>> rest of the documentation on mediawiki.org.
>>
>> * The mw.org hooks pages have additional information. E.g. comparing
>> https://doc.wikimedia.org/mw-**hooks/page_hooks_list.html#**
>> UserCreateFormand
>> http://www.mediawiki.org/wiki/**Manual:Hooks/UserCreateForm,
>>  the
>> mw.org page
>> has
>> ** version = 1.6.0
>> ** source = SpecialUserlogin.php
>> ** These categorize it as [Hooks added in MediaWiki 1.6.0]
>> and [MediaWiki hooks included in SpecialUserlogin.php]
>>
>> If we add this information to hooks.txt maybe there's a way doxygen can
>> show the information and produce tables similar to the categories.
>>
>
> There are other things the hooks pages have that hooks.txt doesn't and may
> never:
> * Some of them have extra documentation and more details than what we can
> simply fit into hooks.txt: https://www.mediawiki.org/**
> wiki/Manual:Hooks/PersonalUrls
> * Hooks pages document all hooks past and present with information on when
> hooks are removed and references to their replacements. Auto-generated
> hooks documentation however generally just makes said hook documentation
> disappear when we naturally remove it from the software.
>
>
> To be clear I'm not really in favor of moving more things to our doxygen
> setup. Quite frankly I haven't met a single person who's said they actually
> used the Doxygen documentation. Most new devs likely don't even know it
> exists. And I'd bet many core devs are just like me and instead of opening
> up Doxygen we just quickly open the relevant php file and read the
> documentation comment raw.
>
> I find the Doxygen documentation to be hard to navigate, slow, and
> extremely disorganized.
> I also do not expect the visual disconnect of leaving the MediaWiki.org
> site and the MW UI and then landing on Doxygen's own custom style will be
> helpful at all to the user.
> The search bar is so recluse-ly tucked away that I've never attempted
> using it. And as expected typing "User" into it wasn't very helpful at all.
>
> The hooks pages on the other hand. Even I've used once or twice. And I'll
> admit I've had to fix some and felt others needed work. But automating away
> from them is probably the wrong way to do things.
>
> Frankly I think we should try automating stuff towards our wiki rather
> than using it as a way to take stuff out. Find ways to integrate this data
> automatically into parts of the wiki. Bots if you ABSOLUTELY need to. But
> preferably instead extensions and Lua stuff. Things that provide the data
> in ways they can be incorporated into wiki pages. Keep wiki pages up to
> date. Show full UIs, etc... on special pages and dedicated namespaces. And
> ideally, be integrated right into the search.
>
> Speaking of search there's something that's been bothering be for awhile.
> The Extension:, Skin:, and API: namespaces aren't part of our default
> search namespaces. A chunk of information about the stuff people come to
> the wiki for isn't even easily searchable.
>
>
>
>  - The hooks are documented in a separate file (still docs/hooks.txt),
>>
>>> when we might want to have the doc near the wfRunHooks() call.
>>>
>>>
>> Hmm. On the one hand if they're all in one place it's easier to do
>> cargo-cult pattern matching when adding new hook documentation.  But if
>> the
>> doc is in the PHP near the wfRunHooks call it's more likely people will
>> update it when making changes.
>>
>
> Hooks can be run from more than one location. I know the skin system has a
> few of those and I wouldn't be surprised if this was true of other parts of
> core and extensions even too.
> They are also run inline where a lot of other code is going on. Breaking
> that complicated method flow with a huge hook documentation comment really
> doesn't sound like a good idea.
>
> So I don't think inline hook documentatio

Re: [Wikitech-l] Doxygen tags - a proposal

[Brian Wolff]

On 2013-06-08 5:29 AM, "S Page"  wrote:
>
> Perhaps Ori is pointing out that doxygen (and jsduck) require needless
> verbiage. The tools aren't smart enough to infer obvious information from
> source on their own (or maybe they are but you're not sure and you see
> other comments using these symbols so you copy and paste), so you wind up
> repeating information in "doc generation syntax".
>
> And to what end?  I view doxygen as an external test that we're being
> consistent in comments (quick, is it @param String $mystr  or @param
$myStr
> {string}  ?) but I never actually refer to the generated output. Does
> anyone? Until someone builds a browser bridge that automatically scrolls
> the right HTML into view as you move around in your editor and
> automatically regenerates the HTML as you type, I don't see my habits
> changing.
>
> If web search engines could understand the generated documentation and
> ranked it higher in search results it would be more useful and used more.

Thank you for that email Ori. It was beautiful.

To answer S's question - I mostly look at the code, but I do use the html
docs occasionally. I used them quite extensively when I was a newbie first
learning about mediawiki. I also regularly link to them when people in irc
say things like "how do I do x".

-bawolff
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] migrating hooks doc to doxygen?

[Brian Wolff]

>Frankly I think we should try automating stuff towards our wiki rather than 
>using it as a way to
>take stuff out. Find ways to integrate this data automatically into parts of 
>the wiki. Bots if you
>ABSOLUTELY need to. But preferably instead extensions and Lua stuff. Things 
>that provide the
>data in ways they can be incorporated into wiki pages. Keep wiki pages up to 
>date. Show full
>UIs, etc... on special pages and dedicated namespaces. And ideally, be 
>integrated right into
>the search.

I agree 100%. It would be cool if we had a bot auto-update part of
those page (While still allowing users to add info and tips). Maybe
even some sort of parser function to retrieve documentation...

Both Manual:Hooks/foo and all the $wgFoo pages can definitely benefit
from some automation. (Even cooler, would be if we could have
something like Special:Documentation/Linker::link (Before anyone
balks, :: is allowed in special page subpage name), which retrieved
the info from doxygen for that page, as an alternative way to view the
docs).

--bawolff

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] migrating hooks doc to doxygen?

[Brad Jorsch]

On Sat, Jun 8, 2013 at 11:07 AM, Brian Wolff  wrote:
> Both Manual:Hooks/foo and all the $wgFoo pages can definitely benefit
> from some automation.

I know the reason I usually don't update the Manual pages is because by the
time the change gets reviewed and merged, I don't remember anymore that the
change actually requires Manual page updates. I have the same problem with
remembering to close bugs; the automated comments posted to the bug on
merge now often remind me, at least for bugs I'm on the CC list for.

If someone were to write a bot that would comment on the changeset after it
was merged linking to hook and $wgFoo manual pages that probably need
updating, that would serve as a useful reminder.


-- 
Brad Jorsch
Software Engineer
Wikimedia Foundation
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] [RFC] Update our code to use RDFa 1.1 instead of RDFa 1.0

[Daniel Friesen]

On Wed, 08 May 2013 03:52:07 -0700, Daniel Friesen  
 wrote:


I was going through our code contemplating dropping XHTML 1.1 support  
and ran into the RDFa support stuff and realized how out of date and  
limited it is.


I've put together an RFC for replacing our code that appears to be based  
on the RDFa 1.0 from 2008 with RDFa 1.1 and expanding support for RDFa.


https://www.mediawiki.org/wiki/Requests_for_comment/Update_our_code_to_use_RDFa_1.1_instead_of_RDFa_1.0


This -- and more -- in:
https://gerrit.wikimedia.org/r/#/c/63106/

--
~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://danielfriesen.name/]


___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] Fwd: [WikimediaMobile] Number crunching: Upload errors on mobile

[Yuvi Panda]

Since nobody reads mobile-l


-- Forwarded message --
From: Jon Robson 
Date: Sat, Jun 8, 2013 at 4:17 AM
Subject: [WikimediaMobile] Number crunching: Upload errors on mobile
To: mobile-l 


I ran some data crunching on a sample of 4429 photo uploads from
mobile web. In this sample 2821 uploads succeeded and 36% (1608/4429)
of attempted uploads failed. This is very high and unacceptable.

Looking closely 53% of all errors were due to problems with invalid or
'anonymous' tokens. This will occur when the client is unable to get a
token using CORS from Commons due to not being logged in there.
Luckily Chris Steipp and the rest of the platform team have pushed a
change that should significantly reduce this error:
https://gerrit.wikimedia.org/r/#/c/57662/

CentralAuth related errors (861)

Anonymous token. 598
Invalid token 263

The next big offender was 'Missing filename' accounting for 22% of all
upload errors. Unfortunately this is ambiguous as it could mean a
variety of things - it simply means that an upload was attempted and
the response didn't report the filename. I've pushed a patch to try to
understand what errors we are running into:
https://gerrit.wikimedia.org/r/67545

Other errors (467)
###
Missing filename 347
This file did not pass file verification 69
Blank error message given 36
The file you submitted was empty 15

There are various other errors all listed below for your enjoyment.
Some due to bad choices of name, permissions problems and attempts to
upload certain file types we do not accept. The good news is we
probably don't want these uploads to succeed as they hint at vandalism
attempts or uploads by poorly educated users.

The server problems section is worth a look though - although a small
percentage "The modification you tried to make was aborted by an
extension hook 61". These errors are occurring on the following wiki
projects:
* sv.m.wikipedia.org
* de.m.wikipedia.org
* test.m.wikipedia.org
* en.m.wikipedia.org
* ar.m.wikipedia.org
* es.m.wikipedia.org
* ja.m.wikipedia.org
* he.m.wikipedia.org
* fr.m.wikipedia.org
* nl.m.wikipedia.org
Any ideas what may be causing that error?

***
Other errors:

Users uploading with bad or unclear filenames (113)

"titleblacklist-custom-filename" 48
(https://commons.m.wikimedia.org/wiki/Template:Titleblacklist-custom-filename/en)
"titleblacklist-forbidden-edit" 37
(https://en.m.wikipedia.org/wiki/MediaWiki_talk:Titleblacklist-forbidden-edit)
Filename exists 25 (I suspect they used a common filename)
Unknown error: "titleblacklist-custom-double-apostrophe" 3

(Out of interest is there any API to check whether a filename will be accepted?)

Server problems (81):

The modification you tried to make was aborted by an extension hook 61
Database query error 10
An internal error occurred 9
error: Internal Server Error 1

Permission based errors (69)

The "autoconfirmed" right is required to edit this page 36
You have been blocked from editing 25
The "protect" right is required to edit this page 7
Unknown error: "globalblocking-ipblocked" 1

(These users should not be seeing the upload button!)

Users uploading with bad file types (17):
###
Filetype not permitted: MOV 8
Filetype not permitted: webp 4
Filetype not permitted: mp3 3
Filetype not permitted: xml 1
Filetype not permitted: bmp 1

___
Mobile-l mailing list
mobil...@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mobile-l


--
Yuvi Panda T
http://yuvi.in/blog

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Fwd: [WikimediaMobile] Number crunching: Upload errors on mobile

[Brian Wolff]

>
> The server problems section is worth a look though - although a small
> percentage "The modification you tried to make was aborted by an
> extension hook 61". These errors are occurring on the following wiki
> projects:
> * sv.m.wikipedia.org
> * de.m.wikipedia.org
> * test.m.wikipedia.org
> * en.m.wikipedia.org
> * ar.m.wikipedia.org
> * es.m.wikipedia.org
> * ja.m.wikipedia.org
> * he.m.wikipedia.org
> * fr.m.wikipedia.org
> * nl.m.wikipedia.org
> Any ideas what may be causing that error?

I suspect that is caused by UploadBlacklist extension, which
blacklists about 23 files by their sha hash. According to the config
file, there's a log at  "udp://$wmfUdp2logDest/upload-blacklist", so
you can probably check if that guess is right.

--bawolff

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] [tool labs] central logging service

[Tyler Romeo]

Where is the source code for this logging script/software?

*-- *
*Tyler Romeo*
Stevens Institute of Technology, Class of 2016
Major in Computer Science
www.whizkidztech.com | tylerro...@gmail.com


On Sat, Jun 8, 2013 at 6:36 AM, Petr Bena  wrote:

> Replies bellow
>
> On Sat, Jun 8, 2013 at 11:58 AM, Ori Livneh  wrote:
> > On Sat, Jun 8, 2013 at 1:44 AM, Petr Bena  wrote:
> >
> >> Hi,
> >>
> >> per https://bugzilla.wikimedia.org/show_bug.cgi?id=48846 we are
> >> setting up a logging service for tools and bots, so that every tool or
> >> bot can easily log to a central logging base which in future should
> >> support some nice web-based gui with log filtering (eventually some
> >> 3rd notifications, like e-mails (sms) / irc pings) and so on.
> >>
> >> The website of this project is here: http://tools.wmflabs.org/logs/
> >>
> >> I haven't got much feedback so far so I would appreciate some, in this
> >> moment we are in phase where we are discussing the best options how to
> >> design this feature.
> >>
> >
> > What does the 's' prefix mean?
> >
>
> it is shortcut for "store"
>
> you can either type
>
> s ...
> or
> store ...
>
> it will do same, or you can use "n" (noreply) that will do same as s
> or store but will send no reply on success
>
> > What is the expected character encoding of messages?
> >
>
> You got me. I have no idea, either mono is smart enough to find out or
> it's uses some standard encoding by default, like utf-8 or unicode? I
> will find out. Google doesn't bring clear answer.
>
> > How is malformed input handled? What happens if I log this message: "s
> test
> > 0 hi\ns fake_tool 0 evil_message\n"?
> >
>
> malformed (invalid) input gets response ERROR: 
>
> malformed (malicious) input is something I am still thinking of, I
> don't expect many users to intentionally break logs of others, but I
> am thinking of implementing optional authentication. If tool requested
> to use authentication (it would subscribe / register a folder somehow)
> it could for example get a temporary token that would stored somewhere
> like /data/project/logs/tokens/tool and which would be readable only
> by tool account.
>
> This token would be updated periodically for security reasons and tool
> would be required to provide it together with log message in order to
> write to its folder.
>
> But this is something I am still designing and I want to keep it
> opt-in as it complicate stuff and many users will likely not require
> it. Also we are getting far beyond possibilities of rsyslog now
> (another reason why using own daemon could be better).
>
> > If I don't terminate my message with a newline, does my message swallow
> the
> > next one to come along?
> >
>
> I forgot to mention newline isn't required in UDP connection. You can
> send multiple log lines using newline or just 1 line and it will be
> parsed.
>
> If you terminate TCP connection before writing newline (which means -
> buffer is finished, store it - to daemon), it will be likely dropped
> (you won't get the STORED response either).
>
> > How would you go about adding a field, if you discovered you needed one?
> > Would clients using the old format break?
> >
>
> What kind of field do you mean?
>
> > How reliable does the service need to be? What is the cost of an outage?
> Is
> > it OK for the service to be down for a few hours
> >
>
> It's not OK for it to be down for few hours, however the clients
> should be able to recognize the server is down if they are using tcp
> (because they won't be able to connect).
>
> The wrapper script I made now (logeater) should be optimized to
> recognize this as well and keep retrying until successful or
> something. Outage is always a problem for any kind of logger.
>
> >
> >
> >>
> >> Some people believe that it would be best to use some already existing
> >> logging service such as facebook's scribe, I /think/ that despite the
> >> already made and working solution might be a good idea, on other hand
> >> these usually were designed for another purpose than what we need and
> >> thus it's quite complicated to set them up for our needs. Having said
> >> that I started working on simple, but powerful logging daemon which
> >> should do precisely what we need (and which can be infinitely extended
> >> for our purposes) - but of course we can set up multiple solutions and
> >> let tool operators pick what they prefer most.
> >>
> >
> > I think your intuitions are good. Everyone has their favorite message
> > queue, but most are quite complex. "Simple" and "adequate" are the
> virtues
> > you should optimize for.
> >
> > Get input from some early adopters of your service, then iterate. Let
> > people know that the service is experimental for now, so that you have
> > plenty of room to change the protocol if you need to. If you find
> yourself
> > adding feature after feature, stop, and reconsider existing solutions.
> >
> >
> >> If it's simpler for a tool / bot operator to intergrate with syslog,
> >> then why

Re: [Wikitech-l] Doxygen tags - a proposal

[Tyler Romeo]

On Sat, Jun 8, 2013 at 3:42 AM, Ori Livneh  wrote:

> @file
>
> Of course! That's what this is -- a file! I wept with joy, and my heart
> soared with gratitude for this humble Doxygen tag, without which the
> ontology of our source code would be occult and irretrievable.
>

I should note that in MediaWiki's context this tag is useless. Doxygen will
automatically realize that a file comment is a file comment. The actual
purpose of the @file tag is if you have a project where you are
constructing your documentation in a different file than the actual source
code (yes, people do this). In other words, if all of your documentation is
in docs/hello.txt and you want to document another file docs/test.php, then
the @file tag should be used.

 (quick, is it @param String $mystr  or @param $myStr
> {string}  ?)


It is @param [type] $param. I have referred to the output, and it is indeed
different. When Doxygen sees a type, it separates it from the parameter
description and adds styling and whatnot.

*-- *
*Tyler Romeo*
Stevens Institute of Technology, Class of 2016
Major in Computer Science
www.whizkidztech.com | tylerro...@gmail.com
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Fwd: [WikimediaMobile] Number crunching: Upload errors on mobile

[Max Semenik]

On 08.06.2013, 21:07 Brian wrote:


> I suspect that is caused by UploadBlacklist extension, which
> blacklists about 23 files by their sha hash. According to the config
> file, there's a log at  "udp://$wmfUdp2logDest/upload-blacklist", so
> you can probably check if that guess is right.

$ grep -v 'MISS' upload-blacklist.log
$

-- 
Best regards,
  Max Semenik ([[User:MaxSem]])


___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Doxygen tags - a proposal

[Matthew Flaschen]

On 06/08/2013 03:42 PM, Tyler Romeo wrote:
> On Sat, Jun 8, 2013 at 3:42 AM, Ori Livneh  wrote:
> 
>> @file
>>
>> Of course! That's what this is -- a file! I wept with joy, and my heart
>> soared with gratitude for this humble Doxygen tag, without which the
>> ontology of our source code would be occult and irretrievable.
>>
> 
> I should note that in MediaWiki's context this tag is useless.

Thanks, edited accordingly:
https://www.mediawiki.org/w/index.php?title=Manual:Coding_conventions/PHP&diff=next&oldid=705147

> It is @param [type] $param. I have referred to the output, and it is indeed
> different. When Doxygen sees a type, it separates it from the parameter
> description and adds styling and whatnot.

Yes, I fixed the coding conventions accordingly a while back.

Matt Flaschen

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l