On 12 March 2012 15:49, Hydriz Wikipedia admin@alphacorp.tk wrote:
Tparis has the full source code of those tools, and looks like he has already brought them up on his own account. See https://toolserver.org/~tparis.
Could we (in general) *please* not do this? If someones tools are important enough to be taken over by someone else, they are most certainly important enough for a multi-maintainer project. In {one month, one year, five years}, Tparis' account will also expire and we will have the same problem all over again.
Best, Merlijn
On Mon, Mar 12, 2012 at 6:59 PM, Merlijn van Deen valhallasw@arctus.nl wrote:
On 12 March 2012 15:49, Hydriz Wikipedia admin@alphacorp.tk wrote:
Tparis has the full source code of those tools, and looks like he has already brought them up on his own account. See https://toolserver.org/~tparis.
Could we (in general) *please* not do this? If someones tools are important enough to be taken over by someone else, they are most certainly important enough for a multi-maintainer project. In {one month, one year, five years}, Tparis' account will also expire and we will have the same problem all over again.
Best, Merlijn
Toolserver-l mailing list (Toolserver-l@lists.wikimedia.org) https://lists.wikimedia.org/mailman/listinfo/toolserver-l Posting guidelines for this list: https://wiki.toolserver.org/view/Mailing_list_etiquette
That's a good point not to do this ever more. But then we are about to return to the stable toolserver approach, aren't we? :) By the way there is a sort of bugs in Soxred's tools concerning language code <-> project subdomain conversion which I would like to fix or at least report them (I can remind that I've already done it once in Soxred's googlecode issue tracker).
On 12/03/12 17:05, Paul Selitskas wrote:
That's a good point not to do this ever more. But then we are about to return to the stable toolserver approach, aren't we? :) By the way there is a sort of bugs in Soxred's tools concerning language code <-> project subdomain conversion which I would like to fix or at least report them (I can remind that I've already done it once in Soxred's googlecode issue tracker).
I also saw some code to be fixed. Maybe there should be a path for converting an inactive user into a MMP, and keeping the urls (if he were active, he could add 301s himself).
Hello, At Monday 12 March 2012 17:24:15 DaB. wrote:
Maybe there should be a path for converting an inactive user into a MMP,
a MMP is not for collecting all stuff from a user, but for 1 project (side- projects may be included). So a MMP "Soxred93-old-stuff" is not possible, but a MMP "gradient" would be. The idea behind a MMP is to develop and maintaince a tool (together), and if no member of a MMP are left, anybody can overtake the MMP.
Sincerly, DaB.
If you are pushing for an MMP, it would be best not to use my code. It's shoddy, poorly written, broken, and inefficient. Frankly, I'm amazed it lasted as long as it did.
-X!
On Mar 12, 2012, at 12:05 PM, Paul Selitskas p.selitskas@gmail.com wrote:
On Mon, Mar 12, 2012 at 6:59 PM, Merlijn van Deen valhallasw@arctus.nl wrote:
On 12 March 2012 15:49, Hydriz Wikipedia admin@alphacorp.tk wrote:
Tparis has the full source code of those tools, and looks like he has already brought them up on his own account. See https://toolserver.org/~tparis.
Could we (in general) *please* not do this? If someones tools are important enough to be taken over by someone else, they are most certainly important enough for a multi-maintainer project. In {one month, one year, five years}, Tparis' account will also expire and we will have the same problem all over again.
Best, Merlijn
Toolserver-l mailing list (Toolserver-l@lists.wikimedia.org) https://lists.wikimedia.org/mailman/listinfo/toolserver-l Posting guidelines for this list: https://wiki.toolserver.org/view/Mailing_list_etiquette
That's a good point not to do this ever more. But then we are about to return to the stable toolserver approach, aren't we? :) By the way there is a sort of bugs in Soxred's tools concerning language code <-> project subdomain conversion which I would like to fix or at least report them (I can remind that I've already done it once in Soxred's googlecode issue tracker).
-- З павагай, Павел Селіцкас/Paul Selitskas Wizardist @ Wikimedia projects p.selitskas@gmail.com, +375257408304 Skype: p.selitskas
Toolserver-l mailing list (Toolserver-l@lists.wikimedia.org) https://lists.wikimedia.org/mailman/listinfo/toolserver-l Posting guidelines for this list: https://wiki.toolserver.org/view/Mailing_list_etiquette
On Mon, Mar 12, 2012 at 5:54 PM, Soxred93 soxred93@gmail.com wrote:
If you are pushing for an MMP, it would be best not to use my code. It's shoddy, poorly written, broken, and inefficient. Frankly, I'm amazed it lasted as long as it did.
-X!
Well, it's been working so far.
I'd recommend we do the following: * creating a few MMP projects that cover the tools people use most * make your home directory readable for group 'users' via chmod (except for sensitive files) * watch and see people copy your stuff into the SVN repo for the MMP projects and check them out into the MMP account, and see people open stuff in JIRA and get fixed in svn and pushed live :)
-- Krinkle
On 12/03/12 19:36, Krinkle wrote:
On Mon, Mar 12, 2012 at 5:54 PM, Soxred93 wrote: If you are pushing for an MMP, it would be best not to use my code. It's shoddy, poorly written, broken, and inefficient. Frankly, I'm amazed it lasted as long as it did.
-X!Well, it's been working so far.
I'd recommend we do the following:
- creating a few MMP projects that cover the tools people use most
- make your home directory readable for group 'users' via chmod (except
for sensitive files)
- watch and see people copy your stuff into the SVN repo for the MMP
projects and check them out into the MMP account, and see people open stuff in JIRA and get fixed in svn and pushed live :)
-- Krinkle
It's already user-readable. The only prominent non-readable file is public_html/index.php, and I'm not sure if Peachy/Configs has anything of interest.
So assuming I think the steps would be: - X! reopens his account. - Determine the tools requiring a MMP and migrate to a repository. - Redirect the old urls to the new one.
- Make the best possible code. :)
Given that creating a MMP requires root intervention, and a different ACL, it probably makes sense to use a few broad-scope ones, such as "article related tools".
I'm a bit concerned about the diversity of the tools made by each of us. Almost every user utilises its own library of files for providing a skin, db access... Which make integrating them into something coherent quite hard. These multiple frameworks may also be an effect of the large applications ban.
PS: X!, what are your plans of future? Do you intend to continue maintaining your tools?
Platonides platonides@gmail.com wrote:
[...] I'm a bit concerned about the diversity of the tools made by each of us. Almost every user utilises its own library of files for providing a skin, db access... Which make integrating them into something coherent quite hard. These multiple frameworks may also be an effect of the large applications ban. [...]
I had similar thoughts recently when faced for the n-th time with accessing Wikipedia per MySQL (on the toolserver) or the API (elsewhere) in Perl. It would be nice to have one module with an interface that can be used by Toolserver users and others as well. Skins fall into this category as well: I think most developers could easily adapt their tools to use a centralized skin, but wouldn't bother to implement one by themselves that is accessible and usable.
Tim
Tim Landscheidt wrote:
Platonides platonides@gmail.com wrote:
[...] I'm a bit concerned about the diversity of the tools made by each of us. Almost every user utilises its own library of files for providing a skin, db access... Which make integrating them into something coherent quite hard. These multiple frameworks may also be an effect of the large applications ban. [...]
I had similar thoughts recently when faced for the n-th time with accessing Wikipedia per MySQL (on the toolserver) or the API (elsewhere) in Perl. It would be nice to have one module with an interface that can be used by Toolserver users and others as well. Skins fall into this category as well: I think most developers could easily adapt their tools to use a centralized skin, but wouldn't bother to implement one by themselves that is accessible and usable.
Right. Or if the Toolserver is horribly lagged, switch to the API silently to get the most recent data. I've had similar thoughts.
While we all dream of a world in which there's no duplicated coding effort, the reality of these Toolserver tools is that every developer has a programming language preference. You're Perl, I'm Python, others are PHP. So ultimately, I don't know how much integration there can really be.
Consistent styling (importing a common CSS file) is easy enough, though. As long as, y'know, it isn't ugly. ;-)
MZMcBride
MZMcBride z@mzmcbride.com wrote:
[...] I'm a bit concerned about the diversity of the tools made by each of us. Almost every user utilises its own library of files for providing a skin, db access... Which make integrating them into something coherent quite hard. These multiple frameworks may also be an effect of the large applications ban. [...]
I had similar thoughts recently when faced for the n-th time with accessing Wikipedia per MySQL (on the toolserver) or the API (elsewhere) in Perl. It would be nice to have one module with an interface that can be used by Toolserver users and others as well. Skins fall into this category as well: I think most developers could easily adapt their tools to use a centralized skin, but wouldn't bother to implement one by themselves that is accessible and usable.
Right. Or if the Toolserver is horribly lagged, switch to the API silently to get the most recent data. I've had similar thoughts.
While we all dream of a world in which there's no duplicated coding effort, the reality of these Toolserver tools is that every developer has a programming language preference. You're Perl, I'm Python, others are PHP. So ultimately, I don't know how much integration there can really be.
Well, there are 684 directories in /home, so there will probably be more than one project in Perl, Python or PHP :-).
Even if only for PHP there would be a critical mass, it'd be still useful to Perl, Python and other developers. For example, I think it is a common problem to normalize links - e. g., are "[[Diskussion:ABC_abc#.C3.A4.C3.B6.C3.BC]]" and "[[de:Talk:aBC abc#äöü]]" pointing at the same resource? Most developers start with the easy bits and end up with something that works for most of their use cases, but fails if that line is overstepped (for example "Image:" -> "File:"). If there was an existing module for this, you wouldn't have to think about all the fringe cases yourself, but could base upon the sweat poured by others :-). If Me- diaWiki got updated, you would just have to look at the changes in the PHP module and port them to your language of choice.
Consistent styling (importing a common CSS file) is easy enough, though. As long as, y'know, it isn't ugly. ;-)
AFAICS, common CSS wouldn't be enough for a "consistent" user interface.
Tim
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 13.03.2012 17:05, Tim Landscheidt wrote:
Even if only for PHP there would be a critical mass, it'd be still useful to Perl, Python and other developers. For example, I think it is a common problem to normalize links - e. g., are "[[Diskussion:ABC_abc#.C3.A4.C3.B6.C3.BC]]" and "[[de:Talk:aBC abc#äöü]]" pointing at the same resource? Most developers start with the easy bits and end up with something that works for most of their use cases, but fails if that line is overstepped (for example "Image:" -> "File:"). If there was an existing module for this, you wouldn't have to think about all the fringe cases yourself, but could base upon the sweat poured by others :-). If Me- diaWiki got updated, you would just have to look at the changes in the PHP module and port them to your language of choice.
That is the reason why I occasionally use pywikipedia framework with toolserver tools also... ;) So use the pywikipedia as starting point for such a python library.
+1
Last thing I remember to miss (nice to have) was the toolserver notice [1] or a module to check if a given URL is safe (e.g. no "file:///etc/passwd")
[1] https://wiki.toolserver.org/view/Toolserver_notice
On Wed, Mar 14, 2012 at 9:07 AM, Dr. Trigon dr.trigon@surfeu.ch wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 13.03.2012 17:05, Tim Landscheidt wrote:
Even if only for PHP there would be a critical mass, it'd be still useful to Perl, Python and other developers. For example, I think it is a common problem to normalize links - e. g., are "[[Diskussion:ABC_abc#.C3.A4.C3.B6.C3.BC]]" and "[[de:Talk:aBC abc#äöü]]" pointing at the same resource? Most developers start with the easy bits and end up with something that works for most of their use cases, but fails if that line is overstepped (for example "Image:" -> "File:"). If there was an existing module for this, you wouldn't have to think about all the fringe cases yourself, but could base upon the sweat poured by others :-). If Me- diaWiki got updated, you would just have to look at the changes in the PHP module and port them to your language of choice.
That is the reason why I occasionally use pywikipedia framework with toolserver tools also... ;) So use the pywikipedia as starting point for such a python library.
+1
Last thing I remember to miss (nice to have) was the toolserver notice [1] or a module to check if a given URL is safe (e.g. no "file:///etc/passwd")
At the risk of over-designing, would it be worth to gather language-independent requirements for a module/library, on the toolserver wiki or on meta, and then keep implementations of that standard (yes, I know, "one more standard") available on the toolserver? At the very least, a language-neutral brainstorming might prevent design flaws, especially with database-with-API-fallback in mind.
Magnus
Magnus Manske magnusmanske@googlemail.com wrote:
[...] At the risk of over-designing, would it be worth to gather language-independent requirements for a module/library, on the toolserver wiki or on meta, and then keep implementations of that standard (yes, I know, "one more standard") available on the toolserver? At the very least, a language-neutral brainstorming might prevent design flaws, especially with database-with-API-fallback in mind.
It depends on what you mean by "requirement". Something like "a library *must* provide a function normalizeLink() with these semantics" would probably deter developers from trying to implement it. If on the other hand there was an algorithm "if you want to normalize links, do A, B, C, D and E" and corresponding test cases to check compliance, I think it would be much more inviting.
Tim
On Thu, Mar 15, 2012 at 8:33 PM, Tim Landscheidt tim@tim-landscheidt.de wrote:
It depends on what you mean by "requirement". Something like "a library *must* provide a function normalizeLink() with these semantics" would probably deter developers from trying to implement it. If on the other hand there was an algorithm "if you want to normalize links, do A, B, C, D and E" and corresponding test cases to check compliance, I think it would be much more inviting.
+1. Speaking as a framework developer, build a test case and it shall be done! If the list will allow a shameless self plug, based on this thread I've developed an alpha version of a framework (PHP-only, sorry) that:
a.) supports all actions and queries in the API without any specialized code in the framework b.) supports updates to the API with a simple svn update, and c.) automagically selects a backend (HTTP by default but database server if available) for queries without the need to code for any given environment.
Right now I'm seeing speed increases on the order of 2.5x and am a very happy camper. I've got to make it look all pretty (phpDocumented and such) and fix a couple encapsulation violations in the architecture, but if anyone's interested in betaing it once I can stand others looking at it, let me know! It's possible some bugs aren't going to be found except through actual use cases, encountering things like columns and indexes that don't exist on the Toolserver.
Cheers, -Madman
On 03/15/2012 09:50 PM, [[w:en:User:Madman]] wrote:
On Thu, Mar 15, 2012 at 8:33 PM, Tim Landscheidt tim@tim-landscheidt.de wrote:
It depends on what you mean by "requirement". Something like "a library *must* provide a function normalizeLink() with these semantics" would probably deter developers from trying to implement it. If on the other hand there was an algorithm "if you want to normalize links, do A, B, C, D and E" and corresponding test cases to check compliance, I think it would be much more inviting.
+1. Speaking as a framework developer, build a test case and it shall be done! If the list will allow a shameless self plug, based on this thread I've developed an alpha version of a framework (PHP-only, sorry) that:
a.) supports all actions and queries in the API without any specialized code in the framework b.) supports updates to the API with a simple svn update, and c.) automagically selects a backend (HTTP by default but database server if available) for queries without the need to code for any given environment.
Right now I'm seeing speed increases on the order of 2.5x and am a very happy camper. I've got to make it look all pretty (phpDocumented and such) and fix a couple encapsulation violations in the architecture, but if anyone's interested in betaing it once I can stand others looking at it, let me know! It's possible some bugs aren't going to be found except through actual use cases, encountering things like columns and indexes that don't exist on the Toolserver.
Cheers, -Madman
You know what I'm about to say. :-) Come on, come on, just show us the code, as unbearable as you may find that. Release early, release often, let us get our paws on it and help you. :-)
If for whatever reason you'd rather not have it on Toolserver, you can get a Git repository hosted with Wikimedia https://www.mediawiki.org/wiki/Git/New_repositories and share it there.
On Sun, Mar 18, 2012 at 10:10 PM, Sumana Harihareswara sumanah@wikimedia.org wrote:
You know what I'm about to say. :-) Come on, come on, just show us the code, as unbearable as you may find that. Release early, release often, let us get our paws on it and help you. :-)
If for whatever reason you'd rather not have it on Toolserver, you can get a Git repository hosted with Wikimedia https://www.mediawiki.org/wiki/Git/New_repositories and share it there.
Haha, no worries. As it happens, I've made enough progress that I anticipate releasing documentation and examples by the end of tomorrow (today?) and the base code by the end of the next day. I don't mean to be a tease, so to speak. :P Unfortunately, my OCD makes me apply absurdly arbitrary and exacting standards to any code when it has my name on it. This also makes it difficult for me to use source control (though I *do*, as it's absolutely essential to development) as I don't like keeping around code that didn't work or code that's no longer needed; it doesn't seem "organized" to me.
I'm not familiar with Git, but I'll look into it; as the framework has a dependency on MediaWiki, it'll probably be best to use what MediaWiki's going to use, especially if I can define it as an external repository. That way I wouldn't have to keep metadata around that might not be able to be checked in, write a checkout script, or have the possibility of having an old version of MediaWiki distributed with the framework.
Thanks! -Madman
On 03/18/2012 10:50 PM, [[w:en:User:Madman]] wrote:
On Sun, Mar 18, 2012 at 10:10 PM, Sumana Harihareswara sumanah@wikimedia.org wrote:
You know what I'm about to say. :-) Come on, come on, just show us the code, as unbearable as you may find that. Release early, release often, let us get our paws on it and help you. :-)
If for whatever reason you'd rather not have it on Toolserver, you can get a Git repository hosted with Wikimedia https://www.mediawiki.org/wiki/Git/New_repositories and share it there.
Haha, no worries. As it happens, I've made enough progress that I anticipate releasing documentation and examples by the end of tomorrow (today?) and the base code by the end of the next day. I don't mean to be a tease, so to speak. :P Unfortunately, my OCD makes me apply absurdly arbitrary and exacting standards to any code when it has my name on it. This also makes it difficult for me to use source control (though I *do*, as it's absolutely essential to development) as I don't like keeping around code that didn't work or code that's no longer needed; it doesn't seem "organized" to me.
I'm not familiar with Git, but I'll look into it; as the framework has a dependency on MediaWiki, it'll probably be best to use what MediaWiki's going to use, especially if I can define it as an external repository. That way I wouldn't have to keep metadata around that might not be able to be checked in, write a checkout script, or have the possibility of having an old version of MediaWiki distributed with the framework.
Thanks! -Madman
Thanks, Madman! I am sure many people are looking forward to your code's debut. And as for Git, people rave about its flexibility (which does unfortunately come with a learning curve) -- https://www.mediawiki.org/wiki/Git links to our blog post, and https://labsconsole.wikimedia.org/wiki/Help:Access#Access_FAQ will help you get an account. (We're managing Git/Gerrit access via unified logins with Labsconsole on Wikimedia Labs.)
On Sun, Mar 18, 2012 at 10:50 PM, [[w:en:User:Madman]] madman.enwiki@gmail.com wrote:
Haha, no worries. As it happens, I've made enough progress that I anticipate releasing documentation and examples by the end of tomorrow (today?) and the base code by the end of the next day.
Documentation is located at http://toolserver.org/~madman/dementia/ and examples are on classes Action and Query. All further updates (including a description of the framework, its dependencies, and base code) will probably be posted at that address and not sent to the list so as not to spam. I'd be happy to have any comments, bugs, feature requests, ideas for better names, etc. sent to me via e-mail or http://en.wikipedia.org/wiki/User_talk:Madman. I love criticism; for all I know, there could be a hundred reasons why this is just a novelty and won't work in practice (I'm encountering a couple such challenging problems now).
Cheers! -Madman
On 20/03/12 01:30, [[w:en:User:Madman]] wrote:
Documentation is located at http://toolserver.org/~madman/dementia/ and examples are on classes Action and Query. All further updates (including a description of the framework, its dependencies, and base code) will probably be posted at that address and not sent to the list so as not to spam. I'd be happy to have any comments, bugs, feature requests, ideas for better names, etc. sent to me via e-mail or http://en.wikipedia.org/wiki/User_talk:Madman. I love criticism; for all I know, there could be a hundred reasons why this is just a novelty and won't work in practice (I'm encountering a couple such challenging problems now).
Cheers! -Madman
That documentation completely misses the point :( There's no list of what actions to use in the factory, or that a login action has setPassword method (as you're using the magic method __set(), those things aren't listed by phpDocumentor). It's that kind of things what I'd want to view (or an explanation on how to map the api documentation to dementia).
19/03/12 03:50, [[w:en:User:Madman]] wrote:
Unfortunately, my OCD makes me apply absurdly arbitrary and exacting standards to any code when it has my name on it. This also makes it difficult for me to use source control (though I *do*, as it's absolutely essential to development) as I don't like keeping around code that didn't work or code that's no longer needed; it doesn't seem "organized" to me.
I'm not familiar with Git, (...)
You will fell in love with git rebase.
On 16/03/12 01:33, Tim Landscheidt wrote:
Magnus Manske wrote:
[...] At the risk of over-designing, would it be worth to gather language-independent requirements for a module/library, on the toolserver wiki or on meta, and then keep implementations of that standard (yes, I know, "one more standard") available on the toolserver? At the very least, a language-neutral brainstorming might prevent design flaws, especially with database-with-API-fallback in mind.
It depends on what you mean by "requirement". Something like "a library *must* provide a function normalizeLink() with these semantics" would probably deter developers from trying to implement it. If on the other hand there was an algorithm "if you want to normalize links, do A, B, C, D and E" and corresponding test cases to check compliance, I think it would be much more inviting.
Tim
I think it really makes sense to define the names of a set of available functions. That would really make much simpler the development of portable tools, or working on different languages, without having to relearn the framework used. That said, each of us would probably push for their own API to be standarised. I don't think providing tests is the panacea for making people implement them. They are obviously nice, but as it would be open source, each user doesn't need to reimplement them according to the specification. The same code could be shared. The problem is in adoption of the API, and agreeing on an "standarised" one.
Platonides platonides@gmail.com wrote:
[...] I think it really makes sense to define the names of a set of available functions. That would really make much simpler the development of portable tools, or working on different languages, without having to relearn the framework used. That said, each of us would probably push for their own API to be standarised.
I think you found the problem :-). Should "normalizeLink" be a method of "WikiFarm", "Wiki" or "WikiPage"? Should a page title be a string or a "WikiTitle"? If the latter and in a true OOP language, should it be a derived class of "string" or "WikiString" which would be then derived from "string"? And so on, and so forth.
I don't think providing tests is the panacea for making people implement them. They are obviously nice, but as it would be open source, each user doesn't need to reimplement them according to the specification. The same code could be shared. The problem is in adoption of the API, and agreeing on an "standarised" one.
Having recently ported a parser skeleton from Java to PHP, I disagree wholeheartedly :-). There are many subtle differ- ences between languages which programmers usually aren't even aware of because they take them for granted. Take re- gular expressions and their various flavours for example. Test cases ensure reproducable results and give the develop- ers the confidence that their enhancement/optimization will not burn down the house.
So I'm looking forward to Madman publishing his framework.
Tim
On Mon, Mar 12, 2012 at 4:59 PM, Merlijn van Deen valhallasw@arctus.nlwrote:
On 12 March 2012 15:49, Hydriz Wikipedia admin@alphacorp.tk wrote:
Tparis has the full source code of those tools, and looks like he has already brought them up on his own account. See https://toolserver.org/~tparis.
Could we (in general) *please* not do this? If someones tools are important enough to be taken over by someone else, they are most certainly important enough for a multi-maintainer project. In {one month, one year, five years}, Tparis' account will also expire and we will have the same problem all over again.
Best, Merlijn
I agree. There's also the issue of updating links all over the place. Where an MMP would have permanent links, regardless of who maintains it.
toolserver-l@lists.wikimedia.org