tux-droid-user — tuxdroid-user

Re: [tuxdroid-user] Automatically detect language

[David B. <da...@ja...>]

On Thu, 09 Aug 2007 18:53:29 +0200, neimad <ror...@gm...> wrote:

> Georges Dubus <geo...@la...> writes:
>
>> The first dictionary check for a specific country, whereas the second  
>> one
>> check only the language.
>>
>> With one dictionary, it could make the difference between US and GB.
>
> Yeah, I missed the :5 / :2 part :-$

Missed exactly the same :-)
Thanks for the patch, Georges.

Re: [tuxdroid-user] Information about tux-droid python contest ?

[David B. <da...@ja...>]

On Mon, 23 Jul 2007 19:36:18 +0200, KLEIN Stephane <ste...@ha...>  
wrote:

> Hello,
>
> last june, I were at "Journées Python Francophones" in Paris.
>
> I watched Tux Droid presentation and Kysoh Team have spoke about
> "tux-droid python contest". They have saw the next week, they post this
> contest on tux-droid mailing list. Until now, I don't read any post
> about that. I'm mistaken of mailing list ?
>
Sorry for those late replies. I was out of office for a while.

I didn't hear any news from this contest myself. I know they want to do  
something and asked to be able to get a tux online (daemon) with a webcam  
so that people will be able to drive it and look at the live video feed in  
order to see what it does. I tried to get a webcam server running quiete  
some time ago but didn't find a good solution with my linux server. And as  
there are many other things to do, I'm probably not going to work on this  
anytime soon unless priorities change.

But I have no idea what are the plans of Kysoh with regards to this.

David

Re: [tuxdroid-user] Wiki spam

[David B. <da...@ja...>]

On Mon, 13 Aug 2007 09:35:19 +0200, neimad <ror...@gm...> wrote:

> "David Bourgeois" <da...@ja...> writes:
>
>> The wiki is completely independent of plone right now, it's hosted on
>> a  different server running wikimedia. I guess there should be some
>> addons  for wikimedia too. I'll check.
>
> The stupid fucks are at it again. I had to revert two pages. Btw, how
> can I properly revert a newly created page? (I just wiped out the
> contents of one of them, as I didn't see any way of doing otherwise).

I just delete the page so that it's marked uncreated like it was before.

I now added a couple of stuff to fight spam. Spammers are added to the  
black list, edits that contain tags that hide content are discarded and I  
added the ConfirmEdit extension which enables a very simple text Captcha  
when edits contain external links.

Hope that will keep those spambots out.

David

Re: [tuxdroid-user] Wiki spam

[neimad <ror...@gm...>]

"David Bourgeois" <da...@ja...> writes:

> The wiki is completely independent of plone right now, it's hosted on
> a  different server running wikimedia. I guess there should be some
> addons  for wikimedia too. I'll check.

The stupid fucks are at it again. I had to revert two pages. Btw, how
can I properly revert a newly created page? (I just wiped out the
contents of one of them, as I didn't see any way of doing otherwise).

	Damien

Re: [tuxdroid-user] Tuxsay, an easy way to make you tux say stuffs.

[Mark A. <me...@ma...>]

Georges Dubus <geo...@la...> writes:
> 
> Here is my last script, that enable to use the TTS system easily, in command 
> line, so that it can be integrated in any bash script, or any other 
> programming language.
> 
> It can read the content of a file (or more) given as argument, or read from 
> stdin if no given. It also enable you to select a few options, like the voice 
> you want (language, gender and pitch), or whether tux should open his mouth. 
> Just launch him with ""--help" as argument to learn about all he can do !

It's a neat little script, but it fails to read files that contain
Latin-1 characters, instead of just pure 7bit ASCII or 8bit UTF-8
UNICODE.



-- 
Mark Atwood                 When you do things right, people won't be sure
me...@ma...         you've done anything at all.
http://mark.atwood.name/   http://fallenpegasus.livejournal.com/

[tuxdroid-user] Tuxsay, an easy way to make you tux say stuffs.

[Georges D. <geo...@la...>]

Hello there.

Here is my last script, that enable to use the TTS system easily, in command 
line, so that it can be integrated in any bash script, or any other 
programming language.

It can read the content of a file (or more) given as argument, or read from 
stdin if no given. It also enable you to select a few options, like the voice 
you want (language, gender and pitch), or whether tux should open his mouth. 
Just launch him with ""--help" as argument to learn about all he can do !

Georges

PS : the daemon keep spamming me with the "connect stuff" messages, is there a 
way to hide them ?

Re: [tuxdroid-user] Automatically detect language

[Georges D. <geo...@la...>]

Hi

Just an idea, more or less linked to that. When I select a voice that is not 
present on the system, male american is selected. Maybe there could be a 
warning telling that the voice can be downloaded.

Can it be done in the api, or is the "fallback" to english deeper in the 
daemon ?

Georges

Re: [tuxdroid-user] Automatically detect language

[neimad <ror...@gm...>]

Georges Dubus <geo...@la...> writes:

> The first dictionary check for a specific country, whereas the second one 
> check only the language.
>
> With one dictionary, it could make the difference between US and GB.

Yeah, I missed the :5 / :2 part :-$

	Damien

Re: [tuxdroid-user] Automatically detect language

[Georges D. <geo...@la...>]

On Wednesday 08 August 2007 21:08:33 neimad wrote:
> Georges Dubus <geo...@la...> writes:
> > I think it can be useful. Maybe even in the svn (in order to determine
> > default language, and advice about downloading languages).
> >
> > What do you think about it ?
>
> Why have 2 dictionaries ? A single one would do fine.
>
> 	Damien
>
English and Dutch have one particularity : there are two variants, depending 
on the country.

The first dictionary check for a specific country, whereas the second one 
check only the language.

With one dictionary, it could make the difference between US and GB.

Georges

Re: [tuxdroid-user] Automatically detect language

[neimad <ror...@gm...>]

Georges Dubus <geo...@la...> writes:

> I think it can be useful. Maybe even in the svn (in order to determine default 
> language, and advice about downloading languages).
>
> What do you think about it ?

Why have 2 dictionaries ? A single one would do fine.

	Damien

[tuxdroid-user] Automatically detect language

[Georges D. <geo...@la...>]

Hi

I just wrote a little piece of code that read the locale in order to determine 
which language tux should speak.

Here it is :

def find_language():
    env=os.environ['LANG']
    dict1={ 'en_US':'US',   #American English
            'nl_BE':'B'}    #Belgian Dutch
    dict2={ 'fr':'FR',      #French
            'de':'D',       #Deutsch
            'en':'GB',      #British English
            'ar':'AR',      #Arabic
            'da':'DK',      #Danish
            'es':'E',       #Spanish
            'it':'I',       #Italian
            'nl':'NL',      #Dutch
            'nb':'NO',      #Norwegian
            'pt':'P',       #Portuguese
            'sv':'S'}       #Swedish
    if dict1.has_key(env[:5]):
        return dict1[env[:5]]
    elif dict2.has_key(env[:2]):
        return dict2[env[:2]]
    else:
        return 'US'

I think it can be useful. Maybe even in the svn (in order to determine default 
language, and advice about downloading languages).

What do you think about it ?

Re: [tuxdroid-user] [tuxdroid-svn] r461 - api/python/trunk

[Georges D. <geo...@la...>]

On Wednesday 08 August 2007 07:51:45 Mark Atwood wrote:
> madjar <c2m...@c2...> writes:
> >          """
> > +        if speaker not in (SPK_FR_MALE, SPK_FR_FEMALE, SPK_US_MALE,
> > SPK_US_FEMALE): +            if self.parent.print_warnings:
> > +                print " Invalid speaker"
> > +            return
> >          if (pitch<100) or (pitch>330):
>
> I have the UK voice sets loaded.
>
> Is this going to cause that to stop working?


I'm sorry, I didn't know they added languages ...
I'm correcting that immediatly.

Thank you for noticing it.

PS : patch is ready, but I need to test it a little more. I'll merge it during 
the afternoon.

Re: [tuxdroid-user] [tuxdroid-svn] r461 - api/python/trunk

[Mark A. <me...@ma...>]

madjar <c2m...@c2...> writes:
>          """
> +        if speaker not in (SPK_FR_MALE, SPK_FR_FEMALE, SPK_US_MALE, SPK_US_FEMALE):
> +            if self.parent.print_warnings:
> +                print " Invalid speaker"
> +            return
>          if (pitch<100) or (pitch>330):

I have the UK voice sets loaded.

Is this going to cause that to stop working?


-- 
Mark Atwood                 When you do things right, people won't be sure
me...@ma...         you've done anything at all.
http://mark.atwood.name/   http://fallenpegasus.livejournal.com/

[tuxdroid-user] Information about tux-droid python contest ?

[KLEIN S. <ste...@ha...>]

Hello,

last june, I were at "Journées Python Francophones" in Paris.

I watched Tux Droid presentation and Kysoh Team have spoke about
"tux-droid python contest". They have saw the next week, they post this
contest on tux-droid mailing list. Until now, I don't read any post
about that. I'm mistaken of mailing list ?

Thanks for your information.
Stéphane

-- 
ps: merci de répondre _après_ le message (si vous utilisez Outlook, c'est peine perdue)
KLEIN Stéphane
Mail : ste...@ha...           Home Page : http://www.harobed.org
GSM : 06 61 48 76 04                  Jabber : ha...@my...

Re: [tuxdroid-user] Wiki spam

[David B. <da...@ja...>]

On Sat, 21 Jul 2007 14:53:06 +0200, neimad <ror...@gm...> wrote:

> Hello,
>
> Several pages have been defaced/spammed in the last weeks. I have
> reverted them but we need a countermeasure.
>
> We could make it less easy to create an account by using some captcha:
>
>     http://plone.org/products/plone-captchas
> or  http://plone.org/products/plonecaptcha
>

Hi Damien,

The wiki is completely independent of plone right now, it's hosted on a  
different server running wikimedia. I guess there should be some addons  
for wikimedia too. I'll check.

David

[tuxdroid-user] Wiki spam

[neimad <ror...@gm...>]

Hello,

Several pages have been defaced/spammed in the last weeks. I have
reverted them but we need a countermeasure.

We could make it less easy to create an account by using some captcha:

    http://plone.org/products/plone-captchas
or  http://plone.org/products/plonecaptcha

	Damien

Re: [tuxdroid-user] Europython

[David B. <da...@ja...>]

I posted a summary of Europython on the blog, with some pictures and my  
slides though there's no text in them, just pictures. There are maybe some  
newcomers on the list that were at Europython, as we sold our 12 tuxs in  
less than an hour. Hope you'll enjoy it.

David

On Wed, 04 Jul 2007 16:49:45 +0200, David Bourgeois <da...@ja...>  
wrote:

> A couple of people got some trouble posting here so this is a test of the
> mailing-list.
>
> But I take the opportunity to tell you that I'll be at Vilnius, Lithuania
> next week for Europython. I'll give a talk about Tux Droid there and we
> normally have a table to show them.
>
> Does anybody go there?
>
> David

Re: [tuxdroid-user] Mon e-mail

[David B. <da...@ja...>]

On Wed, 04 Jul 2007 17:31:42 +0200, <rol...@en...>  
wrote:

>     Je t'envoie mon e-mail pour que tu voit pourquoi je n'ai pas recu de
> mail de la mailing liste.
>
>     rol...@en...
>
>     Merci de m'aider

Well, it seems to work now :-)

[tuxdroid-user] Mon e-mail

[<rol...@en...>]

    Je t'envoie mon e-mail pour que tu voit pourquoi je n'ai pas recu de
mail de la mailing liste.

    rol...@en...

    Merci de m'aider

[tuxdroid-user] Europython

[David B. <da...@ja...>]

A couple of people got some trouble posting here so this is a test of the  
mailing-list.

But I take the opportunity to tell you that I'll be at Vilnius, Lithuania  
next week for Europython. I'll give a talk about Tux Droid there and we  
normally have a table to show them.

Does anybody go there?

David

Re: [tuxdroid-user] [tuxdroid-svn] don't know how to commit but got a script to commit

[David B. <da...@ja...>]

On Tue, 26 Jun 2007 19:14:19 +0200, yohann gabory <mrg...@ya...>  
wrote:

> hello every body !
>
> i have write a script for browsering directories, playing music and
> radio with tux and the remote. It's the first time i make a script and i
> don't know how to put it on the svn to let you all modify it !
>
> I am prety sure it is not as good as I would but it works !
>
> You can download  this script on the forum.( on the script page, of
> course)
>
> can anybody give me a little directory in the software directory so I
> will be able to put it here ?
>
> An acount would be great too !
>

Hi,

We still don't have much software and scripts on svn. You can add it under  
the software directory, just follow the structure
/software/yourscriptname/{trunk,tags,branches}

If you don't know how to add this yourself, I can do it for you. Otherwise  
I just added you in the devel group so you should have write access to the  
repository right now, with the same login and password as the website.

BTW, could you use tux-doid-user group for discussions? tux-droid-svn is  
reserved for commits made on svn. I couldn't find a way to restrict the  
list so that only the repository server can post, someone has any idea?

David

Re: [tuxdroid-user] Naming functions

[David B. <da...@ja...>]

As usual, I'm delighted to read your posts. Thanks for all the details,  
I've now a much better idea on how to handle that. You're right on the  
point when saying "naming is almost random", where almost means that  
sometimes we really think about it but without common guidelines that  
doesn't make anything better.

I'll certainly bug you again when I'll be stuck on some choices. For now  
I'll go for your suggestions :-)

Cheers,
David

Re: [tuxdroid-user] Naming functions

[neimad <ror...@gm...>]

"David Bourgeois" <da...@ja...> writes:

[...]

> - disconnect_from_tux()
> - connect_to_tux(id)
> - random_tux_connection()
> - id_request(*id)
> - id_lookup(*id)
> - change_id(id)
> - wakeup_tux(id)
> - avoid_wifi_channel(wifi_channel)

The naming of these particular functions isn't bad per se, but if we
want to be consistent throughout the code, we should pick a naming
convention.

Taking the above functions as examples, I think I'd name them:

  tux_disconnect()
  tux_connect()
  tux_connect_random()
  tux_id()
  tux_lookup()
  tux_change_id()
  tux_avoid_wifi_channel() or dongle_avoid_wifi_channel() [depending
  on *what* exactly will avoid using the channel: is it the dongle or
  tux ?]

All these functions work on a "tux" object (albeit abstract, as we
don't currently have any data structure representing a tux), hence
their tux_ prefix.

tux_connect() could be connect_to_tux(), as it doesn't have yet a "tux
object" to act upon and instead it does return/find such an object. If
I take an example using files:

    file_t *open_file(const char *filename)

This function doesn't act on a file_t object but returns one and thus
doesn't have the file_ prefix, but

    int file_write(file_t *file, void *data, size_t size)

acts on a file_t object and thus is prefixed with file_. Or we may
just decide that open_file() would be better named file_open(), since
it's in a "file" module (my preference). And so on...

(Notice too that the file_t parameter is always first.)

We can have very strict naming conventions, or we can give some slack,
but currently the naming is almost random ;-) I prefer very strict
naming conventions, because then you don't even have to ask yourself
"what was the name of that function again ?": if you have a file, of
type file_t, then you now all ops on it start with file_. Same goes
for variables and constants (say, FILE_MODE_RO, FILE_MODE_RW...).

Btw, if I have an enum about the file access modes, I'd name it as
follows (file_mode prefix for the type and its values):

    typedef enum {
        FILE_MODE_RO,
        FILE_MODE_RW
    } file_mode_t;

> - should all these functions return an int that indicates if there's
> an  error or not?

Not necessarily. Sometimes it's just more convenient to have special
values meaning error (for example, >= 0 might be the number of bytes
while < 0 is an error).

But this is not always possible nor desirable. I don't really have
rules here, I just pick what I think is best...

> - if so, should we do it also for functions that can't catch an error
> right now, just to ease the future in case we can add an error check
> later. I guess that makes sense only if we know it's possible to add
> such  a check later;

No, that's "overdesign", kinda. And all your code will have to manage
non-existent errors everywhere you call these functions, all for
nothing.

> - you can also give some recommendations for the name of parameters
> (like  wifi_channel) and variables while we're at it. What about
> wakeup or  wake_up or wake-up?

I don't have any recommendation for the naming of parameters, except
that they should make as obvious as possible what they are, of course.

> - is "int id_lookup(*id)" a good way to return both the id and if the
> command succeeded or not? That's something I copied from some unix
> functions;

Yes, it's alright.

Going back to your first question: this is a case were it may be
possible to return a special value for errors, depending on the actual
type of id: if it's signed, the usual convention "< 0 means error"
could be used, but if it's unsigned and zero is a valid id value, then
you can't and you must write the function as you did.

Having special values may also simplify the code a lot: if we can have
a special value ID_NONE to mean "no id", then there's no need to have
both an id value and a boolean telling whether the id is actually set.

> - should we return 0 if successful, -1 otherwise in all functions?
> Some of  them return 0 if failure and 1 if success, ... I guess we
> should be  consistent here too

Well, those functions that return 1 on success and 0 on failure should
really return true and false, respectively. Here too, it all depends
on how much consistent we want to be.

Imho, a module (say, USBDaemon_log.c) should use the same convention
for all its functions as much as possible. Different conventions for
different modules might be perfectly legit, though.

	Damien

Re: [tuxdroid-user] Naming functions

[David B. <da...@ja...>]

On Sun, 24 Jun 2007 17:23:52 +0200, neimad <ror...@gm...> wrote:

> Hello,
>
> The naming of functions is currently very inconsistent: some are verbs
> (orders), some are nouns; some have a prefix, some have a suffix --
> some have both, and some have neither.
>
> For example: tux_connection() is a noun but connect_to_tux() is an
> order, id_request() is prefixed while wakeup_tux() is suffixed. These
> last two functions both take an id but one has "id" in its name and
> the other has "tux"...
>
> Imo, all functions should be _verbs_ in the imperative form: functions
> are *orders* given to the machine. It's the usual naming scheme for
> english code.
>
> I think a good convention is also to prefix functions with the type of
> object they act upon. Say I have a type dongle_t; then, connecting to
> a dongle would be done with dongle_connect().
>
> What about send_usb_tux_cmd() ? Does it "send a 'usb tux' command" ?
> If so, what does that mean ? I have a really hard time trying to
> figure out what functions do from their name.
>
> We really need to define some consistent naming conventions for types,
> variables and functions...
>
I completely agree with you here but I have really no experience with  
naming practices. So just give me the name of a couple of functions you're  
not sure about, I'll try to describe them correcty so you can show us some  
good names.

Here are the connection functions I wrote and some description of them:

- disconnect_from_tux()
   Disconnect from a tux (only one is connected so we don't need to pass  
any parameter)

- connect_to_tux(id)
   Connect to a tux which has the id given as parameter

- random_tux_connection()
   Connect to the first tux found around, that's the same behavior as the  
connection we have now in the daemon, we can't choose which tux we want to  
connect to, so this is random.

- id_request(*id)
   Returns the id (as pointer) of the tux you're connected to. (That may  
sound stupid as you had to give the id to connect, but another application  
running on the same daemon/tux will not know it. And if your application  
is restarted, the connection will stay but you may loose the id.)

- id_lookup(*id)
   Returns the id (pointer) of the first tux found around

- change_id(id)
   Chenge the id of a disconnected tux to the id given as parameter

- wakeup_tux(id)
   Wake-up the tux with the id given as parameter

- avoid_wifi_channel(wifi_channel)
   Avoid the frequencies of a wifi_channel, tux will use all the other  
frequencies except those used by the given wifi_channel.


A few extra questions and points:

- should all these functions return an int that indicates if there's an  
error or not?

- if so, should we do it also for functions that can't catch an error  
right now, just to ease the future in case we can add an error check  
later. I guess that makes sense only if we know it's possible to add such  
a check later;

- you can also give some recommendations for the name of parameters (like  
wifi_channel) and variables while we're at it. What about wakeup or  
wake_up or wake-up?

- is "int id_lookup(*id)" a good way to return both the id and if the  
command succeeded or not? That's something I copied from some unix  
functions;

- should we return 0 if successful, -1 otherwise in all functions? Some of  
them return 0 if failure and 1 if success, ... I guess we should be  
consistent here too

- thanks again for taking care of the sanity of the code ;-)

David

[tuxdroid-user] Naming functions

[neimad <ror...@gm...>]

Hello,

The naming of functions is currently very inconsistent: some are verbs
(orders), some are nouns; some have a prefix, some have a suffix --
some have both, and some have neither.

For example: tux_connection() is a noun but connect_to_tux() is an
order, id_request() is prefixed while wakeup_tux() is suffixed. These
last two functions both take an id but one has "id" in its name and
the other has "tux"...

Imo, all functions should be _verbs_ in the imperative form: functions
are *orders* given to the machine. It's the usual naming scheme for
english code.

I think a good convention is also to prefix functions with the type of
object they act upon. Say I have a type dongle_t; then, connecting to
a dongle would be done with dongle_connect().

What about send_usb_tux_cmd() ? Does it "send a 'usb tux' command" ?
If so, what does that mean ? I have a really hard time trying to
figure out what functions do from their name.

We really need to define some consistent naming conventions for types,
variables and functions...

	Damien