tux-droid-user — tuxdroid-user

Re: [tuxdroid-user] Speech software suite: TTS & Recognition

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

************* CVoiceControl

Well, i spoke too fast. Seems to me this one may be the good one
(needs some testing though): it's really pattern-matching oriented,
simple, intended for command line script launching.

"CVoiceControl is a tool that gives the user voice control over unix
commands. A template matching based speaker dependent isolated word
recognition approach is employed."

But it's 16 kHz, 16 bit, mono, not 8 kHz...

http://www.kiecza.net/daniel/linux/

There's even a deb !

I have to test it when i'm home :)

Depends on:

    * Ncurses library and header files
    * Pthreads library
    * OSS sound library (sys/soundcard.h)

************* Yet another speech recog software: Julius

We could also try Julius
http://julius.sourceforge.jp/en_index.php

[tuxdroid-user] Speech software suite: TTS & Recognition

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

*********** Speech recognition:

* Option 1: Xvoice + IBM ViaVoice

I found interesting stuff. I don't know why, but sphinx really seems
hard to use: it almost killed the xvoice project. So, the best option
for voice recognition / command launching seems to be the old Xvoice,
using IBM's viavoice (which isn't available anymore @ IBM); the
following link is a viavoice & xvoice tutorial

http://taint.org/wk/ViaVoiceModernLinux (2004 last updated)

+ It's supposed to work quite good
- old, unsupported, no future, non-free

* Option 2: sphinx

Considering tux's microphone performance, our best chance is with PocketSphinx
http://www.speech.cs.cmu.edu/pocketsphinx/

There's an package / ipkg already in openembedded
http://www.openembedded.org/viewmtn/revision.psp?id=5369901ff675d4c926113d856ce9da4c8c12fed0

*********************** Text to speech

* Option 1: stick with tuxdroid's team choice (acapela)

* Option 2: use the simple & efficient espeak

I really was surprised by the plug-n-play functionality, and it's
light resource footprint. http://espeak.sourceforge.net

I may switch to this one.

We may want to let the possibility to choose between several packages
(i.e. no hard acapela-specific integration). Is it possible do keep it
modular?

Re: [tuxdroid-user] Fwd: Re: subscribe tux-droid-user-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org

[Henrik G. B. <hg...@if...>]

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

> Finally, here it is. They need a first message to create the group,
> this will be the one :-) I just sent the archives now so you should
> get them in the near future.

Great.

> p.s. should we add the svn list there too?

Yes, please.

-- 
Henrik Grindal Bakken <hg...@if...>
PGP ID: 8D436E52
Fingerprint: 131D 9590 F0CF 47EF 7963  02AF 9236 D25A 8D43 6E52

[tuxdroid-user] Fwd: Re: subscribe tux-droid-user@lists.sourceforge.net

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

Finally, here it is. They need a first message to create the group, this=

will be the one :-)
I just sent the archives now so you should get them in the near future.

Yours faithfully

p.s. should we add the svn list there too?

------- Forwarded message -------
From: "Lars Magne Ingebrigtsen" <la...@gn...>
To: da...@ja...
Subject: Re: subscribe tux...@li...
Date: Wed, 21 Mar 2007 23:03:54 +0100

The following message is a courtesy copy of an article
that has been posted to gmane.discuss.subscribe as well.

da...@ja... writes:

> #gmane.comp.hardware.tuxdroid.user   tux...@li...urceforge.=
net
>   Tux Droid is a small robot companion for the Linux OS
>   mailman dummy
>   encode=3Dencrypt
>   lang=3Deng
>   mail-archive=3Dyes
>   url=3Dwww.tuxisalive.com
>
> Second attempt to subscribe, what am I supposed to do/receive after  =

> filling this form? Thanks

Subscription messages for the requested mailing lists have been sent.
The resulting groups will be created when the first message
arrives from the mailing lists.

Re: [tuxdroid-user] Dedicated distro/device thread

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

... added to the wiki

On 3/21/07, Florent THIERY <ft...@gm...> wrote:
> This discussion/idea started because tux cannot do a lot of standalone
> things (like waking a desktop up). Some people like me don't like to
> keep a computer up all the time (400-600W), so the only solution is to
> plug tux to an embedded device: silent, power efficient.
>
> Interesting devices (80=80 budget)
> - Linksys NSLU2 (2 usb, 2 ether, 266 mhz)
> - Asus WL-500G Premium Router (2 usb, ether switch, wlan...)
> - old computers
>
> Why?
> - multiple usb connectivity
> - officially GPLed -> custom firmwares
> - no sound, low power consumption : the ideal tuxdroid companion
>
> Interesting firmwares: ipkg-based firmwares
> - unslug firmware
> - openwrt/dd-wrt
>
> http://www.dd-wrt.com/wiki/index.php/Ipkg ipkg support on it's way
> Packages list: http://ipkg.nslu2-linux.org/feeds/unslung/wl500g/Packages
>
> Interesting packages:
> - heyu (X10 home automation): for REAL desktop wakingup (not only from
> hibernation), lights controlling, etc...
> - speex codec support
> - wakelan
> - attractive web interfaces (dd-wrt / x-wrt...), cgi-bin sys cmd
> execution (cf openwrt)
> - mpc/mpd
> - irc/jabber/IM gateways
>
> What misses (TODO/TOPORT/IDEAS)
> - speech things (flite / pocketsphinx)
> - webif dev, packaging
> - daemon porting (ARM)
> - aria2c frontend (for torrent dl)
> ....
>
> I really think that a web interface would do the job better than GTK
> bindings, plus it would allow working on non-desktop computers
> (screenless, from xbox, from anything...). How could it be achieved
> (the webif/python interfacing)?
>
> In fact, i'm imagining something like a real "home server", using tux
> as human interface ("tux, lights on !") with (very limited)
> emotions/animation.
>
> Please tell me what you think. I know it's off the tuxdroid project.
>
> Florent
>

Re: [tuxdroid-user] How tuxes "see" each other?

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

On Wed, 21 Mar 2007 15:58:24 +0100, Florent THIERY <ft...@gm...>  
wrote:

>> Basically, you could have a manager on your computer for all stuff that
>> occurs there, but the waker should be on the manager running on the  
>> slug.
>> We still need an access to that manaer from the computer for  
>> configuration
>> but after it should be able to run alone.
>
> So the gui would be used ONLY for application
> setup/activation/options? Upon "OK", it stores the parameters and the
> execution will be scheduled in the aggregator?

Yes, for the aggregator running on the slug, we need something like this.  
For the aggregator running on the computer, it doesn't really matter.

I thought of having the manager (or aggregator) very light and which  
handles the configuration and priorities/routing. Then a set of plugins  
could be installed, each plugin offering a functionality for tux. On a  
slug, you could have a waker plugin, a wheather plugin and an email plugin  
for example. Configuration could be done through a gui or simply  
configuration files. If you get an email, pressing on the head would read  
the emil, but if tux was waking you up, pressing on the head would stop  
the alarm. And pressing on the head when no event occured would tell the  
wheather forecast. That's the manager that should be able to route these  
events between the daemon and the plugins.

That's maybe not the good way to implement it but basically managing  
different functionalities is the problem we'll have to solve in the  
future. And having a computer running continuously is not something we  
usually accept so being able to run the daemon and the 'manager' on a  
small box is really necessary.

Re: [tuxdroid-user] How tuxes "see" each other?

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

> Basically, you could have a manager on your computer for all stuff that
> occurs there, but the waker should be on the manager running on the slug.
> We still need an access to that manaer from the computer for configuration
> but after it should be able to run alone.

So the gui would be used ONLY for application
setup/activation/options? Upon "OK", it stores the parameters and the
execution will be scheduled in the aggregator?

Re: [tuxdroid-user] How tuxes "see" each other?

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

On Wed, 21 Mar 2007 14:25:06 +0100, Florent THIERY <ft...@gm...>  =

wrote:

> On 3/21/07, David Bourgeois <da...@ja...> wrote:
>> Yep, a powered usb hub may help probably, though a special firmware  =

>> needs
>> to be done but that seems possible.
>>
>> > I think i'll buy an NSLU2 for always-on operation. That way, the NS=
LU2
>> > will be able to send wake on lan packets to the desktop (on
>> > hibernation only).
>> >
>> > Still, it sets new problems: no gui ! How can i use tux apps if tux=
 is
>> NSLU2 is certainly the solution to go for ow as it seems easier and w=
ill
>> give you much more functionality. The daemon can run on the slug and =
you
>> can still use your gui's or scripts from any computer as they  =

>> communicate
>> together through tcp/ip.
>
> Indeed, but if i close the waker's GUI, the waker won't work right?

Yes, but we'll need a kind of aggregator program, somethink that manages=
  =

all functionalities you want your Tux to have. I put some thoughts about=
  =

this on the wiki:  =

http://www2.tux-is-alive.com/wiki/New_software_architecture
Basically, you could have a manager on your computer for all stuff that =
 =

occurs there, but the waker should be on the manager running on the slug=
.  =

We still need an access to that manaer from the computer for configurati=
on  =

but after it should be able to run alone.

> I'm also considering a WL-500gP over the NSLU2 (not significantly more=

> expensive; maybe even less, and more powerful, + wifi ! + switch).
> What could be awesome: starting with dd-wrt, and add custom web
> interface controls for tux (ex: a waker tab :p). Installing a single
> tux ipkg may add the daemon, python apps + webif extension at once.
>
> From NSUL2 homepage: "There are also Downloadable Packages available
> for the Unslung firmware and also for other devices like the Asus
> WL-500g,WL-HDD, WL-500gx, WL-500gP routers, the Synology DS-101 and
> DS-101g+ NAS devices, and other wireless routers with support for
> external storrage and based on Oleg or DD-WRT firmware."
>
> So, a single package may work for both NSLU2 & DD-WRT.

Yep, feel free to share your experiences on the wiki too, the page will =
be  =

http://www2.tux-is-alive.com/mediawiki/index.php?title=3DNAS

[tuxdroid-user] Dedicated distro/device thread

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

This discussion/idea started because tux cannot do a lot of standalone
things (like waking a desktop up). Some people like me don't like to
keep a computer up all the time (400-600W), so the only solution is to
plug tux to an embedded device: silent, power efficient.

Interesting devices (80=80 budget)
- Linksys NSLU2 (2 usb, 2 ether, 266 mhz)
- Asus WL-500G Premium Router (2 usb, ether switch, wlan...)
- old computers

Why?
- multiple usb connectivity
- officially GPLed -> custom firmwares
- no sound, low power consumption : the ideal tuxdroid companion

Interesting firmwares: ipkg-based firmwares
- unslug firmware
- openwrt/dd-wrt

http://www.dd-wrt.com/wiki/index.php/Ipkg ipkg support on it's way
Packages list: http://ipkg.nslu2-linux.org/feeds/unslung/wl500g/Packages

Interesting packages:
- heyu (X10 home automation): for REAL desktop wakingup (not only from
hibernation), lights controlling, etc...
- speex codec support
- wakelan
- attractive web interfaces (dd-wrt / x-wrt...), cgi-bin sys cmd
execution (cf openwrt)
- mpc/mpd
- irc/jabber/IM gateways

What misses (TODO/TOPORT/IDEAS)
- speech things (flite / pocketsphinx)
- webif dev, packaging
- daemon porting (ARM)
- aria2c frontend (for torrent dl)
....

I really think that a web interface would do the job better than GTK
bindings, plus it would allow working on non-desktop computers
(screenless, from xbox, from anything...). How could it be achieved
(the webif/python interfacing)?

In fact, i'm imagining something like a real "home server", using tux
as human interface ("tux, lights on !") with (very limited)
emotions/animation.

Please tell me what you think. I know it's off the tuxdroid project.

Florent

Re: [tuxdroid-user] How tuxes "see" each other?

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

On 3/21/07, David Bourgeois <da...@ja...> wrote:
> Yep, a powered usb hub may help probably, though a special firmware needs
> to be done but that seems possible.
>
> > I think i'll buy an NSLU2 for always-on operation. That way, the NSLU2
> > will be able to send wake on lan packets to the desktop (on
> > hibernation only).
> >
> > Still, it sets new problems: no gui ! How can i use tux apps if tux is
> NSLU2 is certainly the solution to go for ow as it seems easier and will
> give you much more functionality. The daemon can run on the slug and you
> can still use your gui's or scripts from any computer as they communicate
> together through tcp/ip.

Indeed, but if i close the waker's GUI, the waker won't work right?

> Then we can also have a client on the slug itself that could handle your
> wakeup clock, get sounds/text from the internet to stream it to your tux.
> That would be a great functionality yo have soon.

That's what i'm aiming :)

By the way: i think the way to go for tux python apps is interfacing
with regular software: mpd, x10 controlling apps, etc. What's the way
to go? sysexecs?

> I removed the packaging of my slug yesterday, I'm now determined to give
> it a go, I think I'll try to install gentoo on it. We should do it
> together and track this on the wiki. I'll add a page there.

We may try rolling our own angstr=F6m distro

I'm also considering a WL-500gP over the NSLU2 (not significantly more
expensive; maybe even less, and more powerful, + wifi ! + switch).
What could be awesome: starting with dd-wrt, and add custom web
interface controls for tux (ex: a waker tab :p). Installing a single
tux ipkg may add the daemon, python apps + webif extension at once.

>From NSUL2 homepage: "There are also Downloadable Packages available
for the Unslung firmware and also for other devices like the Asus
WL-500g,WL-HDD, WL-500gx, WL-500gP routers, the Synology DS-101 and
DS-101g+ NAS devices, and other wireless routers with support for
external storrage and based on Oleg or DD-WRT firmware."

So, a single package may work for both NSLU2 & DD-WRT.

Re: [tuxdroid-user] How tuxes "see" each other?

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

Yep, a powered usb hub may help probably, though a special firmware needs  
to be done but that seems possible.

> I think i'll buy an NSLU2 for always-on operation. That way, the NSLU2
> will be able to send wake on lan packets to the desktop (on
> hibernation only).
>
> Still, it sets new problems: no gui ! How can i use tux apps if tux is
> connected on NSLU2 on my main desktop?
> - Simply let the daemon run on the NSLU2, and connect to this daemon
> from my desktop ? But then the python apps will be closed when the
> computer sleeps. I will be limited to non-gui only apps :(
> - Or nfs/samba share the devices? I'm getting confused now :-p

NSLU2 is certainly the solution to go for ow as it seems easier and will  
give you much more functionality. The daemon can run on the slug and you  
can still use your gui's or scripts from any computer as they communicate  
together through tcp/ip.
Then we can also have a client on the slug itself that could handle your  
wakeup clock, get sounds/text from the internet to stream it to your tux.  
That would be a great functionality yo have soon.

I removed the packaging of my slug yesterday, I'm now determined to give  
it a go, I think I'll try to install gentoo on it. We should do it  
together and track this on the wiki. I'll add a page there.

Re: [tuxdroid-user] How tuxes "see" each other?

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

> A timer is no real problem though you'll never get it accurate. Need to do
> some tests about calibration but we would have need a crystal and a real
> time clock to do such a thing.

At least we would have a "real" waker functionnality; plus, the sound
of motors can easily frighten you up in the morning :)

> The main issue comes from the powering, if the dongle is unpowered,
> there's no way to get connected with Tux. Can a usb keyboard wake-up your
> computer? I don't think so.

I found this (concerns A7N8X mb):

"The USB device wake-up feature requires a power supply that can
provide 500 mA ... for each USB port. Otherwise, the system would not
power up."

So, if we use a powered usb hub...

> Or use an old wakeup clock with
> the hammers and bells and stick it close to your keyboard  so the hammers
> hit it :-)

LOL. Or simply make the hammer hit me instead.

I think i'll buy an NSLU2 for always-on operation. That way, the NSLU2
will be able to send wake on lan packets to the desktop (on
hibernation only).

Still, it sets new problems: no gui ! How can i use tux apps if tux is
connected on NSLU2 on my main desktop?
- Simply let the daemon run on the NSLU2, and connect to this daemon
from my desktop ? But then the python apps will be closed when the
computer sleeps. I will be limited to non-gui only apps :(
- Or nfs/samba share the devices? I'm getting confused now :-p

Re: [tuxdroid-user] How tuxes "see" each other?

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

On Wed, 21 Mar 2007 13:05:18 +0100, Florent THIERY <ft...@gm...>  
wrote:

> Sorry to talk again about that, but would it be possible for tux to
> trigger an action from the hub? The fish is unpowered when the
> computer is shut down, right?
>
> What i don't get is: a keyboard press can power a computer up (acpi
> bios function) when it's off. Could we do the same with the fish?
>
> For that we would need:
> - a built in timer for standalone waker functionnality (in tux) -> how  
> feasible?
> - usb keyboard press emulation on the fish
>
> But the more i think about it, the less it seems doable...

A timer is no real problem though you'll never get it accurate. Need to do  
some tests about calibration but we would have need a crystal and a real  
time clock to do such a thing.

The main issue comes from the powering, if the dongle is unpowered,  
there's no way to get connected with Tux. Can a usb keyboard wake-up your  
computer? I don't think so.

Now if we can startup the computer from a logic signal connected  
somewhere, a hack that could power the dongle separately and adding an  
output from the RF board of the dongle and a custom firmware could do the  
trick. That's something we can imagine. But to wake-up your computer at a  
certain time, you better use your bios or build a small real time clock  
that connects to the computer directly. Or use an old wakeup clock with  
the hammers and bells and stick it close to your keyboard  so the hammers  
hit it :-)

Re: [tuxdroid-user] How tuxes "see" each other?

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

Sorry to talk again about that, but would it be possible for tux to
trigger an action from the hub? The fish is unpowered when the
computer is shut down, right?

What i don't get is: a keyboard press can power a computer up (acpi
bios function) when it's off. Could we do the same with the fish?

For that we would need:
- a built in timer for standalone waker functionnality (in tux) -> how feasible?
- usb keyboard press emulation on the fish

But the more i think about it, the less it seems doable...

Re: [tuxdroid-user] How tuxes "see" each other?

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

On Mon, 19 Mar 2007 21:02:54 +0100, Florent THIERY <ft...@gm...>  
wrote:

> About standalone features: could you please try describing how far
> these feature could go?

Sorry but that'll take some time to write something clear and I'll add a  
page about this on the wiki but I have other priorities now. I'll tell you  
when it's ready, it'll be there: http://www2.tux-is-alive.com

But in a few words, right now we can only store some small sequences of  
tux commands (sounds, movements, leds, send IR,...). Then you can trigger  
one of these sequences from an event. These events needs to be hardcoded  
in the firmware but we can have them even if we don't use them.

What I planned to do at first is to have:
- configuration registers in flash and eeprom that enable/disable events
- events associated to sequences
- sequence definitions in eeprom

When you press on the head button, I should do:
- detect the head button
- if the configuration register for the head button event is enabled, I  
emmit the head button event
- the head button event will launch the head button sequence which is  
stored in eeprom ans is a blink of the blue led's

I would like to be able to configure that from the computer by:
- enabling or disabling events (registers changed in flash so when you  
switch off, you loose your changes)
- storing configuration registers in eeprom to keep changes permanently
- customizing the sequences in eeprom

Maybe we can also have 2 sets of configuration registers so one is valid  
when tux is connected to the RF and one when tux is really in standalone.

You could do much more with standalone but then you'll have to customize  
the firmware directly and because the memory is limited, you're likely to  
have to remove stuff to add what you want to do. But it should be possible  
to add stuff on the I2C bus like temperature/humidity sensors,  
accelerometers,... you may also have to open tux and alter the circuit if  
you want to connect other things. If you don't do that, you're limited  
anyway by the input of tux which is only a few buttons, light and IR.

HTH,
david

Re: [tuxdroid-user] Some IR & RF questions...

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

On Tue, 20 Mar 2007 23:26:50 +0100, Philippe Teuwen <ph...@te...>  
wrote:

> Hi,
>
> How a dongle and a tux are paired?

They are not :-)

> Is it a unique code?
> What if many tuxes/dongles are present simultaneously?
> Could one single dongle command several tuxes?

At the moment, when the dongle is plugged, it sends an initialization  
frame. Then when you switch on Tux, it initializes in receiving mode  
looking for that frame. When it get's it, they exchange a code which is  
kept all the time the connection stays stable. When the connection drops  
(tux switched off or oo far), the dongle resets itself in init mode.

So now you have to power your dongl and tux simultaneously and when  
they're connected, you can power another set of tux/dongle, otherwise you  
may mix them.

One dongle won't never be able to control several tux with the current rf  
protocol. Right now, audio frames are taking the complete bandwidth  
continuously. It's a major rewrite of the RF modules to do such a thing  
and you won't be able to use the audio simultaneously on 2 tux anyway. And  
if you have 2 tux, you also have 2 dongles. btw, what's the plural of tux?  
Is it tux, tuxs or tuxes? :D

I personally don't think it's interesting to do that work, but to have a  
daemon that uses 2 dongles correctly would be great. One of my proposals  
were to be able to set a name inside a tux (in eeprom somewhere) from the  
computer interface, then whenever you reconnect the same tux, the daemon  
could get that name whatever dongle it's connected to and you can control  
your tux by it's name.

>
> How to get an IR RC5 code from the API?
> I saw only commands to send RC5 but I'd like to learn the codes from my
> own remote unit.

It's sent in the status. Whenever a code is received, there's a IR status  
sent back that the daemon should capture.
I'm going to rewrite the commands.h documentation, that should be clearer  
afterwards. Yes I'll do it someday ;-)

All the codes are listed in remote.h. Don't forget the toggle bit,  
whenever you push a key, the toggle bit get toggled. So if you push the  
same key, you get A then B then A then B where A is the code + togle low,  
and B is the same code and toggle high

Cheers,
david

[tuxdroid-user] Some IR & RF questions...

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

Hi,

How a dongle and a tux are paired?
Is it a unique code?
What if many tuxes/dongles are present simultaneously?
Could one single dongle command several tuxes?

How to get an IR RC5 code from the API?
I saw only commands to send RC5 but I'd like to learn the codes from my 
own remote unit.

Phil

[tuxdroid-user] speech recognition software

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

Hi list,

David and I had a chat during last FOSDEM about opportunities to use speech
recognition software to control the droid. Here is a project to help open source
developers make their project work better by submitting your speech samples to
add them to a speech corpus used to train 4 open source projects that work on
that task:

  http://www.voxforge.org/home

Best,

-- 
Olivier

Re: [tuxdroid-user] How tuxes "see" each other?

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

About standalone features: could you please try describing how far
these feature could go?

Re: [tuxdroid-user] How tuxes "see" each other?

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

Yep, it's IR but it doesn't work correctly. We didn't have enough time t=
o  =

fix that before production and since priorities have changed.

I think this feature should be handled by the standalone behavior and th=
e  =

event manager in the firmware instead of the ir functions directly. As I=
'm  =

planning to rewrite the ir functions at some point, I didn't try to fix =
 =

the greeting event.

Normally, you should have 1 tux that sends a code, the other one sees it=
,  =

says greet1 and send another code, the first tux receives that code, say=
s  =

greet2 and sends a thirs code that the second tux detects again and says=
  =

greet3. But usually you'll get greet1 and occasionally greet2 but that's=
  =

all.

david which is back in localtime ;-)

On Mon, 19 Mar 2007 18:17:51 +0100, Philippe Teuwen <ph...@te...>  =

wrote:

> Hi,
>
> I saw those standalone features allowing 2 tuxes to greet each other.
> But actually how do they "see" each other?
> RF ping?
> IR ping?
>
> Phil
>
>
>
> ----------------------------------------------------------------------=
---
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to shar=
e  =

> your
> opinions on IT & business topics through brief surveys-and earn cash
> http://www.techsay.com/default.php?page=3Djoin.php&p=3Dsourceforge&CID=
=3DDEVDEV
> _______________________________________________
> tux-droid-user mailing list
> tux...@li...
> https://lists.sourceforge.net/lists/listinfo/tux-droid-user

Re: [tuxdroid-user] Seeing diffs of last modifs?

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

Unfortunaltely not, but the next version of Plone which is due soon will=
  =

get versioning and staging so that will be possible then.

On Mon, 19 Mar 2007 18:09:21 +0100, Philippe Teuwen <ph...@te...>  =

wrote:

> Hi all,
>
> I usually monitor http://www.tuxisalive.com/recently_modified
> but is there a way (like in a wiki, hum hum) to see what are the actua=
l
> changes done on e.g. a howto page which was recently modified?
>
> Phil
>
>
>
> ----------------------------------------------------------------------=
---
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to shar=
e  =

> your
> opinions on IT & business topics through brief surveys-and earn cash
> http://www.techsay.com/default.php?page=3Djoin.php&p=3Dsourceforge&CID=
=3DDEVDEV
> _______________________________________________
> tux-droid-user mailing list
> tux...@li...
> https://lists.sourceforge.net/lists/listinfo/tux-droid-user

[tuxdroid-user] How tuxes "see" each other?

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

Hi,

I saw those standalone features allowing 2 tuxes to greet each other.
But actually how do they "see" each other?
RF ping?
IR ping?

Phil

Re: [tuxdroid-user] [PATCH] Using SO_REUSEADDR on TCP socket

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

Thanks a lot, I applied the patch in svn. Next step is to give you svn  =

access :-)

On Mon, 19 Mar 2007 14:12:10 +0100, Philippe Teuwen <ph...@te...>  =

wrote:

> Hi,
>
> Good one!
> This problem hitted me too this weekend.
> I filed your patch in the issue tracker.
> I guess the same is true for the tuxttsdaemon but there it's up to Kys=
oh
> to release a new version.
>
> Phil
>
>
>
> ----------------------------------------------------------------------=
---
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to shar=
e  =

> your
> opinions on IT & business topics through brief surveys-and earn cash
> http://www.techsay.com/default.php?page=3Djoin.php&p=3Dsourceforge&CID=
=3DDEVDEV
> _______________________________________________
> tux-droid-user mailing list
> tux...@li...
> https://lists.sourceforge.net/lists/listinfo/tux-droid-user

[tuxdroid-user] Seeing diffs of last modifs?

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

Hi all,

I usually monitor http://www.tuxisalive.com/recently_modified
but is there a way (like in a wiki, hum hum) to see what are the actual
changes done on e.g. a howto page which was recently modified?

Phil

Re: [tuxdroid-user] [PATCH] Using SO_REUSEADDR on TCP socket

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

Hi,

Good one!
This problem hitted me too this weekend.
I filed your patch in the issue tracker.
I guess the same is true for the tuxttsdaemon but there it's up to Kysoh
to release a new version.

Phil