Re: [Nxtcommand-developers] iCommand 0.5 CLDC pre2

SourceForge Headquarters 225 Broadway Suite 1600 San Diego, CA 92101 +1 (858) 422-6466

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
> 