|
|
| Author |
Message |
| 25 new of 115 responses total. |
gelinas
|
|
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.
|
gelinas
|
|
response 76 of 115:
|
Feb 3 12:27 UTC 2005 |
For example, this item is now favored.
|
janc
|
|
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.
|
janc
|
|
response 78 of 115:
|
Feb 3 15:01 UTC 2005 |
If your participation file gets trashed, you can do
fixseen
Fronttalk help page:
Usage: FIXSEEN <item range>
Mark all selected items as seen. All currently existing responses will
be marked seen, so they will not appear in a future "READ NEW".
For a full description of item ranges, do "HELP RANGE". Here are some
common examples:
FIX 13 - Mark item 13 seen.
FIX "blue" - Mark items with the word "blue" in their titles seen.
If you just say "FIXSEEN" the default is to mark all items if you are at
the "Ok" prompt, or just the current item if you are at the "Respond or
pass" prompt.
In addition to the flags described in "HELP RANGE" you can also give the
CONFIRM flag on the command line. Then each selected item's header will
be printed, and you will be asked if you want to mark it seen it.
I have some notes saying that it Picospan the "fixseen" command actually
marks things "unseen" not "seen". That would be goofy though. I need to
check that out some more.
|
janc
|
|
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.
|
janc
|
|
response 80 of 115:
|
Feb 3 15:15 UTC 2005 |
Suspending when you have fronttalk running gate running vi isn't working
right. Not sure exactly what is going on there. Behavior varied. On all
three trials the suspend worked fine, but when I resumed, I got both the
vi screen and gate's ">" prompt. This happened both in Fronttalk and
Picospan, so I guess it means this is a OpenBSD/gate bug, not a Fronttalk
bug. Which probably also means it should get higher priority.
|
janc
|
|
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.
|
janc
|
|
response 82 of 115:
|
Feb 3 15:23 UTC 2005 |
Hmmm...if you try simultaneous item entry in Picospan, it does the
Saved old edit buffer /a/j/a/janc/.cfdir/cf.buffer as /a/j/a/janc/cbf.gC6080
thing. This is better than mixing up the buffers, but why not just use and
edit buffer name with the PID in it in the first place?
|
janc
|
|
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.
|
janc
|
|
response 84 of 115:
|
Feb 3 15:30 UTC 2005 |
Boy, everytime I think I'm getting close to the end with Fronttalk....
|
davel
|
|
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).
|
gelinas
|
|
response 86 of 115:
|
Feb 3 16:00 UTC 2005 |
(3) explains the behaviour I'm seeing with "favor." I can live with it.
|
janc
|
|
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.
|
gelinas
|
|
response 88 of 115:
|
Feb 3 18:43 UTC 2005 |
I find 'unseen' useful for slowly catching up on a conference. I don't think
I would like having items I've actually read subsequently marked "unseen,"
though. Had I known that Picospan's "fixseen" marked things as "unseen"
instead of "read," I might have used it more often.
|
remmers
|
|
response 89 of 115:
|
Feb 7 18:06 UTC 2005 |
I'm curious what native "ignore" facilities FT has, and how to invoke them.
|
remmers
|
|
response 90 of 115:
|
Feb 8 16:35 UTC 2005 |
The "brandnew" argument to the "browse" command doesn't work in FT.
For example (using minimal abbreviations), "b bra" should display a list
of all brand new items.
|
cross
|
|
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?
|
naftee
|
|
response 92 of 115:
|
Feb 17 18:09 UTC 2005 |
This is a bit confusing:
FrontTalk 0.9.1
Copyright 2001-2005, Jan Wolter
Connected to Grex server (version 0.9.1 - direct)
Should it not be the Backtalk version that's displayed ? wouldn't that be more
meaningful ?
|
janc
|
|
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.
|
janc
|
|
response 94 of 115:
|
Feb 18 16:01 UTC 2005 |
There are a couple tools on Grex that are handy for accessing conferences
from scripts.
extract - prints out ranges of resposnes from any item
forget - forgets an item in a conerence
partname - prints participation file name for a conference
findconf - prints full pathname for a conference
These are mostly derived from the bbsread source, a long ago predecessor to
Backtalk. However, there is no post command. Jeff Poskanzer wrote a similar
set of commands, including a post command, for the Well long ago.
The easiest way to implement a post program would be as a Fronttalk client.
I should really do a set of little Perl programs with interfaces similar to
the ones above, that use the Fronttalk library functions to make fronttalk
requests to do simple operations like these. Probably not high on my priority
list right now though.
|
cross
|
|
response 95 of 115:
|
Feb 18 17:39 UTC 2005 |
Hmm, it would be nice to have the grexsoft commit messages logged into
BBS. Currently, I'm using the log_accum.pl and commit_prep.pl scripts
that the FreeBSD people use to send myself emails with commit messages;
it'd be nice to wrap that into BBS as well.
|
naftee
|
|
response 96 of 115:
|
Feb 18 20:32 UTC 2005 |
re 93 Thank you, that was interesting. I think it's sad when people say they
wrote too much :(
|
cross
|
|
response 97 of 115:
|
Feb 21 01:25 UTC 2005 |
Hmm, is there a way to get fronttalk to set the process title to something
more meaningful than, ``/usr/bin/perl /usr/local/bin/ft'' ? A perl
equivalent to secroctitle() or something?
|
cross
|
|
response 98 of 115:
|
Feb 21 15:16 UTC 2005 |
Regarding #46; Well, I specifically meant things like exceptions
to what `set supersane' does and things of that nature (see your
#43). I'd prefer that, moving forward, we go with behavior that
makes the most sense logically, even if that strays from what
picospan does when what picospan does is *illogical*. Building in
backwards compatibility for stupid behavior seems like misplaced
effort to me.
By the way, whate sites still actually use picospan? The Well is
the only one I'm aware of. Might it make sense to make them aware
of the fronttalk/backtalk combination? I haven't heard of many
bugs in fronttalk recently; it would seem we've gotten to the point
of semi-stability in that many of the requests we see now are
requests for additionally functionality of things that have long
been on individuals' picospan wishlists. Should we then try to
make the switch of the `bbs' symlink in /usr/local/bin to point to
fronttalk, installing a `picospan' symlink to /usr/local/bin for
those who encounter bugs or wish to run the older software?
|
cross
|
|
response 99 of 115:
|
Feb 27 08:48 UTC 2005 |
Regarding #94, #95; I figured out enough of fronttalk to write a
minimal `post' command for logging CVS commit messages into the
BBS. I've hooked it into the log_accum.pl stuff I'm using for the
grexsoft CVS repository; see item 9 in the garage group for an
example. Note that this is in addition to email.
This is all actually pretty easy and cool; the FreeBSD people did
a reasonable job of modularizing everything such that log_accum.pl
and commit_prep.pl use a configuration file to figure out where to
send their output. I wrote a simple shell script that acts as a
wrapper around sendmail to capture log_accum.pl's output and then
(a) email it to the address, `cvs-grexsoft' here on grex, and (b)
post it into item 9 in garage. I then changed the configuration
file such that log_accum.pl invokes my shell script instead of
sendmail.
The intention is that cvs-grexsoft should be a list of people
interested in getting these things via email, while others can read
them via BBS.
I'm fairly pleased with the result.
|