Menu
▾
▴
wsjt-devel
|
From: Bill S. <g4...@cl...> - 2015-04-27 15:50:04
|
Hi All,
that time has arrived again where a general availability (GA) release is
imminent in the form of v1.5.0. I know there has been discussion on how
to handle versions within the documentation but I doubt any real
progress will be made on that front unless we have a way of building the
documentation on every platform including Windows as part of the product
build. That aside, releases do have a local copy of the user guide so
versioning is implicit therefore I don't think there is an urgent need
to sort out documentation builds.
Here are some suggested user guide updates for v1.5.0:
Throughout: references to v1.4.0 need to be updated to v1.5.0,
-----------------------------------------------------------------------------------
3.2 Linux: the Linux prerequisite dependencies have changed,
on Debian based systems:
sudo apt-get install libqt5multimedia5-plugins libqt5serialport5
if on Ubuntu 15.04 or similar systems shipping with Qt v5.4, the Qt
dependencies are slightly different:
sudo apt-get install libfftw3-single3 libqt5opengl5
libqt5multimedia5-plugins libqt5serialport5
on RPM based systems:
sudo rpm install fftw-libs-single qt5-qtmultimedia qt5-qtserialport
We should also add a "build from the release source tarball" section for
other *nix systems:
required tools: autotools, cmake, gcc, g++ (opptionally clang &
clang++), gfortran, libfftw3-dev, qt5 development (v5.2.1 or newer).
mkdir ~/src
cd ~/src
tar xzf wsjtx-1.5.0.tgz
cd wsjtx-1.5.0
mkdir build
cd build
cmake ..
cmake --build .
sudo cmake --build . --target install
For all Linux installation methods we need to add a section on obtaining
and running the KVASD installer.
-----------------------------------------------------------------------------------
4.1 Settings - General: new fields:
"Message generation for type 2 compound callsign holders" we probably
only need to say this option is only relevant to type 2 compound
callsign holders,
"Monitor returns to last used frequency" hopefully self explanatory,
option is greyed out if no CAT control is selected.
-----------------------------------------------------------------------------------
4.2 Settings - Radio: new behaviour:
The screen shot probably needs updating as with "None" as rig most
fields are now greyed out,
"Force Control Lines" - this whole group is now checkable, this
allows DTR and RTS to be forced either high or low.
-----------------------------------------------------------------------------------
4.5 Reporting: new fields:
UDP server group controls the name or address and port number of a
UDP server that will receive status updates from WSJT-X. Although no
implementations are yet available, it is expected that cooperating
applications like JTAlertX will take advantage of this to get maximum
information about a running WSJT-X application.
-----------------------------------------------------------------------------------
4.7 Colors: new page.
-----------------------------------------------------------------------------------
6.4 Sample File 2 example: minor changes related to parallel decoding,
"Since the Tx mode was set to *Tx JT65*, signals in that mode were
decoded first. If you had selected *Tx JT9*, JT9 signals would have been
decoded first." is not quite correct on a multi core CPU. Perhaps the
decoded activity screen shot should be with interleaved modes.
-----------------------------------------------------------------------------------
7.3 Type 2 Compound-Callsign Messages: behaviour changes,
This is probably the place to mention that the "Settings->General"
option to change the format of generated messages for type 2 compound
call holders. Also WSJT-X v1.5.0 makes a better attempt to process QSO
with or by a type 2 compound callsign holder by using double-clicks of
decodes. The warning about actually taking notice of the message
content is of course still appropriate.
-----------------------------------------------------------------------------------
7.4 Pre-QSO Checklist: advice,
It is best to not suggest the rig be set to split mode manually, if
WSJT-X can't set split for itself then split mode working is unlikely to
work.
-----------------------------------------------------------------------------------
8.2 Main Window: additional information,
Monitor - if using CAT control; clicking "Monitor" off relinquishes
control of the rig and if "Monitor returns to last used frequency" in
"Settings->General" is selected; clicking "Monitor" back on will return
to the original frequency.
-----------------------------------------------------------------------------------
8.7.1 File Menus: new item,
Now has "Open log directory".
-----------------------------------------------------------------------------------
8.7.7 Help Menu: changes:
Needs a new screen shot of the "Keyboard Shortcuts" window.
-----------------------------------------------------------------------------------
9 ShowDXCC entity and worked before status: query and changes:
I'm not sure why this section is in the "Platform Dependencies"
section as it works everywhere.
The "Settings->Colors" page needs a mention here.
73
Bill
G4WJS.
|
|
From: Joe T. <jo...@pr...> - 2015-04-27 18:26:17
|
Hi Bill, Thanks for the detailed list of needed updates to the User Guide for Version 1.5. I hope to find time to do this, in the next day or so. Will let you know when it's done. -- Joe On 4/27/2015 11:49 AM, Bill Somerville wrote: > Hi All, > > that time has arrived again where a general availability (GA) release is > imminent in the form of v1.5.0. I know there has been discussion on how > to handle versions within the documentation but I doubt any real > progress will be made on that front unless we have a way of building the > documentation on every platform including Windows as part of the product > build. That aside, releases do have a local copy of the user guide so > versioning is implicit therefore I don't think there is an urgent need > to sort out documentation builds. > > Here are some suggested user guide updates for v1.5.0: > > Throughout: references to v1.4.0 need to be updated to v1.5.0, > ----------------------------------------------------------------------------------- > > 3.2 Linux: the Linux prerequisite dependencies have changed, > on Debian based systems: > sudo apt-get install libqt5multimedia5-plugins libqt5serialport5 > > if on Ubuntu 15.04 or similar systems shipping with Qt v5.4, the Qt > dependencies are slightly different: > sudo apt-get install libfftw3-single3 libqt5opengl5 > libqt5multimedia5-plugins libqt5serialport5 > > on RPM based systems: > sudo rpm install fftw-libs-single qt5-qtmultimedia qt5-qtserialport > > We should also add a "build from the release source tarball" section for > other *nix systems: > > required tools: autotools, cmake, gcc, g++ (opptionally clang & > clang++), gfortran, libfftw3-dev, qt5 development (v5.2.1 or newer). > > mkdir ~/src > cd ~/src > tar xzf wsjtx-1.5.0.tgz > cd wsjtx-1.5.0 > mkdir build > cd build > cmake .. > cmake --build . > sudo cmake --build . --target install > > For all Linux installation methods we need to add a section on obtaining > and running the KVASD installer. > ----------------------------------------------------------------------------------- > > 4.1 Settings - General: new fields: > "Message generation for type 2 compound callsign holders" we probably > only need to say this option is only relevant to type 2 compound > callsign holders, > > "Monitor returns to last used frequency" hopefully self explanatory, > option is greyed out if no CAT control is selected. > ----------------------------------------------------------------------------------- > > 4.2 Settings - Radio: new behaviour: > The screen shot probably needs updating as with "None" as rig most > fields are now greyed out, > > "Force Control Lines" - this whole group is now checkable, this allows > DTR and RTS to be forced either high or low. > ----------------------------------------------------------------------------------- > > 4.5 Reporting: new fields: > UDP server group controls the name or address and port number of a UDP > server that will receive status updates from WSJT-X. Although no > implementations are yet available, it is expected that cooperating > applications like JTAlertX will take advantage of this to get maximum > information about a running WSJT-X application. > ----------------------------------------------------------------------------------- > > 4.7 Colors: new page. > ----------------------------------------------------------------------------------- > > 6.4 Sample File 2 example: minor changes related to parallel decoding, > "Since the Tx mode was set to *Tx JT65*, signals in that mode were > decoded first. If you had selected *Tx JT9*, JT9 signals would have been > decoded first." is not quite correct on a multi core CPU. Perhaps the > decoded activity screen shot should be with interleaved modes. > ----------------------------------------------------------------------------------- > > 7.3 Type 2 Compound-Callsign Messages: behaviour changes, > This is probably the place to mention that the "Settings->General" > option to change the format of generated messages for type 2 compound > call holders. Also WSJT-X v1.5.0 makes a better attempt to process QSO > with or by a type 2 compound callsign holder by using double-clicks of > decodes. The warning about actually taking notice of the message content > is of course still appropriate. > ----------------------------------------------------------------------------------- > > 7.4 Pre-QSO Checklist: advice, > It is best to not suggest the rig be set to split mode manually, if > WSJT-X can't set split for itself then split mode working is unlikely to > work. > ----------------------------------------------------------------------------------- > > 8.2 Main Window: additional information, > Monitor - if using CAT control; clicking "Monitor" off relinquishes > control of the rig and if "Monitor returns to last used frequency" in > "Settings->General" is selected; clicking "Monitor" back on will return > to the original frequency. > ----------------------------------------------------------------------------------- > > 8.7.1 File Menus: new item, > Now has "Open log directory". > ----------------------------------------------------------------------------------- > > 8.7.7 Help Menu: changes: > Needs a new screen shot of the "Keyboard Shortcuts" window. > ----------------------------------------------------------------------------------- > > 9 ShowDXCC entity and worked before status: query and changes: > I'm not sure why this section is in the "Platform Dependencies" section > as it works everywhere. > > The "Settings->Colors" page needs a mention here. > > 73 > Bill > G4WJS. > > > > ------------------------------------------------------------------------------ > One dashboard for servers and applications across Physical-Virtual-Cloud > Widest out-of-the-box monitoring support with 50+ applications > Performance metrics, stats and reports that give you Actionable Insights > Deep dive visibility with transaction tracing using APM Insight. > http://ad.doubleclick.net/ddm/clk/290420510;117567292;y > > > > _______________________________________________ > wsjt-devel mailing list > wsj...@li... > https://lists.sourceforge.net/lists/listinfo/wsjt-devel |
|
From: Bill S. <g4...@cl...> - 2015-04-27 18:29:23
|
On 27/04/2015 19:26, Joe Taylor wrote: > Hi Bill, Hi Joe, > > Thanks for the detailed list of needed updates to the User Guide for > Version 1.5. I hope to find time to do this, in the next day or so. > Will let you know when it's done. Thanks for that. I don't think there is a big rush to get v1.5.0 RC2 out of the door since the issues reported so far have reasonable workarounds. > > -- Joe 73 Bill G4WJS. > > On 4/27/2015 11:49 AM, Bill Somerville wrote: >> Hi All, >> >> that time has arrived again where a general availability (GA) release is >> imminent in the form of v1.5.0. I know there has been discussion on how >> to handle versions within the documentation but I doubt any real >> progress will be made on that front unless we have a way of building the >> documentation on every platform including Windows as part of the product >> build. That aside, releases do have a local copy of the user guide so >> versioning is implicit therefore I don't think there is an urgent need >> to sort out documentation builds. >> >> Here are some suggested user guide updates for v1.5.0: >> >> Throughout: references to v1.4.0 need to be updated to v1.5.0, >> ----------------------------------------------------------------------------------- >> >> 3.2 Linux: the Linux prerequisite dependencies have changed, >> on Debian based systems: >> sudo apt-get install libqt5multimedia5-plugins libqt5serialport5 >> >> if on Ubuntu 15.04 or similar systems shipping with Qt v5.4, the Qt >> dependencies are slightly different: >> sudo apt-get install libfftw3-single3 libqt5opengl5 >> libqt5multimedia5-plugins libqt5serialport5 >> >> on RPM based systems: >> sudo rpm install fftw-libs-single qt5-qtmultimedia qt5-qtserialport >> >> We should also add a "build from the release source tarball" section for >> other *nix systems: >> >> required tools: autotools, cmake, gcc, g++ (opptionally clang & >> clang++), gfortran, libfftw3-dev, qt5 development (v5.2.1 or newer). >> >> mkdir ~/src >> cd ~/src >> tar xzf wsjtx-1.5.0.tgz >> cd wsjtx-1.5.0 >> mkdir build >> cd build >> cmake .. >> cmake --build . >> sudo cmake --build . --target install >> >> For all Linux installation methods we need to add a section on obtaining >> and running the KVASD installer. >> ----------------------------------------------------------------------------------- >> >> 4.1 Settings - General: new fields: >> "Message generation for type 2 compound callsign holders" we probably >> only need to say this option is only relevant to type 2 compound >> callsign holders, >> >> "Monitor returns to last used frequency" hopefully self explanatory, >> option is greyed out if no CAT control is selected. >> ----------------------------------------------------------------------------------- >> >> 4.2 Settings - Radio: new behaviour: >> The screen shot probably needs updating as with "None" as rig most >> fields are now greyed out, >> >> "Force Control Lines" - this whole group is now checkable, this allows >> DTR and RTS to be forced either high or low. >> ----------------------------------------------------------------------------------- >> >> 4.5 Reporting: new fields: >> UDP server group controls the name or address and port number of a UDP >> server that will receive status updates from WSJT-X. Although no >> implementations are yet available, it is expected that cooperating >> applications like JTAlertX will take advantage of this to get maximum >> information about a running WSJT-X application. >> ----------------------------------------------------------------------------------- >> >> 4.7 Colors: new page. >> ----------------------------------------------------------------------------------- >> >> 6.4 Sample File 2 example: minor changes related to parallel decoding, >> "Since the Tx mode was set to *Tx JT65*, signals in that mode were >> decoded first. If you had selected *Tx JT9*, JT9 signals would have been >> decoded first." is not quite correct on a multi core CPU. Perhaps the >> decoded activity screen shot should be with interleaved modes. >> ----------------------------------------------------------------------------------- >> >> 7.3 Type 2 Compound-Callsign Messages: behaviour changes, >> This is probably the place to mention that the "Settings->General" >> option to change the format of generated messages for type 2 compound >> call holders. Also WSJT-X v1.5.0 makes a better attempt to process QSO >> with or by a type 2 compound callsign holder by using double-clicks of >> decodes. The warning about actually taking notice of the message content >> is of course still appropriate. >> ----------------------------------------------------------------------------------- >> >> 7.4 Pre-QSO Checklist: advice, >> It is best to not suggest the rig be set to split mode manually, if >> WSJT-X can't set split for itself then split mode working is unlikely to >> work. >> ----------------------------------------------------------------------------------- >> >> 8.2 Main Window: additional information, >> Monitor - if using CAT control; clicking "Monitor" off relinquishes >> control of the rig and if "Monitor returns to last used frequency" in >> "Settings->General" is selected; clicking "Monitor" back on will return >> to the original frequency. >> ----------------------------------------------------------------------------------- >> >> 8.7.1 File Menus: new item, >> Now has "Open log directory". >> ----------------------------------------------------------------------------------- >> >> 8.7.7 Help Menu: changes: >> Needs a new screen shot of the "Keyboard Shortcuts" window. >> ----------------------------------------------------------------------------------- >> >> 9 ShowDXCC entity and worked before status: query and changes: >> I'm not sure why this section is in the "Platform Dependencies" section >> as it works everywhere. >> >> The "Settings->Colors" page needs a mention here. >> >> 73 >> Bill >> G4WJS. |
|
From: Joe T. <jo...@pr...> - 2015-04-27 18:46:26
|
Hi BIll, >> Thanks for the detailed list of needed updates to the User Guide for >> Version 1.5. I hope to find time to do this, in the next day or so. >> Will let you know when it's done. > Thanks for that. I don't think there is a big rush to get v1.5.0 RC2 out > of the door since the issues reported so far have reasonable workarounds. For any cases where there's a workaround (as opposed to a true fix), should there be an entry in the User Guide's "FAQ" section? -- Joe |
|
From: Bill S. <g4...@cl...> - 2015-04-27 18:54:14
|
On 27/04/2015 19:46, Joe Taylor wrote: Hi Joe, > Hi BIll, > >>> Thanks for the detailed list of needed updates to the User Guide for >>> Version 1.5. I hope to find time to do this, in the next day or so. >>> Will let you know when it's done. >> Thanks for that. I don't think there is a big rush to get v1.5.0 RC2 out >> of the door since the issues reported so far have reasonable workarounds. > For any cases where there's a workaround (as opposed to a true fix), > should there be an entry in the User Guide's "FAQ" section? Sorry, I wasn't clear. RC2 is the proper fix for the issues in RC1 that currently have a reasonable workaround. > > -- Joe 73 Bill G4WJS. |
|
From: Alessandro G. <al...@li...> - 2015-04-27 20:15:24
|
Hi All, I see the proposed modifications on user manual. Personally I think is correct to advise users the presence of temporary files adding a few lines in 9. Platform Dependencies as : Temp files (windows) %TEMP%\WSJT-X\*.* %TEMP%\WSJT-X.lock tmp files (linux) /tmp/WSJT-X/* /tmp/WSJT-X.lock Tmp files (OSX) ?? 73's Sandro IW3RAB Il 27/04/2015 20:54, Bill Somerville ha scritto: > On 27/04/2015 19:46, Joe Taylor wrote: > > Hi Joe, >> Hi BIll, >> >>>> Thanks for the detailed list of needed updates to the User Guide for >>>> Version 1.5. I hope to find time to do this, in the next day or so. >>>> Will let you know when it's done. >>> Thanks for that. I don't think there is a big rush to get v1.5.0 RC2 out >>> of the door since the issues reported so far have reasonable workarounds. >> For any cases where there's a workaround (as opposed to a true fix), >> should there be an entry in the User Guide's "FAQ" section? > Sorry, I wasn't clear. RC2 is the proper fix for the issues in RC1 that > currently have a reasonable workaround. >> >> -- Joe > 73 > Bill > G4WJS. > > ------------------------------------------------------------------------------ > One dashboard for servers and applications across Physical-Virtual-Cloud > Widest out-of-the-box monitoring support with 50+ applications > Performance metrics, stats and reports that give you Actionable Insights > Deep dive visibility with transaction tracing using APM Insight. > http://ad.doubleclick.net/ddm/clk/290420510;117567292;y > _______________________________________________ > wsjt-devel mailing list > wsj...@li... > https://lists.sourceforge.net/lists/listinfo/wsjt-devel > |
|
From: Bill S. <g4...@cl...> - 2015-04-27 22:32:27
|
On 27/04/2015 21:14, Alessandro Gorobey wrote: > Tmp files (OSX) > ?? tmp files (OS X) $TMPDIR/WSJT-X/* $TMPDIR/WSJT-X.lock 73 Bill G4WJS. |
|
From: Alessandro G. <al...@li...> - 2015-04-27 22:39:28
|
Hi Bill, Il 28/04/2015 00:32, Bill Somerville ha scritto: > On 27/04/2015 21:14, Alessandro Gorobey wrote: >> Tmp files (OSX) >> ?? I have no OSX > > tmp files (OS X) > $TMPDIR/WSJT-X/* > $TMPDIR/WSJT-X.lock Thanks > > 73 > Bill > G4WJS. 73 Sandro IW3RAB > > > ------------------------------------------------------------------------------ > One dashboard for servers and applications across Physical-Virtual-Cloud > Widest out-of-the-box monitoring support with 50+ applications > Performance metrics, stats and reports that give you Actionable Insights > Deep dive visibility with transaction tracing using APM Insight. > http://ad.doubleclick.net/ddm/clk/290420510;117567292;y > > > > _______________________________________________ > wsjt-devel mailing list > wsj...@li... > https://lists.sourceforge.net/lists/listinfo/wsjt-devel > |
|
From: Jim B. <k9...@au...> - 2015-04-27 19:13:35
|
On Mon,4/27/2015 11:46 AM, Joe Taylor wrote: > For any cases where there's a workaround (as opposed to a true fix), > should there be an entry in the User Guide's "FAQ" section? I'm a firm believer in RTFM. I object to the use of FAQs to answer questions that would not be asked if the primary documentation had the answer in the logical place. :) 73, Jim K9YC |
|
From: KI7MT <ki...@gm...> - 2015-04-28 06:09:23
|
Hello All, I don't know about Mac, but for Windows, we can do away with JTSDK-DOC, install a Full version of Python27 + Asciidoc, and that should do it. I need to test if base64 encoding is available with a full Python27 install on Windows, but I think it is. Linux, is simple to implement. The Cmake scripts should be able to deal with this easily, it's just paths to Python2 and Asciidoc (maybe a toolchain.cmake file item? not sure). For WSPR and WSJT, we can add a small Makefile in the docs directory, building both the HTML docs and Manpages, and it's done. I'm working on this approach for JTSDK Nix now. The biggest change is the location of Icons and Images. For Data-URI builds (single file HTML) the images must be in the same directory (./icons ./images ./main-file.adoc ) as the file being built. This will no doubt cause duplication of a few files (links.adoc xyz.icon etc). With a full Python27 + AsciiDoc, Docs && Manpages can be compiled at build time, Linux and Windows. This should give you the versatility your needing. I think Mac should be OK with this approach also. If you want to go that route, I'll start working on the necessary changes. The Build commands are simple: Example Doc (for 1.5.1 or something): asciidoc -b xhtml11 -a data-uri -a toc2 -o wsjtx-1.5.0.html ./wsjtx-1.5.0.adoc Example Manpage: a2x --doctype manpage --format manpage --no-xmllint wsjtx.1.txt While this sounds like allot, it's really not allot of work to implement. 73's Greg, KI7MT On 04/27/2015 09:49 AM, Bill Somerville wrote: > Hi All, > > that time has arrived again where a general availability (GA) release is > imminent in the form of v1.5.0. I know there has been discussion on how > to handle versions within the documentation but I doubt any real > progress will be made on that front unless we have a way of building the > documentation on every platform including Windows as part of the product > build. That aside, releases do have a local copy of the user guide so > versioning is implicit therefore I don't think there is an urgent need > to sort out documentation builds. > > Here are some suggested user guide updates for v1.5.0: > > Throughout: references to v1.4.0 need to be updated to v1.5.0, > ----------------------------------------------------------------------------------- > > 3.2 Linux: the Linux prerequisite dependencies have changed, > on Debian based systems: > sudo apt-get install libqt5multimedia5-plugins libqt5serialport5 > > if on Ubuntu 15.04 or similar systems shipping with Qt v5.4, the Qt > dependencies are slightly different: > sudo apt-get install libfftw3-single3 libqt5opengl5 > libqt5multimedia5-plugins libqt5serialport5 > > on RPM based systems: > sudo rpm install fftw-libs-single qt5-qtmultimedia qt5-qtserialport > > We should also add a "build from the release source tarball" section for > other *nix systems: > > required tools: autotools, cmake, gcc, g++ (opptionally clang & > clang++), gfortran, libfftw3-dev, qt5 development (v5.2.1 or newer). > > mkdir ~/src > cd ~/src > tar xzf wsjtx-1.5.0.tgz > cd wsjtx-1.5.0 > mkdir build > cd build > cmake .. > cmake --build . > sudo cmake --build . --target install > > For all Linux installation methods we need to add a section on obtaining > and running the KVASD installer. > ----------------------------------------------------------------------------------- > > 4.1 Settings - General: new fields: > "Message generation for type 2 compound callsign holders" we probably > only need to say this option is only relevant to type 2 compound > callsign holders, > > "Monitor returns to last used frequency" hopefully self explanatory, > option is greyed out if no CAT control is selected. > ----------------------------------------------------------------------------------- > > 4.2 Settings - Radio: new behaviour: > The screen shot probably needs updating as with "None" as rig most > fields are now greyed out, > > "Force Control Lines" - this whole group is now checkable, this allows > DTR and RTS to be forced either high or low. > ----------------------------------------------------------------------------------- > > 4.5 Reporting: new fields: > UDP server group controls the name or address and port number of a UDP > server that will receive status updates from WSJT-X. Although no > implementations are yet available, it is expected that cooperating > applications like JTAlertX will take advantage of this to get maximum > information about a running WSJT-X application. > ----------------------------------------------------------------------------------- > > 4.7 Colors: new page. > ----------------------------------------------------------------------------------- > > 6.4 Sample File 2 example: minor changes related to parallel decoding, > "Since the Tx mode was set to *Tx JT65*, signals in that mode were > decoded first. If you had selected *Tx JT9*, JT9 signals would have been > decoded first." is not quite correct on a multi core CPU. Perhaps the > decoded activity screen shot should be with interleaved modes. > ----------------------------------------------------------------------------------- > > 7.3 Type 2 Compound-Callsign Messages: behaviour changes, > This is probably the place to mention that the "Settings->General" > option to change the format of generated messages for type 2 compound > call holders. Also WSJT-X v1.5.0 makes a better attempt to process QSO > with or by a type 2 compound callsign holder by using double-clicks of > decodes. The warning about actually taking notice of the message > content is of course still appropriate. > ----------------------------------------------------------------------------------- > > 7.4 Pre-QSO Checklist: advice, > It is best to not suggest the rig be set to split mode manually, if > WSJT-X can't set split for itself then split mode working is unlikely to > work. > ----------------------------------------------------------------------------------- > > 8.2 Main Window: additional information, > Monitor - if using CAT control; clicking "Monitor" off relinquishes > control of the rig and if "Monitor returns to last used frequency" in > "Settings->General" is selected; clicking "Monitor" back on will return > to the original frequency. > ----------------------------------------------------------------------------------- > > 8.7.1 File Menus: new item, > Now has "Open log directory". > ----------------------------------------------------------------------------------- > > 8.7.7 Help Menu: changes: > Needs a new screen shot of the "Keyboard Shortcuts" window. > ----------------------------------------------------------------------------------- > > 9 ShowDXCC entity and worked before status: query and changes: > I'm not sure why this section is in the "Platform Dependencies" > section as it works everywhere. > > The "Settings->Colors" page needs a mention here. > > 73 > Bill > G4WJS. > > > > ------------------------------------------------------------------------------ > One dashboard for servers and applications across Physical-Virtual-Cloud > Widest out-of-the-box monitoring support with 50+ applications > Performance metrics, stats and reports that give you Actionable Insights > Deep dive visibility with transaction tracing using APM Insight. > http://ad.doubleclick.net/ddm/clk/290420510;117567292;y > > > > _______________________________________________ > wsjt-devel mailing list > wsj...@li... > https://lists.sourceforge.net/lists/listinfo/wsjt-devel > -- ---------------------------------------------------------------- Launchpad....: https://launchpad.net/~ki7mt Ubuntu Hams..: https://launchpad.net/~ubuntu-hams-devel Debian Hams..: https://alioth.debian.org/projects/pkg-hamradio/ JTSDK........: https://sourceforge.net/projects/jtsdk/ OpenPGP......: C177 6630 7115 78FE 9A2B 9F7F 18C0 F6B7 0DA2 F991 |
|
From: Bill S. <g4...@cl...> - 2015-04-28 18:55:42
|
On 28/04/2015 07:09, KI7MT wrote:
> Hello All,
Hi Greg & All,
>
> I don't know about Mac, but for Windows, we can do away with JTSDK-DOC,
> install a Full version of Python27 + Asciidoc, and that should do it. I
> need to test if base64 encoding is available with a full Python27
> install on Windows, but I think it is. Linux, is simple to implement.
OK I have tweaked the CMake build script to build the user guide. I
found that asciidoc 8.6.9 (the latest release) is broken on Windows but
using the latest development source from github was OK. You can get it from:
https://github.com/asciidoc/asciidoc/archive/master.zip
Unzip this somewhere (I used c:\Tools) and add the new asciidoc-master
directory to the CMAKE_PREFIX_PATH set up in your CMake toolchain file.
Assuming you have some form of Python 2.7 or later installed such that
.py files are automatically executable, this should be all you need to
do. On Linux and Mac just install asciidoc by the normal route and all
will be fine.
>
> The Cmake scripts should be able to deal with this easily, it's just
> paths to Python2 and Asciidoc (maybe a toolchain.cmake file item? not
> sure). For WSPR and WSJT, we can add a small Makefile in the docs
> directory, building both the HTML docs and Manpages, and it's done.
I have added a new option to the WSJT-X CMakeLists.txt, set
WSJT_GENERATE_DOCS to ON (it is OFF by default) in your build area if
you want to build the user guide.
>
> I'm working on this approach for JTSDK Nix now. The biggest change is
> the location of Icons and Images. For Data-URI builds (single file HTML)
> the images must be in the same directory (./icons ./images
> ./main-file.adoc ) as the file being built. This will no doubt cause
> duplication of a few files (links.adoc xyz.icon etc).
I have copied the documentation sources across to the ^/branches/wsjtx
tree as a temporary measure for testing purposes, DO NOT EDIT THESE
FILES as hey will be deleted when the real ones are migrated with their
svn history in tact.
I renamed globals to common and rearranged the directory structure a
little as it seemed to be broken, I'm not sure how it builds in the docs
branch as the relative paths of the images seem to be wrong.
>
> With a full Python27 + AsciiDoc, Docs && Manpages can be compiled at
> build time, Linux and Windows. This should give you the versatility your
> needing. I think Mac should be OK with this approach also.
>
> If you want to go that route, I'll start working on the necessary changes.
>
> The Build commands are simple:
>
> Example Doc (for 1.5.1 or something):
> asciidoc -b xhtml11 -a data-uri -a toc2 -o wsjtx-1.5.0.html
> ./wsjtx-1.5.0.adoc
I had to add '-a max-width=1024px' to get similar output although the
final rendering is a tiny bit different when built on Windows - this may
well be due to the newer version of asciidoc.
>
> Example Manpage:
> a2x --doctype manpage --format manpage --no-xmllint wsjtx.1.txt
I not going to even attempt this on Windows as a2x isn't practical
without adding various things to the PATH which I have no desire to
force developers to do. If we want to do fancier document generation I
think doing a Docbook XML generation with asciidoc and the various post
processing steps like xmllint, xsltproc, dot and FOP can be added as
CMake custom commands rather than using the a2x driver.
>
>
> While this sounds like allot, it's really not allot of work to implement.
>
> 73's
> Greg, KI7MT
>
73
Bill
G4WJS.
|
|
From: KI7MT <ki...@gm...> - 2015-04-28 20:54:17
|
Hi Bill, On 04/28/2015 12:55 PM, Bill Somerville wrote: > On 28/04/2015 07:09, KI7MT wrote: >> Hello All, > Hi Greg & All, >> >> I don't know about Mac, but for Windows, we can do away with JTSDK-DOC, >> install a Full version of Python27 + Asciidoc, and that should do it. I >> need to test if base64 encoding is available with a full Python27 >> install on Windows, but I think it is. Linux, is simple to implement. > OK I have tweaked the CMake build script to build the user guide. I > found that asciidoc 8.6.9 (the latest release) is broken on Windows but > using the latest development source from github was OK. You can get it from: > > https://github.com/asciidoc/asciidoc/archive/master.zip > > Unzip this somewhere (I used c:\Tools) and add the new asciidoc-master > directory to the CMAKE_PREFIX_PATH set up in your CMake toolchain file. > Assuming you have some form of Python 2.7 or later installed such that > .py files are automatically executable, this should be all you need to > do. On Linux and Mac just install asciidoc by the normal route and all > will be fine. For Windows, adding Python27 is a sensitive situation with regards to WSPR and WSJT builds. I will need to do some testing. Will take fare bit of time to sort that all out. I don't know what the diff's are in packages, but the Distro versions are 8.6.9 and his Git repo is 8.6.9 .. so dunno. >> >> The Cmake scripts should be able to deal with this easily, it's just >> paths to Python2 and Asciidoc (maybe a toolchain.cmake file item? not >> sure). For WSPR and WSJT, we can add a small Makefile in the docs >> directory, building both the HTML docs and Manpages, and it's done. > I have added a new option to the WSJT-X CMakeLists.txt, set > WSJT_GENERATE_DOCS to ON (it is OFF by default) in your build area if > you want to build the user guide. Until I have a solution for keeping Py2 and Py3 separate on Windows, I'll hold off on Building Docs during compile. Linux can be added no problem. >> >> I'm working on this approach for JTSDK Nix now. The biggest change is >> the location of Icons and Images. For Data-URI builds (single file HTML) >> the images must be in the same directory (./icons ./images >> ./main-file.adoc ) as the file being built. This will no doubt cause >> duplication of a few files (links.adoc xyz.icon etc). > I have copied the documentation sources across to the ^/branches/wsjtx > tree as a temporary measure for testing purposes, DO NOT EDIT THESE > FILES as hey will be deleted when the real ones are migrated with their > svn history in tact. > > I renamed globals to common and rearranged the directory structure a > little as it seemed to be broken, I'm not sure how it builds in the docs > branch as the relative paths of the images seem to be wrong. Yes, this is a PITA, as there is a bug or something in AsciiDoc. For the build scripts I use, Data-URI, I have to copy (rsync) the image folders into the source folder before building. This same problem *is not* present when building Linked Documents. I chased this one in circles for a long time, and finally, just copied the stuff over and let it be. >> >> With a full Python27 + AsciiDoc, Docs && Manpages can be compiled at >> build time, Linux and Windows. This should give you the versatility your >> needing. I think Mac should be OK with this approach also. >> >> If you want to go that route, I'll start working on the necessary changes. >> >> The Build commands are simple: >> >> Example Doc (for 1.5.1 or something): >> asciidoc -b xhtml11 -a data-uri -a toc2 -o wsjtx-1.5.0.html >> ./wsjtx-1.5.0.adoc > I had to add '-a max-width=1024px' to get similar output although the > final rendering is a tiny bit different when built on Windows - this may > well be due to the newer version of asciidoc. Yes, I dropped that off, sorry, I use that option for JTSDK doc builds also or at least, I used to have it on the build line. >> >> Example Manpage: >> a2x --doctype manpage --format manpage --no-xmllint wsjtx.1.txt > I not going to even attempt this on Windows as a2x isn't practical > without adding various things to the PATH which I have no desire to > force developers to do. If we want to do fancier document generation I > think doing a Docbook XML generation with asciidoc and the various post > processing steps like xmllint, xsltproc, dot and FOP can be added as > CMake custom commands rather than using the a2x driver. Yup. Windows and Manpages are a zoo. DockBook is massive overkill for the simple manpages we generate. FOP has some odd dependencies on Ubuntu, I don't recall what it is now, But I just use a2x.py on Ubuntu / Linux, no problems at all. DocBook itself wants to install like 1GB worth of files, that is crazy for a manpage. >> >> >> While this sounds like allot, it's really not allot of work to implement. >> >> 73's >> Greg, KI7MT >> > 73 > Bill > G4WJS. > 73's Greg, KI7MT |
|
From: Bill S. <g4...@cl...> - 2015-04-28 21:13:00
|
On 28/04/2015 21:54, KI7MT wrote: > Hi Bill, Hi Greg, > > > On 04/28/2015 12:55 PM, Bill Somerville wrote: >> On 28/04/2015 07:09, KI7MT wrote: >>> Hello All, <snip> >> OK I have tweaked the CMake build script to build the user guide. I >> found that asciidoc 8.6.9 (the latest release) is broken on Windows but >> using the latest development source from github was OK. You can get it from: >> >> https://github.com/asciidoc/asciidoc/archive/master.zip >> >> Unzip this somewhere (I used c:\Tools) and add the new asciidoc-master >> directory to the CMAKE_PREFIX_PATH set up in your CMake toolchain file. >> Assuming you have some form of Python 2.7 or later installed such that >> .py files are automatically executable, this should be all you need to >> do. On Linux and Mac just install asciidoc by the normal route and all >> will be fine. > For Windows, adding Python27 is a sensitive situation with regards to > WSPR and WSJT builds. I will need to do some testing. Will take fare bit > of time to sort that all out. Looking at the asciidoc prequisites it says Python 2.4 and up is OK so it may not be an issue. I haven't put any Python checks in the WSJT-X CMake script, it just finds asciidoc and takes the view that if you have installed asciidoc then you really ought to have a working Python around. > > I don't know what the diff's are in packages, but the Distro versions > are 8.6.9 and his Git repo is 8.6.9 .. so dunno. That is the official git repo (a bit confusing as the home page still refers to the Google Code repositiory), fetching a snapshot of master is pre-release code. The actual issue that causes 8.6.9 not to work on Windows is: https://github.com/asciidoc/asciidoc/pull/39 See the associated ML link for details. > >>> The Cmake scripts should be able to deal with this easily, it's just >>> paths to Python2 and Asciidoc (maybe a toolchain.cmake file item? not >>> sure). For WSPR and WSJT, we can add a small Makefile in the docs >>> directory, building both the HTML docs and Manpages, and it's done. >> I have added a new option to the WSJT-X CMakeLists.txt, set >> WSJT_GENERATE_DOCS to ON (it is OFF by default) in your build area if >> you want to build the user guide. > Until I have a solution for keeping Py2 and Py3 separate on Windows, > I'll hold off on Building Docs during compile. > > Linux can be added no problem. There is no point progressing until the user guide sources can be moved across. Assuming that it builds with all Pythons since 2.4, that shouldn't be an issue. > >>> I'm working on this approach for JTSDK Nix now. The biggest change is >>> the location of Icons and Images. For Data-URI builds (single file HTML) >>> the images must be in the same directory (./icons ./images >>> ./main-file.adoc ) as the file being built. This will no doubt cause >>> duplication of a few files (links.adoc xyz.icon etc). >> I have copied the documentation sources across to the ^/branches/wsjtx >> tree as a temporary measure for testing purposes, DO NOT EDIT THESE >> FILES as hey will be deleted when the real ones are migrated with their >> svn history in tact. >> >> I renamed globals to common and rearranged the directory structure a >> little as it seemed to be broken, I'm not sure how it builds in the docs >> branch as the relative paths of the images seem to be wrong. > Yes, this is a PITA, as there is a bug or something in AsciiDoc. For the > build scripts I use, Data-URI, I have to copy (rsync) the image folders > into the source folder before building. This same problem *is not* > present when building Linked Documents. I chased this one in circles for > a long time, and finally, just copied the stuff over and let it be. I don't think it is a bug. The .adoc files reference the images as image::images/<file> so the images are expected to be in a subdirectory of the file that references them. I simply moved the .adoc files up one level and did away with the 'source' directory and all is fine. <snip> >>> Example Manpage: >>> a2x --doctype manpage --format manpage --no-xmllint wsjtx.1.txt >> I not going to even attempt this on Windows as a2x isn't practical >> without adding various things to the PATH which I have no desire to >> force developers to do. If we want to do fancier document generation I >> think doing a Docbook XML generation with asciidoc and the various post >> processing steps like xmllint, xsltproc, dot and FOP can be added as >> CMake custom commands rather than using the a2x driver. > Yup. Windows and Manpages are a zoo. DockBook is massive overkill for > the simple manpages we generate. FOP has some odd dependencies on > Ubuntu, I don't recall what it is now, But I just use a2x.py on Ubuntu / > Linux, no problems at all. DocBook itself wants to install like 1GB > worth of files, that is crazy for a manpage. I don't think Docbook is the problem, it is the back end stuff that a2x can potentially use - particularly dblatex. The issue is that a2x is a wrapper script for everything and therefore installing it requires everything. Anyway a2x is a nuisance on widows because it expects all the intermediate and back end tools to be on the PATH and provides no way to provide explicit locations for programs :( I don't think manpage generation for ascidoc generated Docbook XML is any more than a simple xslt transform. > >>> >>> While this sounds like allot, it's really not allot of work to implement. >>> >>> 73's >>> Greg, KI7MT >>> >> 73 >> Bill >> G4WJS. >> > 73's > Greg, KI7MT 73 Bill G4WJS. |
|
From: Bill S. <g4...@cl...> - 2015-04-28 21:28:40
|
On 28/04/2015 22:12, Bill Somerville wrote: <snip> > For Windows, adding Python27 is a sensitive situation with regards to > WSPR and WSJT builds. I will need to do some testing. Will take fare bit > of time to sort that all out. > Looking at the asciidoc prequisites it says Python 2.4 and up is OK so > it may not be an issue. I haven't put any Python checks in the WSJT-X > CMake script, it just finds asciidoc and takes the view that if you have > installed asciidoc then you really ought to have a working Python around. I've just tried asciidoc on Windows with Python 2.5 and it works fine. <snip> 73 Bill G4WJS. |
|
From: KI7MT <ki...@gm...> - 2015-04-28 22:57:38
|
Hi Bill, Yes, AsciiDoc works with Python2.5 through the latest Python2 which is Python2.7.9 I believe. There won't be a Python2.8 from what I understand. However, AsciiDoc *will not* work with Python3.x., which is what WSPR and WSJT use. 73's Greg, KI7MT On 04/28/2015 03:28 PM, Bill Somerville wrote: > On 28/04/2015 22:12, Bill Somerville wrote: > > <snip> > >> For Windows, adding Python27 is a sensitive situation with regards to >> WSPR and WSJT builds. I will need to do some testing. Will take fare bit >> of time to sort that all out. >> Looking at the asciidoc prequisites it says Python 2.4 and up is OK so >> it may not be an issue. I haven't put any Python checks in the WSJT-X >> CMake script, it just finds asciidoc and takes the view that if you have >> installed asciidoc then you really ought to have a working Python around. > I've just tried asciidoc on Windows with Python 2.5 and it works fine. > > <snip> > > 73 > Bill > G4WJS. > > ------------------------------------------------------------------------------ > One dashboard for servers and applications across Physical-Virtual-Cloud > Widest out-of-the-box monitoring support with 50+ applications > Performance metrics, stats and reports that give you Actionable Insights > Deep dive visibility with transaction tracing using APM Insight. > http://ad.doubleclick.net/ddm/clk/290420510;117567292;y > _______________________________________________ > wsjt-devel mailing list > wsj...@li... > https://lists.sourceforge.net/lists/listinfo/wsjt-devel > -- ---------------------------------------------------------------- Launchpad....: https://launchpad.net/~ki7mt Ubuntu Hams..: https://launchpad.net/~ubuntu-hams-devel Debian Hams..: https://alioth.debian.org/projects/pkg-hamradio/ JTSDK........: https://sourceforge.net/projects/jtsdk/ OpenPGP......: C177 6630 7115 78FE 9A2B 9F7F 18C0 F6B7 0DA2 F991 |
|
From: Bill S. <g4...@cl...> - 2015-04-28 23:07:40
|
On 28/04/2015 23:57, KI7MT wrote: > Hi Bill, Hi Greg, > > Yes, AsciiDoc works with Python2.5 through the latest Python2 which is > Python2.7.9 I believe. There won't be a Python2.8 from what I understand. > > However, AsciiDoc *will not* work with Python3.x., which is what WSPR > and WSJT use. Ah OK. So how do you deal with that on Linux? Do you have to do an alternate Python package switch every time you move between docs and WSPR/WSJT? > > > 73's > Greg, KI7MT 73 Bill G4WJS. > > > On 04/28/2015 03:28 PM, Bill Somerville wrote: >> On 28/04/2015 22:12, Bill Somerville wrote: >> >> <snip> >> >>> For Windows, adding Python27 is a sensitive situation with regards to >>> WSPR and WSJT builds. I will need to do some testing. Will take fare bit >>> of time to sort that all out. >>> Looking at the asciidoc prequisites it says Python 2.4 and up is OK so >>> it may not be an issue. I haven't put any Python checks in the WSJT-X >>> CMake script, it just finds asciidoc and takes the view that if you have >>> installed asciidoc then you really ought to have a working Python around. >> I've just tried asciidoc on Windows with Python 2.5 and it works fine. >> >> <snip> >> >> 73 >> Bill >> G4WJS. >> >> ------------------------------------------------------------------------------ >> One dashboard for servers and applications across Physical-Virtual-Cloud >> Widest out-of-the-box monitoring support with 50+ applications >> Performance metrics, stats and reports that give you Actionable Insights >> Deep dive visibility with transaction tracing using APM Insight. >> http://ad.doubleclick.net/ddm/clk/290420510;117567292;y >> _______________________________________________ >> wsjt-devel mailing list >> wsj...@li... >> https://lists.sourceforge.net/lists/listinfo/wsjt-devel >> |
|
From: KI7MT <ki...@gm...> - 2015-04-28 23:27:54
|
Hi Bill, Linux is designed to run multiple versions of Python simultaneously. e.g. Py2 and Py3. Or at least, the Debian based Distros are. That's not the case for some others. I can't speak to how Arch, Slack, Fedora etc manage multiple Python version installs. If you call python -V on a standard Ubuntu / Debian System, you will most like get 2.7.x back as the version. If calling python3 -V, it should return 3.3.x or 3.4.x or later. Scripts requiring python3, should list it in the shebang stating as such: #!/usr/bin env python3 Most of the Debian based distros are still locked to Python2 as it's core Python, but that is changing. Ubuntu and Debian are agressively updating to Python3, but there are 1000's of package deps on Python2, so it's taking a while. Here's another issue. Some distro's do not have Python2 installed as a default package (Arch for example). So, if I were to install python3, and then type python-V .. it would render the python3 version. Needless to say, the transition from Py2 and Py3 has been messy for all OS's, not just Linux. The only way to Isolate Py2 and Py3 in Windows is through a Python Virtualenv which ensures both Python versions are not on the path, which is tricky when using the same Makefile to build both Docs and the App itself, but it can be done. 73's Greg, KI7MT On 04/28/2015 05:07 PM, Bill Somerville wrote: > On 28/04/2015 23:57, KI7MT wrote: >> Hi Bill, > Hi Greg, >> >> Yes, AsciiDoc works with Python2.5 through the latest Python2 which is >> Python2.7.9 I believe. There won't be a Python2.8 from what I understand. >> >> However, AsciiDoc *will not* work with Python3.x., which is what WSPR >> and WSJT use. > Ah OK. > > So how do you deal with that on Linux? Do you have to do an alternate > Python package switch every time you move between docs and WSPR/WSJT? >> >> >> 73's >> Greg, KI7MT > 73 > Bill > G4WJS. >> >> >> On 04/28/2015 03:28 PM, Bill Somerville wrote: >>> On 28/04/2015 22:12, Bill Somerville wrote: >>> >>> <snip> >>> >>>> For Windows, adding Python27 is a sensitive situation with regards to >>>> WSPR and WSJT builds. I will need to do some testing. Will take fare bit >>>> of time to sort that all out. >>>> Looking at the asciidoc prequisites it says Python 2.4 and up is OK so >>>> it may not be an issue. I haven't put any Python checks in the WSJT-X >>>> CMake script, it just finds asciidoc and takes the view that if you have >>>> installed asciidoc then you really ought to have a working Python around. >>> I've just tried asciidoc on Windows with Python 2.5 and it works fine. >>> >>> <snip> >>> >>> 73 >>> Bill >>> G4WJS. >>> >>> ------------------------------------------------------------------------------ >>> One dashboard for servers and applications across Physical-Virtual-Cloud >>> Widest out-of-the-box monitoring support with 50+ applications >>> Performance metrics, stats and reports that give you Actionable Insights >>> Deep dive visibility with transaction tracing using APM Insight. >>> http://ad.doubleclick.net/ddm/clk/290420510;117567292;y >>> _______________________________________________ >>> wsjt-devel mailing list >>> wsj...@li... >>> https://lists.sourceforge.net/lists/listinfo/wsjt-devel >>> > > > ------------------------------------------------------------------------------ > One dashboard for servers and applications across Physical-Virtual-Cloud > Widest out-of-the-box monitoring support with 50+ applications > Performance metrics, stats and reports that give you Actionable Insights > Deep dive visibility with transaction tracing using APM Insight. > http://ad.doubleclick.net/ddm/clk/290420510;117567292;y > _______________________________________________ > wsjt-devel mailing list > wsj...@li... > https://lists.sourceforge.net/lists/listinfo/wsjt-devel > -- ---------------------------------------------------------------- Launchpad....: https://launchpad.net/~ki7mt Ubuntu Hams..: https://launchpad.net/~ubuntu-hams-devel Debian Hams..: https://alioth.debian.org/projects/pkg-hamradio/ JTSDK........: https://sourceforge.net/projects/jtsdk/ OpenPGP......: C177 6630 7115 78FE 9A2B 9F7F 18C0 F6B7 0DA2 F991 |
|
From: Bill S. <g4...@cl...> - 2015-04-28 23:37:04
|
On 29/04/2015 00:27, KI7MT wrote:
> Hi Bill,
Hi Greg,
>
> Linux is designed to run multiple versions of Python simultaneously.
> e.g. Py2 and Py3. Or at least, the Debian based Distros are. That's not
> the case for some others. I can't speak to how Arch, Slack, Fedora etc
> manage multiple Python version installs.
>
> If you call python -V on a standard Ubuntu / Debian System, you will
> most like get 2.7.x back as the version. If calling python3 -V, it
> should return 3.3.x or 3.4.x or later. Scripts requiring python3, should
> list it in the shebang stating as such:
>
> #!/usr/bin env python3
That seems dangerous to me, all those scripts are going to die when
Python 4 replaces Python 3, sounds like the Millennium Bug all over again :(
>
> Most of the Debian based distros are still locked to Python2 as it's
> core Python, but that is changing. Ubuntu and Debian are agressively
> updating to Python3, but there are 1000's of package deps on Python2, so
> it's taking a while.
>
> Here's another issue. Some distro's do not have Python2 installed as a
> default package (Arch for example). So, if I were to install python3,
> and then type python-V .. it would render the python3 version.
>
> Needless to say, the transition from Py2 and Py3 has been messy for all
> OS's, not just Linux.
>
> The only way to Isolate Py2 and Py3 in Windows is through a Python
> Virtualenv which ensures both Python versions are not on the path, which
> is tricky when using the same Makefile to build both Docs and the App
> itself, but it can be done.
I suppose I could invoke asciidoc like:
${PYTHON_EXE} ${ASCIIDOC} ....
which would bypass the shebang/Windows file associations and allow the
location of Python to be set by the CMake finder, that way you could
steer the version of Python from CMAKE_PREFIX_PATH.
>
>
> 73's
> Greg, KI7MT
>
>
> On 04/28/2015 05:07 PM, Bill Somerville wrote:
>> On 28/04/2015 23:57, KI7MT wrote:
>>> Hi Bill,
>> Hi Greg,
>>> Yes, AsciiDoc works with Python2.5 through the latest Python2 which is
>>> Python2.7.9 I believe. There won't be a Python2.8 from what I understand.
>>>
>>> However, AsciiDoc *will not* work with Python3.x., which is what WSPR
>>> and WSJT use.
>> Ah OK.
>>
>> So how do you deal with that on Linux? Do you have to do an alternate
>> Python package switch every time you move between docs and WSPR/WSJT?
>>>
>>> 73's
>>> Greg, KI7MT
>> 73
>> Bill
>> G4WJS.
>>>
>>> On 04/28/2015 03:28 PM, Bill Somerville wrote:
>>>> On 28/04/2015 22:12, Bill Somerville wrote:
>>>>
>>>> <snip>
>>>>
>>>>> For Windows, adding Python27 is a sensitive situation with regards to
>>>>> WSPR and WSJT builds. I will need to do some testing. Will take fare bit
>>>>> of time to sort that all out.
>>>>> Looking at the asciidoc prequisites it says Python 2.4 and up is OK so
>>>>> it may not be an issue. I haven't put any Python checks in the WSJT-X
>>>>> CMake script, it just finds asciidoc and takes the view that if you have
>>>>> installed asciidoc then you really ought to have a working Python around.
>>>> I've just tried asciidoc on Windows with Python 2.5 and it works fine.
>>>>
>>>> <snip>
>>>>
>>>> 73
>>>> Bill
>>>> G4WJS.
|
|
From: KI7MT <ki...@gm...> - 2015-04-28 23:52:49
|
Hi Bill,
On 04/28/2015 05:36 PM, Bill Somerville wrote:
> On 29/04/2015 00:27, KI7MT wrote:
>> Hi Bill,
> Hi Greg,
>>
>> Linux is designed to run multiple versions of Python simultaneously.
>> e.g. Py2 and Py3. Or at least, the Debian based Distros are. That's not
>> the case for some others. I can't speak to how Arch, Slack, Fedora etc
>> manage multiple Python version installs.
>>
>> If you call python -V on a standard Ubuntu / Debian System, you will
>> most like get 2.7.x back as the version. If calling python3 -V, it
>> should return 3.3.x or 3.4.x or later. Scripts requiring python3, should
>> list it in the shebang stating as such:
>>
>> #!/usr/bin env python3
> That seems dangerous to me, all those scripts are going to die when
> Python 4 replaces Python 3, sounds like the Millennium Bug all over again :(
I don't think there's anythe worry about Python4 rolling out any time
soon :-), as in, it is years away. I've not even seen a spec for it
anywhere. Using the Shebang is the recommended way on a Multi Python system.
Python Major version changes are not like Compilers or r Qt changes,
they happen "Very Slowly", when moving from Major to Major (2 to 3 or 3
to 4).The transition from 2 to 3 has taken years and it's far from complete.
>>
>> Most of the Debian based distros are still locked to Python2 as it's
>> core Python, but that is changing. Ubuntu and Debian are agressively
>> updating to Python3, but there are 1000's of package deps on Python2, so
>> it's taking a while.
>>
>> Here's another issue. Some distro's do not have Python2 installed as a
>> default package (Arch for example). So, if I were to install python3,
>> and then type python-V .. it would render the python3 version.
>>
>> Needless to say, the transition from Py2 and Py3 has been messy for all
>> OS's, not just Linux.
>>
>> The only way to Isolate Py2 and Py3 in Windows is through a Python
>> Virtualenv which ensures both Python versions are not on the path, which
>> is tricky when using the same Makefile to build both Docs and the App
>> itself, but it can be done.
> I suppose I could invoke asciidoc like:
>
> ${PYTHON_EXE} ${ASCIIDOC} ....
>
> which would bypass the shebang/Windows file associations and allow the
> location of Python to be set by the CMake finder, that way you could
> steer the version of Python from CMAKE_PREFIX_PATH.
There is some good news here. Makefiles process things one line at a
time, and in their own shell.
So, if there is a var set for the path to python2, then $(PYTHON)
$ASCIIDOC) x,y,z should only use the Python2 interrupter. Likewise, if
the var is set to Python3, it should work for 3 only.
<snip>
73's
Greg, KI7MT
|
|
From: Bill S. <g4...@cl...> - 2015-04-29 01:02:10
|
On 29/04/2015 00:52, KI7MT wrote:
> Hi Bill,
<snip>
>
>> I suppose I could invoke asciidoc like:
>>
>> ${PYTHON_EXE} ${ASCIIDOC} ....
>>
>> which would bypass the shebang/Windows file associations and allow the
>> location of Python to be set by the CMake finder, that way you could
>> steer the version of Python from CMAKE_PREFIX_PATH.
> There is some good news here. Makefiles process things one line at a
> time, and in their own shell.
>
> So, if there is a var set for the path to python2, then $(PYTHON)
> $ASCIIDOC) x,y,z should only use the Python2 interrupter. Likewise, if
> the var is set to Python3, it should work for 3 only.
I'm not sure of the relevance of any of that?
I have changed the WSJT-X CMake script to use find_package() to locate
the Python interpreter and have made it an error if a v3 or newer one is
found. I have also executed asciidoc explicitly using the interpreter
found above. This will allow multiple Python interpreters even if the v3
is first on the PATH or associated with .py files on Windows, all you
need to do is set the correct Python directory in your CMAKE_PREFIX_PATH
if you happen to have a Python v3 on the path ahead of any earlier version.
>
>
> <snip>
>
> 73's
> Greg, KI7MT
73
Bill
G4WJS.
|
|
From: KI7MT <ki...@gm...> - 2015-04-29 01:24:33
|
Hi Bill,
On 04/28/2015 07:01 PM, Bill Somerville wrote:
> On 29/04/2015 00:52, KI7MT wrote:
>> Hi Bill,
> <snip>
>>
>>> I suppose I could invoke asciidoc like:
>>>
>>> ${PYTHON_EXE} ${ASCIIDOC} ....
>>>
>>> which would bypass the shebang/Windows file associations and allow the
>>> location of Python to be set by the CMake finder, that way you could
>>> steer the version of Python from CMAKE_PREFIX_PATH.
>> There is some good news here. Makefiles process things one line at a
>> time, and in their own shell.
>>
>> So, if there is a var set for the path to python2, then $(PYTHON)
>> $ASCIIDOC) x,y,z should only use the Python2 interrupter. Likewise, if
>> the var is set to Python3, it should work for 3 only.
> I'm not sure of the relevance of any of that?
See Below.
>
> I have changed the WSJT-X CMake script to use find_package() to locate
> the Python interpreter and have made it an error if a v3 or newer one is
> found. I have also executed asciidoc explicitly using the interpreter
> found above. This will allow multiple Python interpreters even if the v3
> is first on the PATH or associated with .py files on Windows, all you
> need to do is set the correct Python directory in your CMAKE_PREFIX_PATH
> if you happen to have a Python v3 on the path ahead of any earlier version.
The problem is not with WSJT-X or any of the Qt based, apps, it's with
WSPR and WSJT where python3 is required to be in the path in order to
build all the targets.
Additionally, can we build the docs without building the app? That would
most helpful when writing the docs.?
>>
>>
>> <snip>
>>
>> 73's
>> Greg, KI7MT
> 73
> Bill
> G4WJS.
|
|
From: Bill S. <g4...@cl...> - 2015-04-29 01:37:42
|
On 29/04/2015 02:24, KI7MT wrote:
> Hi Bill,
Hi Greg,
>
> On 04/28/2015 07:01 PM, Bill Somerville wrote:
>> On 29/04/2015 00:52, KI7MT wrote:
>>> Hi Bill,
>> <snip>
>>>> I suppose I could invoke asciidoc like:
>>>>
>>>> ${PYTHON_EXE} ${ASCIIDOC} ....
>>>>
>>>> which would bypass the shebang/Windows file associations and allow the
>>>> location of Python to be set by the CMake finder, that way you could
>>>> steer the version of Python from CMAKE_PREFIX_PATH.
>>> There is some good news here. Makefiles process things one line at a
>>> time, and in their own shell.
>>>
>>> So, if there is a var set for the path to python2, then $(PYTHON)
>>> $ASCIIDOC) x,y,z should only use the Python2 interrupter. Likewise, if
>>> the var is set to Python3, it should work for 3 only.
>> I'm not sure of the relevance of any of that?
> See Below.
>
>> I have changed the WSJT-X CMake script to use find_package() to locate
>> the Python interpreter and have made it an error if a v3 or newer one is
>> found. I have also executed asciidoc explicitly using the interpreter
>> found above. This will allow multiple Python interpreters even if the v3
>> is first on the PATH or associated with .py files on Windows, all you
>> need to do is set the correct Python directory in your CMAKE_PREFIX_PATH
>> if you happen to have a Python v3 on the path ahead of any earlier version.
> The problem is not with WSJT-X or any of the Qt based, apps, it's with
> WSPR and WSJT where python3 is required to be in the path in order to
> build all the targets.
OK, so that is what I have dealt with. If you have Python 3 as your
default Python interpreter on any system, just install Python 2.x and
don't add it to the PATH, put its location in CMAKE_PREFIX_PATH in your
CMake toolchain file and you are good to go with WSJT-X.
>
> Additionally, can we build the docs without building the app? That would
> most helpful when writing the docs.?
Of course! Just build the 'docs' target. The CMake script knows if a
file is changed and rebuilds accordingly. The doc/CMakeLists.txt has to
be maintained with new/deleted source files just as per C/C++/Fortran
files. Unfortunately CMake doesn't have an include scanner for asciidoc
so it doesn't detect included file changes automatically like it does
with program source files so they have to be maintained in the script.
cmake --build <build-tree> --target docs
I have also put in an asciidoc config file to set up stuff like the
version number as attributes so that the documents follow the versions
without having to edit them. Also the final document is installed with a
version specific name so the copies on the server can all coexist, the
program gets the correct URL embedded automatically. Should make
releases much simpler and deals with the documentation versioning
problem that was discussed recently.
73
Bill
G4WJS.
|
|
From: KI7MT <ki...@gm...> - 2015-04-29 01:47:30
|
Hi Bill,
On 04/28/2015 07:37 PM, Bill Somerville wrote:
> On 29/04/2015 02:24, KI7MT wrote:
>> Hi Bill,
> Hi Greg,
>>
>> On 04/28/2015 07:01 PM, Bill Somerville wrote:
>>> On 29/04/2015 00:52, KI7MT wrote:
>>>> Hi Bill,
>>> <snip>
>>>>> I suppose I could invoke asciidoc like:
>>>>>
>>>>> ${PYTHON_EXE} ${ASCIIDOC} ....
>>>>>
>>>>> which would bypass the shebang/Windows file associations and allow the
>>>>> location of Python to be set by the CMake finder, that way you could
>>>>> steer the version of Python from CMAKE_PREFIX_PATH.
>>>> There is some good news here. Makefiles process things one line at a
>>>> time, and in their own shell.
>>>>
>>>> So, if there is a var set for the path to python2, then $(PYTHON)
>>>> $ASCIIDOC) x,y,z should only use the Python2 interrupter. Likewise, if
>>>> the var is set to Python3, it should work for 3 only.
>>> I'm not sure of the relevance of any of that?
>> See Below.
>>
>>> I have changed the WSJT-X CMake script to use find_package() to locate
>>> the Python interpreter and have made it an error if a v3 or newer one is
>>> found. I have also executed asciidoc explicitly using the interpreter
>>> found above. This will allow multiple Python interpreters even if the v3
>>> is first on the PATH or associated with .py files on Windows, all you
>>> need to do is set the correct Python directory in your CMAKE_PREFIX_PATH
>>> if you happen to have a Python v3 on the path ahead of any earlier version.
>> The problem is not with WSJT-X or any of the Qt based, apps, it's with
>> WSPR and WSJT where python3 is required to be in the path in order to
>> build all the targets.
> OK, so that is what I have dealt with. If you have Python 3 as your
> default Python interpreter on any system, just install Python 2.x and
> don't add it to the PATH, put its location in CMAKE_PREFIX_PATH in your
> CMake toolchain file and you are good to go with WSJT-X.
WSPR and WSJT don't use Cmake, they use Autotools (Makefile) :-) .. I
think I can add a separate Makefile in the docs dir and call it from
the parent. That is the part that needs testing.
Unless you converting WSPR and WSJT over to building with Cmake?
>>
>> Additionally, can we build the docs without building the app? That would
>> most helpful when writing the docs.?
> Of course! Just build the 'docs' target. The CMake script knows if a
> file is changed and rebuilds accordingly. The doc/CMakeLists.txt has to
> be maintained with new/deleted source files just as per C/C++/Fortran
> files. Unfortunately CMake doesn't have an include scanner for asciidoc
> so it doesn't detect included file changes automatically like it does
> with program source files so they have to be maintained in the script.
>
> cmake --build <build-tree> --target docs
Ok, that's easy enough.
> I have also put in an asciidoc config file to set up stuff like the
> version number as attributes so that the documents follow the versions
> without having to edit them. Also the final document is installed with a
> version specific name so the copies on the server can all coexist, the
> program gets the correct URL embedded automatically. Should make
> releases much simpler and deals with the documentation versioning
> problem that was discussed recently.
>
> 73
> Bill
> G4WJS.
>
|
|
From: Neil Z. <ne...@te...> - 2015-04-29 13:05:57
|
On 04/28/15 07:52 pm, KI7MT wrote: > > #!/usr/bin env python3 >> That seems dangerous to me, all those scripts are going to die when >> Python 4 replaces Python 3, sounds like the Millennium Bug all over again :( > I don't think there's anythe worry about Python4 rolling out any time > soon :-), as in, it is years away. > Hmmmm ..... having been involved with the changed needed for COBOL programs in the period 1995-2000, I can honestly say that "it is years away" was the opinion of many a system designer/architect/programmer in the 70's - 80's - early 90's. Guess its the old 'history repeats itself' axiom proven again. ;) Cheers, Neil Z KN3ILZ |
Thanks for helping keep SourceForge clean.
X