Figured it out, thanks!!
-Original Message-
From: KI7MT
Sent: Wednesday, July 01, 2015 2:09 PM
To: wsjt-devel@lists.sourceforge.net
Subject: Re: [wsjt-devel] Doc checkout and generation
Hi Bill/ND0B,
There are several things in play here. First, documentation builds are
in a state of tr
Greg,
Thank you for the helpful reply. I have found the doc files in WSJT but
the build file does not seem to reference them. I as assuming I did
something wrong when I installed the development environment and am
backtracking to see what that might be.
Much Appreciated!
73 de Bill ND0B
Hi Joe,
With colored lines I simply refer to F2 (settings) "Colors" tab,that
with the flag "Show DXCC entity and worked before status" change
background color on CQ, new DXCC etc.
I won the prize for the worst explanation!
Testing r5651 the problem is changed and depend on last saved status.
I
Hi Bill,
> On Jul 1, 2015, at 8:39 AM, Bill Somerville wrote:
>
> On 01/07/2015 14:25, Steven Franke wrote:
>> Bill, Joe, Michael, and all,
> Hi Steve,
>> Do we know what change caused the larger stack requirement?
>> Yes, I caused this problem by being lazy when I added the arrays used for
>> s
OK..so I've set up an alias to mingw32-make now plus added the
/c/JTSDK/mingw32/bin to the PATH.
All working fine now.
Thanks
73
Mike W9MDB
-Original Message-
From: KI7MT [mailto:ki7m...@gmail.com]
Sent: Wednesday, July 01, 2015 1:51 PM
To: wsjt-devel@lists.sourceforge.net
Subject: Re:
Hi Bill/ND0B,
There are several things in play here. First, documentation builds are
in a state of transition, from JTSDK-DOC to In-Application builds.
WSJT-X was the first to convert over to In-App building of documentation.
Since then, I've updated WSJT ( Windows only ) and WSPR ( Windows and
L
I use
build-wsjt
Richard m0clz
From: Bill Ockert - ND0B
Sent: Wednesday, July 01, 2015 6:21 PM
To: WSJT Developers
Subject: [wsjt-devel] Doc checkout and generation
Good afternoon,
I am attempting to update the WSJT documentation to include my recent changes
to ISCAT and am running into issu
Hi Mike, Bill,
From within JTSDK-MSYS, he should not be using make.exe as that is
attached to MSYS. Unless an alias has been setup, one should use
mingw32-make, and if the %PATH% is setup properly, that should pull the
Qt5 Toolchain elements, AR, LD, etc.
This is why I do the check at the beginn
On 01/07/2015 19:25, Michael Black wrote:
Hi Mike,
Well I've duplicated this problem on two different computers.
gcc for example is in the Makefile – but ar is not – and there is no
path to the MinGW tools by default. All the paths come from the
Makefile or from the build scripts.
OK, but
Hi Mike, Bill,
Nothing has changed in the hamlib3 build script for the Tool-Chain. The
only thing that has changes is the SRC and Build location, which is now
in: /c/JTSDK/src/hamlib3 as opposed to /c/JTSDK/msys/%USERNAME%/.. .. ..
This was to eliminate issues surrounding compound user names ( tho
Well I've duplicated this problem on two different computers.
gcc for example is in the Makefile - but ar is not - and there is no path to
the MinGW tools by default. All the paths come from the Makefile or from
the build scripts.
Have you tested JTSDK-MSYS with doing a simple "make" in the b
Hi Sandro,
On 7/1/2015 12:56 PM, Alessandro Gorobey wrote:
> There is double windows modes and single windows mode.
> Actually WSPR and ECHO have only one windows.
> The other modes are double windows.
I believe I have fixed this problem in r5651.
>> As the function of colored lines is very nice
On 01/07/2015 18:02, Michael Black wrote:
Hi Mike,
Apparently all the paths are fixed in build-hamlib3 – that's what I've
been doing here the last few days.
Been a while since I had to compile hamlib and it appears something
got changed in JTSDK-MSYS as I was used to playing with a g4wjs-ha
Good afternoon,
I am attempting to update the WSJT documentation to include my recent changes
to ISCAT and am running into issues...
As per the developers guide I did a windows install and then an update for
developers using
svn co https://us...@svn.code.sf.net/p/wsjt/wsjt/branches/doc replac
Apparently all the paths are fixed in build-hamlib3 - that's what I've been
doing here the last few days.
Been a while since I had to compile hamlib and it appears something got
changed in JTSDK-MSYS as I was used to playing with a g4wjs-hamlib in my
home directory that used to work just fine but
Hi All,
I found the some problem also with selecting "Echo" mode
OK, I cannot do moon echo with my hardware, but the program can be tamed.
There is double windows modes and single windows mode.
Actually WSPR and ECHO have only one windows.
The other modes are double windows.
I try to reason on
On 01/07/2015 17:45, Michael Black wrote:
Hi Mike,
That works too adding /C/JTSDK/mingw32/bin to the PATH.
Agreed, but it begs the question "How did you (or configure) select the
compiler & linker before?"
73
Mike W9MDB
73
Bill
G4WJS.
*From:*Bill Somerville [mailto:g4...@classdesign.co
That works too adding /C/JTSDK/mingw32/bin to the PATH.
73
Mike W9MDB
From: Bill Somerville [mailto:g4...@classdesign.com]
Sent: Wednesday, July 01, 2015 11:36 AM
To: wsjt-devel@lists.sourceforge.net
Subject: Re: [wsjt-devel] building hamblib
On 01/07/2015 17:32, Michael Black wrote:
Hi
Works fine for "build hamlib3". But that takes way too long.
But trying to build hamlib from with a make in hamlib3/build and ar is not
in the path.
CC newcat.lo
CCLD libhamlib-yaesu.la
../libtool: line 1115: ar: command not found
Makefile:382: recipe for target `libhamlib-ya
On 01/07/2015 17:32, Michael Black wrote:
Hi Mike,
Works fine for "build hamlib3". But that takes way too long.
But trying to build hamlib from with a make in hamlib3/build and ar is
not in the path.
CC newcat.lo
CCLD libhamlib-yaesu.la
../libtool: line 1115: ar: command no
Goodmorning Bill,
Using the JTS-QT environment I did build-wsjtx rinstall and successfully
completed r5647 which is behaving just fine. I can only suspect the diff since
r5644 and r5647 has resolved my issue. Thanks for the response.
Bob Kalkwarf w7wo
> On Jul 1, 2015, at 3:19 AM, Bill Somerv
On 01/07/2015 16:57, f5djl wrote:
Hello Bill and all team
Bonjour Jean-Louis,
While I am working on the Hamlib / FT991 issue with Michael I got
caught too by the wsprd issue .
1/ 5644 :error message in wsjtx at decode time starting or running wsprd
2/ Dos command wsprd without parameter
Hello Bill and all team
While I am working on the Hamlib / FT991 issue with Michael I got caught too by
the wsprd issue .
1/ 5644 :error message in wsjtx at decode time starting or running wsprd
2/ Dos command wsprd without parameter : just the usage ok
3/ Dos command but trying
On 01/07/2015 14:25, Steven Franke wrote:
> Bill, Joe, Michael, and all,
Hi Steve,
> Do we know what change caused the larger stack requirement?
> Yes, I caused this problem by being lazy when I added the arrays used for
> signal subtraction. I’m at work this morning, but will be able to look at
Bill, Joe, Michael, and all,
> On Jul 1, 2015, at 8:02 AM, Bill Somerville wrote:
>
> On 01/07/2015 13:54, Joe Taylor wrote:
>> Hi Steve, Bill, and all,
> Hi Joe,
>>
>> On 6/30/2015 6:18 PM, Steven Franke wrote:
>>> For those testing wspr mode in wsjt-x ver 1.6, I’ve just committed r5644
>>> wh
There are several easy fixes
500k here:
float buffer[2*65536];
>2M here
double refi[45000],refq[45000];
double ci[45000],cq[45000],cfi[45000],cfq[45000];
>400k here
char hashtab[32768][13];
73
Mike W9MDB
-Original Message-
From: Bill Somerville [mailto:g4...@
On 01/07/2015 13:54, Joe Taylor wrote:
> Hi Steve, Bill, and all,
Hi Joe,
>
> On 6/30/2015 6:18 PM, Steven Franke wrote:
>> For those testing wspr mode in wsjt-x ver 1.6, I’ve just committed r5644
>> which makes decoder #5 from Joe’s table, below, the default decoder in
>> wsjt-x ver 1.6. It is no
Hi Steve, Bill, and all,
On 6/30/2015 6:18 PM, Steven Franke wrote:
> For those testing wspr mode in wsjt-x ver 1.6, I’ve just committed r5644
> which makes decoder #5 from Joe’s table, below, the default decoder in
> wsjt-x ver 1.6. It is no longer necessary to separately compile
> wsprd_exp to g
On 01/07/2015 06:16, Robert Kalkwarf wrote:
> Steve,
Hi Bob,
>
> Win7 32 bit
>
> I get an Error running or starting c:/WSJT/wsjtx/bin/wsprd
That looks like you have installed using an installer generated by the
package build option. Have a look in the installed folder and see if
wsprd.exe is ther
29 matches
Mail list logo
