Re: [Nxtcommand-developers] CLDC

[Peter Joosten <ptg.joosten@ch...>]

> With this setup will we still be able to make changes to iCommand
> code and use it "realtime" in Eclipse?

Yes.

You will see sources in the projects icommand, icommand-cldc.
You will edit / make changes to the sources in the projects icomand,
icommand-cldc.
(So for the developer the new icommand project will look and behave as
before.)
The differences are:
1. While it looks like you are editing the sources in icommand,
icommand-cldc,
   you are actually editing the sources in the project icommand-sources.
   In this way we achieve our goal: 1 source tree.
2. The sources in projects icommand, icommand-cldc are compiled according
their
   own project settings, which is a requirement to support the diffent
platforms.

Or will we have to manually run an
> ANT build
> after every change to the iCommand source?
>
> ----- Original Message -----
> From: "Peter Joosten" <ptg.joosten@...>
> To: "Brian Bagnall" <bbagnall@...>; "iCommand Developers"
> <nxtcommand-developers@...>
> Sent: Friday, December 15, 2006 10:23 AM
> Subject: RE: [Nxtcommand-developers] CLDC
>
>
> > Supporting multiple runtime environments / platforms
> > with different development kits, requieres different
> > project settings. These can not coexist in 1 project.
> > (In eclipse terms: there can only be 1 .project, 1
> > .classpath, and 1 .settings). Therefore each platform
> > should have its own project(s). I suggest the next setup:
> >
> > project icommand-sources : contains only the java sources
> > (with prepocessor commands) these sources are linked into
> > the other projects as an external source folder.
> >
> > project icommand : the sources of icommand-sources are linked
> > as an external source folder in this project and prepocessed &
> > compiled according the settings of the icommand project.
> >
> > project icommand-cldc : the sources of icommand-sources are linked
> > as an external source folder in this project and prepocessed &
> > compiled according the settings of the icommand-cldc project.
> >
> > The name of the project "icommand-cldc" is just an example.
> >
> > - In this ways every project only has 1 set of files for the project
> > settings.
> > - In this way we can use netbeans (if requied) for one project and
> >  eclipse for another.
> > - we have 1 source tree in the project icommand-sources
> >
> > - This will break the ant build system, but that can be fixed.
> >
> > Agree/Disagree ? Questions ? If I get a GO a start implementing it, and
> > will integrate icommand-0.5_CLDCpre2.zip into icommand-sources.
> >
> > Stefano, is icommand-0.5_CLDCpre2.zip the latest version ?
> >
> > Peter.
> >
>
>
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to
> share your
> opinions on IT & business topics through brief surveys - and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> Nxtcommand-developers mailing list
> Nxtcommand-developers@...
> https://lists.sourceforge.net/lists/listinfo/nxtcommand-developers
>

Re: [Nxtcommand-developers] CLDC

[Brian Bagnall <bbagnall@mt...>]

With this setup will we still be able to make changes to iCommand code and 
use it "realtime" in Eclipse? Or will we have to manually run an ANT build 
after every change to the iCommand source?

----- Original Message ----- 
From: "Peter Joosten" <ptg.joosten@...>
To: "Brian Bagnall" <bbagnall@...>; "iCommand Developers" 
<nxtcommand-developers@...>
Sent: Friday, December 15, 2006 10:23 AM
Subject: RE: [Nxtcommand-developers] CLDC


> Supporting multiple runtime environments / platforms
> with different development kits, requieres different
> project settings. These can not coexist in 1 project.
> (In eclipse terms: there can only be 1 .project, 1
> .classpath, and 1 .settings). Therefore each platform
> should have its own project(s). I suggest the next setup:
>
> project icommand-sources : contains only the java sources
> (with prepocessor commands) these sources are linked into
> the other projects as an external source folder.
>
> project icommand : the sources of icommand-sources are linked
> as an external source folder in this project and prepocessed &
> compiled according the settings of the icommand project.
>
> project icommand-cldc : the sources of icommand-sources are linked
> as an external source folder in this project and prepocessed &
> compiled according the settings of the icommand-cldc project.
>
> The name of the project "icommand-cldc" is just an example.
>
> - In this ways every project only has 1 set of files for the project
> settings.
> - In this way we can use netbeans (if requied) for one project and
>  eclipse for another.
> - we have 1 source tree in the project icommand-sources
>
> - This will break the ant build system, but that can be fixed.
>
> Agree/Disagree ? Questions ? If I get a GO a start implementing it, and
> will integrate icommand-0.5_CLDCpre2.zip into icommand-sources.
>
> Stefano, is icommand-0.5_CLDCpre2.zip the latest version ?
>
> Peter.
> 

Re: [Nxtcommand-developers] CLDC

[Peter Joosten <ptg.joosten@ch...>]

Supporting multiple runtime environments / platforms
with different development kits, requieres different
project settings. These can not coexist in 1 project.
(In eclipse terms: there can only be 1 .project, 1
 .classpath, and 1 .settings). Therefore each platform
should have its own project(s). I suggest the next setup:

project icommand-sources : contains only the java sources
(with prepocessor commands) these sources are linked into
the other projects as an external source folder.

project icommand : the sources of icommand-sources are linked
as an external source folder in this project and prepocessed &
compiled according the settings of the icommand project.

project icommand-cldc : the sources of icommand-sources are linked
as an external source folder in this project and prepocessed &
compiled according the settings of the icommand-cldc project.

The name of the project "icommand-cldc" is just an example.

- In this ways every project only has 1 set of files for the project
settings.
- In this way we can use netbeans (if requied) for one project and
  eclipse for another.
- we have 1 source tree in the project icommand-sources

- This will break the ant build system, but that can be fixed.

Agree/Disagree ? Questions ? If I get a GO a start implementing it, and
will integrate icommand-0.5_CLDCpre2.zip into icommand-sources.

Stefano, is icommand-0.5_CLDCpre2.zip the latest version ?

Peter.

Re: [Nxtcommand-developers] CLDC

[Peter Joosten <ptg.joosten@ch...>]

>
> Are you looking for subversion support for NetBeans because there is no
> Eclipse for MacOSX? Stefano, are you using MacOSX with NetBeans as an IDE?
>

There IS an eclipse version for Mac OSX. I thougth Sefano was using NetBeans
on OSX.
That was the only reason that I was looking for subversion suppot for
NetBeans.
The following fragment suggests he is using Windows for CLDC.
- It would be interesting to know what IDE and OS Stefano is using (?).

> Maybe I missed some messages: what is it needed to do on Mac? My default
> platform (outside the mobile world, which requires Windows :-( ) is Mac
> OS X 10.4 on PPC platform.

Re: [Nxtcommand-developers] CLDC

[Brian Bagnall <bbagnall@mt...>]

----- Original Message ----- 
From: "Peter Joosten" <ptg.joosten@...>

> I have got here: icommand-0.5_CLDCpre2.zip
> Do you have a more recent version ?

That's the one I've got. I'm not sure if Stefano has done any more work on 
it since then.

> The instuctions are at: http://www.vortoj.com/sjpp/readme.html ;-)
>
> 1. I will make the changes in my working directory, and when I have
> a working setup (eclipse and netbeans) I will commit them to subversion,
> together with some instructions. There are not that many changes.
>
> Could you send met te latest sources!

All my changes are commited to subversion.

> 2. I will see if there is a netbeans module for subversion support.
> If not, TortoiseSVN is a good option. I think Stefano is using a Mac.
> I hope that Mac OS X is supported. We will see.

Are you looking for subversion support for NetBeans because there is no 
Eclipse for MacOSX? Stefano, are you using MacOSX with NetBeans as an IDE?

- Brian

> 3. Change the build script to make an icommand-cldc.jar
>
>> Which solution do you like, preprocessor or split code? Do you have the
>> instructions to install the preprocessor software, setup, etc...?
>> I'd like
>> to get this set up so that we can call try out the preprocessor
>> and see how
>> it works. I've got his CLDC code so maybe we could implement
> 

Re: [Nxtcommand-developers] CLDC

[Peter Joosten <ptg.joosten@ch...>]

subversion support for netbeans: http://subversion.netbeans.org/

> 
> 2. I will see if there is a netbeans module for subversion support.
> If not, TortoiseSVN is a good option. I think Stefano is using a Mac.
> I hope that Mac OS X is supported. We will see.
>

[Nxtcommand-developers] CLDC

[Peter Joosten <ptg.joosten@ch...>]

Bian,

I have got here: icommand-0.5_CLDCpre2.zip
Do you have a more recent version ? 

The instuctions are at: http://www.vortoj.com/sjpp/readme.html ;-)

1. I will make the changes in my working directory, and when I have
a working setup (eclipse and netbeans) I will commit them to subversion,
together with some instructions. There are not that many changes.

Could you send met te latest sources!

2. I will see if there is a netbeans module for subversion support.
If not, TortoiseSVN is a good option. I think Stefano is using a Mac.
I hope that Mac OS X is supported. We will see.

3. Change the build script to make an icommand-cldc.jar

> Which solution do you like, preprocessor or split code? Do you have the 
> instructions to install the preprocessor software, setup, etc...? 
> I'd like 
> to get this set up so that we can call try out the preprocessor 
> and see how 
> it works. I've got his CLDC code so maybe we could implement

Re: [Nxtcommand-developers] rolyv19: modified Keep-Alive threadinNXTCommRXTX and NXTCommSun open() method.

[Brian Bagnall <bbagnall@mt...>]

>  On the list there are 10 developers. If they all would be actively
> commiting, I think,  hell would brake loose,
>  because Icommand has evolved from a solo to a team project, but we still
> lack any organisational structure / procedures / way of working.

I don't really know any special working procedures or anything. Pretty much 
just relying on Subversion to let us turn back code if anything goes 
horribly wrong. On the leJOS Sourceforge project it seemed to go well by 
just letting people know what you were working on (to avoid duplicate work) 
and then letting us know when something new was committed. If anyone wanted 
to throw in their 2 cents they could do that in the mailing list.

So far in iCommand it seems like we know what everyone is doing. When it 
comes time to merge this as the wireless aspect of leJOS NeXT we will 
probably have to change our API quite a bit to match leJOS, so nothing is in 
stone right now.

For the keepalive, I saw that command in the NXT docs but haven't played 
with it much. I think the important thing is to put any method for keepalive 
in there, test it on the next release (and among ourselves when we update 
Subversion) and then we can hone it some more if there are problems on each 
subsequent release. As soon as we figure out how to have forums for general 
users we can get some feedback from them. (The lack of a mail server on 
Sourceforge/a place to host the forum is our problem.)

- Brian 

Re: [Nxtcommand-developers] rolyv19: modified Keep-Alive thread inNXTCommRXTX and NXTCommSun open() method.

[Peter Joosten <ptg.joosten@ch...>]

Hi Roly

- 95 % of the code is Brian's code
- were both developers, your opinion is as good as mine
- I do not guard the code like a watchdog, my eye just happened to catch
your commit message, and I got curious.
- it started as Brian's solo project, I made little contributions, Stefano
is working on CLDC, your are no 4 (did I forget someone ?).
  On the list there are 10 developers. If they all would be actively
commiting, I think,  hell would brake loose,
  because Icommand has evolved from a solo to a team project, but we still
lack any organisational structure / procedures / way of working.

Peter
  -----Original Message-----
  From: Roly Vicaria [mailto:rolyv19@...]
  Sent: Tuesday, December 12, 2006 8:13 AM
  To: ptg.joosten@...
  Subject: Re: [Nxtcommand-developers] rolyv19: modified Keep-Alive thread
inNXTCommRXTX and NXTCommSun open() method.


  I know I'm a rookie here, so I'll yield to whatever you and Brian say...I
don't want to start adding fields and making larger modifications to your
code.

  Roly

Re: [Nxtcommand-developers] rolyv19: modified Keep-Alive thread inNXTCommRXTX and NXTCommSun open() method.

[Peter Joosten <ptg.joosten@ch...>]

The note at the end of my previous messsage, was just some comment on the NI
document.
This document explicitly mentions that the sleep time is reset after the
KeepAlive command.
I wonder why it is mentioned only there, or why it is mentioned at all,
because (I asume) it is
reset after every command.

Only sending KeepAlive commands during idle time. I didn't think of that.
But why not ?
It probably can be easily implemented setting some timestamp field.

I am just one of the developers. I would be interested in Brian's opinion
about the KeepAlive thread.

Peter Joosten.
  -----Original Message-----
  From: Roly Vicaria [mailto:rolyv19@...]
  Sent: Tuesday, December 12, 2006 5:59 AM
  To: ptg.joosten@...
  Subject: Re: [Nxtcommand-developers] rolyv19: modified Keep-Alive thread
inNXTCommRXTX and NXTCommSun open() method.


  So you think the thread should only send keepAlive during the idle time?
If no commands are sent for an X period of time, and send keepAlive is set
to true, send keepAlive message.
  So then the thread just needs to check how long it's been since the last
command was sent...would you agree?

  Roly V.


  On 12/11/06, Peter Joosten <ptg.joosten@...> wrote:
    I  just had a quick look at the system commands. I could not find a
command to change the KeepAlive time programmatically.
     That would be my preference.

    I agree with your suggestion to make the KeepAlive thread an optional
feature (using a boolean).
    This would be usefull for dashboard applications.
    If someone returns from a break, he still wants his brick to be turned
on, the BT connection to be alive,
    and able to continue playing with the application.

    Peter Joosten.

    A note:
    1 . The NI document says that the KeepAlive command resets the sleep
timer.

    Probably all commands reset the sleep timer. It would be very bad design
if the
    brick goes asleep while still firing commands. I think the sleep time is
(/should be)
    an idle time, time since last command.

      -----Original Message-----
      From: Roly Vicaria [mailto:rolyv19@...]
      Sent: Tuesday, December 12, 2006 3:50 AM
      To: ptg.joosten@...
      Subject: Re: [Nxtcommand-developers] rolyv19: modified Keep-Alive
thread inNXTCommRXTX and NXTCommSun open() method.


      OK...I see your point. But what if someone doesn't want to set the
sleep to never, after all, it is a safeguard for battery life. So if the NXT
gives you a choice of setting it to never sleep or not, then how about
setting a boolean of whether or not to send the keep-alive message to give
the user the same choice?


      On 12/11/06, Peter Joosten <ptg.joosten@...> wrote:
        First a little correction. According the National Instruments
Avdvanced
        Programming Guide
        the KeepAlive command not only reads the current sleep time, but
also resets
        the sleep
        time counter to zero. (An example of the "added-value" of the NI
document
        compared to Lego BTSDK).

        This doesn't change my message: Firing periodic keep-alive commands
from the
        NXTComm implementations
        makes no sense, since the NXT brick can be set to never sleep.
Therefore
        this change in the code
        should be undone / removed again. This is my personal opinion.

        Peter Joosten.

        > -----Original Message-----
        > From: nxtcommand-developers-bounces@...
        > [mailto:nxtcommand-developers-bounces@... ]On
Behalf Of
        > Peter Joosten
        > Sent: Monday, December 11, 2006 6:45 AM
        > To: iCommand Developers
        > Subject: [Nxtcommand-developers] rolyv19: modified Keep-Alive
thread
        > inNXTCommRXTX and NXTCommSun open() method.
        >
        >
        > Hi Rolyv19,
        >
        > I saw your Keep-Alive thread commited to subversion.
        >
        > The only thing the Keep Alive command does is read the "sleep"
setting (in
        > msec).
        > Ok, you may send Keep Alive commands (or any other command) just
        > before the
        > NXT is falling asleep.
        > But why not set the "sleep" setting on your brick manually to
        > "never" (value
        > = 0).
        >
        > A desciption of the commands can be found at:
        > http://mindstorms.lego.com/Overview/NXTreme.aspx Download the BDK
        > documents
        >
        > >From National Instruments
        > http://zone.ni.com/devzone/cda/tut/p/id/4435
        >
        > Download the The Advanced Progamming Guide. I thinks this is a
very fine
        > resource.
        > The BDK only describes the command layout. Not giving any "good"
        > explanation.
        >
        > Personally, I had a hard time figuring out from the BDK what
        > combinations of
        > enumerations
        > can be used for what sensor. This guide gives an explanation.
        >
        > Peter Joosten.
        >
        >
        > ------------------------------------------------------------------
-------
        > Take Surveys. Earn Cash. Influence the Future of IT
        > Join SourceForge.net's Techsay panel and you'll get the chance to
        > share your
        > opinions on IT & business topics through brief surveys - and earn
cash
        >
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
        > _______________________________________________
        > Nxtcommand-developers mailing list
        > Nxtcommand-developers@...
        > https://lists.sourceforge.net/lists/listinfo/nxtcommand-developers


        --------------------------------------------------------------------
-----
        Take Surveys. Earn Cash. Influence the Future of IT
        Join SourceForge.net's Techsay panel and you'll get the chance to
share your
        opinions on IT & business topics through brief surveys - and earn
cash
        http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=D
EVDEV
        _______________________________________________
        Nxtcommand-developers mailing list
        Nxtcommand-developers@...
        https://lists.sourceforge.net/lists/listinfo/nxtcommand-developers

Re: [Nxtcommand-developers] rolyv19: modified Keep-Alive thread inNXTCommRXTX and NXTCommSun open() method.

[Peter Joosten <ptg.joosten@ch...>]

I  just had a quick look at the system commands. I could not find a command
to change the KeepAlive time programmatically.
 That would be my preference.

I agree with your suggestion to make the KeepAlive thread an optional
feature (using a boolean).
This would be usefull for dashboard applications.
If someone returns from a break, he still wants his brick to be turned on,
the BT connection to be alive,
and able to continue playing with the application.

Peter Joosten.

A note:
1 . The NI document says that the KeepAlive command resets the sleep timer.

Probably all commands reset the sleep timer. It would be very bad design if
the
brick goes asleep while still firing commands. I think the sleep time is
(/should be)
an idle time, time since last command.

  -----Original Message-----
  From: Roly Vicaria [mailto:rolyv19@...]
  Sent: Tuesday, December 12, 2006 3:50 AM
  To: ptg.joosten@...
  Subject: Re: [Nxtcommand-developers] rolyv19: modified Keep-Alive thread
inNXTCommRXTX and NXTCommSun open() method.


  OK...I see your point. But what if someone doesn't want to set the sleep
to never, after all, it is a safeguard for battery life. So if the NXT gives
you a choice of setting it to never sleep or not, then how about setting a
boolean of whether or not to send the keep-alive message to give the user
the same choice?


  On 12/11/06, Peter Joosten <ptg.joosten@...> wrote:
    First a little correction. According the National Instruments Avdvanced
    Programming Guide
    the KeepAlive command not only reads the current sleep time, but also
resets
    the sleep
    time counter to zero. (An example of the "added-value" of the NI
document
    compared to Lego BTSDK).

    This doesn't change my message: Firing periodic keep-alive commands from
the
    NXTComm implementations
    makes no sense, since the NXT brick can be set to never sleep. Therefore
    this change in the code
    should be undone / removed again. This is my personal opinion.

    Peter Joosten.

    > -----Original Message-----
    > From: nxtcommand-developers-bounces@...
    > [mailto:nxtcommand-developers-bounces@...]On Behalf
Of
    > Peter Joosten
    > Sent: Monday, December 11, 2006 6:45 AM
    > To: iCommand Developers
    > Subject: [Nxtcommand-developers] rolyv19: modified Keep-Alive thread
    > inNXTCommRXTX and NXTCommSun open() method.
    >
    >
    > Hi Rolyv19,
    >
    > I saw your Keep-Alive thread commited to subversion.
    >
    > The only thing the Keep Alive command does is read the "sleep" setting
(in
    > msec).
    > Ok, you may send Keep Alive commands (or any other command) just
    > before the
    > NXT is falling asleep.
    > But why not set the "sleep" setting on your brick manually to
    > "never" (value
    > = 0).
    >
    > A desciption of the commands can be found at:
    > http://mindstorms.lego.com/Overview/NXTreme.aspx Download the BDK
    > documents
    >
    > >From National Instruments
    > http://zone.ni.com/devzone/cda/tut/p/id/4435
    >
    > Download the The Advanced Progamming Guide. I thinks this is a very
fine
    > resource.
    > The BDK only describes the command layout. Not giving any "good"
    > explanation.
    >
    > Personally, I had a hard time figuring out from the BDK what
    > combinations of
    > enumerations
    > can be used for what sensor. This guide gives an explanation.
    >
    > Peter Joosten.
    >
    >
    > ----------------------------------------------------------------------
---
    > Take Surveys. Earn Cash. Influence the Future of IT
    > Join SourceForge.net's Techsay panel and you'll get the chance to
    > share your
    > opinions on IT & business topics through brief surveys - and earn cash
    >
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
    > _______________________________________________
    > Nxtcommand-developers mailing list
    > Nxtcommand-developers@...
    > https://lists.sourceforge.net/lists/listinfo/nxtcommand-developers


    ------------------------------------------------------------------------
-
    Take Surveys. Earn Cash. Influence the Future of IT
    Join SourceForge.net's Techsay panel and you'll get the chance to share
your
    opinions on IT & business topics through brief surveys - and earn cash
    http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDE
V
    _______________________________________________
    Nxtcommand-developers mailing list
    Nxtcommand-developers@...
    https://lists.sourceforge.net/lists/listinfo/nxtcommand-developers

Re: [Nxtcommand-developers] rolyv19: modified Keep-Alive thread inNXTCommRXTX and NXTCommSun open() method.

[Peter Joosten <ptg.joosten@ch...>]

First a little correction. According the National Instruments Avdvanced
Programming Guide
the KeepAlive command not only reads the current sleep time, but also resets
the sleep
time counter to zero. (An example of the "added-value" of the NI document
compared to Lego BTSDK).

This doesn't change my message: Firing periodic keep-alive commands from the
NXTComm implementations
makes no sense, since the NXT brick can be set to never sleep. Therefore
this change in the code
should be undone / removed again. This is my personal opinion.

Peter Joosten.

> -----Original Message-----
> From: nxtcommand-developers-bounces@...
> [mailto:nxtcommand-developers-bounces@...]On Behalf Of
> Peter Joosten
> Sent: Monday, December 11, 2006 6:45 AM
> To: iCommand Developers
> Subject: [Nxtcommand-developers] rolyv19: modified Keep-Alive thread
> inNXTCommRXTX and NXTCommSun open() method.
>
>
> Hi Rolyv19,
>
> I saw your Keep-Alive thread commited to subversion.
>
> The only thing the Keep Alive command does is read the "sleep" setting (in
> msec).
> Ok, you may send Keep Alive commands (or any other command) just
> before the
> NXT is falling asleep.
> But why not set the "sleep" setting on your brick manually to
> "never" (value
> = 0).
>
> A desciption of the commands can be found at:
> http://mindstorms.lego.com/Overview/NXTreme.aspx Download the BDK
> documents
>
> >From National Instruments
> http://zone.ni.com/devzone/cda/tut/p/id/4435
>
> Download the The Advanced Progamming Guide. I thinks this is a very fine
> resource.
> The BDK only describes the command layout. Not giving any "good"
> explanation.
>
> Personally, I had a hard time figuring out from the BDK what
> combinations of
> enumerations
> can be used for what sensor. This guide gives an explanation.
>
> Peter Joosten.
>
>
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to
> share your
> opinions on IT & business topics through brief surveys - and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> Nxtcommand-developers mailing list
> Nxtcommand-developers@...
> https://lists.sourceforge.net/lists/listinfo/nxtcommand-developers

[Nxtcommand-developers] rolyv19: modified Keep-Alive thread in NXTCommRXTX and NXTCommSun open() method.

[Peter Joosten <ptg.joosten@ch...>]

Hi Rolyv19,

I saw your Keep-Alive thread commited to subversion.

The only thing the Keep Alive command does is read the "sleep" setting (in
msec).
Ok, you may send Keep Alive commands (or any other command) just before the
NXT is falling asleep.
But why not set the "sleep" setting on your brick manually to "never" (value
= 0).

A desciption of the commands can be found at:
http://mindstorms.lego.com/Overview/NXTreme.aspx Download the BDK documents

>From National Instruments
http://zone.ni.com/devzone/cda/tut/p/id/4435

Download the The Advanced Progamming Guide. I thinks this is a very fine
resource.
The BDK only describes the command layout. Not giving any "good"
explanation.

Personally, I had a hard time figuring out from the BDK what combinations of
enumerations
can be used for what sensor. This guide gives an explanation.

Peter Joosten.

Re: [Nxtcommand-developers] iCommand 0.5 CLDC pre2

[Brian Bagnall <bbagnall@mt...>]

I forgot to mention, Stefano, that you would still be able to build your own 
package for the visual tools you need for the PDA. Since that wouldn't 
likely be used for the PC version of iCommand, the PC ant-build script would 
just not incorporate that when it does the build, whereas the JME version 
would include that package. 

Re: [Nxtcommand-developers] iCommand 0.5 CLDC pre2

[Brian Bagnall <bbagnall@mt...>]

We're talking about making two seperate code bases, correct? One code base 
for iCommand for PC's and one code base for Cell Phones/PDA's using JME? In 
other words, if we make a change to the Motor class in the iCommand project 
we'll have to remember to manually go and make the same change to the Motor 
class in the JME project too?

To me, that sounds like a nightmare and not the proper way to structure the 
project. We should go with the one tiny pre-processor command in the 
NXTCommand class (plus a different ant-build script for the JME version) and 
then we can keep the iCommand project unified.

Stefano, do you agree with this? I'm just going by guesswork since I've 
never done this before. If we use the preprocessor command, does that get in 
the way of your own development projects?

- Brian

----- Original Message ----- 
From: "Peter Joosten" <ptg.joosten@...>
To: "Brian Bagnall" <bbagnall@...>; "iCommand Developers" 
<nxtcommand-developers@...>
Sent: Wednesday, December 06, 2006 3:39 PM
Subject: RE: [Nxtcommand-developers] iCommand 0.5 CLDC pre2


> Brian, maybe you can roll some dice to make a decision ;-)
>
> Maybe from an academic point of view, preprocessor is the way to go.
>
> As far as I understand, Stefano, prefers to have a seperate ported
> ICommand copy in his project. Maybe that should be the main argument
> to make a decision. See how it works.
>
>>
>> Well, I'm probably the last guy who should have final say on which way to
> 

Re: [Nxtcommand-developers] developers mailinglist seenfromsourceforge website

[Peter Joosten <ptg.joosten@ch...>]

OK! 

> > 2. I did not now that there was public read-access to the 
> developers list. 
> > I
> > better watch my mouth.
> 
> Thought this would be best in case future developers want to catch up on 
> topics.
> 
> - Brian 
> 

Re: [Nxtcommand-developers] iCommand 0.5 CLDC pre2

[Peter Joosten <ptg.joosten@ch...>]

Brian, maybe you can roll some dice to make a decision ;-)

Maybe from an academic point of view, preprocessor is the way to go.

As far as I understand, Stefano, prefers to have a seperate ported
ICommand copy in his project. Maybe that should be the main argument
to make a decision. See how it works.

>
> Well, I'm probably the last guy who should have final say on which way to

Re: [Nxtcommand-developers] developers mailinglist seen fromsourceforge website

[Brian Bagnall <bbagnall@mt...>]

>I just had a look at the archive of the developers mailinglist from the
> nxtcommand project website at sourceforge.
> 1. It really looks like <!-- censored -->, because all end-of line
> characters are ignored.
>   Is there someting we can do about that ?

That looks ugly. I changed something about an ascii bit in the settings but 
I'm not sure if it will have an effect.

> 2. I did not now that there was public read-access to the developers list. 
> I
> better watch my mouth.

Thought this would be best in case future developers want to catch up on 
topics.

- Brian 

Re: [Nxtcommand-developers] iCommand 0.5 CLDC pre2

[Brian Bagnall <bbagnall@mt...>]

Well, I'm probably the last guy who should have final say on which way to 
go, seeing as my experience isn't great with preprocessor usage. Here's how 
I break it down in pluses and minuses:

Two Separate Code Bases:
+ Neater code
- Must manually move improvements from one project to the other

Preprocessor commands:
- Code looks messy
- More complicated, higher learning curve for developers
+ An improvement for one platform improves all platforms

To me it looks like Preprocessor commands wins out because manually updating 
code for each project will be a tedious task. I think our preprocessor 
commands are going to be limited to just a few places, and once we get the 
Ant-Build script in place it will be one click to build the respective 
projects.

Are there other pluses/minuses I'm missing? Like I say, I'm not too familiar 
with these tools.

- Brian

----- Original Message ----- 
From: "Peter Joosten" <ptg.joosten@...>
To: "Stefano Sanna" <gerdavax@...>; "iCommand Developers" 
<nxtcommand-developers@...>
Sent: Monday, December 04, 2006 10:52 AM
Subject: Re: [Nxtcommand-developers] iCommand 0.5 CLDC pre2


> Just to be sure: I have no "hard" objections when the CLDC projects have a
> modified copy of icommand in it. Maybe my arguments are becoming a little
> theoretical. Using 1 source tree will surely increase complexity, and
> (probably)
> needs more strict planning of releases. And to be honest, using 
> preprocessor
> commands
> is the only way (I know of) to have 1 source tree to support multiple
> execution
> environments, but hat does not mean that I like #ifdef / #endif cluttering
> my code.
>
>> Brian, you have the final word :-)
>
> I agree @:-$)>
>
> Peter Joosten.
>
>> -----Original Message-----
>> From: nxtcommand-developers-bounces@...
>> [mailto:nxtcommand-developers-bounces@...]On Behalf Of
>> Stefano Sanna
>> Sent: Monday, December 04, 2006 9:54 AM
>> To: iCommand Developers
>> Subject: Re: [Nxtcommand-developers] iCommand 0.5 CLDC pre2
>>
>>
>> Peter Joosten wrote:
>> > My opinion (this should be our goal, if it is practically
>> feasible ...?):
>>
>> [...]
>>
>> Using preprocessor seems nice, however it brings a new issue. Suppose we
>> have a source code version 2.0. Somebody writes an enhancement to such
>> version, just for the "JSE side", while the "JME side" is still to be
>> update. How do we release this new version? 2.1? Yes and no. It is 2.1
>> from the JSE point of view, while it is still a 2.0 from the JME point
>> of view.
>>
>> What I want to say is that merging JME and JSE code makes sense only if
>> we synchronously release the same version for both platforms. Otherwise
>> it will get confused. Moreover, Javadoc generation will have to take
>> into account differences between JSE and JME.
>>
>> Brian, you have the final word :-)
>>
>> Cheers,
>> Stefano.
>>
>> --
>> Stefano Sanna - gerdavax@...
>> Personal web site: http://www.gerdavax.it
>> AIM: gerdavax - Skype: gerdavax - Callsign: IS0DZE
>>
>> -------------------------------------------------------------------------
>> Take Surveys. Earn Cash. Influence the Future of IT
>> Join SourceForge.net's Techsay panel and you'll get the chance to
>> share your
>> opinions on IT & business topics through brief surveys - and earn cash
>> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
>> _______________________________________________
>> Nxtcommand-developers mailing list
>> Nxtcommand-developers@...
>> https://lists.sourceforge.net/lists/listinfo/nxtcommand-developers
>
>
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share 
> your
> opinions on IT & business topics through brief surveys - and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> Nxtcommand-developers mailing list
> Nxtcommand-developers@...
> https://lists.sourceforge.net/lists/listinfo/nxtcommand-developers
> 

[Nxtcommand-developers] developers mailinglist seen from sourceforge website

[Peter Joosten <ptg.joosten@ch...>]

I just had a look at the archive of the developers mailinglist from the
nxtcommand project website at sourceforge.
1. It really looks like <!-- censored -->, because all end-of line
characters are ignored.
   Is there someting we can do about that ?
2. I did not now that there was public read-access to the developers list. I
better watch my mouth.

Peter Joosten.

Re: [Nxtcommand-developers] Multiple NXT Bricks

[Brian Bagnall <bbagnall@mt...>]

Hi Roly,

We would really appreciate some help from someone who can offer a 
perspective on controlling two bricks. None of us in the team have more than 
one brick so we don't really know what it takes to do that.

We've talked about a possible change to the API to make it friendly for two 
or more NXT's but so far we haven't done anything concrete. I would love it 
if you could pick up that part of the project and run with it. I guess the 
first step is to send your Sourceforge ID (and anyone else on your project 
who will contribute to your programming).

BTW Tank battle sounds neat. Kind of like some of the old 
Atari/Intellivision games.

- Brian

----- Original Message ----- 
From: "Roly Vicaria" <rolyv19@...>
To: <bbagnall@...>
Sent: Monday, December 04, 2006 3:44 PM
Subject: Hello, my name is Roly Vicaria...


> ... I am a CS student at Florida International University. This semester I
> was put in charge of a mentorship project which is designed to attract
> students to Engineering. The project I chose was to create a "game" using 
> 2
> NXT kits. The game is a simulated Tank Battle where each NXT tank will 
> seek
> out its enemy according to the algorithms it's programmed with ( there can
> be different type of tanks with different algorithms, eg. lazy, wanderer,
> destroyer, etc...we want the game to be able to extend to more than 2 
> tanks
> in the future  ).
>
> That was all the background info...bottom line is that I have been trying 
> to
> write the battle simulation code in Java using the iCommand API to tell 
> each
> tank what to do at any given point thru the Bluetooth connection based on
> the information that each tank sends back from their sensors.
>
> I know that the code is very buggy, I have become intimately familiar with
> all of it. I was reading through your mailing lists on Sourceforge about
> changes you are anticipating for v. 0.6 and I think that you have some 
> great
> ideas floating around. I particularly noted how you were making an
> intentional decision to not focus on the multiple NXT case from your 
> design
> for the time being "since you don't know many people with more than 1". I
> was wondering if you needed any more help with it since we just so happen 
> to
> have 2 that will have to work with a laptop running the simulation code
> through a single Bluetooth dongle.
>
> I have a team of 3 guys that we are building our NXT tanks and refining 
> the
> code as we've come across problems, so we can put in plenty of time into
> this.
>
>
> Sincerely,
>
> Roly Vicaria
> 

Re: [Nxtcommand-developers] iCommand 0.5 CLDC pre2

[Peter Joosten <ptg.joosten@ch...>]

I have just a look at the code of icommand-0.5 CLDC pre2 for the 1st time.
There are not that many changes to the code.
Some of CLDC code is supported by the J2SE, so we can have the CLDC code
for both CLDC and J2SE, even reducing the differences.

I do not now if the code is already fully ported, or if the changes will
increase much more in the future.

Peter Joosten.

[Nxtcommand-developers] reply for Peter Joosten

[Kirkey, Kurt M. <kurt.kirkey@un...>]

Dear Peter,

=20

Reply below:

=20

Message: 3

Date: Mon, 4 Dec 2006 04:42:28 +0100

From: "Peter Joosten" <ptg.joosten@...>

Subject: Re: [Nxtcommand-developers] iCommand 0.5 CLDC pre2

To: "iCommand Developers"

      <nxtcommand-developers@...>

Message-ID: <IOEMLEDHODCADJMONPMOMEIJCBAA.ptg.joosten@...>

Content-Type: text/plain;     charset=3D"us-ascii"

=20

My opinion (this should be our goal, if it is practically feasible
...?):

=20

1. One source tree for the icommand library using preprocessor macros

   to differentiate between the execution environments.

2. Applications using the icommand library should be in seperate
projects

   These projects may have NXTComm implementations, because in my
opinion

   NXTComm implementations do not belong to the (core) icommand library.

   (For convenience we will keep the "i386" NXTComm implementations
where

   they are.)

   These projects however will have a dependency on the icommand

   project, and should not contain a (modified) copy of the icommand

sources.

   Platform specific bytecode can be preprocessed/compiled from the
icommand

source tree.

=20

Have look at the Simple Java PreProcessor (SJPP) :

http://www.vortoj.com/sjpp/readme.html

=20

1. I have a file pp.charset.properties in my home directory:

charset =3D PRJ-J2SE \

          PRJ-J2ME

=20

PRJ-J2SE.defines =3D J2SE

PRJ-J2ME.defines =3D J2ME

-----------------------

2. I have a java source that looks like this, when I open it with a text

editor (notepad)

=20

public class Sample {

=20

      public static void main(String[] args) {

#ifdef J2ME

            System.out.println("J2ME");

#endif

#ifdef J2SE

            System.out.println("J2SE");

#endif

      }

}

=20

3. But when I open the java source and I set the encoding of the project
to

PRJ-J2ME

   in the IDE it looks like (all non-J2ME code commented out):

=20

public class Sample {

=20

      public static void main(String[] args) {

//~#ifdef J2ME

            System.out.println("J2ME");

//~#endif

//~#ifdef J2SE

//~         System.out.println("J2SE");

//~#endif

      }

}

=20

So with this preprocessor You do not first have to gerenerate platform

specific

source code, in order to run your program within the ide. I have tested
SJPP

with Eclipse and NetBeans. Eclipse: OK. NetBeans: Nearly OK. It gives an

error

at the last statement of the code. I you delete the invisible character

after

the statement and then add a space, the error disappears. I think this
is an

error in the sjpp generating some strange invisible character at the end

(EOF ?).

I will have to look into this. Maybe there are some better
preprocessors,

but this is the best I have found so far. With the other pre-processors
I

have

found, you first have to generate the platform specific source code,
before

you can

run your application. I do not like that. Whether it's a good idea to
use a

preprocessor ? It will depend on the preprocessors functionality.

I have used sjpp pre-processor on a past project and it works fine:
although, I'm not a big fan of pre-processor's in Java/C#)

=20

Peter Joosten.

=20

Re: [Nxtcommand-developers] iCommand 0.5 CLDC pre2

[Peter Joosten <ptg.joosten@ch...>]

Just to be sure: I have no "hard" objections when the CLDC projects have a
modified copy of icommand in it. Maybe my arguments are becoming a little
theoretical. Using 1 source tree will surely increase complexity, and
(probably)
needs more strict planning of releases. And to be honest, using preprocessor
commands
is the only way (I know of) to have 1 source tree to support multiple
execution
environments, but hat does not mean that I like #ifdef / #endif cluttering
my code.

> Brian, you have the final word :-)

I agree @:-$)>

Peter Joosten.

> -----Original Message-----
> From: nxtcommand-developers-bounces@...
> [mailto:nxtcommand-developers-bounces@...]On Behalf Of
> Stefano Sanna
> Sent: Monday, December 04, 2006 9:54 AM
> To: iCommand Developers
> Subject: Re: [Nxtcommand-developers] iCommand 0.5 CLDC pre2
>
>
> Peter Joosten wrote:
> > My opinion (this should be our goal, if it is practically
> feasible ...?):
>
> [...]
>
> Using preprocessor seems nice, however it brings a new issue. Suppose we
> have a source code version 2.0. Somebody writes an enhancement to such
> version, just for the "JSE side", while the "JME side" is still to be
> update. How do we release this new version? 2.1? Yes and no. It is 2.1
> from the JSE point of view, while it is still a 2.0 from the JME point
> of view.
>
> What I want to say is that merging JME and JSE code makes sense only if
> we synchronously release the same version for both platforms. Otherwise
> it will get confused. Moreover, Javadoc generation will have to take
> into account differences between JSE and JME.
>
> Brian, you have the final word :-)
>
> Cheers,
> Stefano.
>
> --
> Stefano Sanna - gerdavax@...
> Personal web site: http://www.gerdavax.it
> AIM: gerdavax - Skype: gerdavax - Callsign: IS0DZE
>
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to
> share your
> opinions on IT & business topics through brief surveys - and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> Nxtcommand-developers mailing list
> Nxtcommand-developers@...
> https://lists.sourceforge.net/lists/listinfo/nxtcommand-developers

Re: [Nxtcommand-developers] iCommand 0.5 CLDC pre2

[Stefano Sanna <gerdavax@ti...>]

Hi.

Brian Bagnall wrote:
> 
> I have NO mobile devices. :( Not sure what I'm waiting for seeing as they 
> are so cheap and full featured. I want one with GPS, Bluetooth, Wi-Fi, 
> Camera, Cell Phone, Keyboard, and Windows Mobile 5.0. Some contenders are 
> UTStarcom PPC 6700 (www.utstar.com), HP iPAQ, IMate Jasjar, or Palm Treo 
> 700W.

The new Fujitsu-Siemens T830 has most of the feature you are looking 
for, including GPS.

> BTW Are you set up to commit code to subversion yet? If not there's a doc 
> here on how to do it:
> http://sourceforge.net/docman/?group_id=178176

Before updating the code it would be better you to say the final word 
about branching vs preprocessing approach for JME code.

Regards,
Stefano.

-- 
Stefano Sanna - gerdavax@...
Personal web site: http://www.gerdavax.it
AIM: gerdavax - Skype: gerdavax - Callsign: IS0DZE