On 11/19/2010 08:17 AM, Brian Lloyd wrote:
On Fri, Nov 19, 2010 at 1:01 AM, w1hkj <[email protected]
<mailto:[email protected]>> wrote:
Leigh L. Klotz, Jr WA5ZNU wrote:
I agree this is what it is doing but it doesn't do what I had
thought it would do"
1. put a bunch of spaces in the TX buffer
2. press a macro button with <CLR2X><TX><CALL> DE <MYCALL><RX>
3. RESULT: it still sends the spaces; DESIRED RESULT: it
doesn't send the spaces.
I can see how this may be hard with the macro invocation
separate from the macro interpretation.
I'm not sure this current behavior is useful; we on the list
seem to agree on that point.
Leigh/WA5ZNU
OK Leigh etal,
I will go back and see what an be done to achieve your requested
behavior.
Dave,
There is a definite need for a macro atom that will clear the TX
buffer up to the point of that atom and then begin immediate
transmission at that point. This is analogous to the TCP 'push' and
'urgent' control bits, i.e. "read and discard everything in the buffer
up to this point and then begin processing everything after to the
application." While not used too much anymore in todays faster
networks, it was critically necessary for sending things like the
attention character (^c) over a slow path to a telnet application. I
think we can probably agree that something like this would be useful
when sending using a low-speed transport.
As we move to future systems where we are passing message and control
data over internet protocols it makes a lot of sense to see where the
application can better make use of the behaviors of the underlying
transport.
But I would also want one that just works for visually formatting my
TX and RX buffers when interleaving both TX and RX data. I think you
really are talking about two different atoms here.
--
Brian Lloyd, WB6RQN/J79BPL
3191 Western Dr.
Cameron Park, CA 95682
[email protected] <mailto:[email protected]>
+1.767.617.1365 (Dominica)
+1.931.492.6776 (USA)
(+1.931.4.WB6RQN)
_______________________________________________
fldigi-alpha mailing list
[email protected]
https://lists.berlios.de/mailman/listinfo/fldigi-alpha
This is indeed what I wanted, but if it's too hard (or too hard for now)
then I'll just take a look at the macro output space problem (unless
Dave does).
You might remember with urgent data that Berkeley implemented it
improperly in their TCP stack and instead of giving you the pointer to
the urgent data, it retrieved the single byte at that location in the
stream and handed it to you, as in "Urgent data: 42". That may be one
reason it didn't gain the use it originally was designed for, even
though other TCP stacks prior to Berkeley Unix did it correctly. The
analogy fails to some degree, though, in that the urgent data pointer is
processed on the RX side, and the cleartx is for the TX side.
Leigh/WA5ZNU
_______________________________________________
fldigi-alpha mailing list
[email protected]
https://lists.berlios.de/mailman/listinfo/fldigi-alpha
