tux-droid-user — tuxdroid-user

[tuxdroid-user] Imagination?

[<ma...@ma...>]

Am I imagining this or did there used to be a method in the Python API  
to get the sound level from the microphone?

I want to monitor ambient noise levels and use the feedback to control  
the volume before using TTS to make announcements: "There's a tornado  
warning for your area!" or "Don't you think it's time to go to sleep?"

Cheers // Martin

Re: [tuxdroid-user] alarm_clock and email_alert depending on gnome

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

On Fri, 04 May 2007 18:04:15 +0200, Georges Dubus  
<geo...@la...> wrote:

> Hi again
>
> It seems I killed the mailing list ...
>
> Here's a little patch I just wrote and that apply on last svn gtdi.py.
> During the loading of the program, it check for the presence of a  
> terminal

Hi Georges,

Thanks for your patch, I committed it on svn. I could also remove the  
unnecessary import of the gnome module on email alert and alarm clock.

The mailing list is indeed very quiet at the moment.

David

Re: [tuxdroid-user] alarm_clock and email_alert depending on gnome

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

Hi again

It seems I killed the mailing list ...

Here's a little patch I just wrote and that apply on last svn gtdi.py.
During the loading of the program, it check for the presence of a terminal 
app : first gnome-terminal, then konsole and the xterm (I think everybody 
have at least xterm). When clicking the "Tux Droid Shell Button", it use the 
detected terminal instead of gnome-terminal, so that it works on non-gnome 
systems.

I hope the code isn't too dirty, so that it can be useful

Georges

[tuxdroid-user] alarm_clock and email_alert depending on gnome

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

Hi all

I'm a kde user, and I've got some problems with alarm_clock and email_alert : 
they are depending on python-gnome. I know I could just install it, but as 
I'm lazy, I looked into the script.

There are only 2 lignes talking about gnome in both scripts :
> import gnome
> gnome.program_init("tdac", "0.0.1")

I couldn't find what is their use. Are they really needed ?

Georges

Re: [tuxdroid-user] Tux's widgets and Impress

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

In 2003 it seems not to be possible:
http://www.openoffice.org/servlets/ReadMsg?list=3Ddev&msgNo=3D8914

I contacted the author in case he got something working finally, let's s=
ee  =

if the email address still exists.

Re: [tuxdroid-user] Tux's widgets and Impress

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

On Fri, 27 Apr 2007 16:49:31 +0200, <car...@fr...> wrote:

> I 've already think about it. And my first idea is to work with PyUno (
> http://udk.openoffice.org/python/python-bridge.html). It's a  
> python-bridge to
> automate openoffice. As you can create a OODocument, i think it's  
> possible to
> manage presentation. ( I will like use it for my exam !!!)
>
> If you have others idea to do it. I am interested to do it.

Yes I remember you talked about it (forum or IRC) and your solution seems  
good. I thought about this a couple of months ago, I wanted to do that for  
my presentation at fosdem but just got the time to prepare my talk,  
nothing more. I wanted to find a way to generate keys events (keys from  
the keyboard) so Tux could use pgdn/pgup to go forward/backward in the  
slides. If that's possible, that would be an easy way to control a few  
stuff.

That's the application I like the most, it can really be impressive if it  
works. And if you have some hard to remember sentences, just let tux say  
them for you, just interact a bit with him :-)

If you want to start on this, you may add a link under the widget name and  
create a new page dedicated to that only, as that's worth a page on it's  
own. Feel free to change the description too if you want to improve it.

[tuxdroid-user] Tux's widgets and Impress

[<car...@fr...>]

hi all,

I have read on the Wiki  paragraph concerning impress :

"Impress, pdf or any presetation software
Slide show control with the remote control.
Each slide can be associated with a script so tux could interact with the slide
by explaining stuff, doing movements and interacting with the presenter or the
audience.
Controlled interaction within a single slide from the remote control, can be
used to control different steps of the slide or the interaction with tux.
Automatic scripting from the slide notes with simple tags to control the TTS and
simple movements
Configuration of the slide files and the scripts for each slide "

I 've already think about it. And my first idea is to work with PyUno (
http://udk.openoffice.org/python/python-bridge.html). It's a python-bridge to
automate openoffice. As you can create a OODocument, i think it's possible to
manage presentation. ( I will like use it for my exam !!!)

If you have others idea to do it. I am interested to do it.

Thomas

Re: [tuxdroid-user] Wiki update

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

On Fri, 27 Apr 2007 15:34:31 +0200, Florent THIERY <ft...@gm...>  
wrote:

> About the widgets, it's a great idea ! But the choice of app will be  
> important:
>
> There's screenlets, which looks very promising:
> http://hendrik.kaju.pri.ee/screenlets/

Another source of inspiration could be:
http://adesklets.sourceforge.net/desklets.html

They're in python and some of them can be nice for Tux.

I think we could have a first version of the widget manager ready next  
week.

Re: [tuxdroid-user] Wiki update

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

On Fri, 27 Apr 2007 16:02:13 +0200, Florent THIERY <ft...@gm...>  
wrote:

>> I do not want to have to install Gnome libs on my NSLU2 ;-)
>
> Our screenlets/widgets should be able to connect to a distant tuxdaemon  
> :)

Yes that's true, though the widget manager should also run on the NSLU2 as  
for example the alarm clock will run there. The idea of the NSLU2 is to  
not have a computer running all the time for just a few things tux should  
be aware of permanently.

Actually that makes me think we should be able to handle 2 widgets  
managers from the daemon, one running on the NSLU2 and another one from a  
workstation for local events, if you want to get alerted that your  
compilation failed for example.

Re: [tuxdroid-user] Wiki update

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

On Fri, 27 Apr 2007 15:50:48 +0200, Philippe Teuwen <ph...@te...>  
wrote:

> Hi,
>> And the marketing team needs something badly so they decided to get
>> Rémi working on Tux Widgets
> Nothing surprizing, according to this article
> http://seo-space.blogspot.com/2007/01/top-100-marketing-buzzwords-of-2007.html
> "widget marketing" is number 36 in the Top 100 Marketing Buzzwords of  
> 2007.
> Not bad at all! ;-) your marketing team is really à-la-page!
>
> That doesn't mean it's a bad idea.
> Just pay attention to not be captured in a rigid framework (even if
> you're free within the framework).
> I do not want to have to install Gnome libs on my NSLU2 ;-)

me neither :-)

Actually widgets is just the name and corresponds to the idea of having a  
framework that accepts a lot of very light applications that evrybody can  
build. So the idea here is to have a manager for tux scripts, that's all.  
There's no plan for graphical interfaces yet for every widget, only the  
manager will have some basic GUI to handle the widgets. We more or less  
want to focus on the use of tux when the user is not in front of his  
computer, we don't need to compete with classic widgets, the clock will  
use tux to say the time, the alarm will make tux ring,... nothing on the  
computer side.

So really it's just a master application to handle multiple scripts and  
which uses the API to communicate with tux. The framework should not add  
any other dependency that the API/daemon currently have.

>> I'll try to be the relay between the ML/wiki/IRC and Rémi.
> Why is Rémi so shy? :-)

He's coming from the M$ world and has always been a solo developer so he's  
not used to the community way of life :-), but now his wife will give  
birth in the coming days and he relocated recently too and doesn't get  
internet access yet...

Re: [tuxdroid-user] Wiki update

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

> I do not want to have to install Gnome libs on my NSLU2 ;-)

Our screenlets/widgets should be able to connect to a distant tuxdaemon :)

Re: [tuxdroid-user] Wiki update

[Philippe T. <ph...@te...>]

Hi,
> And the marketing team needs something badly so they decided to get 
> Rémi working on Tux Widgets 
Nothing surprizing, according to this article
http://seo-space.blogspot.com/2007/01/top-100-marketing-buzzwords-of-2007.html
"widget marketing" is number 36 in the Top 100 Marketing Buzzwords of 2007.
Not bad at all! ;-) your marketing team is really à-la-page!

That doesn't mean it's a bad idea.
Just pay attention to not be captured in a rigid framework (even if 
you're free within the framework).
I do not want to have to install Gnome libs on my NSLU2 ;-)
> I'll try to be the relay between the ML/wiki/IRC and Rémi. 
Why is Rémi so shy? :-)

Phil

Re: [tuxdroid-user] Wiki update

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

About the widgets, it's a great idea ! But the choice of app will be important:

There's screenlets, which looks very promising:
http://hendrik.kaju.pri.ee/screenlets/

" Screenlets are small owner-drawn applications (written in Python, a
very simple object-oriented programming-language) that can be
described as "the virtual representation of things lying/standing
around on your desk". Sticknotes, clocks, rulers, the possibilities
are endless. The goal of the Screenlets base-class is to simplify the
creation of fully themeable mini-apps that each solve basic
desktop-work-related needs and generally improve the usability and
eye-candy of the modern Linux desktop. "

* it looks nice
* it has meteo, clocks, etc... <---- who said text to speech?
* it uses python and gnome
* beryl hackers just introduced screenlets support
(http://forum.ubuntu-fr.org/viewtopic.php?pid=714671), an OSX
Dashboard like.

Let's just hope they will eventually support osx's widget format one day...

What do you think? Should we build widgets using screenlets?

Florent

Re: [tuxdroid-user] Wiki update

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

I continued updating the wiki and reorganized it a bit.

I'm starting working on the firmware and I wanted to share the development  
with you so I added a firmware page where I'll try to put all information  
I have. Right now there's only the main topics I'm going to get into, with  
empty pages but that's a start ;-)

- Standalone behavior - description of the standalone behavior that should  
be integrated into Tux.
- Remote mode - control your tux with the remote only, no computer here.
- Light sensor - schema, measurement and linearization of the light  
measurement.
- Tux ID - adding an identification code in tux firmware.
- Sleep mode - adding a sleep mode in tux to increase battery life.

I'll keep you updated when I'll really start dealing with that.

On the other hand, we got a nice release of tuxsetup last week and it  
seems to be quite stable and good. Thanks to Philippe and Damien for their  
last commits, and all the others that reported bug, feedback and  
suggestions at different places. Now I think we should really try to get  
something that uses it. And the marketing team needs something badly so  
they decided to get Rémi working on Tux Widgets from this week on. Widgets  
are fun, it's a hot word,  it's great for marketing but is it somehow  
useful for us? Well, I got a meeting with Rémi yesterday and I learned  
about that. Actually it's pretty close to our discussion a while ago about  
a manager application with a plugin framework  
(http://wiki.tuxisalive.com/index.php/New_software_architecture), just  
%s/plugin/widget/g :-)

So at the end that's a pretty good thing because it will be easy to make a  
widget out of a small script and the widget manager will handle priorities  
and conflicts. I added all I know on this topic on the wiki, there's also  
a list of all the widgets that are going to be developed first, have a  
look by yourself at http://wiki.tuxisalive.com/index.php/Tux's_Widgets.  
All comments are welcome, I'll try to be the relay between the ML/wiki/IRC  
and Rémi. It's only a description as I don't have the code and don't know  
exactly what Rémi is going to change along the way.

Cheers,
david

ps. I need to work on the hardware but right now I rather feel like  
getting my NSLU2 out of the box and installing gentoo on it :-)

Re: [tuxdroid-user] Tuxdroid ans slug (NSLU2)

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

Le mardi 24 avril 2007,
"David Bourgeois" <da...@ja...> a =C3=A9crit :

[...]
> I guess we need the following structure in any case:
> USB <-> status structure and command stack <-> TCP/IP
>=20
> I don't have any experience with threads and TCP/IP but can't we do =20
> without threads at all? Isn't select() supposed to call a function
> when data is available?

Yes, it is generally possible to do without threads and use instead
select() along with a (more or less implicit) state machine. Haven't
looked how well/easily this could be done with the current daemon,
though.

> Now we could also use pipes to communicate with a separate USB
> process as the data can be kept as raw there.

We should avoid having several processes on setups where it is not
necessary.

Damien

[tuxdroid-user] Wiki update

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

Hi all,

I'm back at work since yesterday :-)

I updated mediawiki to version 1.9.3.
I moved it to another server as it was still on my old PII. Now I need to  
install some automatic backup for it. I also slightly (very slightly)  
updated the skin to better match the main portal. We still have to improve  
the logo as it doesn't show well on the dark background. Finally I added a  
link in the developer corner.
But all I wanted to say is that the address has been changed to  
http://wiki.tuxisalive.com

Any suggestions are welcome.

Cheers,
David

Re: [tuxdroid-user] Tuxdroid ans slug (NSLU2)

[Philippe T. <ph...@te...>]

Hi all,

Ok part of the mystery is solved:

On my PC:# getconf GNU_LIBPTHREAD_VERSION
NPTL 2.3.6

cf http://en.wikipedia.org/wiki/Native_POSIX_Thread_Library

On NSLU2:# getconf GNU_LIBPTHREAD_VERSION
linuxthreads-0.10

So the Etch for ARM seems to still use linuxthreads and from the above 
webpage:
"The LinuxThreads <http://en.wikipedia.org/wiki/LinuxThreads> project 
used this system call to simulate thread support entirely in userland. 
Unfortunately, it had a number of issues with true POSIX compliance, 
particularly in the areas of signal handling, scheduling, and 
inter-process synchronization primitives."

Immediate conclusion is that tuxdaemon *requires* NPTL to work properly.

 From some posts on the net, NPTL will be available on ARM with glibc 2.5
and on Debian apparently libc6 unstable is 2.5-3

I could give a try but the I've basically to upgrade all the distro to 
unstable and i'll do that only if I can mirror the current setup to 
another external harddrive.

Meanwhile we've now a better idea of what to do: read linuxthread faqs 
to understand te limitations and make tuxdaemon backward compatible with 
the slightly less POSIX compliant linuxthreads.

cf http://pauillac.inria.fr/~xleroy/linuxthreads/ and its readme and faq

Phil

Re: [tuxdroid-user] Tuxdroid ans slug (NSLU2)

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

On Tue, 24 Apr 2007 13:19:53 +0200, Philippe Teuwen <ph...@te...>  
wrote:
> What I propose as first step is to use only the libpthread
> from the GNU libc (glibc, pkg libc6) and to not mix them with the  
> libgthread
> from the Gnome lib (glib, pkg libglib2.0).
> So stick only to the pthread_xxx() fcts described in glibc-doc.
>
> uClibc should support pthreads properly:
>
> config UCLIBC_HAS_THREADS
> 	bool "POSIX Threading Support"
> 	depends on !HAS_NO_THREADS
> 	default y

In this case, will threads still be converted into different processes?
 From what I found, this was the behavior with 2.4 kernels: "linux-2.4  
didn't have threads; libraries for theading forked processes to do the  
trick."
But DebianSlug uses 2.6.18.
Anyway using pthreads instead of gthreads is a first good step for ARM.

Re: [tuxdroid-user] Tuxdroid ans slug (NSLU2)

[Philippe T. <ph...@te...>]

> The available glib is an old one (version 1.2), so the references to
> libgthread don't work. I tried to compile a more recent one (v 2.0.7),
> but it requires several other libraries -- libiconv, gettext... --
> which are not provided with uClibC.
>   
What I propose as first step is to use only the libpthread
from the GNU libc (glibc, pkg libc6) and to not mix them with the libgthread
from the Gnome lib (glib, pkg libglib2.0).
So stick only to the pthread_xxx() fcts described in glibc-doc.

uClibc should support pthreads properly:

config UCLIBC_HAS_THREADS
	bool "POSIX Threading Support"
	depends on !HAS_NO_THREADS
	default y

Then, if setuid still does not setup all processes properly after that,
I will reorder the operations:
- (in main) USB enumerate
- USB open handler
- setuid nobody
- create USB and TCP threads
So setuid is before creating threads/forking and I don't need TCP server 
to wait anymore.

And we'll see what is still broken.

Phil

Re: [tuxdroid-user] Tuxdroid ans slug (NSLU2)

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

> Now, as Philippe says:
>> Apparently all pthreads are handled through processes on ARM,
>> I've seen the same with apache2-mpm-worker where what should be
>> plenty of threads becoming standalone processes.
>> Probably a kind of thread emulation if the ARM arch doesn't allow
>> native support of threads, no idea...
>
> I don't have much experience with threads, but I am wondering: would
> it be interesting to create a specific version of tuxdaemon for
> embedded systems, based on forks and no longer on threads ? It might
> be handled more reliably, be easier to compile using the different
> SDKs and should not require lots of modifications.
>
> Any advice ?

I guess we need the following structure in any case:
USB <-> status structure and command stack <-> TCP/IP

I don't have any experience with threads and TCP/IP but can't we do  
without threads at all? Isn't select() supposed to call a function when  
data is available?
Now we could also use pipes to communicate with a separate USB process as  
the data can be kept as raw there.

Re: [tuxdroid-user] Tuxdroid ans slug (NSLU2)

[Florent V. <fvu...@gm...>]

Hi,

I tried to compile the tux daemon for OpenWrt (for an Asus WL-500GD)
and I also faced a problem:

The available glib is an old one (version 1.2), so the references to
libgthread don't work. I tried to compile a more recent one (v 2.0.7),
but it requires several other libraries -- libiconv, gettext... --
which are not provided with uClibC.
This was quite laborious, so I gave up and started looking at the
deamon's source code.

Now, as Philippe says:
>Apparently all pthreads are handled through processes on ARM,
>I've seen the same with apache2-mpm-worker where what should be
>plenty of threads becoming standalone processes.
>Probably a kind of thread emulation if the ARM arch doesn't allow
>native support of threads, no idea...

I don't have much experience with threads, but I am wondering: would
it be interesting to create a specific version of tuxdaemon for
embedded systems, based on forks and no longer on threads ? It might
be handled more reliably, be easier to compile using the different
SDKs and should not require lots of modifications.

Any advice ?

Cheers,
--
Florent Vuillemin

Re: [tuxdroid-user] Tuxdroid ans slug (NSLU2)

[Philippe T. <ph...@te...>]

Hi all,

Some more progress with the last trunk on ARM.

What I changed to get sth working up to now:
Commented out pthread_cond_wait() in the tcp_server otherwise it never 
starts.

Apparently all pthreads are handled through processes on ARM,
I've seen the same with apache2-mpm-worker where what should be
plenty of threads becoming standalone processes.
Probably a kind of thread emulation if the ARM arch doesn't allow
native support of threads, no idea...

I ran the tuxdaemon on the slug and took control with gtdi from my laptop.

1st problem:
I can do some actions but after a while the gui "slows down", feedback 
takes always 1 second when I do sth and the actions aren't performed 
anymore.
If I restart the daemon the gui recovers very nicely till the next 
freeze, probably always on the daemon side.

2nd problem:
After one of those freezes when I ctrl-c the daemon, I got a segfault, 
unfortunately I didn't get any code file, ulimit coresize was =0 and 
since I enabled it I could not reproduce the crash.
So just a little tip for all devels here: be sure to set ulimit -c to 
some high value to be able to capture any segfault when it happens ;-)

3rd problem:
Still as before, it looks like all forked processes (those which should 
be threads) still go through the main code at exit time and I get:
Daemon closed
Daemon closed
Could not delete PID file
Daemon closed
Could not delete PID file
-> one of the three already deleted the PID file and the 2 other 
complain that they cannot do it themselves.

Looks like all processes herited the signal(SIGINT, on_close_daemon);
and that an exit() has no effect on the other processes, which seems
logical but different from what threads do.

So I don't know how to maintain the thread architecture in a way 
compatible with ARM.

4th problem:
As I said I could not use yet pthread_cond_wait()

5th problem:
As I said in a previous mail only one of the processes actually changed 
its UID to nobody
while on i686 the three threads are actually changed to UID nobody

Phil

Re: [tuxdroid-user] Installing on a 64bit system

[Philippe T. <ph...@te...>]

For info I successfully compiled and ran tuxdaemon on a
Etch amd64 distribution (ran without attached dongle,
my 64bits box is in a datacenter...)

phil@devel:~/tuxdroid/daemon/trunk$ ldd tuxdaemon
libglib-2.0.so.0 => /usr/lib/libglib-2.0.so.0 (0x00002ab837b02000)
libgthread-2.0.so.0 => /usr/lib/libgthread-2.0.so.0 (0x00002ab837c9f000)
libpthread.so.0 => /lib/libpthread.so.0 (0x00002ab837da4000)
libusb-0.1.so.4 => /lib/libusb-0.1.so.4 (0x00002ab837eb9000)
libc.so.6 => /lib/libc.so.6 (0x00002ab837fc1000)
librt.so.1 => /lib/librt.so.1 (0x00002ab8381ff000)
/lib64/ld-linux-x86-64.so.2 (0x00002ab8379e3000)

So your probs should be solved just by installing the libusb* I mentioned

Phil

Re: [tuxdroid-user] Installing on a 64bit system

[Philippe T. <ph...@te...>]

Hi

> I recently crashed my system, and i installed ubuntu destkop 7.04 64
> bits. But i can't manage to launch tuxdaemon...
>
> ./tuxdaemon: error while loading shared libraries: libusb-0.1.so.4:
> cannot open shared object file: No such file or directory
>   
Did you install packages libusb-0.1-4 and libusb-dev?
Did you recompile the daemon from scratch after that?

Normally the library should be located in /lib
and /lib is anyway in the search path of ld

What gives "ldd tuxdaemon"?

> After copying... (from /lib32)
>   
Certainly not!
Once you're under 64bits libs you've to stick to 64bits!
(unless under a chroot/vserver/...)


Phil

[tuxdroid-user] Installing on a 64bit system

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

Hi

I recently crashed my system, and i installed ubuntu destkop 7.04 64
bits. But i can't manage to launch tuxdaemon...

./tuxdaemon: error while loading shared libraries: libusb-0.1.so.4:
cannot open shared object file: No such file or directory

strace gives me crap like:

open("/usr/lib/i686-linux-gnu/i686/sse2/cmov/libusb-0.1.so.4",
O_RDONLY) = -1 ENOENT (No such file or directory)

After copying... (from /lib32)
/opt/tuxdroid/bin/tuxdaemon: error while loading shared libraries:
libusb-0.1.so.4: wrong ELF class: ELFCLASS64

What should i do?

Thx