Thread: Re: [Nxtcommand-developers] iCommand 0.5 CLDC pre2
Status: Beta
Brought to you by:
bbagnall
From: Peter J. <ptg...@ch...> - 2006-11-24 17:29:51
|
Message was bounced. Try again. See previous message > -----Original Message----- > From: Peter Joosten [mailto:ptg...@ch...] > Sent: Friday, November 24, 2006 6:27 PM > To: Stefano Sanna; iCommand Developers > Subject: RE: [Nxtcommand-developers] iCommand 0.5 CLDC pre2 > > > We could icommand CLDC into a seperate project in subversion. > But how about the next idea ? > > We could use a java preprocessor, and integrate the code into the > "standard" icommand project. This works just like C/C++ #define, > #ifdef #end-if, ... > > 1. Benefits: > Prevents duplicate code. So we only have to maintain 1 source tree. > 2. Possible draw back: > You have to generate the source code for a specific platform by the > preprocessor, before it can be run. (But thats the way C programmers > work all the time) > > Preprocessing can be done by an Ant target of de build.xml > > I do not now if there will be an issue with the IDE (Eclipse) not > recognizing the preprocessor macros, resulting in Java error codes, > or maybe there is a plugin that fixes this. Also not sure of the > drawback, because this is dependend on the preprocessor product > where going to use. > > ======================================================================== > I am willing to look into this, if you agree with the gerenal idea using > a preprocessor and integrating icommmand cldc into the existing project. > ======================================================================== > > I can make a diff between "standard" and cldc icommand to decide where > to put the preprocessor commands. Generate the code for both platforms, > and diff generated sources with supplied sources for both plaforms to > verify correctness. > > Peter Joosten. > > > > > > > > -----Original Message----- > > From: nxt...@li... > > [mailto:nxt...@li...]On Behalf Of > > Stefano Sanna > > Sent: Friday, November 24, 2006 7:21 AM > > To: iCommand Developers > > Subject: [Nxtcommand-developers] iCommand 0.5 CLDC pre2 > > > > > > Hi all. > > > > I've just uploaded the pre2 version of iCommand 0.5 for CLDC. It solves > > some issues with properties initialization. > > > > You can find it at: > > > > http://www.esnips.com/doc/ae3ba49a-e1a7-4da5-8568-b7580bdde921 > > > > Brian, once iCommand for CLDC is stable we may put it into sourceforge > > repository. Is it ok? > > > > Best regards, > > Stefano. > > > > -- > > Stefano Sanna - ger...@ti... > > Personal web site: http://www.gerdavax.it > > AIM: gerdavax - Skype: gerdavax - Callsign: IS0DZE > > > > *** Solo chi non fa niente non sbaglia *** > > > > > ------------------------------------------------------------------------- > > 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-11-24 19:13:30
|
Hi Peter, hi all. Peter Joosten wrote: > We could icommand CLDC into a seperate project in subversion. > But how about the next idea ? > > We could use a java preprocessor, and integrate the code into the > "standard" icommand project. This works just like C/C++ #define, > #ifdef #end-if, ... > > 1. Benefits: > Prevents duplicate code. So we only have to maintain 1 source tree. > 2. Possible draw back: > You have to generate the source code for a specific platform by the > preprocessor, before it can be run. (But thats the way C programmers > work all the time) > > Preprocessing can be done by an Ant target of de build.xml [...] From my point of view, porting from JSE to JME is not an automatic task, it a creative work. The developer has to substitute classes of standard edition with the (more or less) equivalent of micro edition, how event he/she has to optimize code if necessary. Moreover, JME version will be split into specialized versions for different kind of devices. For instance, current version of JNXT works on Windows Mobile devices and has a pen-based input; upcoming version for Symbian OS will be joypad based: the two versions will be managed through the configuration manager of Netbeans, which has been design to handle this kind of specific issues of JME development. I suggest to keep the two separate projects: iCommand and iCommand_CLDC. The more iCommand gets enhanced, the more we will have to carefully port it to CLDC. Best regards, Stefano. -- Stefano Sanna - ger...@ti... Personal web site: http://www.gerdavax.it AIM: gerdavax - Skype: gerdavax - Callsign: IS0DZE Best of Banana Fratelli D'Etails Gerda: "Mi hanno contattato per avere idee nuove..." Dada: "... e le vanno a chiedere proprio a te???" |
From: Peter J. <ptg...@ch...> - 2006-11-24 21:39:54
|
> > > > Preprocessing can be done by an Ant target of de build.xml > > [...] > > From my point of view, porting from JSE to JME is not an automatic > task, it a creative work. The developer has to substitute classes of I agree it can not be automated. That was not the argument. My goal was to prevent duplicate code. The suggestion was to use 1 "master" source tree with preprocessor macros, from which the several platform dependend source code can be generated. This is an automated process. You still wil have to program ALL the code between the macros yourself. #define CLDC #ifdef CLDC // CLDC int lastPos = name.toString().indexOf(".") + 4; //CLDC #else // CLDC UNSUPPORTED // int lastPos = name.indexOf(".") + 4; // CLDC UNSUPPORTED #endif Generated source: // CLDC int lastPos = name.toString().indexOf(".") + 4; //CLDC > standard edition with the (more or less) equivalent of micro edition, > how event he/she has to optimize code if necessary. Moreover, JME > version will be split into specialized versions for different kind of > devices. For instance, current version of JNXT works on Windows Mobile You are the better judge of how much code can be reused, and if this is a usefull suggestion, or not. The more platforms that will be supported, the greater the risk of cluttering the source code with macro statements. > I suggest to keep the two separate projects: iCommand and iCommand_CLDC. I have no objections. > The more iCommand gets enhanced, the more we will have to carefully port > it to CLDC. That's why I suggest to keep as much code as possible platform independend. If this is feasible ? For the GUI layer and bluetooth interface it is not. Peter Joosten. |
From: Brian B. <bba...@mt...> - 2006-11-25 01:04:12
|
Hi Stefano, I'm a little confused about what our goal is for CLDC integration. Are you basically uploading iCommand code directly to Windows Mobile devices and running it from there, without the PC taking any action once the cell phone device takes command of the NXT? If that is the case, maybe the best thing to do would be to use the NXTComm interface, creating NXTCommCLDC. The user can choose to use CLDC via the icommand.properties file setting. So far we have NXTCommRXTX, NXTCommBluez, and NXTCommSun (using the Java Communications API). It looks like your changes to the code are exclusively in the NXTComm class. BTW Do you develop and compile the code on a PC and then upload it to your cell phone? How does the code get uploaded to your cell phone? - Brian ----- Original Message ----- From: "Stefano Sanna" <ger...@ti...> To: <ptg...@ch...> Cc: "iCommand Developers" <nxt...@li...> Sent: Friday, November 24, 2006 1:13 PM Subject: Re: [Nxtcommand-developers] iCommand 0.5 CLDC pre2 > Hi Peter, hi all. > > Peter Joosten wrote: >> We could icommand CLDC into a seperate project in subversion. >> But how about the next idea ? >> >> We could use a java preprocessor, and integrate the code into the >> "standard" icommand project. This works just like C/C++ #define, >> #ifdef #end-if, ... >> >> 1. Benefits: >> Prevents duplicate code. So we only have to maintain 1 source tree. >> 2. Possible draw back: >> You have to generate the source code for a specific platform by the >> preprocessor, before it can be run. (But thats the way C programmers >> work all the time) >> >> Preprocessing can be done by an Ant target of de build.xml > > [...] > > From my point of view, porting from JSE to JME is not an automatic > task, it a creative work. The developer has to substitute classes of > standard edition with the (more or less) equivalent of micro edition, > how event he/she has to optimize code if necessary. Moreover, JME > version will be split into specialized versions for different kind of > devices. For instance, current version of JNXT works on Windows Mobile > devices and has a pen-based input; upcoming version for Symbian OS will > be joypad based: the two versions will be managed through the > configuration manager of Netbeans, which has been design to handle this > kind of specific issues of JME development. > > I suggest to keep the two separate projects: iCommand and iCommand_CLDC. > The more iCommand gets enhanced, the more we will have to carefully port > it to CLDC. > > Best regards, > Stefano. > > -- > Stefano Sanna - ger...@ti... > Personal web site: http://www.gerdavax.it > AIM: gerdavax - Skype: gerdavax - Callsign: IS0DZE > > Best of Banana > > Fratelli D'Etails > > Gerda: "Mi hanno contattato per avere idee nuove..." > Dada: "... e le vanno a chiedere proprio a te???" > > ------------------------------------------------------------------------- > 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-03 21:40:15
|
----- Original Message ----- From: "Stefano Sanna" <ger...@ti...> >> >> If that is the case, maybe the best thing to do would be to use the >> NXTComm interface, creating NXTCommCLDC. The user can choose to use CLDC >> via the icommand.properties file setting. So far we have NXTCommRXTX, >> NXTCommBluez, and NXTCommSun (using the Java Communications API). It >> looks like your changes to the code are exclusively in the NXTComm class. > > I changed code in the Properties class and others. Even if we use > different implementations for NXTComm interface, the bytecode for standard > edition will be not compatible with JME devices. In other words, once the > code as been modified, it must be compiled especially for the JME target. > The same is required for libraries. > > That's why I suggest to have to source tree for JSE and JME. It Could we keep the same source tree but just have two seperate releases: one compiled for standard JVM and one compiled specifically for JME? (2 different downloads on the home page but one common source code base). Some of the other classes would be useless to the JME build and could be excluded with the ANT-build script. - Brian |
From: Peter J. <ptg...@ch...> - 2006-12-04 03:51:03
|
My opinion (this should be our goal, if it is practically feasible ...?): 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. Have look at the Simple Java PreProcessor (SJPP) : http://www.vortoj.com/sjpp/readme.html 1. I have a file pp.charset.properties in my home directory: charset = PRJ-J2SE \ PRJ-J2ME PRJ-J2SE.defines = J2SE PRJ-J2ME.defines = J2ME ----------------------- 2. I have a java source that looks like this, when I open it with a text editor (notepad) public class Sample { public static void main(String[] args) { #ifdef J2ME System.out.println("J2ME"); #endif #ifdef J2SE System.out.println("J2SE"); #endif } } 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): public class Sample { public static void main(String[] args) { //~#ifdef J2ME System.out.println("J2ME"); //~#endif //~#ifdef J2SE //~ System.out.println("J2SE"); //~#endif } } 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. Peter Joosten. > -----Original Message----- > From: nxt...@li... > [mailto:nxt...@li...]On Behalf Of > Brian Bagnall > Sent: Sunday, December 03, 2006 10:40 PM > To: iCommand Developers > Subject: Re: [Nxtcommand-developers] iCommand 0.5 CLDC pre2 > > > ----- Original Message ----- > From: "Stefano Sanna" <ger...@ti...> > >> > >> If that is the case, maybe the best thing to do would be to use the > >> NXTComm interface, creating NXTCommCLDC. The user can choose > to use CLDC > >> via the icommand.properties file setting. So far we have NXTCommRXTX, > >> NXTCommBluez, and NXTCommSun (using the Java Communications API). It > >> looks like your changes to the code are exclusively in the > NXTComm class. > > > > I changed code in the Properties class and others. Even if we use > > different implementations for NXTComm interface, the bytecode > for standard > > edition will be not compatible with JME devices. In other > words, once the > > code as been modified, it must be compiled especially for the > JME target. > > The same is required for libraries. > > > > That's why I suggest to have to source tree for JSE and JME. It > > Could we keep the same source tree but just have two seperate > releases: one > compiled for standard JVM and one compiled specifically for JME? (2 > different downloads on the home page but one common source code > base). Some > of the other classes would be useless to the JME build and could > be excluded > with the ANT-build script. > > - Brian > > > ------------------------------------------------------------------------- > 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-04 05:39:22
|
Hi Peter, SJPP looks good. We probably won't have to use many preprocessor commands anyway - mostly the import I'm guessing, and the code that chooses which NXTComm to use. When you say it works with Eclipse, do you mean it works as a sort of plugin? - Brian ----- Original Message ----- From: "Peter Joosten" <ptg...@ch...> To: "iCommand Developers" <nxt...@li...> Sent: Sunday, December 03, 2006 9:42 PM Subject: Re: [Nxtcommand-developers] iCommand 0.5 CLDC pre2 > My opinion (this should be our goal, if it is practically feasible ...?): > > 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. > > Have look at the Simple Java PreProcessor (SJPP) : > http://www.vortoj.com/sjpp/readme.html > > 1. I have a file pp.charset.properties in my home directory: > charset = PRJ-J2SE \ > PRJ-J2ME > > PRJ-J2SE.defines = J2SE > PRJ-J2ME.defines = J2ME > ----------------------- > 2. I have a java source that looks like this, when I open it with a text > editor (notepad) > > public class Sample { > > public static void main(String[] args) { > #ifdef J2ME > System.out.println("J2ME"); > #endif > #ifdef J2SE > System.out.println("J2SE"); > #endif > } > } > > 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): > > public class Sample { > > public static void main(String[] args) { > //~#ifdef J2ME > System.out.println("J2ME"); > //~#endif > //~#ifdef J2SE > //~ System.out.println("J2SE"); > //~#endif > } > } > > 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. > > Peter Joosten. > >> -----Original Message----- >> From: nxt...@li... >> [mailto:nxt...@li...]On Behalf Of >> Brian Bagnall >> Sent: Sunday, December 03, 2006 10:40 PM >> To: iCommand Developers >> Subject: Re: [Nxtcommand-developers] iCommand 0.5 CLDC pre2 >> >> >> ----- Original Message ----- >> From: "Stefano Sanna" <ger...@ti...> >> >> >> >> If that is the case, maybe the best thing to do would be to use the >> >> NXTComm interface, creating NXTCommCLDC. The user can choose >> to use CLDC >> >> via the icommand.properties file setting. So far we have NXTCommRXTX, >> >> NXTCommBluez, and NXTCommSun (using the Java Communications API). It >> >> looks like your changes to the code are exclusively in the >> NXTComm class. >> > >> > I changed code in the Properties class and others. Even if we use >> > different implementations for NXTComm interface, the bytecode >> for standard >> > edition will be not compatible with JME devices. In other >> words, once the >> > code as been modified, it must be compiled especially for the >> JME target. >> > The same is required for libraries. >> > >> > That's why I suggest to have to source tree for JSE and JME. It >> >> Could we keep the same source tree but just have two seperate >> releases: one >> compiled for standard JVM and one compiled specifically for JME? (2 >> different downloads on the home page but one common source code >> base). Some >> of the other classes would be useless to the JME build and could >> be excluded >> with the ANT-build script. >> >> - Brian >> >> >> ------------------------------------------------------------------------- >> 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-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: 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-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: 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: Stefano S. <ger...@ti...> - 2006-12-04 08:53:54
|
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 |
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: 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-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-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: 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: 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: 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: Stefano S. <ger...@ti...> - 2006-12-04 08:53:12
|
Brian Bagnall wrote: > > Could we keep the same source tree but just have two seperate releases: one > compiled for standard JVM and one compiled specifically for JME? (2 > different downloads on the home page but one common source code base). Some > of the other classes would be useless to the JME build and could be excluded > with the ANT-build script. I experienced that it is better to separate code for JME and JSE, however it is ok for me to try the pre-processing way. Stefano. -- Stefano Sanna - ger...@ti... Personal web site: http://www.gerdavax.it AIM: gerdavax - Skype: gerdavax - Callsign: IS0DZE |
From: Stefano S. <ger...@ti...> - 2006-11-28 20:28:20
|
Peter Joosten wrote: >>> Preprocessing can be done by an Ant target of de build.xml >> [...] >> >> From my point of view, porting from JSE to JME is not an automatic >> task, it a creative work. The developer has to substitute classes of > > I agree it can not be automated. That was not the argument. My goal > was to prevent duplicate code. The suggestion was to use 1 "master" > source tree with preprocessor macros, from which the several platform > dependend source code can be generated. This is an automated process. > You still wil have to program ALL the code between the macros yourself. > > #define CLDC > > #ifdef CLDC > // CLDC > int lastPos = name.toString().indexOf(".") + 4; > //CLDC > #else > // CLDC UNSUPPORTED > // int lastPos = name.indexOf(".") + 4; > // CLDC UNSUPPORTED > #endif > > Generated source: > // CLDC > int lastPos = name.toString().indexOf(".") + 4; > //CLDC OK, sorry for my misunderstaning. It seems ok. It would be good to have an ANT task for extracting source code for a certain platform. >> standard edition with the (more or less) equivalent of micro edition, >> how event he/she has to optimize code if necessary. Moreover, JME >> version will be split into specialized versions for different kind of >> devices. For instance, current version of JNXT works on Windows Mobile > > You are the better judge of how much code can be reused, and if this is > a usefull suggestion, or not. The more platforms that will be supported, > the greater the risk of cluttering the source code with macro statements. Maybe the good solution is in the middle (in italian we say: "the truth is in the middle"). We may start with two separate source archives, having in mind that if complexity grows we may switch to macro approach. >> I suggest to keep the two separate projects: iCommand and iCommand_CLDC. > > I have no objections. > >> The more iCommand gets enhanced, the more we will have to carefully port >> it to CLDC. > > That's why I suggest to keep as much code as possible platform independend. > If this is feasible ? For the GUI layer and bluetooth interface is not. You are right: Bluetooth and GUI not. However, we may evaluate to use a JSR 82 stack on desktop platform: Avetana Bluetooth for Linux and Bluecove for Windows. In both cases we would have the same API of JME. Best regards, Stefano. -- Stefano Sanna - ger...@ti... Personal web site: http://www.gerdavax.it AIM: gerdavax - Skype: gerdavax - Callsign: IS0DZE Best of Banana Fratelli D'Etails Gerda: "Mi hanno contattato per avere idee nuove..." Dada: "... e le vanno a chiedere proprio a te???" |
From: Peter J. <ptg...@ch...> - 2006-11-30 17:14:22
|
Vote +1 My thougths: Make a separate project in subversion: 1. You need one for the gui anyway. 2. You need one because you are using NetBeans instead of Eclipse. NetBeans has better support for Mobile Apllications, so it's a good choice. At a later moment we can have a look if it is possible the reintegrate the ICommand part of your application back into the ICommand project. But than still you wiil have the need for a seperate project. > > Maybe the good solution is in the middle (in italian we say: "the truth > is in the middle"). We may start with two separate source archives, > having in mind that if complexity grows we may switch to macro approach. > |
From: Stefano S. <ger...@ti...> - 2006-11-30 21:18:59
|
Peter Joosten wrote: > Vote +1 > > My thougths: > > Make a separate project in subversion: > 1. You need one for the gui anyway. > 2. You need one because you are using NetBeans instead of Eclipse. > NetBeans has better support for Mobile Apllications, so it's a good > choice. > > At a later moment we can have a look if it is possible the reintegrate > the ICommand part of your application back into the ICommand project. > But than still you wiil have the need for a seperate project. Excellent! I'm getting close to release code for Nokia devices (some Series 60). May I ask you (all) what kind of Java mobile phone you have? Just to focus my tests on devices actually available on the iCommand community. Thank you. All the best Stefano. -- Stefano Sanna - ger...@ti... Personal web site: http://www.gerdavax.it AIM: gerdavax - Skype: gerdavax - Callsign: IS0DZE |
From: Peter J. <ptg...@ch...> - 2006-11-30 21:48:17
|
Stefano, Brian is the BOSS here ;-) So maybe you should wait for his GO/NOGO I am just a humble servent. (Brain did I earn my right to vote ?) However, I have created the icommand-bluez project, without asking. Peter. > -----Original Message----- > From: Stefano Sanna [mailto:ger...@ti...] > Sent: Thursday, November 30, 2006 10:19 PM > To: iCommand Developers > Cc: ptg...@ch... > Subject: Re: [Nxtcommand-developers] iCommand 0.5 CLDC pre2 > > > Peter Joosten wrote: > > Vote +1 > > > > My thougths: > > > > Make a separate project in subversion: > > 1. You need one for the gui anyway. > > 2. You need one because you are using NetBeans instead of Eclipse. > > NetBeans has better support for Mobile Apllications, so it's a good > > choice. > > > > At a later moment we can have a look if it is possible the reintegrate > > the ICommand part of your application back into the ICommand project. > > But than still you wiil have the need for a seperate project. > > Excellent! > > I'm getting close to release code for Nokia devices (some Series 60). > May I ask you (all) what kind of Java mobile phone you have? Just to > focus my tests on devices actually available on the iCommand community. > > Thank you. > > All the best > Stefano. > > -- > Stefano Sanna - ger...@ti... > Personal web site: http://www.gerdavax.it > AIM: gerdavax - Skype: gerdavax - Callsign: IS0DZE |
From: Brian B. <bba...@mt...> - 2006-12-03 21:55:05
|
----- Original Message ----- From: "Stefano Sanna" <ger...@ti...> > > Excellent! > > I'm getting close to release code for Nokia devices (some Series 60). > May I ask you (all) what kind of Java mobile phone you have? Just to > focus my tests on devices actually available on the iCommand community. Hi Stefano, 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. 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 - Brian |