[Toolserver-l] Toolserver Intuition: non-PHP projects
Merlijn van Deen wrote:
> Would it be possible just to use translatewiki to export python-based
> translations? Pywikipediabot currently uses this for some of its
> translations. It does not support plurals at the moment, though, as it's a
> simple dictionary-based system ({'translatewiki-key': {'lang': 'value'}})
Generally, translatewiki.net can do that, and is already doing it for some
pywikipediabot pieces, with likely more to come.
I expect that we shall have a PLURAL implementation in python as well
some time in the future.
I have not investigated that, but I assume, we have some similar
functionality in JavaScript in the new ressource loader context already.
--
Greetings - Purodha
___
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
[Toolserver-l] recent issues
I have noticed within the last 7 days or so several issues that have cropped up without any real source. I am wondering if this is isolated or if others are having unusual issues. The two main issues that I have seen is that sendmail functionality either recently changed or broke. Ive had a script that emails me logs every day at 0100UTC via a python wrapper to sendmail, however the last emails that I received where for the 6th and after that all I received was error messages, (one about no recipient, and the second about encoding ) even though the last time that file was march 3rd. Ive gone head and fixed those issues. I also have had an issue with a db query that I've been running since July 2009 with just a few minor teaks which used to execute in 5-10 minutes its now taking over an hour for the same query to run (this started happening within the last 24 hours). Has anyone else experienced similar issues or things breaking or is it just me? Betacommand ___ 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
Re: [Toolserver-l] Toolserver Intuition: non-PHP projects
On 11 April 2011 19:52, Paul Selitskas wrote:
> On Mon, Apr 11, 2011 at 8:46 PM, Purodha Blissenbach
> wrote:
> > Krinkle wrote:
> >> * Python
> >> - Not sure how to pull this one off yet,
> > Count me in for supporting python, too.
>
Would it be possible just to use translatewiki to export python-based
translations? Pywikipediabot currently uses this for some of its
translations. It does not support plurals at the moment, though, as it's a
simple dictionary-based system ({'translatewiki-key': {'lang': 'value'}})
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
Re: [Toolserver-l] Toolserver Intuition: non-PHP projects
On Mon, Apr 11, 2011 at 8:46 PM, Purodha Blissenbach wrote: > Krinkle wrote: >> * Python >> - Not sure how to pull this one off yet, as a work around it could >> make http request to the api in json (since Python supports that) but >> a way without making http calls would be preferred. I'm not a heavy >> Python developer (I've used it a couple of times to write simple >> ircbots (irclib) and wikibots (pywikibot), but that's about it). Any >> suggestions from python developers how they would like to have it >> delivered, let me know how you want it served and I'll see what I can >> do. > > Count me in for supporting python, too. My experience is similar to yours, > and I cannot start rightaway, but I think, getting the php implementation > as a reference should have preceedence anyways. > > Btw., I have been thinking about PLURAL implementations. It might > be possible to automatically extract plural routines from MediaWikis > LanguageZxx.php files, and wrapping them into a piece of code such > as a big switch on language codes. Since the functions are pretty small, > and there are not really many languages having their own PLURAL > implementations, this might at least be a simple and effective start. > > -- > Greetings - Purodha > > ___ > 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 > Yes, you may "pack" some PLURALs. For instance, a lot of slavic languages have similar rule on plurals (three arguments and identical algorithm, at least in Belarusian, Russian and Ukrainian). -- З павагай, Павел Селіцкас/Paul Selitskas Wizardist @ Wikimedia projects p.selits...@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
Re: [Toolserver-l] Toolserver Intuition: non-PHP projects
Krinkle wrote: > * Python > - Not sure how to pull this one off yet, as a work around it could > make http request to the api in json (since Python supports that) but > a way without making http calls would be preferred. I'm not a heavy > Python developer (I've used it a couple of times to write simple > ircbots (irclib) and wikibots (pywikibot), but that's about it). Any > suggestions from python developers how they would like to have it > delivered, let me know how you want it served and I'll see what I can > do. Count me in for supporting python, too. My experience is similar to yours, and I cannot start rightaway, but I think, getting the php implementation as a reference should have preceedence anyways. Btw., I have been thinking about PLURAL implementations. It might be possible to automatically extract plural routines from MediaWikis LanguageZxx.php files, and wrapping them into a piece of code such as a big switch on language codes. Since the functions are pretty small, and there are not really many languages having their own PLURAL implementations, this might at least be a simple and effective start. -- Greetings - Purodha ___ 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
Re: [Toolserver-l] Alternative C function to vasprintf() on Toolserver
Am 09.04.2011 11:28, schrieb Ilmari Karonen:
> char *vasprintf (const char *format, va_list ap) {
> int len; char *buf;
> len = vsnprintf(NULL, 0, format, ap); /* get needed size */
> if (len< 0) return NULL;
> buf = malloc(len + 1); /* reserve 1 byte for trailing \0 */
> if (!len) return NULL;
shouldn't that line read
if (!buf) return NULL;
> if (vsnprintf(buf, len + 1, format, ap) == len) return buf;
> free(buf); /* something went wrong in second vsnprintf() */
> return NULL;
> }
Peter
___
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
Re: [Toolserver-l] Alternative C function to vasprintf() on Toolserver
On 11 April 2011 19:59, River Tarnell wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Andrew Dunbar:
>> Hmm currently I'm using _vscprintf / vsprintf on Windows/MSVC inside
>> #ifdef _WIN32
>> and vasprintf Ubuntu/gcc inside #else
>
>> But my C-fu is to puny to figure out what #ifdefs to use to detect
>> what combination of C compiler and libc I'm compiling under.
>
>> Apparently it's important with snprintf since some implementations
>> return "an unspecified return value less than 1" with size=0.
>
> That's true, but no current Unix implementation should do that, since
> the return value of snprintf() is standardised in the current POSIX
> standard (IEEE 1003.1-2004) and in the C99 standard (ISO/IEC 9899:1999).
>
> The following code should handle Windows and both old and new Unix,
> although it's completely untested and comes with no warranty:
>
> /* Compile with "-D_XOPEN_SOURCE=600 -std=c99" */
> int
> my_vasprintf(char **res, char const *fmt, va_list args)
> {
> int sz, r;
> #ifdef _WIN32
> sz = _vscprintf(fmt, args);
> #else
> sz = snprintf(NULL, 0, fmt, args);
> #endif
>
> #if defined(_WIN32) || (defined(__STDC__) && __STDC__ >= 199901L) \
> || (defined(_XOPEN_VERSION) && (_XOPEN_VERSION >= 600))
> if (sz < 0)
> return sz;
> if (sz >= 0) {
> #else
> if (sz >= 1) {
> #endif
> if ((*res = malloc(sz + 1)) == NULL)
> return -1;
>
> if ((sz = sprintf(*res, fmt, args)) < 0) {
> free(*res);
> *res = NULL;
> }
>
> return sz;
> }
>
> #define MAXLN 65535
> *res = NULL;
> for (sz = 128; sz <= MAXLN; sz *= 2) {
> if ((*res = realloc(*res, sz)) == NULL)
> return -1;
> r = vsnprintf(*res, sz, fmt, args);
> if (r > 0 && r < sz)
> return r;
> }
>
> errno = ENOMEM;
>
> if (*res) {
> free(*res);
> *res = NULL;
> }
>
> return -1;
> }
>
> Obviously, this will be slower than the modern implementation, and you
> may want to tune the initial buffer size for the expected string length.
Thanks River, that's really helpful!
Andrew Dunbar (hippietrail)
> - river.
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1.4.11 (SunOS)
>
> iEYEARECAAYFAk2i0QcACgkQIXd7fCuc5vI1ewCfTdlavg0rr56l7JzwAe5Oea9x
> 55sAnA4MIosJLfOnD/O3z/nkq0yqD5CE
> =AGMe
> -END PGP SIGNATURE-
>
> ___
> 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
>
___
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
Re: [Toolserver-l] Alternative C function to vasprintf() on Toolserver
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Andrew Dunbar:
> Hmm currently I'm using _vscprintf / vsprintf on Windows/MSVC inside
> #ifdef _WIN32
> and vasprintf Ubuntu/gcc inside #else
> But my C-fu is to puny to figure out what #ifdefs to use to detect
> what combination of C compiler and libc I'm compiling under.
> Apparently it's important with snprintf since some implementations
> return "an unspecified return value less than 1" with size=0.
That's true, but no current Unix implementation should do that, since
the return value of snprintf() is standardised in the current POSIX
standard (IEEE 1003.1-2004) and in the C99 standard (ISO/IEC 9899:1999).
The following code should handle Windows and both old and new Unix,
although it's completely untested and comes with no warranty:
/* Compile with "-D_XOPEN_SOURCE=600 -std=c99" */
int
my_vasprintf(char **res, char const *fmt, va_list args)
{
int sz, r;
#ifdef _WIN32
sz = _vscprintf(fmt, args);
#else
sz = snprintf(NULL, 0, fmt, args);
#endif
#if defined(_WIN32) || (defined(__STDC__) && __STDC__ >= 199901L) \
|| (defined(_XOPEN_VERSION) && (_XOPEN_VERSION >= 600))
if (sz < 0)
return sz;
if (sz >= 0) {
#else
if (sz >= 1) {
#endif
if ((*res = malloc(sz + 1)) == NULL)
return -1;
if ((sz = sprintf(*res, fmt, args)) < 0) {
free(*res);
*res = NULL;
}
return sz;
}
#define MAXLN 65535
*res = NULL;
for (sz = 128; sz <= MAXLN; sz *= 2) {
if ((*res = realloc(*res, sz)) == NULL)
return -1;
r = vsnprintf(*res, sz, fmt, args);
if (r > 0 && r < sz)
return r;
}
errno = ENOMEM;
if (*res) {
free(*res);
*res = NULL;
}
return -1;
}
Obviously, this will be slower than the modern implementation, and you
may want to tune the initial buffer size for the expected string length.
- river.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (SunOS)
iEYEARECAAYFAk2i0QcACgkQIXd7fCuc5vI1ewCfTdlavg0rr56l7JzwAe5Oea9x
55sAnA4MIosJLfOnD/O3z/nkq0yqD5CE
=AGMe
-END PGP SIGNATURE-
___
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
