Hello All, On 10/17/2014 02:05 PM, Bill Somerville wrote: > On 17/10/2014 20:25, Joe Taylor wrote: >> Hi all, > Hi Joe, >> Bill responded to a recent query on wsjtgroup about the use of compound >> callsigns. >> >> As we all know, these are bit of a nuisance in JT65, JT9, and JT4, in >> part because of the need to maintain backward compatibility with the >> original JT65 protocol specification, defined more than ten years ago. >> >> The original question posed by KE4PT was this: >> >>> Suppose I am operating as ZL/KE4PT. >>> Suppose I hear: CQ N8PR EL96 calling and SNR = -20 >>> >>> I wish to "generate message", and expect to find the generated message: >>> N8PR ZL/KE4PT >>> in the "Grid" button, or the "TX2" message, but instead WSJT-X 1.4 >>> generates: >>> N8PR KE4PT -20 >>> thus N8PR never knows that ZL/KE4PT answered his CQ. >> Of course, a savvy user would edit the automatically generated message >> so that "N8PR ZL/KE4PT" is sent. That's a legal message, because "ZL" >> is one of the 339 "standard" prefixes defined in pfx.f90. They are >> legitimate for the compound-callsign messages we call "Type 1" in the >> WSJT-X User Guide. > Oops, so my answer was partially incorrect and I should have suggested > that as another alternative. > > Also that particular example response you give is valid as a free text > message. >> However, suppose the authorities in ZL required him to sign his call as >> ZL3/KE4PT. ZL3 is not in the list of standard prefixes, so he must use >> Type 2 messages. The automatic message-generating facility in WSJT-X >> assumes that Type 2 messages will be used. >> >> In fact we could do slightly better for users. The program could >> generate Type 1 messages when possible, and Type 2 otherwise. I would >> see about making such a change... but it occurs to me that now might be >> the right time to do something that we have been putting off. >> >> For consistency it would be better, by far, to put all the pack/unpack >> routines (and a few support routines) in a separate library of their >> own. That library should be used by our Qt-based programs (WSJT-X and >> MAP65) and also by the Python-based WSJT -- in short, by any program >> that uses the 72-bit compressed messages pioneered by JT65. >> >> I would be happy to hear opinions from others about how best to organize >> the code for such a separate library. I suppose it should be something >> like making a new SVN branch, say "packmsg", for the pack/unpack source >> code, and having the relevant build scripts go there to build the >> library. Does this sound right? > Factoring out common code has been on my list for a while. I was > planning to do some investigation after the 1.4 release and after I > check in my current work on merging wsjtx and jt9. The later involves > among other things giving the Fortran decoding code a C/C++ interface > and it occurs to me that a Python interface might be valuable too, given > the amount of Python code used in some of the WSJT projects. So common > library implementation is closely related to merging wsjtx and jt9 as well. > > I would like to see any common libraries built with CMake, this is > because CMake has powerful tools for exporting library code for use in > other CMake built projects. This doesn't make them any less useful for > non-CMake projects. Unless you plan on coveting WSJT and / or WSPR over to Cmake, I wouldn’t' want to deal with this at all, WSPR may not factor in, but still. The builds for those two packages are already hybrids, adding a third layer would compound things further. I'm sure there is a long list of reasons why X is better that Y, but, seems to me, there are plenty of fish to fry, so no urgent need to go throw a line in the water :-)
I would think, fixing MAP65 and WSPR-X, the other two CMake projects, would be higher in priority rather than adding complexity to the non-Cmake projects, maybe they need to move in parallel, I don't know. I certainly see the benefits of having a common library set, but if that's to be done, do them all, not just one or two for a particular need. Clearly a roadmap of some kind could be beneficial here, maybe include long term integration plans for all the apps, if that is on the cards. A few months back, 6+ or so, I tried to do some commonality checks between the different .F90 / .f90 files. I found allot of delta's, but I had no way of knowing which file was truth, so, kinda of gave up on that adventure. I think this would be benifical for sure, but do them all, and publish the libs. > For me the biggest issue after learning about internals of all the > clients using any proposed common libraries is the repository layout. I > am currently working on a git-svn configuration that can successfully > map a conventional trunk/branches/tags layout onto our off kilter "trunk > in branches" layout with some success but it is horribly complex and I'm > not yet sure it works. This is important to me because I would not give > up the huge advantages of using git-svn over raw svn. I suspect no one > else is using git-svn so I may be out on a limb here :( I have philosophical issues with Git, it's origin, and current implementation, so I don't use it full stop. I suppose that's not 100% true, I do preform check-out's, pull's or whatever the terms are called, but only when I have no other choice. Sorta like going to the petrol station, if all they sell is 85 octane, not much choice, but if there is a choice, run the other direction. -- Joe, K1JT > 73 > Bill > G4WJS. > > ------------------------------------------------------------------------------ > Comprehensive Server Monitoring with Site24x7. > Monitor 10 servers for $9/Month. > Get alerted through email, SMS, voice calls or mobile push notifications. > Take corrective actions from your mobile device. > http://p.sf.net/sfu/Zoho > _______________________________________________ > wsjt-devel mailing list > wsjt-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/wsjt-devel ------------------------------------------------------------------------------ Comprehensive Server Monitoring with Site24x7. Monitor 10 servers for $9/Month. Get alerted through email, SMS, voice calls or mobile push notifications. Take corrective actions from your mobile device. http://p.sf.net/sfu/Zoho _______________________________________________ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel