nxtcommand-developers Mailing List for iCommand (Page 2)
Status: Beta
Brought to you by:
bbagnall
Menu
▾
▴
nxtcommand-developers — Forum for developers to discuss changes and improvements to iCommand.
You can subscribe to this list here.
| 2006 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(50) |
Dec
(38) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2007 |
Jan
(1) |
Feb
(4) |
Mar
(3) |
Apr
|
May
|
Jun
|
Jul
(7) |
Aug
(2) |
Sep
(1) |
Oct
(1) |
Nov
|
Dec
|
|
From: Peter J. <ptg...@ch...> - 2006-12-16 20:56:49
|
> 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...@ch...> > To: "Brian Bagnall" <bba...@mt...>; "iCommand Developers" > <nxt...@li...> > 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 > Nxt...@li... > https://lists.sourceforge.net/lists/listinfo/nxtcommand-developers > |
|
From: Brian B. <bba...@mt...> - 2006-12-16 04:56:40
|
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...@ch...> To: "Brian Bagnall" <bba...@mt...>; "iCommand Developers" <nxt...@li...> 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. > |
|
From: Peter J. <ptg...@ch...> - 2006-12-15 16:23:36
|
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. |
|
From: Peter J. <ptg...@ch...> - 2006-12-15 15:35:32
|
> > 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. |
|
From: Brian B. <bba...@mt...> - 2006-12-15 00:42:29
|
----- Original Message ----- From: "Peter Joosten" <ptg...@ch...> > 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 > |
|
From: Peter J. <ptg...@ch...> - 2006-12-13 19:45:30
|
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. > |
|
From: Peter J. <ptg...@ch...> - 2006-12-13 19:29:57
|
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 |
|
From: Brian B. <bba...@mt...> - 2006-12-13 06:36:34
|
> 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 |
|
From: Peter J. <ptg...@ch...> - 2006-12-12 19:11:27
|
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:ro...@gm...] Sent: Tuesday, December 12, 2006 8:13 AM To: ptg...@ch... 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 |
|
From: Peter J. <ptg...@ch...> - 2006-12-12 06:43:03
|
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:ro...@gm...]
Sent: Tuesday, December 12, 2006 5:59 AM
To: ptg...@ch...
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...@ch...> 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:ro...@gm...]
Sent: Tuesday, December 12, 2006 3:50 AM
To: ptg...@ch...
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...@ch...> 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: nxt...@li...
> [mailto:nxt...@li... ]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
> Nxt...@li...
> 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
Nxt...@li...
https://lists.sourceforge.net/lists/listinfo/nxtcommand-developers
|
|
From: Peter J. <ptg...@ch...> - 2006-12-12 03:44:48
|
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:ro...@gm...]
Sent: Tuesday, December 12, 2006 3:50 AM
To: ptg...@ch...
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...@ch...> 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: nxt...@li...
> [mailto:nxt...@li...]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
> Nxt...@li...
> 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
Nxt...@li...
https://lists.sourceforge.net/lists/listinfo/nxtcommand-developers
|
|
From: Peter J. <ptg...@ch...> - 2006-12-12 02:37:44
|
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: nxt...@li... > [mailto:nxt...@li...]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 > Nxt...@li... > https://lists.sourceforge.net/lists/listinfo/nxtcommand-developers |
|
From: Peter J. <ptg...@ch...> - 2006-12-11 05:45:01
|
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. |
|
From: Brian B. <bba...@mt...> - 2006-12-07 18:34:12
|
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. |
|
From: Brian B. <bba...@mt...> - 2006-12-07 18:31:16
|
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...@ch...> To: "Brian Bagnall" <bba...@mt...>; "iCommand Developers" <nxt...@li...> 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 > |
|
From: Peter J. <ptg...@ch...> - 2006-12-06 22:19:19
|
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 > |
|
From: Peter J. <ptg...@ch...> - 2006-12-06 21:39:43
|
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 |
|
From: Brian B. <bba...@mt...> - 2006-12-06 18:56:06
|
>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 |
|
From: Brian B. <bba...@mt...> - 2006-12-06 18:43:19
|
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...@ch...> To: "Stefano Sanna" <ger...@ti...>; "iCommand Developers" <nxt...@li...> 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: nxt...@li... >> [mailto:nxt...@li...]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 - ger...@ti... >> 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 >> Nxt...@li... >> 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 > Nxt...@li... > https://lists.sourceforge.net/lists/listinfo/nxtcommand-developers > |
|
From: Peter J. <ptg...@ch...> - 2006-12-05 22:05:18
|
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. |
|
From: Brian B. <bba...@mt...> - 2006-12-05 06:11:19
|
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" <ro...@gm...> To: <bba...@mt...> 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 > |
|
From: Peter J. <ptg...@ch...> - 2006-12-04 20:50:24
|
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. |
|
From: Kirkey, K. M. <kur...@un...> - 2006-12-04 17:06:04
|
Dear Peter,
=20
Reply below:
=20
Message: 3
Date: Mon, 4 Dec 2006 04:42:28 +0100
From: "Peter Joosten" <ptg...@ch...>
Subject: Re: [Nxtcommand-developers] iCommand 0.5 CLDC pre2
To: "iCommand Developers"
<nxt...@li...>
Message-ID: <IOE...@ch...>
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
|
|
From: Peter J. <ptg...@ch...> - 2006-12-04 16:53:11
|
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: nxt...@li... > [mailto:nxt...@li...]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 - ger...@ti... > 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 > Nxt...@li... > https://lists.sourceforge.net/lists/listinfo/nxtcommand-developers |
|
From: Stefano S. <ger...@ti...> - 2006-12-04 08:54:02
|
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 - ger...@ti... Personal web site: http://www.gerdavax.it AIM: gerdavax - Skype: gerdavax - Callsign: IS0DZE |
