tux-droid-user — tuxdroid-user

[tuxdroid-user] New release

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

New versions of the daemon, python api and gtdi (graphical interface) have
been released today.

Here are the changelogs. (I know they could be more detailed but I didn't
get more information myself.)

Tux Daemon 0.2.0-alpha2:

    * USB communication now uses interrupt transfers.
    * Raises an ERROR when connecting to the old firmware.
    * Cleaned the code to follow the new guidelines at
http://www.tuxisalive.com/documentation/how-to/guidelines-for-creating-and-packaging-an-application
and improve readbility and debugging.
    * Bug fixes.

Python API 0.1.1:

    * Added a limitation of the wav file to store the sounds in the local
flash to 70 seconds.
    * New functions and events are added.
    * Minor modifications.

GTDI 0.2.0:

    * Complete rework of the interface and new functionalities

[tuxdroid-user] Wiki rebirth?

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

As some of you requested a wiki, I cleaned the old one which is still
available at
http://www2.tux-is-alive.com/wiki

Right now there's only the TODO page and you should guess what it's for.
When there are suggestions on IRC, mailing list, tracker or the forum,
we'll try to add them there as to keep track of them. We can use the
associated discussion page to discuss the implementation, but you can
always comment it here or on IRC and we'll add your comments there if
they're relevant.

I'm going to update mediawiki to the last version so don't worry if at
some point it doesn't work anymore ;-)

Re: [tuxdroid-user] Why TCP?

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

Because he was used to TCP/IP but not UDP :-). On the other hand, the  
daemon can send information at any time to the client so it's probably  
better if the socket stays connected. And if we want to access the daemon  
 from another location, UDP won't assure you that the data is valid iirc.

On Wed, 14 Mar 2007 11:07:30 +0100, Srikanta Prasanna  
<sri...@gm...> wrote:

> Hi,
>
> Remi, thanks for the Daemon API doc (I hope Remi is subscribed the list  
> :-).
>
> I am not completely aware of the amount and frequency of traffic b/w the
> daemon & the apps. So, are there any specific reason why TCP was used
> instead of UDP?
>
> thanks,
> srikanta
>
> PS: Tried to post this as a comment on the website, but got a 110 (Conn
> timed
> out) error.

[tuxdroid-user] Why TCP?

[Srikanta P. <sri...@gm...>]

Hi,

Remi, thanks for the Daemon API doc (I hope Remi is subscribed the list :-).

I am not completely aware of the amount and frequency of traffic b/w the
daemon & the apps. So, are there any specific reason why TCP was used
instead of UDP?

thanks,
srikanta

PS: Tried to post this as a comment on the website, but got a 110 (Conn
timed
out) error.

Re: [tuxdroid-user] Voice control apps: Perlbox: an embryon of tts & voice recognition & cmd launcher app ; other voice apps & resources

[Srikanta P. <sri...@gm...>]

On 3/14/07, Florent THIERY <ft...@gm...> wrote:
>
>
> BTW: why is'nt the wiki used anymore?
>

We have restarted using it.
David has made some cleanup, and I've updated the TODO page
about the idea of adding logging facility to the daemon.

Re: [tuxdroid-user] Voice control apps: Perlbox: an embryon of tts & voice recognition & cmd launcher app ; other voice apps & resources

[Florent T. <ft...@gm...>]

After some investigation, i found that the peripheral is statically
defined in sphinx2 source at
sphinx2/src/libsphinx2ad/ad_oss.c at line 88 (svned version)

I get this error:

ad_oss.c 216: can't set input gain/recording level for this device.

When i talk, nothing seems to happen ...

What i saw from sphinx2 wasn't that clean, i'm not sure it's the way
to go... I sent a mail to perlbox dev, hope he may help.

If anybody manages to let it work (even with a regular mic), this
would be great. I'm also looking for IBM's viavoice SDK in order to
test Xvoice.

Well, now i shall go to bed :)

Florent

[tuxdroid-user] Voice control apps: Perlbox: an embryon of tts & voice recognition & cmd launcher app ; other voice apps & resources

[Florent T. <ft...@gm...>]

Hi, i found this:

http://perlbox.org/

Look @ the features, it's quite interesting. It uses festival, sphinx2
and has (for now) a kde plugin only.  I didn't manage to force sphinx
use /dev/dsp2 (my own tux mic entry) instead of /dev/dsp. It could be
an interesting base for tuxdroid, even if it's a tk interface (mm...
no antialiasing :p Anybody using amsn will know what i'm talking
about) and it is perl..

I tried testing xvoice, which seems quite interesting too (but uses
ibm's viavoice, sphinx support not ready afaik): it allows diction.
It's features are great, but i don't know how usable it is.

I quickly evaluated espeak, which gives good results (english though),
festival (i didn't try the good models...) which is undoubltly less
working than acapela, and others i could'nt make work

I tested the mic ( aplay /dev/dsp2 ), and there's this constant noise,
but apparently sphinx2 is robust against parasites. This one is
constant, which is good, but when the motors light up.... We can't
hear a thing apart of this. Plus, mouth has to be wide open to get
better sound.

Interesting links:
Lots of testing TODO :)
http://www.linux.com/howtos/Speech-Recognition-HOWTO/software.shtml

http://www.cstr.ed.ac.uk/projects/festival/mbrola.html (the "good"
models for festival; non-free though)

French resources:
http://kubuntu.free.fr/blog/index.php/2006/09/24/121-synthese-vocale-en-francais-sous-linux
KDE: commandes vocales http://kubuntu.free.fr/blog/index.php?p=43

See you next week.

BTW: why is'nt the wiki used anymore?

Re: [tuxdroid-user] Hello; Working with svn ; several questions & suggestions

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

On Tue, 13 Mar 2007 17:39:10 +0100, Florent THIERY <ft...@gm...>  
wrote:

> As long as we can retrieve a voltage value, we have to use/create a
> model of the battery's voltage evolution. I guess acpi's guessing (the
> one you get when typing "acpi") relies on such a model, and would give
> us hints. What type of battery is it?
>
Battery packs have an IC included which monitors the charge/discharge all  
the time. It can get how muh current get's in and out and computes the  
battery level from that. From the voltage, that may work but will be  
inaccurate. First I'll monitor the curves and from that we'll see what we  
can do.

> There's a feature that would be great if tux can emit: a IR recording
> mode; you just type the sequences on your regular remote in front of
> tux, then you assign a vocal command to them (ex: tv on + dvd player
> on + switch tv source + open tray...). We don't really need our
> software to "understand"/know the devices, do we? Just mimicking...

Yes, that's the idea of the universal receiver. Get the raw signal and the  
computer will keep it as raw or decrypt it according to various protocols.

david

Re: [tuxdroid-user] Hello; Working with svn ; several questions & suggestions

[Olivier G. <oli...@en...>]

Florent THIERY a écrit :

>>> - python question: what's the "command"/call for knowing the existing
>>> objects?
>> I'm not better than you. But you can use dir(tux) or dir(tux.cmd)

There is also help(tux) to display the inline documentation of the object
(provided someone wrote meaningful docstrings ;)

You should have a look at the ipython interactive shell that has <tab> based
autocompletion.

There are some screencasts here:
http://showmedo.com/videos/series?name=PythonIPythonSeries

-- 
Olivier

Re: [tuxdroid-user] Hello; Working with svn ; several questions & suggestions

[Florent T. <ft...@gm...>]

> > - what about autonomy ? Standby (idle) time? "Regular use" battery
> > time?
> Didn't do checks yet but that should be a around 15h but that depends on
> mutliple factors. We need to implement the sleep mode and I hope to reach much longer
> battery life then, a few days probably.

I guess my tux will stay plugged in then :)

> Yep, voltage should be there but not implemented yet, that should not be
> very hard though. But I have no idea on how to get a battery level out of
> that.

As long as we can retrieve a voltage value, we have to use/create a
model of the battery's voltage evolution. I guess acpi's guessing (the
one you get when typing "acpi") relies on such a model, and would give
us hints. What type of battery is it?

> > - about IR: what can we do with it? I mean, of course using the
> > remote, but can tux emit IR? Or is it just recieving? Because if yes,
> > it means tux could act as the first vocal universal remote :)
>
> Atm only RC5 works, you can receive all RC5 codes and send them. I found
> an application note to be able to have a universal receiver/emitter but I
> would want to know if this will be compatible with lirc before doing so.

There's a feature that would be great if tux can emit: a IR recording
mode; you just type the sequences on your regular remote in front of
tux, then you assign a vocal command to them (ex: tv on + dvd player
on + switch tv source + open tray...). We don't really need our
software to "understand"/know the devices, do we? Just mimicking...

> > - about mic : quality? Enough for basic voice recognition? What's the
> > peripheral (/dev/?) ?
> That should be fine for voice recognition.

I'd love to log in/out using voice, or simply audiosudo ^_^ (a pam module?)

> I would prefer to have small scripts that work and a good daemon before
> doing that [super app].

Sure, that's logical :)

> > - python question: what's the "command"/call for knowing the existing
> > objects?
>
> I'm not better than you. But you can use dir(tux) or dir(tux.cmd)

Thx, that's what i was looking for.

> We should use doxygen to generate all the documentation. Someone already
> created the missing configuration file though for the moment you'll get a
> listing of all the functions with only few documentation. You can also
> look at the python class directly and start documenting it ;-)

I started to look, but i lack practical skill and tux knowledge. Plus,
i'm out of time for now, but i may have some in a while.

Thanks for the answears !

Florent

Re: [tuxdroid-user] Hello; Working with svn ; several questions & suggestions

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

On Tue, 13 Mar 2007 15:41:24 +0100, Florent THIERY <ft...@gm...>  
wrote:

> Some other questions:
> - what about autonomy ? Standby (idle) time? "Regular use" battery
> time? I know there won't be an answear, but i'd like to get a rough
> estimation

Didn't do checks yet but that should be a around 15h but that depends on  
mutliple factors.
We need to implement the sleep mode and I hope to reach much longer  
battery life then, a few days probably.

> - is there a mean of knowing the battery level (voltage) ?

Yep, voltage should be there but not implemented yet, that should not be  
very hard though. But I have no idea on how to get a battery level out of  
that.

> - about IR: what can we do with it? I mean, of course using the
> remote, but can tux emit IR? Or is it just recieving? Because if yes,
> it means tux could act as the first vocal universal remote :)

Atm only RC5 works, you can receive all RC5 codes and send them. I found  
an application note to be able to have a universal receiver/emitter but I  
would want to know if this will be compatible with lirc before doing so.

> - about voice recognition: any plans yet? TTS is nice, but voice
> recognition would be awesome, primarily for bash/python script
> launching (X10 controlling, login, ...)

No plans from me, I would like to try it but there are much more things to  
do so I'll probably wait for someone to try it first :-)

> - about mic : quality? Enough for basic voice recognition? What's the
> peripheral (/dev/?) ?

Here it's in /dev/dsp1 but that depends on your settings and what other  
cards you have. Alsa should display it too. The quality is fine, but it's  
also 8 bits 8kHz. That should be fine for voice recognition.

> - about service unification: is there a planned "super software", in
> charge of launching and managing the queuing of all the software (with
> app downloading for instance)?

Yes we thought about that, to have a master application and plugins you  
could install/remove and monitor. Rémi is working into that direction but  
I would prefer to have small scripts that work and a good daemon before  
doing that. Or that someone which has a good understanding of tux and such  
a structure.

> - python question: what's the "command"/call for knowing the existing
> objects? sort of "ls tux.cmd.* " ; i forgot it... I'm kinda python
> newbie

I'm not better than you. But you can use dir(tux) or dir(tux.cmd)
We should use doxygen to generate all the documentation. Someone already  
created the missing configuration file though for the moment you'll get a  
listing of all the functions with only few documentation. You can also  
look at the python class directly and start documenting it ;-)

> - little feedback: at first my tux wasn't working at all ("dongle busy
> or disconnected"), had to upgrade firmware, but then, everythin's ok.
> The howto is cool, but lacks a little bit of clarity for the final
> step (tux upgrading, apart RF). The tuxup -a worked, but looks a bit
> dangerous...

OK, will have a look at it. tuxup -a is not dangerous as long as you use  
the hex files we provide (svn or futur releases). we never got any  
problem. I added that warning in case people start to mess up with  
firmwares or edit the hex files manually.

>
> And, an off one: does kysoh plan other toys in the future? I guess it
> depends on the success of this very one...

I don't know exactly about their plans but they should have. And indeed  
the success of this one will probably influence what will happen.

david

Re: [tuxdroid-user] Hello; Working with svn ; several questions & suggestions

[Florent T. <ft...@gm...>]

> Thanks! That's much appreciated, it's invaluable to get some thoughts of
> someone that know how to get things right.

I just wanted to say, as a user, that easy_install ROCKS :) When well
done, it's flawless and transparent. As almost everything here will be
python, it may be a good choice.

Some other questions:
- what about autonomy ? Standby (idle) time? "Regular use" battery
time? I know there won't be an answear, but i'd like to get a rough
estimation
- is there a mean of knowing the battery level (voltage) ?
- about IR: what can we do with it? I mean, of course using the
remote, but can tux emit IR? Or is it just recieving? Because if yes,
it means tux could act as the first vocal universal remote :)
- about voice recognition: any plans yet? TTS is nice, but voice
recognition would be awesome, primarily for bash/python script
launching (X10 controlling, login, ...)
- about mic : quality? Enough for basic voice recognition? What's the
peripheral (/dev/?) ?
- about service unification: is there a planned "super software", in
charge of launching and managing the queuing of all the software (with
app downloading for instance)?
- python question: what's the "command"/call for knowing the existing
objects? sort of "ls tux.cmd.* " ; i forgot it... I'm kinda python
newbie
- little feedback: at first my tux wasn't working at all ("dongle busy
or disconnected"), had to upgrade firmware, but then, everythin's ok.
The howto is cool, but lacks a little bit of clarity for the final
step (tux upgrading, apart RF). The tuxup -a worked, but looks a bit
dangerous...

And, an off one: does kysoh plan other toys in the future? I guess it
depends on the success of this very one...

Florent

Re: [tuxdroid-user] Hello; Working with svn ; several questions & suggestions

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

On Tue, 13 Mar 2007 14:03:46 +0100, Olivier Grisel  
<oli...@en...> wrote:

> I'm sorry I have not enough spare time to hack the droid right now but I  
> can try
> and help guide a volonteer for such a task.
>

Thanks! That's much appreciated, it's invaluable to get some thoughts of  
someone that know how to get things right.

I would like to have a look into that and fix the final structure of the  
folder tree of our software before releasing a binary package that will  
install everything.

Re: [tuxdroid-user] Hello; Working with svn ; several questions & suggestions

[Olivier G. <oli...@en...>]

David Bourgeois a écrit :

>> - what about a python egg (easy_install) ?
> 
> Unfortunaltely I missed the presentation of Olivier Grizel on packaging
> python products so I've no idea but Olivier is on this list, maybe he
> can give us some hints on what to do here, Olivier?

Hi David, hi all,

My FOSDEM slides are now online:

  http://linuxfr.org/2007/03/04/22154.html#809756

Direct link for the egg packaging tutorial:

  http://champiland.homelinux.net/fosdem2007/eggs_howto/eggs_howto.html
  http://champiland.homelinux.net/fosdem2007/eggs_howto/eggs_howto.txt

However this tutorial does not show how to package binary extensions. Please
refer to the official documentation for both distutils and setuptools:

  http://docs.python.org/dist/

and:

  http://peak.telecommunity.com/DevCenter/setuptools

You can also take a look at how other projects build eggs with binary extensions
such as the lxml project for instance.

I'm sorry I have not enough spare time to hack the droid right now but I can try
and help guide a volonteer for such a task.

-- 
Olivier

Re: [tuxdroid-user] Hello; Working with svn ; several questions & suggestions

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

On Tue, 13 Mar 2007 03:07:06 +0100, Florent THIERY <ft...@gm...>  
wrote:

> Hi everybody. I'm a proud owner of a tuxdroid (recieved today); after
> an update, everything works fine :) A little bit surprised by the
> sound made by motors, but happy enough.

Hi Florent,
Mechanics and motors are what they use in standard toy factories. We  
worked on reducing the noise and the result is satisfactory I think. It's  
not 'silent' but quite good for a toy. Using more high tech components  
would have improved that indeed but at a much higher cost so we had to  
make a choice.

> I synced the svn in order to get the latest version, but i have a
> problem: when you want to use svn versions of user programs, the call
> to the api is static ( /opt/tuxdroid/api/python ) whereas the actual
> svn version is in the trunk subdir ( /opt/tuxdroid/api/python/trunk );
> i modified the path in the sample programs (gtui, alarm clock...)

I hope someone good enough will be able to clean up that folder hierarchy  
and come up with a proposal for a new structure. The python api should  
probably be packaged with distutils so should move from there.

> - what will happen upon update? what's the "correct" way to do it?
> Copy it at the root dir?

For now, I would do a checkout of the api trunk only:
svn co https://svn.kysoh.com/api/python/trunk /opt/tuxdroid/api/python

> - what about a python egg (easy_install) ?

Unfortunaltely I missed the presentation of Olivier Grizel on packaging  
python products so I've no idea but Olivier is on this list, maybe he can  
give us some hints on what to do here, Olivier?

> - about the sound capabilities, is the capacity permanently limited? I
> guess real time transcoding do the job? (i tried listening some music
> with xmms, heared nothing but crap...), but if i was to plug tux on
> "real" speakers, would the quality still be very limited?

The sound format we can send through the RF is 8 bits 8kHz, no matter what  
speaker you use. That's not a lot but should still give you much better  
results than 'crap' ;-) Do you use the firmware update for the dongle? The  
sound quality has significantly improved there. Using speakers will  
improve the low-end response (bass) as the small internal speaker has a  
limited bandwidth there.

> - about the waker, does the computer need to be ON ? Or is tux  
> autonomous?

The computer needs to be ON. Though it may be possible to hack the  
firmware to add a poor-man RTC maybe (real time clock) which, with some  
calibration, could keep trig some functions at certain time events. But I  
have no idea of the precision we could get and I wouldn't rely on that for  
an alarm clock. So yes, you need the computer.

> - about waking the host computer up: do you think it would be feasible
> to add usb keyboard emulation to the usb dongle? If we managed to
> simulate a keypress, we could wake the computer up (but i guess the
> dongle needs power; then why should an usb keyboard do the job?)

Interesting question. As we can reprogram the dongle and if that's  
possible, that may be a good idea to implement.

> - what are the line out quality capabilities?

Line out is 8 bits 8kHz mono

> - would it be possible to detect motors forcing? I'm thinking of the
> rotation motors: if we (slightly) force tux to turn, can we detect it?
> That would add 2 more "switches", ideal for volume adjustment

The clutch will trigger if you force the gearbox so it won't work probably.

>
> Sorry for this bunch of random questions :)
>
> I'm willing to help developing the waker functionnality (i really need
> a good waker), thinking of webradios, rss headlines reading, X10 &
> randomization of "unlocking" sequence.
>
> I'll also consider using a NSLU2 or comparable for always-on operation
> (i'm very reluctant in regard of letting my main desktop on all the
> time...).

Yep, that's the way to go I think, I bought one but it's still in the box  
since 1 month now, don't have enough time to do all what I want to ...

>
> Anyway, this device looks like a fun toy for grown ups :) I'll try to
> bring my stone.
>
> Florent

We certainly need developments before getting something really usefull.  
Thanks to join the group.
david

[tuxdroid-user] Hello; Working with svn ; several questions & suggestions

[Florent T. <ft...@gm...>]

Hi everybody. I'm a proud owner of a tuxdroid (recieved today); after
an update, everything works fine :) A little bit surprised by the
sound made by motors, but happy enough.

I synced the svn in order to get the latest version, but i have a
problem: when you want to use svn versions of user programs, the call
to the api is static ( /opt/tuxdroid/api/python ) whereas the actual
svn version is in the trunk subdir ( /opt/tuxdroid/api/python/trunk );
i modified the path in the sample programs (gtui, alarm clock...)

- what will happen upon update? what's the "correct" way to do it?
Copy it at the root dir?
- what about a python egg (easy_install) ?
- about the sound capabilities, is the capacity permanently limited? I
guess real time transcoding do the job? (i tried listening some music
with xmms, heared nothing but crap...), but if i was to plug tux on
"real" speakers, would the quality still be very limited?
- about the waker, does the computer need to be ON ? Or is tux autonomous?
- about waking the host computer up: do you think it would be feasible
to add usb keyboard emulation to the usb dongle? If we managed to
simulate a keypress, we could wake the computer up (but i guess the
dongle needs power; then why should an usb keyboard do the job?)
- what are the line out quality capabilities?
- would it be possible to detect motors forcing? I'm thinking of the
rotation motors: if we (slightly) force tux to turn, can we detect it?
That would add 2 more "switches", ideal for volume adjustment

Sorry for this bunch of random questions :)

I'm willing to help developing the waker functionnality (i really need
a good waker), thinking of webradios, rss headlines reading, X10 &
randomization of "unlocking" sequence.

I'll also consider using a NSLU2 or comparable for always-on operation
(i'm very reluctant in regard of letting my main desktop on all the
time...).

Anyway, this device looks like a fun toy for grown ups :) I'll try to
bring my stone.

Florent

Re: [tuxdroid-user] Fwd: Re: PATCH: For new coding style

[Florent T. <ft...@gm...>]

On 3/11/07, David Bourgeois <da...@ja...> wrote:
> Thanks Henrik,
>
> Do other people have problems posting on the list? For those who never
> posted, just give us your opinion so you'll know if it works or not.

Hi.

Test

Re: [tuxdroid-user] Fwd: Re: PATCH: For new coding style

[Srikanta P. <sri...@gm...>]

On 3/11/07, David Bourgeois <da...@ja...> wrote:
>
> Thanks Henrik,
>
> > Another point, functions seems to be declared that way:
> >
> > type
> > my_function (
> >     type arg1,
> >     type arg2,
> >         )
> > {
> >     // body
> > }
> >
> > while another common way is
> >
> > type my_function (type arg1, type arg2)
> > {
> >     // body
> > }
>
> I prefer #2 here (actually, I prefer to have the opening brace on the
> same line as well, but that's not too common, I think).  I think the
> best argument for #2 is that it helps grepping.  If a function has
> many arguments, one can always do
> type func(type arg1,
>            type arg2,
>            ...
>            type argn)
> {
>
> }
>
>
Another + point for #2 way:
In Vi, to reach the function beginning, one can just to [[.
This works only when the { is on column 1. :-)

[tuxdroid-user] Fwd: Re: PATCH: For new coding style

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

Thanks Henrik,

Do other people have problems posting on the list? For those who never  
posted, just give us your opinion so you'll know if it works or not.

------- Forwarded message -------
From: "Henrik Grindal Bakken" <hg...@if...>
To: da...@ja...
Subject: Re: [tuxdroid-user] PATCH: For new coding style
Date: Mon, 12 Mar 2007 13:05:22 +0100

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

Since you asked for opinions...  I emailed this to you directly (hope
you didn't get two copies now...), because either the sourceforge mail
server or my work mail server refused me to post to the list.

> In these guidelines, I was surprised to see that you prefer flower
> braces on a new line (#2). That's the way I personally like it but
> when looking at various guidelines I saw that most of the time they
> prefer and recommend the more compact use #1 instead. I'm just
> concerned many coders will prefer #1. What do you think?
>
> #1:
>   if (test) {
>       // do something
>   }
>
> #2:
>   if (test)
>   {
>       // do something
>   }

Personally, at least, I prefer #1.

> Another point, functions seems to be declared that way:
>
> type
> my_function (
>     type arg1,
>     type arg2,
>         )
> {
>     // body
> }
>
> while another common way is
>
> type my_function (type arg1, type arg2)
> {
>     // body
> }

I prefer #2 here (actually, I prefer to have the opening brace on the
same line as well, but that's not too common, I think).  I think the
best argument for #2 is that it helps grepping.  If a function has
many arguments, one can always do
type func(type arg1,
           type arg2,
           ...
           type argn)
{

}

I prefer having return type on the same line as the function name no
matter how one place the arguments.  Using doxygen to document
arguments is a better solution than per-argument comments anyway,
IMHO.

Hopefully the tuxen will arrive soon.  Then I guess I have to have a
look at the code myself too :)

Re: [tuxdroid-user] PATCH: For new coding style

[Srikanta P. <sri...@gm...>]

On 3/11/07, David Bourgeois <da...@ja...> wrote:
>
> On Sat, 10 Mar 2007 16:23:20 +0100, Srikanta Prasanna
> > Some points to remember:
> > - Changes almost all the files.
> > - No functionality changes.
> > - Lots of changes, so its basically upto the maintainer
> > to accept/reject.  :-)
>
> No problem, I applied it loaclly and indeed have to commit it now
> otherwise it will break soon.


Thanks!


> - I've changed the existing code to follow the coding-style as
> > I've documented on the website how-to
> > (
> >
> http://www.tuxisalive.com/documentation/how-to/guidelines-for-creating-and-packaging-an-application
> ).
>
> Now the indenting and spacings look like they should be :-)
>
> In these guidelines, I was surprised to see that you prefer flower braces
> on a new line (#2). That's the way I personally like it but when looking
> at various guidelines I saw that most of the time they prefer and
> recommend the more compact use #1 instead. I'm just concerned many coders
> will prefer #1. What do you think?
>
> #1:
>    if (test) {
>        // do something
>    }
>
> #2:
>    if (test)
>    {
>        // do something
>    }


_Personally_, I prefer #2  just to maintain uniformity while using
flower-braces.
That is, while defining a method, we use { in new line. So, why not for all
other
stuff? ;-). Just for sake of uniformity.

Ofcourse, its very true that many prefer #1. That's why, I added
"Recommended"
and "Not Recommended" in the coding doc, instead of "Good" / "Bad" :-)

Infact, we can remove this flower braces stuff from the doc, and let the
contributor
decide what way he wants (just for now ;-).


Another point, functions seems to be declared that way:
>
> type
> my_function (
>      type arg1,
>      type arg2,
>          )
> {
>      // body
> }
>
> while another common way is
>
> type my_function (type arg1, type arg2)
> {
>      // body
> }
>
> I've seen that the first way was preferred in order to add comments for
> every argument on each line. But if we use doxygen to generate comments,
> we don't really need that as the params should be documented in the
> function comment I think.


Yes, even I prefer the second way. Its more common and natural. And doxygen
(I think) expects the documentation in the function header comment. So, we
can
go with the second way.


I'd like to have some opinions quickly so I can commit the patch if
> everyone seems to agree to the current guidelines or correct it.


My part is done :-)

regards,
Srikanta

Re: [tuxdroid-user] PATCH: For new coding style

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

On Sat, 10 Mar 2007 16:23:20 +0100, Srikanta Prasanna  
<sri...@gm...> wrote:

> Hi,
>
> As we discussed yesterday on IRC, I'm submitting a patch
> to change existing daemon trunk code to follow new coding
> style.

Hi Srikanta,
Thanks, greatly appreciated.

> Some points to remember:
> - Changes almost all the files.
> - No functionality changes.
> - Lots of changes, so its basically upto the maintainer
> to accept/reject.  :-)

No problem, I applied it loaclly and indeed have to commit it now  
otherwise it will break soon.

> - I've changed the existing code to follow the coding-style as
> I've documented on the website how-to
> (
> http://www.tuxisalive.com/documentation/how-to/guidelines-for-creating-and-packaging-an-application).

Now the indenting and spacings look like they should be :-)

In these guidelines, I was surprised to see that you prefer flower braces  
on a new line (#2). That's the way I personally like it but when looking  
at various guidelines I saw that most of the time they prefer and  
recommend the more compact use #1 instead. I'm just concerned many coders  
will prefer #1. What do you think?

#1:
   if (test) {
       // do something
   }

#2:
   if (test)
   {
       // do something
   }

Another point, functions seems to be declared that way:

type
my_function (
     type arg1,
     type arg2,
         )
{
     // body
}

while another common way is

type my_function (type arg1, type arg2)
{
     // body
}

I've seen that the first way was preferred in order to add comments for  
every argument on each line. But if we use doxygen to generate comments,  
we don't really need that as the params should be documented in the  
function comment I think.

I'd like to have some opinions quickly so I can commit the patch if  
everyone seems to agree to the current guidelines or correct it.

Thanks
david

[tuxdroid-user] PATCH: For new coding style

[Srikanta P. <sri...@gm...>]

Hi,

As we discussed yesterday on IRC, I'm submitting a patch
to change existing daemon trunk code to follow new coding
style.

Some points to remember:
- Changes almost all the files.
- No functionality changes.
- Lots of changes, so its basically upto the maintainer
to accept/reject.  :-)
- I've changed the existing code to follow the coding-style as
I've documented on the website how-to
(
http://www.tuxisalive.com/documentation/how-to/guidelines-for-creating-and-packaging-an-application).

Incase the patch is accepted, lets apply the patch asap, before new
code gets in.

regards,
srikanta

[tuxdroid-user] Error : Tux dongle is busy or disconnected

[david <da...@ja...>]

If you didn't follow the forum or IRC, there's been some issue with the =
 =

dongle connection on most >=3D2.6.18 kernels.

That was a bug of the dongle which is now FIXED !

Thanks to all of you who were on IRC and helped to get a clear view on  =

this. We found that a delay used by the interrupt interface was set to 0=
ms  =

(that's the case in bulk) but should have been a 1ms at least.
Don't ask me why it could work like this with the older kernels, I have =
no  =

idea but it seems they corrected that in 2.6.18.

So update your firmware :)

I wrote a howto, check it at  =

http://www.tuxisalive.com/documentation/how-to/updating-the-firmware
You only need to update fuxusb.hex so you can stop after the second step=
  =

of 'Testing tuxup'

There's no release of tuxup yet, but you can get it from SVN with
     svn co https://svn.kysoh.com/firmware/tuxup/trunk tuxup

Then you need to update the daemon, I didn't make a release neither so  =

once more svn is your friend:
     svn co https://svn.kysoh.com/daemon/trunk tuxdaemon
     build the daemon and copy tuxdaemon to /opt/tuxdroid/bin if you did=
 so  =

in the past

I'll do a release of tuxup, the daemon and other firmwares next week but=
  =

for all of you who have a kernel >=3D 2.6.18, you can at least fix your =
 =

problems right now. Hope that works for everybody. Let me know about any=
  =

problem you encounter with the procedure.

Cheers,
david

[tuxdroid-user] PATCH: Including USB connection status enums

[Srikanta P. <sri...@gm...>]

Addition of enum TUX_USB_CONN_STATUS.
Code indentation.

Re: [tuxdroid-user] PATCH: Minor code cleanup

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

Thanks Srikanta.

As I said on the forum, I just made a dump of the repository that will now  
be hosted with the website so LDAP will handle access for everybody and  
we'll be able to grant access to users subscribed on the website.

I applied your patch and will commit it as soon as the new repository is  
up.

david

On Wed, 07 Mar 2007 03:06:54 +0100, Srikanta Prasanna  
<sri...@gm...> wrote:

> Patch to use enums instead of 0/1 values for
> Tux TCP status.