Hi, Sorry for the delay, I didn't see this mail. (and nobody else answered either -_-')
On Fri, Apr 18, 2008 at 10:32:01PM +0300, Alexander Shulgin wrote: > Hi Savannah Hackers, > > I need some advice on this project submission: > http://savannah.gnu.org/task/?7917 > > On Fri, Apr 18, 2008 at 3:49 AM, Otavio <[EMAIL PROTECTED]> wrote: > > > > Follow-up Comment #7, task #7917 (project administration): > > > [snip] > > > > No, I have not tried to run it on Linux. > > > > The program just send a sequence of commands to the controller, which, in > > turn, sends other commands to the transceiver. The syntax is determined by > > the > > rigs. The primary handshake (i.e., between PC and PTC) will depend both on > > the > > OS and the Basic interpreter (or compiler). In principle, only the > > following > > data transfer format is important: 8 data bits, 1 stop bit, no parity and > > half > > duplex. The later I did not define and the program run, so I did not paid > > attention on it. Of course, the baud rate is also important, but PTC has an > > option to detect baud rate automatically. > > > > I fear there is no universal way to solve the handshake problem. I used > > another interpreter years ago and the syntax was similar, but not equal. > > The program in question uses code like open("COM3") to communicate > with the transceiver via COM port. In my experience this is > DOS/Windows who makes such special file names be mapped onto serial > ports, and to achieve similar effect in Unix-like systems we need > something like open("/dev/ttySn"). > > That said, I'm aware that the world of free operating systems is not > limited to GNU/Linux and BSDs, and the code might be found happily > running w/o modifications on, for example, FreeDOS... Moreover, > actual name of device file to use is not likely to be hardcoded in a > real program and users can specify 'COMn' on Windows and '/dev/ttySn' > on Unix-likes. If it runs on FreeDOS without requiring proprietary drivers and such, then it runs with 100% free software and it can be accepted at Savannah. Same goes for *BSD (and possibly ReactOS, though I don't know how clean their licensing is). > Also, in GPL there is a disclaimer of warranties and in the current > state the program runs on my box, but just doesn't do what it's > supposed to do. And that depends on how do you look at this: the > program provides 'more features' (it actually works) on Windows while > it runs, but it doesn't work (less features) on GNU/Linux. ;-) If a program runs with more features on MS Woe then that's a problem; it entices people to use proprietary software and we won't accept it at Savannah. > I believe there's no real obstacle to approve the project now, but > still I feel we need to persuade author to 'improve users experience' > on GNU/Linux. > > Your comments? I'd say the author has to test his software under a free OS (GNU/Linux, FreeDOS, etc.) and tell us how it goes. He also has to agree to continue doing so when maintaining the project. It's similar to what we ask when people use Java (~ "Did you test it with a Free Java Suite, and do you agree to make sure it continues working that way in the future?"). -- Sylvain
