On 17/12/2015 14:42, Joe Taylor wrote: > On a related matter: have you given up your effort aimed at compiling > the decoders into wsjt-x, as opposed to a separate jt9 process? You > may have noticed that the "fast" modes -- JTMSK, ISCAT, and Fast JT9 > -- are decoded in WSJT-X itself, with a separate thread started with a > QtConcurrent::run() call. My hangup in bringing the jt9[.exe] stuff > into WSJT-X has been that it would need a way to send decoding > results, as obtained, back to the GUI thread. I haven't spent the > time to work out how to (in effect) send Qt "signals" from the Fortran > code. Hi Joe,
I have not given up, it is on my work stack but several layers deep. I need to revisit it as it is a constant source of frustration! The callback for decodes is fairly easy. Fortran supports function pointers so a callback point can call a passed in function pointer with predetermined arguments. The target of the function pointer can be either a C function or a Fortran function so we can slot the same decoder into WSJT-X or into a standalone Fortran test framework equally easily. If we want decodes to become Qt signals, which is probably desirable at some point but not essential, then the C callback function can emit the signal with a little bit of extra scaffolding to recover the QOject pointer of the object that should send the signal. I have a lot of this coded but I need to consider if there are any OpenMP implications (there surely are). The parallel decoding work was what interrupted the direct decoder calling work. Working with the wsjtx/jt9 interface is sharply reminding me how much this need doing. 73 Bill G4WJS. ------------------------------------------------------------------------------ _______________________________________________ wsjt-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/wsjt-devel
