Re: [wsjt-devel] v1.6 callsigns retrieved from hashtable
On 10/06/2015 13:19, Steven Franke wrote: Bill, Hi Steve, I noticed that callsigns retrieved from the hashtable are not being displayed in the spots window. The callsign is visible in ALL_WSPR.TXT, with the customary callsign notation, however the callsign field is blank in the spots window. That is probably due to the decodes window processing text as Qt rich text which is a subset of HTML 4. The and characters will need escaping. I will commit something shortly. Steve k9an 73 Bill G4WJS. -- ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] v1.6 callsigns retrieved from hashtable
Hi again, further update - looks like the C function nhash_() is receiving args by value but is called from Fortran which passes by reference. I will see if I can sort it out. 73 Bill G4WJS. On 10/06/2015 14:49, Bill Somerville wrote: Hi Steve probably Joe, I have a change to deal with this, I think. But when I tried to test it out by sending a WSPR Tx from a local instance of WSJT-X using the call PJ4/K1ABC and grid FK52ud the first Tx goes Ok but WSJT-X crashes with the following stack trace just as it is about to transmit the 2nd message: Program received signal SIGSEGV, Segmentation fault. 0x004979df in nhash_ (key=0x28c820, length=2642428, initval=6623596) at C:\Users\bill\src\wsjt\lib\wsprd\nhash.c:224 224 b += k[1]; (gdb) p k $1 = (const uint32_t *) 0x293ffc (gdb) bt #0 0x004979df in nhash_ (key=0x28c820, length=2642428, initval=6623596) at C:\Users\bill\src\wsjt\lib\wsprd\nhash.c:224 #1 0x0048c8d8 in hash ( string=error reading variable: Cannot access memory at address 0x28ca14, l en=9, ihash=0, _string=12) at C:\Users\bill\src\wsjt\lib\hash.f90:10 #2 0x00487be9 in wqencode (msg=..., ntype=2673464, data0=..., _msg=22) at C:\Users\bill\src\wsjt\lib\wqencode.f90:48 #3 0x0047606f in genwspr (message=..., msgsent=..., itone=..., _message=22, _msgsent=22) at C:\Users\bill\src\wsjt\lib\genwspr.f90:21 #4 0x00436c69 in MainWindow::guiUpdate (this=0x28f8c0) at C:\Users\bill\src\wsjt\mainwindow.cpp:1987 #5 0x005d8425 in QtPrivate::FunctorCallQtPrivate::IndexesList, QtPrivate::Li st, void, void (MainWindow::*)()::call(void (MainWindow::*)(), MainWindow*, v oid**) (f= (void (MainWindow::*)(MainWindow * const)) 0x4353f6 MainWindow::guiUpdate() , o=0x28f8c0, arg=0x28cf9c) at C:/Tools/Qt/5.2.1/mingw48_32/include/QtCore/qobjectdefs_impl.h:508 #6 0x005dbe76 in QtPrivate::FunctionPointervoid (MainWindow::*)()::callQtPri vate::List, void(void (MainWindow::*)(), MainWindow*, void**) (f= (void (MainWindow::*)(MainWindow * const)) 0x4353f6 MainWindow::guiUpdate() , o=0x28f8c0, arg=0x28cf9c) at C:/Tools/Qt/5.2.1/mingw48_32/include/QtCore/qobjectdefs_impl.h:527 #7 0x005d9bd3 in QtPrivate::QSlotObjectvoid (MainWindow::*)(), QtPrivate::List , void::impl(int, QtPrivate::QSlotObjectBase*, QObject*, void**, bool*) ( which=1, this_=0x18534150, r=0x28f8c0, a=0x28cf9c, ret=0x0) at C:/Tools/Qt/5.2.1/mingw48_32/include/QtCore/qobject_impl.h:149 #8 0x6ba35685 in QtPrivate::QSlotObjectBase::call (this=0x18534150, r=0x28f8c0, a=0x28cf9c) at ../../include/QtCore/../../src/corelib/kernel/qobject_impl.h:132 #9 0x6b9467c7 in QMetaObject::activate (sender=0x28fbb0, signalOffset=3, local_signal_index=0, argv=warning: (Internal error: pc 0x0 in read in psymt ab, but not in symtab.) 0x0) at kernel\qobject.cpp:3561 #10 0x6b946232 in QMetaObject::activate (sender=0x28fbb0, m=0x6bbc2f44, local_signal_index=0, argv=warning: (Internal error: pc 0x0 in read in psymt ab, but not in symtab.) 0x0) at kernel\qobject.cpp:3444 #11 0x6b99e248 in QTimer::timeout (this=0x28fbb0) at .moc\debug\moc_qtimer.cpp:189 #12 0x6b94a19c in QTimer::timerEvent (this=0x28fbb0, e=0x28d6dc) at kernel\qtimer.cpp:255 #13 0x6b940daa in QObject::event (this=0x28fbb0, e=0x28d6dc) at kernel\qobject.cpp:1128 #14 0x0c5adeb1 in QApplicationPrivate::notify_helper (this=0x15c4c1e8, receiver=0x28fbb0, e=0x28d6dc) at kernel\qapplication.cpp:3482 #15 0x0c5ab7cd in QApplication::notify (this=0x28fd34, receiver=0x28fbb0, e=0x28d6dc) at kernel\qapplication.cpp:2903 #16 0x6b91b91c in QCoreApplication::notifyInternal (this=0x28fd34, receiver=0x28fbb0, event=0x28d6dc) at kernel\qcoreapplication.cpp:881 #17 0x6b9bf427 in QCoreApplication::sendEvent (receiver=0x28fbb0, event=0x28d6dc) at ../../include/QtCore/../../src/corelib/kernel/qcoreapplication.h:232 #18 0x6b965747 in QEventDispatcherWin32Private::sendTimerEvent ( this=0x15b199d8, timerId=15) at kernel\qeventdispatcher_win.cpp:585 #19 0x6b965012 in qt_internal_proc (hwnd=0x533656 hiqsdr_set_freq+93, message=275, wp=15, lp=0) at kernel\qeventdispatcher_win.cpp:426 #20 0x74d48e71 in USER32!CallWindowProcA () from C:\windows\SysWOW64\user32.dll #21 0x74d490d1 in USER32!CallWindowProcA () from C:\windows\SysWOW64\user32.dll #22 0x74d4a66f in USER32!GetOpenClipboardWindow () from C:\windows\SysWOW64\user32.dll #23 0x74d4a6e0 in USER32!DlgDirListComboBoxW () from C:\windows\SysWOW64\user32.dll #24 0x6b9662cb in QEventDispatcherWin32::processEvents (this=0x15c4bea8, flags=...) at kernel\qeventdispatcher_win.cpp:756 #25 0x6285dbc6 in QWindowsGuiEventDispatcher::processEvents (this=0x15c4bea8, flags=...) at qwindowsguieventdispatcher.cpp:80 #26 0x6b919a20 in QEventLoop::processEvents (this=0x28f820, flags=...) at
Re: [wsjt-devel] v1.6 callsigns retrieved from hashtable
Hi Steve probably Joe, I have a change to deal with this, I think. But when I tried to test it out by sending a WSPR Tx from a local instance of WSJT-X using the call PJ4/K1ABC and grid FK52ud the first Tx goes Ok but WSJT-X crashes with the following stack trace just as it is about to transmit the 2nd message: Program received signal SIGSEGV, Segmentation fault. 0x004979df in nhash_ (key=0x28c820, length=2642428, initval=6623596) at C:\Users\bill\src\wsjt\lib\wsprd\nhash.c:224 224 b += k[1]; (gdb) p k $1 = (const uint32_t *) 0x293ffc (gdb) bt #0 0x004979df in nhash_ (key=0x28c820, length=2642428, initval=6623596) at C:\Users\bill\src\wsjt\lib\wsprd\nhash.c:224 #1 0x0048c8d8 in hash ( string=error reading variable: Cannot access memory at address 0x28ca14, l en=9, ihash=0, _string=12) at C:\Users\bill\src\wsjt\lib\hash.f90:10 #2 0x00487be9 in wqencode (msg=..., ntype=2673464, data0=..., _msg=22) at C:\Users\bill\src\wsjt\lib\wqencode.f90:48 #3 0x0047606f in genwspr (message=..., msgsent=..., itone=..., _message=22, _msgsent=22) at C:\Users\bill\src\wsjt\lib\genwspr.f90:21 #4 0x00436c69 in MainWindow::guiUpdate (this=0x28f8c0) at C:\Users\bill\src\wsjt\mainwindow.cpp:1987 #5 0x005d8425 in QtPrivate::FunctorCallQtPrivate::IndexesList, QtPrivate::Li st, void, void (MainWindow::*)()::call(void (MainWindow::*)(), MainWindow*, v oid**) (f= (void (MainWindow::*)(MainWindow * const)) 0x4353f6 MainWindow::guiUpdate() , o=0x28f8c0, arg=0x28cf9c) at C:/Tools/Qt/5.2.1/mingw48_32/include/QtCore/qobjectdefs_impl.h:508 #6 0x005dbe76 in QtPrivate::FunctionPointervoid (MainWindow::*)()::callQtPri vate::List, void(void (MainWindow::*)(), MainWindow*, void**) (f= (void (MainWindow::*)(MainWindow * const)) 0x4353f6 MainWindow::guiUpdate() , o=0x28f8c0, arg=0x28cf9c) at C:/Tools/Qt/5.2.1/mingw48_32/include/QtCore/qobjectdefs_impl.h:527 #7 0x005d9bd3 in QtPrivate::QSlotObjectvoid (MainWindow::*)(), QtPrivate::List , void::impl(int, QtPrivate::QSlotObjectBase*, QObject*, void**, bool*) ( which=1, this_=0x18534150, r=0x28f8c0, a=0x28cf9c, ret=0x0) at C:/Tools/Qt/5.2.1/mingw48_32/include/QtCore/qobject_impl.h:149 #8 0x6ba35685 in QtPrivate::QSlotObjectBase::call (this=0x18534150, r=0x28f8c0, a=0x28cf9c) at ../../include/QtCore/../../src/corelib/kernel/qobject_impl.h:132 #9 0x6b9467c7 in QMetaObject::activate (sender=0x28fbb0, signalOffset=3, local_signal_index=0, argv=warning: (Internal error: pc 0x0 in read in psymt ab, but not in symtab.) 0x0) at kernel\qobject.cpp:3561 #10 0x6b946232 in QMetaObject::activate (sender=0x28fbb0, m=0x6bbc2f44, local_signal_index=0, argv=warning: (Internal error: pc 0x0 in read in psymt ab, but not in symtab.) 0x0) at kernel\qobject.cpp:3444 #11 0x6b99e248 in QTimer::timeout (this=0x28fbb0) at .moc\debug\moc_qtimer.cpp:189 #12 0x6b94a19c in QTimer::timerEvent (this=0x28fbb0, e=0x28d6dc) at kernel\qtimer.cpp:255 #13 0x6b940daa in QObject::event (this=0x28fbb0, e=0x28d6dc) at kernel\qobject.cpp:1128 #14 0x0c5adeb1 in QApplicationPrivate::notify_helper (this=0x15c4c1e8, receiver=0x28fbb0, e=0x28d6dc) at kernel\qapplication.cpp:3482 #15 0x0c5ab7cd in QApplication::notify (this=0x28fd34, receiver=0x28fbb0, e=0x28d6dc) at kernel\qapplication.cpp:2903 #16 0x6b91b91c in QCoreApplication::notifyInternal (this=0x28fd34, receiver=0x28fbb0, event=0x28d6dc) at kernel\qcoreapplication.cpp:881 #17 0x6b9bf427 in QCoreApplication::sendEvent (receiver=0x28fbb0, event=0x28d6dc) at ../../include/QtCore/../../src/corelib/kernel/qcoreapplication.h:232 #18 0x6b965747 in QEventDispatcherWin32Private::sendTimerEvent ( this=0x15b199d8, timerId=15) at kernel\qeventdispatcher_win.cpp:585 #19 0x6b965012 in qt_internal_proc (hwnd=0x533656 hiqsdr_set_freq+93, message=275, wp=15, lp=0) at kernel\qeventdispatcher_win.cpp:426 #20 0x74d48e71 in USER32!CallWindowProcA () from C:\windows\SysWOW64\user32.dll #21 0x74d490d1 in USER32!CallWindowProcA () from C:\windows\SysWOW64\user32.dll #22 0x74d4a66f in USER32!GetOpenClipboardWindow () from C:\windows\SysWOW64\user32.dll #23 0x74d4a6e0 in USER32!DlgDirListComboBoxW () from C:\windows\SysWOW64\user32.dll #24 0x6b9662cb in QEventDispatcherWin32::processEvents (this=0x15c4bea8, flags=...) at kernel\qeventdispatcher_win.cpp:756 #25 0x6285dbc6 in QWindowsGuiEventDispatcher::processEvents (this=0x15c4bea8, flags=...) at qwindowsguieventdispatcher.cpp:80 #26 0x6b919a20 in QEventLoop::processEvents (this=0x28f820, flags=...) at kernel\qeventloop.cpp:136 #27 0x6b919cbb in QEventLoop::exec (this=0x28f820, flags=...) at kernel\qeventloop.cpp:212 #28 0x6b91bf56 in QCoreApplication::exec () at kernel\qcoreapplication.cpp:1134 #29 0x034bb05a in QGuiApplication::exec () at kernel\qguiapplication.cpp:1332 #30 0x0c5ab187 in QApplication::exec () at kernel\qapplication.cpp:2707 #31 0x00468d8b
Re: [wsjt-devel] v1.6 callsigns retrieved from hashtable
Yes, that’s it. I think that this is my fault, though I’m not sure how it came about. If you look at nhash.c back in wsprx: uint32_t nhash_( const void *key, int *length0, uint32_t *initval0) compared to the current nhash.c in wsjtx: uint32_t nhash_( const void *key, size_t length, uint32_t initval) I am using nhash.c in wsprd.c, so if you change it to pass all arguments by reference, then wsprd_utils.c and maybe wsprd.c will need to be fixed up... Steve k9an On Jun 10, 2015, at 9:03 AM, Bill Somerville g4...@classdesign.com wrote: Hi again, further update - looks like the C function nhash_() is receiving args by value but is called from Fortran which passes by reference. I will see if I can sort it out. 73 Bill G4WJS. On 10/06/2015 14:49, Bill Somerville wrote: Hi Steve probably Joe, I have a change to deal with this, I think. But when I tried to test it out by sending a WSPR Tx from a local instance of WSJT-X using the call PJ4/K1ABC and grid FK52ud the first Tx goes Ok but WSJT-X crashes with the following stack trace just as it is about to transmit the 2nd message: Program received signal SIGSEGV, Segmentation fault. 0x004979df in nhash_ (key=0x28c820, length=2642428, initval=6623596) at C:\Users\bill\src\wsjt\lib\wsprd\nhash.c:224 224 b += k[1]; (gdb) p k $1 = (const uint32_t *) 0x293ffc (gdb) bt #0 0x004979df in nhash_ (key=0x28c820, length=2642428, initval=6623596) at C:\Users\bill\src\wsjt\lib\wsprd\nhash.c:224 #1 0x0048c8d8 in hash ( string=error reading variable: Cannot access memory at address 0x28ca14, l en=9, ihash=0, _string=12) at C:\Users\bill\src\wsjt\lib\hash.f90:10 #2 0x00487be9 in wqencode (msg=..., ntype=2673464, data0=..., _msg=22) at C:\Users\bill\src\wsjt\lib\wqencode.f90:48 #3 0x0047606f in genwspr (message=..., msgsent=..., itone=..., _message=22, _msgsent=22) at C:\Users\bill\src\wsjt\lib\genwspr.f90:21 #4 0x00436c69 in MainWindow::guiUpdate (this=0x28f8c0) at C:\Users\bill\src\wsjt\mainwindow.cpp:1987 #5 0x005d8425 in QtPrivate::FunctorCallQtPrivate::IndexesList, QtPrivate::Li st, void, void (MainWindow::*)()::call(void (MainWindow::*)(), MainWindow*, v oid**) (f= (void (MainWindow::*)(MainWindow * const)) 0x4353f6 MainWindow::guiUpdate() , o=0x28f8c0, arg=0x28cf9c) at C:/Tools/Qt/5.2.1/mingw48_32/include/QtCore/qobjectdefs_impl.h:508 #6 0x005dbe76 in QtPrivate::FunctionPointervoid (MainWindow::*)()::callQtPri vate::List, void(void (MainWindow::*)(), MainWindow*, void**) (f= (void (MainWindow::*)(MainWindow * const)) 0x4353f6 MainWindow::guiUpdate() , o=0x28f8c0, arg=0x28cf9c) at C:/Tools/Qt/5.2.1/mingw48_32/include/QtCore/qobjectdefs_impl.h:527 #7 0x005d9bd3 in QtPrivate::QSlotObjectvoid (MainWindow::*)(), QtPrivate::List , void::impl(int, QtPrivate::QSlotObjectBase*, QObject*, void**, bool*) ( which=1, this_=0x18534150, r=0x28f8c0, a=0x28cf9c, ret=0x0) at C:/Tools/Qt/5.2.1/mingw48_32/include/QtCore/qobject_impl.h:149 #8 0x6ba35685 in QtPrivate::QSlotObjectBase::call (this=0x18534150, r=0x28f8c0, a=0x28cf9c) at ../../include/QtCore/../../src/corelib/kernel/qobject_impl.h:132 #9 0x6b9467c7 in QMetaObject::activate (sender=0x28fbb0, signalOffset=3, local_signal_index=0, argv=warning: (Internal error: pc 0x0 in read in psymt ab, but not in symtab.) 0x0) at kernel\qobject.cpp:3561 #10 0x6b946232 in QMetaObject::activate (sender=0x28fbb0, m=0x6bbc2f44, local_signal_index=0, argv=warning: (Internal error: pc 0x0 in read in psymt ab, but not in symtab.) 0x0) at kernel\qobject.cpp:3444 #11 0x6b99e248 in QTimer::timeout (this=0x28fbb0) at .moc\debug\moc_qtimer.cpp:189 #12 0x6b94a19c in QTimer::timerEvent (this=0x28fbb0, e=0x28d6dc) at kernel\qtimer.cpp:255 #13 0x6b940daa in QObject::event (this=0x28fbb0, e=0x28d6dc) at kernel\qobject.cpp:1128 #14 0x0c5adeb1 in QApplicationPrivate::notify_helper (this=0x15c4c1e8, receiver=0x28fbb0, e=0x28d6dc) at kernel\qapplication.cpp:3482 #15 0x0c5ab7cd in QApplication::notify (this=0x28fd34, receiver=0x28fbb0, e=0x28d6dc) at kernel\qapplication.cpp:2903 #16 0x6b91b91c in QCoreApplication::notifyInternal (this=0x28fd34, receiver=0x28fbb0, event=0x28d6dc) at kernel\qcoreapplication.cpp:881 #17 0x6b9bf427 in QCoreApplication::sendEvent (receiver=0x28fbb0, event=0x28d6dc) at ../../include/QtCore/../../src/corelib/kernel/qcoreapplication.h:232 #18 0x6b965747 in QEventDispatcherWin32Private::sendTimerEvent ( this=0x15b199d8, timerId=15) at kernel\qeventdispatcher_win.cpp:585 #19 0x6b965012 in qt_internal_proc (hwnd=0x533656 hiqsdr_set_freq+93, message=275, wp=15, lp=0) at kernel\qeventdispatcher_win.cpp:426 #20 0x74d48e71 in USER32!CallWindowProcA () from C:\windows\SysWOW64\user32.dll #21 0x74d490d1 in USER32!CallWindowProcA () from C:\windows\SysWOW64\user32.dll #22 0x74d4a66f in
Re: [wsjt-devel] v1.6 callsigns retrieved from hashtable
Hi Bill, On 6/10/2015 10:03 AM, Bill Somerville wrote: Hi again, further update - looks like the C function nhash_() is receiving args by value but is called from Fortran which passes by reference. You're exactly right. Compare the nhash.c that's now in the wsjtx branch with the one in the wspr branch. Their interfaces look like this: wsjtx development branch: uint32_t nhash_( const void *key, size_t length, uint32_t initval) wspr branch: uint32_t nhash_( const void *key, int *length0, uint32_t *initval0) This function is called from both Fortran and C; we much change the calls from C so that they use the call-by-reference form for all three arguments. -- Joe -- ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] v1.6 callsigns retrieved from hashtable
On 10/06/2015 15:18, Joe Taylor wrote: Hi Bill, Hi Joe Steve, On 6/10/2015 10:03 AM, Bill Somerville wrote: Hi again, further update - looks like the C function nhash_() is receiving args by value but is called from Fortran which passes by reference. You're exactly right. Compare the nhash.c that's now in the wsjtx branch with the one in the wspr branch. Their interfaces look like this: wsjtx development branch: uint32_t nhash_( const void *key, size_t length, uint32_t initval) wspr branch: uint32_t nhash_( const void *key, int *length0, uint32_t *initval0) This function is called from both Fortran and C; we much change the calls from C so that they use the call-by-reference form for all three arguments. RRR but I prefer a simple wrapper that converts the arguments. I will post shortly, just testing my other change for the and characters. Actually my real preference is that Fortran routines that interoperate with C routines should declare an interface that sets the name binding a C and it can also declare dummy arguments as passed by VALUE if desired. Such procedures can still be called from Fortran seamlessly. Likewise Fortran routines that need to call C routines should declare an interface for the C routine, same as above applies. Not quite as neat as including a C header file although there may well tools around that automatically generate interface blocks from C headers. All so much easier that dealing with different calling conventions and symbol name mangling. -- Joe 73 Bill G4WJS. -- ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] v1.6 callsigns retrieved from hashtable
On 10/06/2015 13:19, Steven Franke wrote: Bill, Hi Steve, I noticed that callsigns retrieved from the hashtable are not being displayed in the spots window. The callsign is visible in ALL_WSPR.TXT, with the customary callsign notation, however the callsign field is blank in the spots window. While testing this I also note that we don't have a setting to allow six digit grids to be sent. Should we be adding this to WSJT-X as well? Steve k9an 73 Bill G4WJS. -- ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] v1.6 callsigns retrieved from hashtable
On 10/06/2015 16:10, Joe Taylor wrote: Hi Bill, Hi Joe, While testing this I also note that we don't have a setting to allow six digit grids to be sent. Should we be adding this to WSJT-X as well? I noticed that, too. Yes, we should do this. OK, I will have a look at that. As for the way we wrap C routines, or otherwise make them callable from Fortran: you've highlighted another way in which my quick-and-dirty approach to writing code is arguably inelegant and less than desirable, especially when many are participating. [It suited me just fine, when I was doing things more or less alone. I knew what I was doing, and why. And it was quick. :-) ] Fully understood. Quick and dirty is often best especially when prototyping new ideas. The way I look at it is from a different angle: programming is about modelling and abstraction, header files/interfaces/classes/... are just a better way of documenting the models and abstraction in the code itself rather than having to recall what you meant later when something needs to change or has gone wrong. The bonus is that others can grasp the concepts faster too and if it is done correctly the maintenance is largely done within one module at a time. By all means, feel free to make the interfaces more elegant, when and if that seems desirable. I have a few bits and pieces lying around awaiting more time to prepare and test but the issue with modern Fortran declarations is that they work so much better if modules are defined and that can be a bit disruptive and lead to regressions if it is not done carefully. An example being wqencode() calling nhash() and wsprd() calling nhash() also. The nhash() function clearly is shared by WSPR encoding and decoding but it is not generic. Underlying that is that either there should be a module for WSPR stuff i.e. encoding decoding or there should be separate modules for encoding and decoding, possibly for more than one mode. The first question I would ask is Is there more similarity between codecs for one specific mode than there is between encoding and decoding in general?. -- Joe 73 Bill G4WJS. -- ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] v1.6 callsigns retrieved from hashtable
Hi Bill, While testing this I also note that we don't have a setting to allow six digit grids to be sent. Should we be adding this to WSJT-X as well? I noticed that, too. Yes, we should do this. As for the way we wrap C routines, or otherwise make them callable from Fortran: you've highlighted another way in which my quick-and-dirty approach to writing code is arguably inelegant and less than desirable, especially when many are participating. [It suited me just fine, when I was doing things more or less alone. I knew what I was doing, and why. And it was quick. :-) ] By all means, feel free to make the interfaces more elegant, when and if that seems desirable. -- Joe -- ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] v1.6 callsigns retrieved from hashtable
Hi Bill, On Jun 10, 2015, at 9:53 AM, Bill Somerville g4...@classdesign.com wrote: On 10/06/2015 13:19, Steven Franke wrote: Bill, Hi Steve, I noticed that callsigns retrieved from the hashtable are not being displayed in the spots window. The callsign is visible in ALL_WSPR.TXT, with the customary callsign notation, however the callsign field is blank in the spots window. While testing this I also note that we don't have a setting to allow six digit grids to be sent. Should we be adding this to WSJT-X as well? I’ll defer to whatever Joe thinks - but my suggestion would be to include the option to send 6-digit locators. Steve k9an 73 Bill G4WJS. -- ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel -- ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
