tux-droid-user — tuxdroid-user

Re: [tuxdroid-user] doxygen style: "\" or "@" ?

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

On Sun, 24 Jun 2007 11:05:42 +0200, David Bourgeois <da...@ja...>  
wrote:

> On Sat, 23 Jun 2007 21:52:32 +0200, neimad <ror...@gm...> wrote:
>
>> Hello,
>>
>> I started "fixing" function comments by making them use doxygen
>> syntax, and I noticed that we currently have doxygen comments using
>> both "\" and "@" styles:
>>
>>     \param[in] toto  Stuff
>>     @param[in] titi  More stuff
>>
>> I may be partly responsible for this, being accustomed to using "\" at
>> work while Tux droïd's code was using "@" (IIRC) where there were dox
>> comments (not many ;-)).
>>
>> It's not important but I like consistency, and I think we should
>> choose one or the other ("@" pleases my eyes more, but I don't really
>> mind).
>>
>> 	Damien
>
> I used \param in the (few documented) firmware functions so we can go  
> with
> that if we're all used to it.
>

I didn't notice you already added a couple of @param, it really doesn't  
matter for me which one we choose. Just go on and I'll follow.

Re: [tuxdroid-user] doxygen style: "\" or "@" ?

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

On Sat, 23 Jun 2007 21:52:32 +0200, neimad <ror...@gm...> wrote:

> Hello,
>
> I started "fixing" function comments by making them use doxygen
> syntax, and I noticed that we currently have doxygen comments using
> both "\" and "@" styles:
>
>     \param[in] toto  Stuff
>     @param[in] titi  More stuff
>
> I may be partly responsible for this, being accustomed to using "\" at
> work while Tux droïd's code was using "@" (IIRC) where there were dox
> comments (not many ;-)).
>
> It's not important but I like consistency, and I think we should
> choose one or the other ("@" pleases my eyes more, but I don't really
> mind).
>
> 	Damien

I used \param in the (few documented) firmware functions so we can go with  
that if we're all used to it.

[tuxdroid-user] doxygen style: "\" or "@" ?

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

Hello,

I started "fixing" function comments by making them use doxygen
syntax, and I noticed that we currently have doxygen comments using
both "\" and "@" styles:

    \param[in] toto  Stuff
    @param[in] titi  More stuff

I may be partly responsible for this, being accustomed to using "\" at
work while Tux dro=C3=AFd's code was using "@" (IIRC) where there were dox
comments (not many ;-)).

It's not important but I like consistency, and I think we should
choose one or the other ("@" pleases my eyes more, but I don't really
mind).

	Damien

Re: [tuxdroid-user] Small issue with tcp/ip when disconnecting the socket

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

"David Bourgeois" <da...@ja...> writes:
> But looking into this, I came up with a question about this:
>  if ((send(tcp_clients_handle[i], data, sizeof(tcp_frame_t), 0)) =3D=3D 0)
>             tcp_remove_client(i);
>
> R=C3=A9mi got this in the past if the client was exited without telling to
> the  daemon, 'send' would return 0.
> Looking at the man page, I can't find how send can return 0, at least
> now  in non blocking mode either it adds the data or it returns -1 as
> an error.  But in blocking mode, 0 would mean that 0 bytes have been
> successfully  sent. Any clarification about this?
> I guess that we can change the '=3D=3D 0' into '<=3D 0' or better '< 0' if
> we're  sure 0 can't happen anymore in non-blocking mode.

Unless I'm mistaken, in the current code the sockets are *blocking*.
If send() returns < 0, we can assume the connection to the client has
been closed, yes.

	Damien

Re: [tuxdroid-user] Small issue with tcp/ip when disconnecting the socket

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

False alarm, it seems it's a bug in tuxgi which still tries to get the RF  
status even after it's disconnected. Sorry for the trouble :-/

But looking into this, I came up with a question about this:
  if ((send(tcp_clients_handle[i], data, sizeof(tcp_frame_t), 0)) == 0)
             tcp_remove_client(i);

Rémi got this in the past if the client was exited without telling to the  
daemon, 'send' would return 0.
Looking at the man page, I can't find how send can return 0, at least now  
in non blocking mode either it adds the data or it returns -1 as an error.  
But in blocking mode, 0 would mean that 0 bytes have been successfully  
sent. Any clarification about this?
I guess that we can change the '== 0' into '<= 0' or better '< 0' if we're  
sure 0 can't happen anymore in non-blocking mode.

Cheers,
David

[tuxdroid-user] Small issue with tcp/ip when disconnecting the socket

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

Hi neimad,

You removed a usleep in send_daemon_disconnected() and asked me why it was  
there.

     tcp_server_send_raw(data);
     usleep(?);
     close(tcp_server_handle);

I had no idea but I now found that sometimes the client doesn't get the  
message so the daemon quits but the client is still hooked on the socket.
Does it also relates to the fact that sockets are now non-blocking?

Any idea on what to do here?

Thanks,
David

Re: [tuxdroid-user] Including dfu-programmer in tuxsetup

[Andrew S. <str...@as...>]

David Bourgeois wrote:

> Andrew, is it OK with you if we include the .deb I generated from your 
> .dcs file in our tuxsetup package until you find a sponsor? We could 
> also ask the administrator of dfu-programmer to host it on the 
> sourceforge download page.

Sure. You should probably rename the generated .deb to include the 
distribution (i.e. include "ubuntu-feisty" or just "feisty" in the 
filename somewhere), because .debs mostly don't work with other 
distributions/versions.

-Andrew

Re: [tuxdroid-user] Including dfu-programmer in tuxsetup

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

Just found that dfu-programmer as also been recently submitted to fedora=
:
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=3D211761

Re: [tuxdroid-user] Including dfu-programmer in tuxsetup

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

On Thu, 14 Jun 2007 22:38:37 +0200, David Bourgeois <da...@ja...>  
wrote:

>> Until Andrew Straw has found a sponsor, you can use the work Andrew has
>> done to build a Debian package for dfu-programmer yourself and set up a
>> tuxdroid-repository where you can download it. There is no need to do
>> duplicated work.
>>
>> I have used Andrew's work to build a Debian-package for dfu-programmer
>> myself, works without a problem:
>
> That's a good solution too. I thought it didn't work. I'm going to try it
> under ubuntu too. Maybe it's possible to upload it on the dfu-programmer
> sourceforge project where it would make more sense. There's already an  
> rpm
> there that should work for fedora. I'll keep you updated.

I had a try with the debian package of Andrew Straw and it works fine on  
Ubuntu. OTH Rémi tried to use the rpm available on the download page of  
dfu-programmer  
(http://sourceforge.net/project/showfiles.php?group_id=147246) and that  
didn't work because of some dependencies that couldn't be resolved.  
Anybody got dfu-programmer installed from the rpm?

Andrew, is it OK with you if we include the .deb I generated from your  
.dcs file in our tuxsetup package until you find a sponsor? We could also  
ask the administrator of dfu-programmer to host it on the sourceforge  
download page.

Cheers,
David

Re: [tuxdroid-user] [tuxdroid-svn] Duplicate enum

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

On Sat, 16 Jun 2007 19:40:26 +0200, neimad <ror...@gm...> wrote:

> "David Bourgeois" <da...@ja...> writes:
>
> [...]
>> Now that I pointed out the difference, improvements on this are
>> welcomed  of course.
>> If I rewsrite the usb files as a usb module, usb_tux_connection_t
>> should  be private to the module and should be the basis for the USB
>> interface as  it's part of the functionalities of the USB dongle. This
>> is hardware  driven so should be quite static.
>
> Making usb_tux_connection_t private would help indeed ;-) As for the
> usb module, I'm all for it - see my post <87v...@gm...>
> (in thread "Daemon to USB connection").

I didn't reply to your post yet as I've still to dig into this first, but  
I'm already converted to your usb module approach, that's where my  
statement came from actually :-)

>> On the other hand, we do whatever we want with tux_connection_t. If we
>> redesign the structures, we should also find a way to organize all
>> functions supported by the daemon, and these included.
>
> Btw, aren't these _commands_ (tux_connection_t, at least) ? And thus,
> shouldn't they be named tux_cmd_t or something ? Right now they sound
> like connection operations only, whereas they're not. And this will be
> even more true in the future, with more high-level operations, as you
> describe. (Not high priority, so this may be postponed to after we've
> cleaned up the usb stuff.)

Yes they are commands, but these are special as they deal with the RF  
connection (connect, disconnect, wakeup) and don't follow the same  
protocol as standard commands (eyes, mouth, leds, etc.) They're managed by  
the 2 RF modules, and tux (the core and audio CPUs) don't have any clue  
about these directly. So they can be mixed with other commands from a user  
point of view but they still make a category of their own. I don't mind  
merging them in a tux_cmd_t. I think we'll have the opportunity to discuss  
this structure when dealing with the api. I'll make a list of all hardware  
commands (handled by tuxdroid) and all end user functionalities we already  
have.

David

Re: [tuxdroid-user] [tuxdroid-svn] Duplicate enum

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

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

[...]
> Now that I pointed out the difference, improvements on this are
> welcomed  of course.
> If I rewsrite the usb files as a usb module, usb_tux_connection_t
> should  be private to the module and should be the basis for the USB
> interface as  it's part of the functionalities of the USB dongle. This
> is hardware  driven so should be quite static.

Making usb_tux_connection_t private would help indeed ;-) As for the
usb module, I'm all for it - see my post <87v...@gm...>
(in thread "Daemon to USB connection").

> On the other hand, we do whatever we want with tux_connection_t. If we
> redesign the structures, we should also find a way to organize all
> functions supported by the daemon, and these included.

Btw, aren't these _commands_ (tux_connection_t, at least) ? And thus,
shouldn't they be named tux_cmd_t or something ? Right now they sound
like connection operations only, whereas they're not. And this will be
even more true in the future, with more high-level operations, as you
describe. (Not high priority, so this may be postponed to after we've
cleaned up the usb stuff.)

	Damien

Re: [tuxdroid-user] [tuxdroid-svn] Duplicate enum

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

On Sat, 16 Jun 2007 14:25:08 +0200, neimad <ror...@gm...> wrote=
:

> Enum usb_tux_connection_t (USBDaemon_usb_enum.h) seems to duplicate
> most of enum tux_connection_t (USBDaemon_status_table.h):
>
>     typedef enum
>     {
>         USB_TUX_CONNECTION_DISCONNECT =3D 1,
>         USB_TUX_CONNECTION_CONNECT =3D 2,
>         USB_TUX_CONNECTION_ID_REQUEST =3D 3,
>         USB_TUX_CONNECTION_ID_LOOKUP =3D 4,
>         USB_TUX_CONNECTION_CHANGE_ID =3D 5,
>         USB_TUX_CONNECTION_WAKEUP =3D 6,
>         USB_TUX_CONNECTION_WIRELESS_CHANNEL =3D 7,
>     } usb_tux_connection_t;
>
>     typedef enum
>     {
>         TUX_CONNECTION_DISCONNECT =3D 1,
>         TUX_CONNECTION_CONNECT =3D 2,
>         TUX_CONNECTION_RANDOM =3D 3,
>         TUX_CONNECTION_ID_REQUEST =3D 4,
>         TUX_CONNECTION_ID_LOOKUP =3D 5,
>         TUX_CONNECTION_CHANGE_ID =3D 6,
>         TUX_CONNECTION_SLEEP =3D 7,
>         TUX_CONNECTION_WAKEUP =3D 8,
>         TUX_CONNECTION_WIRELESS_CHANNEL =3D 9,
>     } tux_connection_t;
>
> They seem to represent the same thing, so I think we should get rid of=

> one of them.
>
> 	Damien

Indeed for now they look rather the same but the second ones are at a  =

higher abstraction level.
usb_tux_connection_t are all commands supported by the USB dongle and th=
e  =

values for the USB frames so these defines can't be chnaged. There's a  =

dedicated command (first byte of the USB frame) group for all these  =

commands.
tux_connection are the commands made available to the end user through t=
he  =

api. Most of them are similar though it's not a simple call of the usb  =

functions. And we can offer more commands here that will never be  =

implemented in the USB dongle, like the random connection. It would also=
  =

be possible to have some USB commands not made available to the end user=
  =

but used as primitives by other user commands.

Actually we should have the same kind of similarity between all commands=
  =

sent to tux (commands.h) and all commands available through the api. Rig=
ht  =

now they're pretty much the same but I'd like to add more and more high =
 =

level functions in the daemon that will use the same basic set of tux  =

commands.

Now that I pointed out the difference, improvements on this are welcomed=
  =

of course.
If I rewsrite the usb files as a usb module, usb_tux_connection_t should=
  =

be private to the module and should be the basis for the USB interface a=
s  =

it's part of the functionalities of the USB dongle. This is hardware  =

driven so should be quite static.

On the other hand, we do whatever we want with tux_connection_t. If we  =

redesign the structures, we should also find a way to organize all  =

functions supported by the daemon, and these included.

David

Re: [tuxdroid-user] Refactoring the API

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

On Fri, 15 Jun 2007 19:31:57 +0200, neimad <ror...@gm...> wrote:

> "David Bourgeois" <da...@ja...> writes:
>
> [...]
>> some end user  applications very quickly which explains why the API is
>> evolving the way  it is now. If we start changing this API, he'll get
>> a lot of troubles  merging all his changes every 2 weeks with ours,
>> and we'll get the same  trouble seing those huge commits changing
>> nearly every line once in a  while. For his applications, Rémi needs
>> to keep his flexibility. On our  side, we want to follow the style
>> guidelines and best development  practices that makes good OS
>> software.
>
> If we start a new API from scratch, maybe we could also write a
> wrapper for new API exposing the same old API, so as to ease the
> transition. This may not be possible for everything, though...

Yes, I'd like to get thattoo though that should not be a requirement  
neither a priority. The project is still at its early stages and there  
isn't yet a lot of applications lying around so I don't think it will  
generate much trouble to refactor the API. I'd vote for a good design  
prior to compatibility.

>> Some strange things also. Right now all status are read from the USB
>> and  stored in variables. The clients get ALL status continuously
>> through the  api, these status are parsed to trigger a few things then
>> dropped. So when  a client wants to know the status of something, it
>> still needs to do a new  request to the daemon which will send the
>> status again. Even if it's not a  big load on the network, it still is
>> a lot of useless transactions.  Imagine a client that does only that:
>> say "dark" when the light level gets  under a chosen threshold. It
>> will receive all status and they'll be  dropped except the light
>> level, while just one notification when the light  gets dark would
>> suffice. We could imagine something closer to what DBUS  does, the
>> client registers a function with an event that the daemon could  offer
>> (like low_light_event, threshold as parameter) and the daemon will
>> only contact the client when the event occurs. Clients could also
>> subscribe to specific status, or request them separately. Such a thing
>> would change the network protocol completely.
>
> I want to add that the current API uses byte arrays for all this and
> it makes things cumbersome and really hard to read and extend. Using
> *real* data structures and marshalling would help immensely by making
> the code shorter, cleaner, and more obvious.

Yes, sure. And we can already add these structures in the daemon too.

>> To conclude, I think it could be a good way to keep Rémi working on
>> the  current api, quickly developping and testing new functionalities
>> and  applications, while we start thinking and working on a new clean
>> branch to  be a mid-term replacement solution. Once nice
>> functionalities are getting  into Rémi's work, we could simply copy
>> them into our branch.
>
> Depends on how different the new API is from the old one. Could be
> tricky unless this new stuff has a clear interface with the API (i.e.,
> no things intertwined or buried deep down the code structure)

Didn't think about cut and paste of course. More like testing new  
functionalities. If something is found to be pretty neat and interesting  
in Rémi's work, we can implement it on our branch. And when we'll get  
something functional, I'll get Rémi move to the community branch too.  
That's just a temporary situation that would free us from the strain which  
is on the curent API.

David

Re: [tuxdroid-user] Refactoring the API

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

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

[...]
> some end user  applications very quickly which explains why the API is
> evolving the way  it is now. If we start changing this API, he'll get
> a lot of troubles  merging all his changes every 2 weeks with ours,
> and we'll get the same  trouble seing those huge commits changing
> nearly every line once in a  while. For his applications, R=C3=A9mi needs
> to keep his flexibility. On our  side, we want to follow the style
> guidelines and best development  practices that makes good OS
> software.

If we start a new API from scratch, maybe we could also write a
wrapper for new API exposing the same old API, so as to ease the
transition. This may not be possible for everything, though...

> Second, I really think it will be quicker to rewrite a new api than to
> change the current one. IMHO the design structure is wrong but I still
> don't have the expertise to be able to design a good one. Just an
> example,  I would expect to have a tux object with an 'leds' property,
> and  'tux.leds' should return the status of the leds
> (left=3Don,right=3Doff) while  writing to 'tux.leds' would set them to the
> value. Right now you have to  call a command with a defined parameter
> for the led command, and call a  completely different status command
> to get the value of the leds. That  sounds like standard structured
> programming to me, not OOP. (I really need  to read a book on that to
> be sure though ;-) )

Agreed.

[...]
> makes it very difficult  to port it to different languages. I would
> suggest to carefully decide  what should be moved from the api to the
> daemon. And going for a new api  makes this easier.

Haven't thought about any of this. I'll have this in mind next time I'll
wander in the code.

> Some strange things also. Right now all status are read from the USB
> and  stored in variables. The clients get ALL status continuously
> through the  api, these status are parsed to trigger a few things then
> dropped. So when  a client wants to know the status of something, it
> still needs to do a new  request to the daemon which will send the
> status again. Even if it's not a  big load on the network, it still is
> a lot of useless transactions.  Imagine a client that does only that:
> say "dark" when the light level gets  under a chosen threshold. It
> will receive all status and they'll be  dropped except the light
> level, while just one notification when the light  gets dark would
> suffice. We could imagine something closer to what DBUS  does, the
> client registers a function with an event that the daemon could  offer
> (like low_light_event, threshold as parameter) and the daemon will
> only contact the client when the event occurs. Clients could also
> subscribe to specific status, or request them separately. Such a thing
> would change the network protocol completely.

I want to add that the current API uses byte arrays for all this and
it makes things cumbersome and really hard to read and extend. Using
*real* data structures and marshalling would help immensely by making
the code shorter, cleaner, and more obvious.

> To conclude, I think it could be a good way to keep R=C3=A9mi working on
> the  current api, quickly developping and testing new functionalities
> and  applications, while we start thinking and working on a new clean
> branch to  be a mid-term replacement solution. Once nice
> functionalities are getting  into R=C3=A9mi's work, we could simply copy
> them into our branch.

Depends on how different the new API is from the old one. Could be
tricky unless this new stuff has a clear interface with the API (i.e.,
no things intertwined or buried deep down the code structure)

> On the actions side, first we can discuss this a bit, see the pros and
> cons. Then I'll use the wiki to draw a list of all functionalities we
> currently have in the api and we'll decide what should be handled by
> the  daemon and the api. There's also a virgin API page on the wiki
> where the  new structure can be defined.
>
> How does this sound to you?

Sounds good :-)

	Damien

Re: [tuxdroid-user] Any good reference to learn Object ad python programming,

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

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

[...]
> Any recommendation on a good book or website about OO? It doesn't need
> to  be python, a general approach on OO is good either.

I don't have any recommendation, sorry. Maybe I've done this for too
long and it now comes naturally...

	Damien, pretentious & disliking C++

[tuxdroid-user] Status Update

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

Well, I promised some test hex files last friday and it won't even be for  
today. There's still a couple of things the guy developping the RF module  
should fix and he got some problems doing so. Right now the RF does  
wake-up correctly when the dongle sends the order but the communication  
doesn't initialize correctly so it makes it unusable for now.
There's also another bug which makes half of the status lost during the  
way. There's a fix which hasn't been tested yet.

I hope to be able to release something next week.
Cheers,
David

[tuxdroid-user] Refactoring the API

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

Hi Guys,

I finally had a closer look at the API when adding the connection  
functions for the ID, sleep and wifi features. We're really going forward  
on the daemon, it gets cleaner and better everyday. The next step would be  
to dig into the API and do the same kind of cleaning and sanity job.  
Though the work here seems to be much different than for the daemon.

The python API is a huge single file that needs to be cut into pieces and  
it doesn't look like the initial architecture has been carefully chosen.  
Don't take me wrong, there's a lot of (good) functionalities in it and it  
does the job. But I see a couple of problems starting working on this one  
with the community.

So I suggest to start a new API from scratch, just taking out the good  
pieces of the current one. Here are a few reasons why.

First, Rémi is actively developping it alone, he does a lot of changes in  
every direction regularly. Unfortunately he doesn't really get into the  
open source development philosophy and this makes it hard for him to use  
svn correctly. On the other hand he has to develop some end user  
applications very quickly which explains why the API is evolving the way  
it is now. If we start changing this API, he'll get a lot of troubles  
merging all his changes every 2 weeks with ours, and we'll get the same  
trouble seing those huge commits changing nearly every line once in a  
while. For his applications, Rémi needs to keep his flexibility. On our  
side, we want to follow the style guidelines and best development  
practices that makes good OS software.

Second, I really think it will be quicker to rewrite a new api than to  
change the current one. IMHO the design structure is wrong but I still  
don't have the expertise to be able to design a good one. Just an example,  
I would expect to have a tux object with an 'leds' property, and  
'tux.leds' should return the status of the leds (left=on,right=off) while  
writing to 'tux.leds' would set them to the value. Right now you have to  
call a command with a defined parameter for the led command, and call a  
completely different status command to get the value of the leds. That  
sounds like standard structured programming to me, not OOP. (I really need  
to read a book on that to be sure though ;-) )

So I suggest we take some time to refine the functionalities of the api,  
decide on the design structure, and then implement it. That will take more  
time to get all opinions before acting but as there's already a functional  
api, we can afford to take the time to do it well.

Third, the current api is way too long. All functionalities are handled by  
the api while the daemon is basically a USB to TCP/IP interface.
There are a few problems to this. As most commands needs to cross a lot of  
interfaces before getting processed by tux and come back as a new status,  
the asynchronous communication between the daemon and the api get's overly  
complicated. And as the api is quite complex, it makes it very difficult  
to port it to different languages. I would suggest to carefully decide  
what should be moved from the api to the daemon. And going for a new api  
makes this easier.

Some strange things also. Right now all status are read from the USB and  
stored in variables. The clients get ALL status continuously through the  
api, these status are parsed to trigger a few things then dropped. So when  
a client wants to know the status of something, it still needs to do a new  
request to the daemon which will send the status again. Even if it's not a  
big load on the network, it still is a lot of useless transactions.  
Imagine a client that does only that: say "dark" when the light level gets  
under a chosen threshold. It will receive all status and they'll be  
dropped except the light level, while just one notification when the light  
gets dark would suffice. We could imagine something closer to what DBUS  
does, the client registers a function with an event that the daemon could  
offer (like low_light_event, threshold as parameter) and the daemon will  
only contact the client when the event occurs. Clients could also  
subscribe to specific status, or request them separately. Such a thing  
would change the network protocol completely.

To conclude, I think it could be a good way to keep Rémi working on the  
current api, quickly developping and testing new functionalities and  
applications, while we start thinking and working on a new clean branch to  
be a mid-term replacement solution. Once nice functionalities are getting  
into Rémi's work, we could simply copy them into our branch.

On the actions side, first we can discuss this a bit, see the pros and  
cons. Then I'll use the wiki to draw a list of all functionalities we  
currently have in the api and we'll decide what should be handled by the  
daemon and the api. There's also a virgin API page on the wiki where the  
new structure can be defined.

How does this sound to you?
David

[tuxdroid-user] Any good reference to learn Object ad python programming,

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

Hi guys,

As you probably know I never learned any Object Oriented programming  
language. I'm doing a bit of python at the moment wich doesn't mean I know  
how to use it the right way, especially the OO stuff. I don't mind much  
about the syntax for now, I really want to learn how to structure and  
write my objects, classes, functions, etc. correctly. So I won't waste all  
my time learning it the hard way.

Any recommendation on a good book or website about OO? It doesn't need to  
be python, a general approach on OO is good either.

Thanks,
David

Re: [tuxdroid-user] Daemon to USB connection

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

On Sat, 09 Jun 2007 07:56:27 +0200, neimad <ror...@gm...> wrote:

> Yet more coding style, this time in the Python API...
>
> _Continued lines_

Corrected now.

> _Private methods and variables_
>
> In tuxapi_class.py again, class TUXcmd has a big doc string listing all
> functions available to the users of the class. This is not necessary
> as the list can be found out using dir().
>
> Some methods have a doc string saying "Not a user function". Their
> name should start with "__" (double underscore) to make them really
> private, which also makes such doc strings useless.

I didn't change these as there are many things I'd like to review in the  
api before taking action. I'll start a new thread on tomorrow about this.

Thanks as usual ;-)
David

Re: [tuxdroid-user] Including dfu-programmer in tuxsetup

[Andrew S. <str...@as...>]

David Bourgeois wrote:
>> Until Andrew Straw has found a sponsor, you can use the work Andrew has
>> done to build a Debian package for dfu-programmer yourself and set up a
>> tuxdroid-repository where you can download it. There is no need to do
>> duplicated work.
>>
>> I have used Andrew's work to build a Debian-package for dfu-programmer
>> myself, works without a problem:
> 
> That's a good solution too. I thought it didn't work.

Why did you think that? Can you let me know if there's a problem?

Re: [tuxdroid-user] Including dfu-programmer in tuxsetup

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

> Until Andrew Straw has found a sponsor, you can use the work Andrew has
> done to build a Debian package for dfu-programmer yourself and set up a
> tuxdroid-repository where you can download it. There is no need to do
> duplicated work.
>
> I have used Andrew's work to build a Debian-package for dfu-programmer
> myself, works without a problem:

That's a good solution too. I thought it didn't work. I'm going to try it  
under ubuntu too. Maybe it's possible to upload it on the dfu-programmer  
sourceforge project where it would make more sense. There's already an rpm  
there that should work for fedora. I'll keep you updated.

David

Re: [tuxdroid-user] Daemon to USB connection

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

"Vincent Fretin" <vin...@gm...> writes:

[...]
> from struct import pack, unpack
> msg = pack('<HBBLL', subdirs, flags, pad, size, mtime)

Yes, that's exactly what I meant by "marshalling", though I didn't
remember the API :-)

	Damien

Re: [tuxdroid-user] Including dfu-programmer in tuxsetup

[Jan W. <jan...@gm...>]

neimad schreef:

> If it takes 3 years to get into the official repository, as it
> happened for Jan Wagemakers' package, we'd better not wait for a
> sponsor.

FWIW, It will not always take 3 years. 

> We just need someone with the knowledge to build packages for Debian
> and Ubuntu and put these packages up for download on TuxDroïd's
> website.

Until Andrew Straw has found a sponsor, you can use the work Andrew has
done to build a Debian package for dfu-programmer yourself and set up a
tuxdroid-repository where you can download it. There is no need to do
duplicated work.

I have used Andrew's work to build a Debian-package for dfu-programmer
myself, works without a problem:

 pts/10  jan ~$ dpkg -s dfu-programmer
Package: dfu-programmer
Status: install ok installed
Priority: optional
Section: devel
Installed-Size: 48
Maintainer: Andrew Straw <str...@as...>
Architecture: i386
Version: 0.4.0-1
Depends: libusb-0.1-4
Description: device firmware update (DFU) based USB programmer for Atmel chips
 A linux based command-line programmer for Atmel chips with a USB
 bootloader supporting in system programming.
 .
 This is a mostly Device Firmware Update (DFU) 1.0 compliant
 user-space application. This program was created because the Atmel
 FLIP program for flashing devices does not run on Linux and because
 standard DFU loaders do not work for Atmel chips.
 pts/10  jan ~$ 


-- 
Met vriendelijke groetjes         - Jan Wagemakers -

... Wij zijn allemaal stripfiguren getekend door het leven

Re: [tuxdroid-user] Daemon to USB connection

[Vincent F. <vin...@gm...>]

2007/6/10, neimad <ror...@gm...>:>
> On the Python side, sending data to a C program that expects structs
> can be achieved by the use of marshaling. I'm not aware of the latest
> and greatest ways to do this in Python, but 10+ years ago there were
> already such facilities, so I guess it must be possible and even
> easier today ;-)

Hi!
You can create struct in python with pack. See an example in the
nfsapp python version (a script you put on your S60 phone or other
which work with p3nfs (http://www.koeniglich.de/p3nfs.html)) :
http://amalfi.dis.unina.it/~foggia/nfsapp.py
Here is the example:

from struct import pack, unpack
msg = pack('<HBBLL', subdirs, flags, pad, size, mtime)
< means little-endian
H:unsigned short;
B:unsigned byte;
L:unsigned long;

for more information:
import struct
help(struct)

I hope it will be useful to you.
Vincent Fretin

Re: [tuxdroid-user] Including dfu-programmer in tuxsetup

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

"Florent THIERY" <ft...@gm...> writes:

> Hi,
>
> Don't you think a single, unique package could be best ? Because maybe
> tuxdroid won't always use the mainstream version...
>
> There is something special about tuxdroid: it's a commercial open
> source product (which is something to encourage IMHO); maybe the time
> to get into the repository (or set one oneself) could be shortened...

If it takes 3 years to get into the official repository, as it
happened for Jan Wagemakers' package, we'd better not wait for a
sponsor.

We just need someone with the knowledge to build packages for Debian
and Ubuntu and put these packages up for download on TuxDro=C3=AFd's
website.

	Damien