nxtcommand-developers Mailing List for iCommand (Page 5)
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: Brian B. <bba...@mt...> - 2006-11-08 19:01:47
|
I think I have a solution to the singleton/multiple NXT/instantiated objects dilemma. After reading about NetBeans, from what I can tell it's sort of an expanded version of JavaBeans that you can use visually in development environments like BlueJ, Netbeans IDE or Eclipse with the NetBeans plugin. The focus is making GUI apps that users can interact with visually. Also they can presumably be used as regular objects in plain text Java code, if we override the no-args constructor? I think we should keep the current static/singleton setup that mirrors leJOS and keep it in the package icommand.platform.nxt, but we could add another package for the Netbeans implementation. We should also aim for sharing common code between these two packages - for example, one place for code that calls Motor.forward(tacho) so that when we improve the accuracy of that call in one class it gets improved for all classes that use that call. It might be possible to just extend each Motor, Sensor, etc... class to make it into a Netbean? We need to figure out the proper architecture for this. - Brian ----- Original Message ----- From: "C.Ho" <cho...@al...> To: <nxt...@li...> Sent: Wednesday, November 08, 2006 12:25 PM Subject: [Nxtcommand-developers] static class > Static class has the limitation of its own. I prefer we change to use Java > bean methodology. One of the pitfalls of static class/method is we have > to look into the static class and method calls first before even trying to > encapsulate logics into one java class. > > I hope I communicate me points clearly. > > Cheung, > > ============================================================ > From: "Peter Joosten" <ptg...@ch...> > Date: 2006/11/08 Wed AM 11:25:59 CST > To: <nxt...@li...> > Subject: Re: [Nxtcommand-developers] icommand.nxtcomm.bluez > > This message was intended for the list > >> -----Original Message----- >> From: Peter Joosten [mailto:ptg...@ch...] >> Sent: Wednesday, November 08, 2006 6:24 PM >> To: Brian Bagnall >> Subject: RE: [Nxtcommand-developers] icommand.nxtcomm.bluez >> >> >> > >> > So rather than a package for each, we could just make an >> interface called >> > NXTComm with the relevant read and write methods, then have >> BluezNXTComm, >> > RXTXNXTComm, etc... The code could default to the best/most >> > common one but >> > if the variable exists then use the appropriate object. >> >> I will take care of it. >> >> > A user named Rojit from the leJOS mailing list says he got more >> > than one NXT >> > brick working with iCommand but then I changed it to singleton >> > static method >> > calls to match leJOS (i.e. Motor.A.forward() instead of >> > nxt.motorA.forward() ). Not many people have multiple NXT bricks >> > but if it's >> > possible to control more than one through Bluetooth we should >> > implement it >> >> I will see if I can come up with a proposal. >> I will also look at the usage of static, access modifiers, ... >> The existing code can use some cleaning up. >> >> > and close() althogether. People seem to favor the commands that >> > match leJOS >> > though. I'm not really sure what to do. >> >> Stick to the Lejos API as much as possible. >> >> > > icommand-bluez-native (eclipse CDT, c) >> > > ====================================== >> > > How about the name of the native library? >> > > Proposal: libicmdbluez.so >> > > >> >> I will commit a project icommand-bluez under icommand-projects >> >> Peter Joosten. >> >> >> >> >> >> > > ------------------------------------------------------------------------- > Using Tomcat but need to do more? Need to support web services, security? > Get stuff done quickly with pre-integrated technology to make your job > easier > Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 > _______________________________________________ > Nxtcommand-developers mailing list > Nxt...@li... > https://lists.sourceforge.net/lists/listinfo/nxtcommand-developers > ============================================================ > > > Cheung, > > > ------------------------------------------------------------------------- > Using Tomcat but need to do more? Need to support web services, security? > Get stuff done quickly with pre-integrated technology to make your job > easier > Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 > _______________________________________________ > Nxtcommand-developers mailing list > Nxt...@li... > https://lists.sourceforge.net/lists/listinfo/nxtcommand-developers > |
|
From: C. Ho <cho...@al...> - 2006-11-08 18:26:01
|
Static class has the limitation of its own. I prefer we change to use Java bean methodology. One of the pitfalls of static class/method is we have to look into the static class and method calls first before even trying to encapsulate logics into one java class. I hope I communicate me points clearly. Cheung, ============================================================ From: "Peter Joosten" <ptg...@ch...> Date: 2006/11/08 Wed AM 11:25:59 CST To: <nxt...@li...> Subject: Re: [Nxtcommand-developers] icommand.nxtcomm.bluez This message was intended for the list > -----Original Message----- > From: Peter Joosten [mailto:ptg...@ch...] > Sent: Wednesday, November 08, 2006 6:24 PM > To: Brian Bagnall > Subject: RE: [Nxtcommand-developers] icommand.nxtcomm.bluez > > > > > > So rather than a package for each, we could just make an > interface called > > NXTComm with the relevant read and write methods, then have > BluezNXTComm, > > RXTXNXTComm, etc... The code could default to the best/most > > common one but > > if the variable exists then use the appropriate object. > > I will take care of it. > > > A user named Rojit from the leJOS mailing list says he got more > > than one NXT > > brick working with iCommand but then I changed it to singleton > > static method > > calls to match leJOS (i.e. Motor.A.forward() instead of > > nxt.motorA.forward() ). Not many people have multiple NXT bricks > > but if it's > > possible to control more than one through Bluetooth we should > > implement it > > I will see if I can come up with a proposal. > I will also look at the usage of static, access modifiers, ... > The existing code can use some cleaning up. > > > and close() althogether. People seem to favor the commands that > > match leJOS > > though. I'm not really sure what to do. > > Stick to the Lejos API as much as possible. > > > > icommand-bluez-native (eclipse CDT, c) > > > ====================================== > > > How about the name of the native library? > > > Proposal: libicmdbluez.so > > > > > I will commit a project icommand-bluez under icommand-projects > > Peter Joosten. > > > > > > ------------------------------------------------------------------------- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 _______________________________________________ Nxtcommand-developers mailing list Nxt...@li... https://lists.sourceforge.net/lists/listinfo/nxtcommand-developers ============================================================ Cheung, |
|
From: Peter J. <ptg...@ch...> - 2006-11-08 17:26:31
|
This message was intended for the list > -----Original Message----- > From: Peter Joosten [mailto:ptg...@ch...] > Sent: Wednesday, November 08, 2006 6:24 PM > To: Brian Bagnall > Subject: RE: [Nxtcommand-developers] icommand.nxtcomm.bluez > > > > > > So rather than a package for each, we could just make an > interface called > > NXTComm with the relevant read and write methods, then have > BluezNXTComm, > > RXTXNXTComm, etc... The code could default to the best/most > > common one but > > if the variable exists then use the appropriate object. > > I will take care of it. > > > A user named Rojit from the leJOS mailing list says he got more > > than one NXT > > brick working with iCommand but then I changed it to singleton > > static method > > calls to match leJOS (i.e. Motor.A.forward() instead of > > nxt.motorA.forward() ). Not many people have multiple NXT bricks > > but if it's > > possible to control more than one through Bluetooth we should > > implement it > > I will see if I can come up with a proposal. > I will also look at the usage of static, access modifiers, ... > The existing code can use some cleaning up. > > > and close() althogether. People seem to favor the commands that > > match leJOS > > though. I'm not really sure what to do. > > Stick to the Lejos API as much as possible. > > > > icommand-bluez-native (eclipse CDT, c) > > > ====================================== > > > How about the name of the native library? > > > Proposal: libicmdbluez.so > > > > > I will commit a project icommand-bluez under icommand-projects > > Peter Joosten. > > > > > > |
|
From: Vic W. <gv...@sa...> - 2006-11-08 16:57:03
|
Brian: I don't think that I want anything done to NetBeans. AllI want is to be able to launch programs that use iCommand via NetBeans. Since NetBeans uses a different environment than the shell, I think it just a matter of knowing how to set up the environment variables for NetBeans to properly handle iCommand. I am able to write and run programs using iCommand from my Mac Pro from bash, but cannot run the same program from bash on my MacBook or iMac (all Intel Macs)...nor can I run the same program from NetBeans in any computer. Vic Wintriss vi...@wi... |
|
From: Brian B. <bba...@mt...> - 2006-11-08 16:22:37
|
Hi Mr. Wintriss, One of our developers Stefano Sanna is interested in adding Netbean functionality to iCommand. Can you please give us some more details about what you want done with Netbeans? BTW: Please reply to nxt...@li... so all the developers are in the loop. - Brian |
|
From: Brian B. <bba...@mt...> - 2006-11-08 04:54:10
|
Hi Peter, > Proposal: > > I like to setup an area in subversion icommand-sandbox at the same level > as > icommand-projects. icommand-sandbox is a playing ground for things that > may > be integrated > in a future release. icommand-projects is for development, working on a > new > release. You don't have to be timid about making changes to the iCommand code. If you have something that is working just throw it in subversion. Consider your own PC as the sandbox to play around with code, and then commit changes to subversion when they are working or somewhat working. > There will be 2 projects in the sandbox: > icommand-bluez (eclipse, java) > ============================== > - java sources in package icommand.nxtcomm.bluez > - class icommand.nxtcomm.bluez.NXTCOMM > this is an alternative to icommand.nxtcomm.NXTCOMM > so an end user, switching from RXTX to BlueZ (and back) only has to > change > 1 import statement in his code. I had an email from someone who changed the code to use the Java comm API so he could run it on his handheld with Windows Mobile. That got me thinking that we should add another optional variable to the property file to choose which serial package you want to use. We could have RXTX, Java Communications API, Bluez, and even possibly the Lego Fantom driver. This would let us test and compare to see which works best. So rather than a package for each, we could just make an interface called NXTComm with the relevant read and write methods, then have BluezNXTComm, RXTXNXTComm, etc... The code could default to the best/most common one but if the variable exists then use the appropriate object. > There is 1 issue however. The NXTCOMM.open() is run from a static > initalizer block > in the NXTCommand class. This makes it "impossible" to not use RXTX. My > proposal is > to remove the static initalizer block, and make NXTCOMM.open() part of > the api. > This means end users have to explicitly use NXTCOMM.open(). They already > have to use > NXTCOMM.close(), introducing NXTCOMM.open() will only lead to a more > logically > program structure (my personal opinion). Note: for the time being ALL > changes > will only be happening in icommand-sandbox, also this api change. open() and close(0 sound good. It would also let the programmer control when they want that 5 second handshaking delay to occur. A user named Rojit from the leJOS mailing list says he got more than one NXT brick working with iCommand but then I changed it to singleton static method calls to match leJOS (i.e. Motor.A.forward() instead of nxt.motorA.forward() ). Not many people have multiple NXT bricks but if it's possible to control more than one through Bluetooth we should implement it somehow. If we do use multiple instantiations, we could do away with open() and close() althogether. People seem to favor the commands that match leJOS though. I'm not really sure what to do. > icommand-bluez-native (eclipse CDT, c) > ====================================== > How about the name of the native library? > Proposal: libicmdbluez.so > > If some C programmer will have a look at my C code, that I would really > appreciate. > Memory leaks, programming standards, ... > I have never done some serious C/C++ programming (before) > Brian, maybe someone of the lejos project can have a look? You could ask Lawrie Griffiths if no one on this project can do it. He's pretty busy with leJOS NXT though. > Now some other topic. For some time I want to setup a project making an > explorer like > NXT robot communicating with its base. That's how I run into ICommand and > got involved. > I like to setup a website to document the project and distribute the > software (Open Source). > The only common denominator (?) with icommand will be this java bluez > interface. > (I hope my english is correct). > > I like to make the java bluez interface a part of lejos, but also want to > distribute it > as part of a software product from my website. I do not hope that > contributing the code > to icommand, implies loosing my rights to do so. Any comments ? What if my > C > code is > significantly improved by some other Icommand developer? iCommand is under the GNU GPL so anyone can take the open source code, modify it and redistribute it. I think the major limitation is that you aren't allowed to sell it or something like that, and it has to remain open source so everyone can see the code. I'm not an expert on GPL but that's what I got out of it. - Brian |
|
From: Peter J. <ptg...@ch...> - 2006-11-07 18:37:55
|
Hi all, I have been working lately on a java jni binding to BlueZ, the Linux bluetooth stack. Reason for this experiment, has been my experience with RXTX: when I run into an error situation its hard to get out of that situation and setup a new connection. The jni binding has been tested with some sample Java programs running the DIRECT commands 0x00 until including 0x04. It's remarkably stable. You may start a Java program, notice your brick is not turned on, correct the situation, and as long as there is no timeout, your program starts after making a connection. This once happened accidentally, and has been tested more times for the fun of it :-) I also didn't have any trouble so far setting up a new connection after abortion willingly or not of a program. Ok, so far the selling the story. Proposal: I like to setup an area in subversion icommand-sandbox at the same level as icommand-projects. icommand-sandbox is a playing ground for things that may be integrated in a future release. icommand-projects is for development, working on a new release. There will be 2 projects in the sandbox: icommand-bluez (eclipse, java) ============================== - java sources in package icommand.nxtcomm.bluez - class icommand.nxtcomm.bluez.NXTCOMM this is an alternative to icommand.nxtcomm.NXTCOMM so an end user, switching from RXTX to BlueZ (and back) only has to change 1 import statement in his code. There is 1 issue however. The NXTCOMM.open() is run from a static initalizer block in the NXTCommand class. This makes it "impossible" to not use RXTX. My proposal is to remove the static initalizer block, and make NXTCOMM.open() part of the api. This means end users have to explicitly use NXTCOMM.open(). They already have to use NXTCOMM.close(), introducing NXTCOMM.open() will only lead to a more logically program structure (my personal opinion). Note: for the time being ALL changes will only be happening in icommand-sandbox, also this api change. icommand-bluez-native (eclipse CDT, c) ====================================== How about the name of the native library? Proposal: libicmdbluez.so If some C programmer will have a look at my C code, that I would really appreciate. Memory leaks, programming standards, ... I have never done some serious C/C++ programming (before) Brian, maybe someone of the lejos project can have a look? Please let me know what you think about it. Shall I commit things to icommand-sandbox, when I am ready, then you all can have a look. I do not know if icommand-sandbox and icommand-projects will have separate revision numbers. There is 1 way to find out. Is this an issue ? (What's the alternative) === Now some other topic. For some time I want to setup a project making an explorer like NXT robot communicating with its base. That's how I run into ICommand and got involved. I like to setup a website to document the project and distribute the software (Open Source). The only common denominator (?) with icommand will be this java bluez interface. (I hope my english is correct). I like to make the java bluez interface a part of lejos, but also want to distribute it as part of a software product from my website. I do not hope that contributing the code to icommand, implies loosing my rights to do so. Any comments ? What if my C code is significantly improved by some other Icommand developer? I am always willing to give credit to who it belongs. Now I know, why I never did have any aspirations to become a layer. I want to be honest, so telling this beforehand, seems the rigth thing to do. Peter Joosten. |
