On 18/10/2014 00:38, Joe Taylor wrote: > Hi Bill and all, > >>>>> 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. >>> One might think so; but in fact it won't be encoded and sent as one. Nor >>> would the message "N8PR XL/KE4PT", which also has 13 characters. Try it >>> with jt65code or jt9code to see what happens. >> Hmm, serves me right for not testing it first. >> >> So why doesn't it default to encoding as a free text message as a last >> resort? > In principle it could, in the special case of short-enough callsigns. > However, backward compatibility might again be an issue. Statistics > from PSKreporter suggest that some 4000 copies of JT65-HF and WSJT-X are > currently in use. Of these, well over 85% are older than WSJT-X v1.4. > It should be obvious that it would not be a good idea to change > something in our encoding/decoding that would make some messages come > out "wrong" for users of older software versions. > > The User Guide explicitly warns against sending a free-text message that > includes the character "/": > > " In general you should avoid the character / in free-text nessages, as > the program may then try to interpret your construction as part of a > compound callsign." > > We could provide users with real-time feedback if they try to send a > message that is recognizably problematic. > > ... and there are other valid reasons for the way it has been done. OK, I think I understand. I assumed that such a change would be an encode only change having no decoding implications and as such would be backwards compatible. > > > On git: I basically understand the reasons why a distributed revision > control system can be a very useful model. I just decided that at > present, my time is better spent on other things than climbing the git > learning curve. Indeed, and git-svn is a tool for git users who have to use Subversion but want to keep as many benefits of git as possible. It is a credit to git that it can be coerced to do that while talking to a Subversion repository and a credit to Subversion that the git team think git-svn is worthy of being part of the main git distribution.
One of the problems of Subversion as I see it are their efforts to keep up with modern SCM tools has largely failed because the underlying model was never designed to do it. Things like merge tracking and branch switching for example show these traits. > > I may not be so good at walking and chewing gum at the same time. A lot of this stuff comes down to how often you use the tools. A software developer spends so much time using them every day that the complexities have little significance against the work flow advantages. OTOH someone who writes software as a secondary requirement to support some other activity can find the learning curves unacceptably steep. > > -- Joe > 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
