response 69 of 115:

Feb 2 22:06 UTC 2005

Suspend doesn't work right.  I tried it while using vi to edit a response
started in gate.  I don't know where I ended up when I foregrounded the
process.  I just know that vi commands didn't work.  Killing the processes
(as root) didn't help, either.  I ended up killing the originating ssh
process. 

response 71 of 115:

Feb 3 04:09 UTC 2005

"link" doesn't work in ft.  I had to use picospan to link an item.

response 73 of 115:

Feb 3 04:38 UTC 2005

Picospan reported:  Got error 13 (Permission denied) in appending to item file

response 75 of 115:

Feb 3 12:26 UTC 2005

I note that FrontTalk automatically favors items.  I've not been able to
figure out exactly when/why it chooses to do so, but it seems to be related
to the use of the 'read' command to read and respond to specific items.

response 77 of 115:

Feb 3 14:57 UTC 2005

OK, pipes and redirects on command lines are another thing that I didn't
know worked in Picospan.  Though the syntax seem strange:

     br all | rev            - works fine
     br all | grep Memory    - Bad parameters near "Memory"
     br all | "grep Memory"  - works fine

By the way, both in Picospan and Fronttalk, you can also just do

     br "Memory"

In Fronttalk you can do

     br (janc)

To find all items entered by janc.

Making pipes and redirects work in Fronttalk is going to force me to revisit
the design of the command parser.  I just kludged my way around semicolons
but this is starting to look like too many kludges.

response 79 of 115:

Feb 3 15:09 UTC 2005

Here's a nice bug.  If you simultaneously enter two responses in different
windows, they all get muddled up.  I guess it's using the same buffer file.
for both.  I need to get the pid into the buffer file name.

response 81 of 115:

Feb 3 15:21 UTC 2005

"Link" doesn't work:   I wasn't able to reproduce this.  I just linked an item
from "test" to "backtalk2" with no problem.

response 83 of 115:

Feb 3 15:29 UTC 2005

Fronttalk's favor logic is the same as Backtalk's.  If you do "read
nofavfirst" it won't show favorites first.  (I guess there should be a "set
nofavfirst" option that makes this the default").

Anyway, items get favored like this:

  (1)  If you entered it (from Backtalk or Fronttalk) then the item is a
       favorite until you use the "disfavor" command on it.
  (2)  If you used the "favor" command to favor an item, then it is
       a favorite until you disfavor it.
  (3)  If you respond to an item, then it is a favorite until the next
       time you read it.

Favored items are displayed before others.

response 85 of 115:

Feb 3 15:56 UTC 2005

Re #68: John, I meant that I hadn't noticed that pipes didn't work. 
Suspecting that redirection used the same logic, I tried it & determined that
it didn't work either.

Jan, I haven't tried fixseen in ft, but it never worked right in Picospan.
It marked items as seen, but not responses.  Thus, when a new response was
entered, suddenly all the old responses began showing up.  This was an
incredible pain to deal with (and a couple of hardware sets back,
my participation files were getting garbaged almost daily).

response 87 of 115:

Feb 3 16:58 UTC 2005

Dave - what you describe is what my note says the fixseen command does in
Picospan.  I was having a hard time believing that that was actually what
Picospan did, so I hadn't fixed the "bug" in Fronttalk where it actually marks
things seen, as if you had really read them.

I think the Fronttalk behavior is actually the desirable behavior.  I can't
imagine why anyone would want the other behavior.  Maybe I should introduce
a new command that marks things "seen" (as the Fronttalk "fixseen" command
does now) and make the "fixseen" commmand in Fronttalk Picospan compatible,
marking things unseen instead.

response 89 of 115:

Feb 7 18:06 UTC 2005

I'm curious what native "ignore" facilities FT has, and how to invoke them.

response 91 of 115:

Feb 17 14:58 UTC 2005

Is it possible with Fronttalk (or any other mechanism) to programmatically
insert a response into an item?  Say, if I want to log cvs `commit' messages
in a conference?

response 93 of 115:

Feb 18 15:53 UTC 2005

No, not really.  Backtalk itself more of a programming language than a
conferencing system - it just happens to have lots of special commands that
are very useful for conferencing.  The interfaces you see, Abalone and
Pistachio and Bubblegum and Papaya and Vanilla are specific programs that run
on Backtalk.  Abalone and Pistachio are part of the core Backtalk
distribution, so their version numbers are identical to the Backtalk version
numbers, but all others are distributed separately.  The behavior of the
interface has a lot more to do with what version of the interface you are
running than on what version of Backtalk you are running.

Fronttalk is a separately distributed package.  It contains two components,
a server, written in the Backtalk Script language, and a client written in
Perl.  The behavior of Fronttalk depends on the server version and the client
version, but hardly at all on the Backtalk version or the Perl version.  Now
if you are using the client on Grex to access the server on Grex, then
typically the client and server will have the same version number.  If you
are using the client on Grex to access a server on another system, then the
version numbers will very likely differ.  There's a lot of forward and
backward compatibility built into the client, so it will work with different
server versions, but some functionality may not be available on an older
server.  Anyway, it is the version number of the fronttalk scripts on the
backtalk server that determine their behavior, not the version of the backtalk
server, so reporting the fronttalk server version number is the right thing
to do.

I just said way too much about that.